Topic: General
What To Expect When You’re Expecting CSS/HTML Handoff
Picture this: You're a designer at Fancy Design Firm, charged with building out a design that another group will implement. You might never meet this group, you don't know how adept they are with buildout, and you're not entirely sure what they'll want to do with your CSS/HTML.
Even worse, maybe you're only delivering a sliver of the site, just one or two pages, and this team will need to finish out the other 90% of the markup. You'll be credited with the buildout or blamed for it, but the final results are out of your hands. What do you do?
Or, imagine that you're a client who's hired Fancy Design Firm to design the site, and you want your Stressed-Out Internal Team to develop it. You need to make sure that S.O.I.T. can correctly implement the stuff you get from F.D.F., and you even want them to expand on it, stretching the design into a full site with new styles.
The trouble? You don't know how F.D.F. codes or what to expect from them. Whatever you get from them will be final - you can't go running back every day until launch and asking them for stylesheet tweaks. You're not a CSS/HTML expert, so you're not sure you'll be able to tell what's good or not. What do you do?
A Bad Place To Be
Both parties are in a spot here: Designers are hoping their work doesn't get mangled, and clients are hoping their deliverable isn't crappy and inflexible, but neither party has a sure-fire way to get what they want.
I've been delivering buildout a lot recently, so I've been reflecting on what works best in this situation. In the interest of helping designers and clients agree on deliverables, I've written this little reference list. This is by no means a "client bill of rights," simply a set of topics clients and designers should discuss when expecting a CSS/HTML deliverable.
Continue reading "What To Expect When You’re Expecting CSS/HTML Handoff"
Making Quicker Interface Decisions With Design Patterns
A Brief Explanation of Design Patterns:
As web design matures and evolves, the collection of web design best practices grows with it. There are best practices for readability, markup, accessibility, usability, on and on and on. As designers, we look to keep our design approaches creative and fresh while at the same time knowing when not to screw with these established practices. These "practices," especially in the realm of user interface design, are often referred to as "design patterns."
A couple of the many definitions for a design pattern:
- A generally repeatable solution to a commonly occurring problem.
- An optimal solution to a common problem within a specific context.
Common user interface questions for which design patterns are well established:
- When I want to filter content on a page, what are the most usable approaches I can take?
- If I want to rotate through features, images, or news articles on a page, what are some proven solutions?
- What are the most effective ways to include error messaging in my web forms?
- What are the most common approaches to designing rating systems?
You get the idea. These, and hundreds of questions like them, have been hammered out, time-tested, and answered by many designers, developers, and ultimately, web users. They may get tweaked, and they will improve and evolve, but the most solid current solutions are well documented and readily (and visually) available for your perusing.
Solid Design Pattern Resources:
Fix It Fast: Rapid IE6 CSS Debugging
IE6: We all hate it, and we all have to work with it (well, most of us). The most frustrating phase of buildout is often the final struggle with this Browser From Hell, but maybe (just maybe) we're struggling too much. When I help friends with IE6 bugs, I'm sometimes surprised at how long they've been stuck on a single problem, or how they've painted themselves into a corner with hacks and fixes. Then I remember that I used to be like that, grinding away for hours at simple float issues, or pulling my hair out over list spacing.
Why do we have so much trouble learning to debug for IE6?
We don't know! There are a lot of bugs out there, and it takes a while before you can intuitively spot them. If we can't identify a behavior, it's easy to throw up our hands and say "Augh, it's just BROKEN!"
We don't want help! Many a designer has spent hours on a problem simply because they didn't ask for help or Google it. With a language as straightforward as CSS, you can eventually solve most problems just by blindly changing stuff (over and over), but changing stuff doesn't mean you're learning.
We're not sure how to start! Debugging is a weird process: At any point, you could come across THE SOLUTION, which would be GREAT, and it always seems like it's JUST AROUND THE CORNER. This constant bait-and-switch means that we don't settle into a solid process for debugging, which, in the end, means debugging can take much longer than it should.
So, is there a way to shortcut through some of the hair-pulling and learn good debugging right from the start? MAYBE. The following is my cycle of preventing, catching, and fixing bugs in IE6. If I could, I would email it to myself in 2004, but until I figure out how to do that, posting it here will have to do:
Stop Driving Your Developers Crazy
A few weeks ago, I had the pleasure of presenting at Refresh the Triangle with one of Viget's crazy talented web developers, David Eisinger. Our original plan was to get up there and talk about how designers and developers can collaborate effectively, but we're both pretty snarky so somewhere along the way our talk title became "10 Things Designers Do To Piss Developers Off (and vice versa)".
As we battled it out putting slides together and making long lists of things we hated about our web counterparts, I found myself becoming much more aware of my "designer quirks". A few of David's points rang especially true, much to my embarrassment. It's hard for a designer to admit they aren't perfection on a stick.
So what hit home the hardest? Well, for starters...
Design Without Pictures, A Few Audio Podcasts Favorites
Living and working in the DC area is a blessing in that there is much to see, and business in the Nation's Capital is seemingly bountiful. The curse is the commute for people (like me) who enjoy living in the burbs. I spend a minimum of 7.5 hours per week commuting to my office. That’s almost a full work day for normal people. Mind-numbing, isn’t it!? If any unexpected roadblocks occur, you can add to that figure.
That said, I don’t find a whole lot of time to do things like read blogs, even though it's probably being done by others on the road (not recommended). I do, however, try to use my commute time wisely. As I travel to work, I listen to at least one design or business podcast per day -- while sipping my first of several daily cups of coffee. Going home … that’s when I rock the tunes!
One of the things that I’ve learned is that a good audio podcast is generally anchored with an interview. News, updates, comments, and random banter can also fill the void, but it’s the interview that seems to be the necessary core component -- at least in my opinion. I’ve opted for the audio podcasts simply because I’d much rather make use of my commute time than stare at a video podcast on my laptop when I’m not driving. The temptations to multitask are just too high.
That is not to say that audio is a better format. It's just that it works better for me considering how I intake the media. There are plenty of good reasons for video podcasting, particularly when tutorials are involved. Alas, I’ve discovered several great audio podcasts related to design. Here are some of my favorites:
Continue reading "Design Without Pictures, A Few Audio Podcasts Favorites"
Ending the Great H1 Debate
Most of us have seen the website The H1 Debate where people could vote on whether the H1 should only be used as a site's logo OR used as a the main heading on a page. The point being that you could only use one H1 on a page. This inspired Josh to blog about the extremely violent disputes we have had about the subject around the office. I've always thought it was fine to use multiple H1's on a page where appropriate and sparingly. However many people, such as SEO experts, have claimed that using multiple H1's on a page is frowned upon by the search engine gods (such as Google) since it could appear you were loading your site with dirty SEO tactics thus hurting your page ranking. Today Samantha sent me an interesting video from Google software engineer Matt Cutts on the Google Webmaster Central Channel that seems to quell the debate:
In the words of Brian Talbot, "Let there be peace among the semantic masses"
Viget Flash Mob: 1” Buttons
On occasion, the designers at Viget reserve four hours out of their busy days and work feverishly to create a project that is outside of their daily web design routines. We call this excercise a "Design Flash Mob." We have a running list of ideas that we all contribute to, and everyone votes on a topic when the time aproaches. In the past, we have done desktop wallpapers and t-shirt designs. This time we tackled 1" buttons, a popular piece of flair amongst web nerds, design geeks, indie rock teeny-boppers, and your TGI Friday's waiter. Many of us turned to Stereohype for inspiration on designing for this tiny canvas.
Recent Comments
Hi Doug!
I just want to print this article :) But the print version is yet to be fully polished. I hope you guys spend sometime :) Viget inspire is a really nice resource for me....
- Lance on 'What To Expect When You're Expecting CSS/HTML Handoff'.
- Erik Wallace on 'What To Expect When You're Expecting CSS/HTML Handoff'.
- Jonathan on 'Switching Mindsets: From WordPress to ExpressionEngine'.
Subscribe to Comments RSS