Story problems.

July 16, 2009 10:08 AM

Web Designers! Tell Me Of The Dragons You Hath Slain!

We all remember the fun we had with this question. As was suggested to me in that thread, I have been spending as much of my time as possible learning on my own. (Concentration has been mostly on Web Design) Unfortunately, the countless books, articles, and blogs I've read are not completely complimentary to my learning style.

Of course I'm gaining knowledge and skills with these, but I'm looking to sharpen this particular sword as quickly as humanly possible. And for me, that mean hearing anecdotes, stories, and real world challenges from people who live within this realm every day. I understand and process information most effectively when it is wrapped in a pretty little narrative. (Probably why I majored in English in the first go round.)

I'm looking for descriptions of problems you've encountered working in web design. If you found a solution, you can feel free to share it. Or not. Be as detailed as you like.

Also, I'd like to hear about your Eureka! moments as you were learning. What made a particular concept sink into that soft, mushy melon of yours? What was that first baffling problem you had that first day? What issue just keeps coming up and won't go away? Just vent if you like; I guarantee I will mine something out of it.

Inevitably, someone will ask for a clarification on what I mean by "web design". I understand that it is a broad and multi-faceted discipline. If you think you have what I'm looking for here, then you do. I am deferring to your experience here. Let's feel free to err on the side of this-is-probably-what-he-wants-even-if-he-doesn't-know-it.

posted by SinisterPurpose to computers & internet (10 answers total)

Over a decade ago, the first big eureka moment for me was grasping the implications of CSS and HTML as a way of describing your content rather than a janky version of page layout markup codes. The ripple effects from that were pretty huge for me.

The next "Oooooohhhh!" came when I started understanding the interaction of the browser, the web server, software like apache, and scripts that ran on the web server itself. Being able to follow the conceptual flow of a request, from the moment a user clicks on a link to the rendering of the destination page in their browser, didn't take a lot of purely technical understanding, but it gave me a much better skeleton to hang other knowledge on.

Both of these realizations boil down to the same thing: memorizing details is not as useful (especially in the short term) as understanding the conceptual pieces that make a system work, and how they interact with each other. That could just be my learning style, but in subsequent teaching and training I've seen that emphasis help many others, too.
posted by verb at 10:47 AM on July 16, 2009 [2 favorites]

Div. Width. Float. Everything after that was learning to be elegant and problem solving with those 3 little elements. Knowing the tools you use and how they can be bent is huge. Google is your buddy!
posted by GilloD at 11:08 AM on July 16, 2009 [1 favorite]

What issue just keeps coming up and won't go away?

One word: MICROSOFT.

This is from 2006, and still true today.
posted by Asparagirl at 11:48 AM on July 16, 2009 [2 favorites]

Total rookie mistake:
When I was a beginner and had to teach myself most things I spent a huge amount of time trying to figure out why the css values I set for a tags (hover, active, link) weren't rendering correctly. It turns out the order that I had them in was the problem--it's the cascading part of cascading style sheets.

Seconding Google is your buddy. 99.9% of any problems I have--others have had before me and sought solutions.
posted by Kimberly at 12:43 PM on July 16, 2009

When you have floated columns of different heights and need their container to expand to the height of the tallest column add 'overflow:auto' to the container. Until I learned that trick I was doing <br style="clear:both" /> (me and a lot of other people ;) ) after the floated columns.
posted by missmagenta at 12:49 PM on July 16, 2009 [2 favorites]

Users have minds of their own, and it can be hard to understand how they will use the system in the abstract. Watching people interact with your website will help you build a better interface, no matter how much domain knowledge and good practices you know and practice. It will help you understand the problems they are trying to solve and those that they create for themselves. You will find out what their assumptions are, and how they want to work. Are they search centric? Do they do lots of little searches, or one big destination search? Are they browsers? Are they sophisticated? Do they require complexity or simplicity? Product requirements aren't always dead-on, and your ability to smartly fine tune as you design, develop and roll out a UI will improve its success.

Examples:
I once saw user satisfaction with a web-based subscription service almost double with the change of one action word on buttons/menus. On the same project, I saw a user access a page she'd normally look up in a big printed booklet and turn to me and say, "This has always annoyed me. I need four key pieces of data to make a decision, and 3 of them are on this page, and the fourth was always in another supplemental book that came on different schedules". By moving some data fields around, we made her more productive, and started getting better feedback from other subscribers. " We ended up going back and investigating other ways we could depart from the information as organized in the books (driven by space limitations and old requirements) and take advantage of the medium. As a bonus, that action and its resulting success got us more work beyond that project.
posted by julen at 2:01 PM on July 16, 2009

Some Eureka Moments

1. When it first truly clicked that Flash is like nested Russian doll thingies, just like people said.

2. When I discovered that I could correct overlapping or repeated background image problems by leaving the path empty (background:url()).

3. Design by committee is always, always, always garbage. If you are really multi-disciplinary, by which I mean usability, tech, and design skills, then the best work you will ever produce will be the work you do solo. The only teams that exceed this rule are teams of multi-disciplinary designers or teams that are led by a single multi-disciplinary designer. If you have free time and/or freelance, then this is not so bad news. If not, it kindof sucks but you can still love your job.

4. What Asparagirl said.
posted by rahnefan at 3:01 PM on July 16, 2009

Whitespace is a beautiful thing.

If site users can't find things they need to find on your site, this is a design problem, not a user problem.

Don't fall in love with something you've designed to the point where you're sacrificing usability in order to keep something you like about your design - it's not about you.

Cosign that design-by-committee is a horrible experience. My experience has been, if you think about the site in terms of the users and try to speak as an advocate for them, it can be easier to win committee people over to your point of view. So, rather than "your idea for a pop out menu here is dumb and also ugly" you can say "site users would have a hard time navigating this, the convention is that users look for a menu on the left hand side."

But if you have to deal with design-by-committee, don't fall in love with something you design to the point that you'll lose your temper when they start messing with it.

And if you have to show a client or committee several designs, and you design two that are good and quickly whip up a third that sucks, simply to be able to show them three, DON'T DO THAT, because they will pick the third one that sucks.
posted by citron at 12:50 AM on July 17, 2009

^^^ Also, some caveats. I have done this stuff in fairly bureaucratic organizations and not in cutting-edge creative fields. There, people more talented than me get to do a lot more interesting things. But I'd still say usability is fundamental and keeping it simple is good, when you're starting out and self-taught especially.

Down the road, work on learning jQuery.

Oh and typography is very, very important. Look at Newsweek versus CNN. All the different fonts on the Newsweek site hurt my brain. Not just my eyes. My brain. I swear.
posted by citron at 12:57 AM on July 17, 2009

Thank you, Asparagirl. As to how I deal with IE, I say "f*** you" to v6, and concentrate most of my efforts on Firefox and Safari. (Aside: why the hell doesn't IE8 support CSS round corners?!)

My Eureka! moment: there's a lot, but one is more recent, and that's optimizing PNGs. I had photos as PNGs, and they were a bitch to load, until I posterized them. Cut their file sizes in half while still keeping the same picture quality. Posterization is king!

Another was the discovery of positioning. I relied a lot on float, but when I learned more about absolute and relative positioning, it really helped sort out some gnarly layout issues I had.

About citron's bit about falling in love with your design: Very true - unless it's for your own site. THEN it's about you. At least, that's how I see it. Take this with a grain of salt.

One more thing: using percent values for an img's width and height attributes. I found this out one day and it's a godsend when you're dealing with fluid layouts.
posted by curagea at 10:03 PM on July 17, 2009