From a perspective of sheer design labor, the most difficult part of bringing a new Web site to life is production. At that point where the major design challenges have been resolved (what the home page and a few other key pages look like, how the site feels) and when those resolutions have been approved by the stakeholders, designers then apply that solution across all the constituent parts of the site: marketing pages, content pages, forms, search interfaces, etc. Typically, this is done with Adobe Photoshop or, recently for me, Macromedia Fireworks, in a fairly painful process of rendering “flat comps”; creating static, visually accurate representations of what the XHTML should render while also suggesting, rather awkwardly, how the interface will respond to user interactions.
Does this sound like a drag? It is, especially for sites with dozens of pages, like the ones we often do at Behavior. It’s not so much that the work itself is drudgery. It’s not; in fact, this work is the crucial evolution between concept and reality, when the design ideas put forward in early comps are expanded and embellished upon to create a fully-fledged system of interrelated parts. In production, the design becomes real. What’s a drag is how much effort it takes to build all of these flat comps; you could spend weeks trying to address all of the design problems that a site presents and iterating on those solutions continuously before even getting to the first line of XHTML. I’ve done that.
The Shortest Distance from A to C
So, I’ve been thinking a lot about ways in which to expedite the production process: methods of simplifying the labor or perhaps eliminating the need for that labor altogether. Rather than spending a lot of time and effort creating what are essentially guidelines for the final product, why not leap directly to the final product? Why not skip right to the code? In spite of its clumsiness, XHTML markup is one of the most direct forms of design execution available, and it’s just begging to be used with a sense of immediacy.
There’s a school of thought that advocates this as the leanest, most immediate way to achieve real results, and in many ways, it’s enormously attractive to me. But I’ve tried it — at least some imperfect approximation of it — and I’ve failed at it. I ran up against low-level browser incompatibilities, diverting time I should have been spending on creative problem solving towards the tweaking of CSS hacks. I’ve run up against the natural inclinations of clients to continually tweak designs and request new layouts that would fundamentally alter the markup I had thought was solidified. And I’ve run into inhibitions on my own creativity, fear of undertaking design solutions that might be too demanding of my coding skills or my time. For these reasons and more, it didn’t feel natural.
The Anal-Rententive Design Chef
Part of my failure can be laid at the feet of my fussy, nit-picky style of design — I have a tendency to pursue the placement of every last pixel until it conforms to some master plan. That master plan is continually evolving, and as cumbersome as flat comps can be, they are at least flexible in terms of continually and non-committally refining the rules of a design system. Moving too quickly to HTML would be in effect prematurely codifying those design rules; I just need lots of time to ruminate over them beforehand.
But part of it too is my own belief that, in essence, design is a process of decision by proxy, that virtually all forms of design are essentially frameworks for decision by proxy. Whether the principal design document is a mechanical, as in the pre-digital days of graphic arts layout, or blueprints, as in architecture, we are almost always creating only a representation of a product, not the product itself. We’re almost always at a certain remove, almost always laboring over interim deliverables that will be ultimately tossed aside.
But what attracted me to interaction design in the first place is the reduction of that remove, how it’s possible to have an idea and execute it in code and almost immediately arrive at the finished product. There’s no other design medium that facilitates that transition from head to hand with quite so much expediency, while also requiring so few raw materials. And with that distance narrowed so sharply, there always exists the temptation to remove the proxy altogether, to actually start molding the actual product without the blueprint. I’m not saying it can’t be done — I whole-heartedly endorse anyone who can manage it — but for me, I just need that proxy.
+
The decision to ditch the proxy depends heavily on the budget too.
For regular projects, I always go through the process of doing the comps and discussing with the client. For low budget, quick projects that need to go online ASAP, comps are too much of a PITA. I just stick to the tried and tested layout and interface designs and concentrate on the content, and add the graphical icing later on.
I move from Illustrator comps to XHTML always.
I rarely go to Photoshop/Fireworks/whatever until I have the *structure* of the finished page complete. (Well, at least almost complete, there will always be the need for revisions).
After the page structure done I move on the CSS. CSS gets the pixel precise (or liquid) working, the colors and text styles, etc going. I try not to use any [img] tags in the XHTML unless they are part of the content of the page. Any images that are “for design only” get put into backgrounds via CSS.
It makes life a lot easier to go straight to XHTML/CSS instead of tightening up the Illustrator comps in Photoshop.
My approach lets me work faster to get the site from design comps to working in a matter of hours or days — not weeks.
The designers can see things working quicker and we can discover problems and fix them. We can even make improvements to the way things are working once we see it in the browser.
A few quick tips:
1. Separate design from content as much as possible. Keep design elements in CSS and structure and content in the XHTML.
2. Use Firefox instead of Internet Explorer or Safari. It follows CSS and XHML standard more closely and other developers have great extensions for validating XHTML and CSS.
3. After everything is working in Firefox then spend the time making the CSS workarounds to get everything working in IE, Safari, etc.
It isn’t a perferct process. All of the sites I plan and develop don’t work out this way, but the better ones tend to.
I tend to go from a flat comp of the two basic pages – home and sublevel and then go straight to working out the HTML structure. I worked in an agency style company before that had a strong culture of giving the client a flat comp of *everything*. This was done with such a disregard for whether or not it was necessary, and consumed so much time I’ve vowed never to go there again.
If at some stage I find I need to develop some visual design for the current thing I’m on, *then* I’ll do a comp, but only for that thing. If the home and sublevel comps don’t explain it, then do a new one, if they do, you’re wasting your time.
I begin with a wireframe in XHTML and CSS to semtically set the templates (global navigation, location navigation, branding, etc.). From this point knowing what will fit where and setting the naming conventions for the images, css, and components of the pages. Things at this point are clickable and can be moved around easily.
At this point the visual layer can be built. The images can be sliced and placed into the CSS or into the pages. I find the visual layer time is a quicker phase and implementing from this phase is much quicker than going from visual to XTML.
This is very much a CSS Zen Garden approach. I have been working this way and training those I work with in this manner for nearly four years now. It also makes it easy to move to a content management system as the components are named in a logical manner and can be pulled out of the pages with a Perl script or two.
One interesting piece of software (from iRise) was demoed for me at work a couple weeks ago. It basically tries to solve all these problems. They give you a simple interface that you plug in your elements and then you can build multiple pages and link them together like a full site. With interaction and everything. I thought, wow this would be great for throwing things together for big wigs who just don’t follow explanations very well. The only problem, the damn software starts around $30,000 bucks. Bleh, I don’t think so…
Thomas: maybe I’m overestimating the value in giving free reign to the visual design aspect (or the visual designer) of a project, but if the XHTML is already in place before the presentation layer is added, are you consticting creativity?
Even with the tightest wireframes (and I generally prefer to receive the tightest wireframe an IA can deliver to me), there’s still so much room for interpretation. That interpretation can lead to nontrival alterations to the structure of the markup. So in this approach, are you confident that you’re getting the maximum creative effort from all aspects of the team?
Maybe I’m just overly hung up on freedom for the visual designer, but I’m genuinely surprised how many people in this thread basically say they skip over the flat comps stage. I think that’s great that they can do that. There’s probably something to be learned in it for me; I may be over-complicating things in my approach to design development. It’s certainly not the first time I’ve over-complicated something.
Khoi:
If you look at CSS Zen Garden you will find no constraining of any creative talent. The underlying page and hooks for presentation layer are set from the beginning. Having all the content objects on the page(s) initially defined greatly helps the project.
With concern to wireframes… Many wireframes mutate over time. The most important piece I have been finding has been in the content and content object discovery phase ensuring all components are captured and represented. We build templates around page types (memos, forms, large complex data tables, browsing pages, etc) and ensure the CSS has all of the possible elements that can occur on the page accounted for up front. Not every iteration of a page type will have all of the objects, but it makes it easy to drop them in.
The visual designer not only has freedom, but using this approach they have all the possible permeations of a page type in front of them.
I find many of my visual designers learned visual comps for print, where every pixel is managed. The visual designers that have come out of digital/multi-media design jump into designing in the medium (XHTML & CSS).
I ever, ever comp in XHTML/CSS, I design solely for Firefox in first place and once everything looks good, i move on to solving inconsistencies on other browsers.
Creativity is good, but usability is first so, my creative aproach is restricted to make look awesome that usable (and accesible) markup I already have. Anyway, you need major CSS skills to do something like this, comping with photoshop you could even (not should) letit generate da code.
design happy .
Thomas: I completely agree that there’s a tremendous amount of freedom in using CSS to govern the layout of pre-existing XHTML structures. I’m a huge proponent of web standards-based design, so I have no quarrel with using these tools to design whenever possible.
But I’m not sure how flexible it will be in, say, moving large content objects from one column to another in a heavily columnar design. Or how well it accomodates moving large content objects from the top of the page to the bottom. Granted, many entrants at CSS Zen Garden do just this, but how easy is it for a designer with moderate CSS talent to make such dramatic changes to the layout — and is it faster than moving around boxes in Fireworks? I have my reservations, especially with the project I’m working on now, which has 5 columns of very tightly packed information.
What’s more, will those design/code solutions scale? Won’t they impose low-level changes to the XHTML — a surfeit of unique divs and IDs that thus mar the semantics of the code? Even if that’s okay, will that code then work cleanly with content managements systems which, themselves, often come with restrictions for the semantic ordering of markup?
I’m not trying to be contrary here. I genuinely want to know if I’m just doing things the hard way. Perhaps even in my long advocacy of CSS/XHTML I’ve been too limited in my thinking of how it can benefit/facilitate the design process. School me.
With regards to drastically moving the page contents… Yes, using CSS to place content can be an extremely quick way of rearranging the page. The XHTML does not have to be touched. It will take a little bit of learning, but once the lightbulb goes off things become really easy. The learning may not be a mid-project type task, but at some point it will make life so much easier.
Large content objects… It is quite easy to move content that has a div with an id of “featcont” (short for featured content) from a center column to being a left column that spans two columns.
Converting to a CMS… Initially, I really do not worry about how the CMS displays the content. My first step is to get the content into the CMS. If I am trying to suck my content into a CMS and understand the page type it goes into I will already have that defined in the XHTML markup and will search for pages with an id for the page type I am interested in and then only pull in the infomation in the “content” section (I will also want to capture the URL – for identity purposes – and any other information specific to that page, perhaps featured links or related information.
Once the content has been sucked into the CMS I then fuss over how it will display. One of the large steps of moving to a CMS is getting the content into the system. Since our pages are already structured this step become relatively easy. It may take a couple steps as of yet I am not aware of a CMS that will allow for a direct import of structured pages.
I usually present clients with an Illustrator comp for the home page, a general interior page, and any other “special need” pages such as a contact form, shopping cart, etc.
Once I’ve gotten their approval, I go into the coding. I’ll go back into Illustrator if I come across any other “special needs” that I hadn’t accounted for, but for the most part I try to solve all design problems ahead of time because once I start with the XHTML, I’ve got a whole other set of problems to deal with.
On a couple of personal projects, I jumped right in and started coding without really kowing where I was going. They always ended up taking a lot longer than they should of. For me to get the best and quickest results, CSS/XHTML should be used for coding, not designing.
Kohi said: Even with the tightest wireframes … there’s still so much room for interpretation. That interpretation can lead to nontrival alterations to the structure of the markup. …are you confident that you’re getting the maximum creative effort from all aspects of the team?
Sure, you move from the Wireframe (IA/planning/strategy) stage to the design stage (experience modeling, etc). Design the heck out of. Work out the details — but don’t get hung up on pixel precision.
Use Illustrator or some other program where it is easier to move things around and work with large document windows. Have a few layouts going at once. Get some feedback from others in the office, your spouse, your pet, whoever is around.
Once a general design direction is made and some styles have been set. Start producing it.
If you need to work out some specifics in the design go back the design program (or a pencil and piece of paper) then back to XHTML.
I think one of the most important parts of this entire discussion is missing – where is the content currently? If it already exists on a site, it’s easy to grab pages of content, add some divs and then fiddle around with a stylesheet to see how things might work, what you like, what you don’t, etc. If you are doing something new and have a page full of lorem ipsum, without really knowing how the content works with each other, you’re more free to create content areas and really define how the various areas interact – which is Information Architecture at it’s finest. It’s just hard to really do a fully new site when what you’re really doing is a remodel of old IA.
Which becomes like buildings. Having worked in architecture for a few years, it’s amazing both the creativity and work that goes into what is really just a fixer-upper. The Cathedral in Helena, MT. is a prime example – the architects couldn’t redo the building, it’s a cathedral, it has to follow certain guidelines and much of the building itself is presented as art for the masses (pardon the pun). But when asked to guide the re-building because of damage done to it by an earthquake and just 100 years of settling in the Rocky Mountains, the architects were presented with a unique goal – rebuild something that, really, there aren’t many of in the world, and do it under budget, faster, and better than anyone else. But it must still be a cathedral. They started by loading the original blueprints into the computers (I helped, joy let me tell you) and then started making notes on the damage, marking ideas for rebuilding, destroying pieces that were too far gone, structural controls for the rework process, everything, on those old plans. They started the project using the equivalent of code-based comps.
Now, however, if they were building a new church, even for the catholics, it would not have the same constraints. More freedom, but also less security that what you’re doing is right. Hence, more comps – and usually flat, quick, clean, and discussed in meetings.
It all seems to boil down to whether you’re designing or redesigning. Designing the first time for any company, or being given the option to toss all old content (rare) means lots of comps, because lots of people will have lots of opinions and lots of time will be come lost time, but eventually, you’ll get to a point where coding makes sense. If you’re just restructuring what is already there, start with the coding, you can see ‘reality’ faster, and make changes to get to ‘working comps’ faster, and then the client works better. Just my 2б.
As for me. I just made the transition from old table on top of table design to XHTML. I find moving things around much easier in XHTML. For example, say a column width is just a shade too skinny or I need to bump everything over 20px, I just make the adjustment in the CSS and it changes ALL the pages. I also find it is much easier to move blocks of content (assuming you lay out the XHTML properly), by changing the css or the position of my div tags. Now that I know XHTML and I see how much cleaner the programming is and how much faster a site renders I don’t plan to turn back. I like the idea that you cannot have more than one ID per page, etc in XHTML it helps keep things organized and heck even ASP.NET conforms to this… Microsoft conforming wow.
Take for example the site I just completed in XHTML I can successfully say that I just completed a site that is XHTML driven and uses ZERO CSS hacks and renders perfectly on all browsers. Yes, this includes IE 5.0 for PC and IE 5.2 for a Mac. It did take me some time to get the CSS to render properly without hacks but it’s I can say it is do-able. Here is the site A Child’s Haven.
Note: If you look at the CSS, it still needs to be organized. I just finished the site. So don’t slam me on sloppiness.
My general process is this.
I sketch first and always. I find I can sketch out a lot of ideas faster than doing things on the computer. I keep them small but big enough to get the major things into detail. My sketches also act as the wireframes, I skip wireframes unless the client can’t understand my sketch. Based on the design/sketch, I’ll either move to Illustrator or Fireworks. Fireworks for a more organic theme, Illustrator for a modular theme (A Child’s Haven was done in Fireworks). I do this to get the graphical elements and then I use the slice tool to make my cuts as I construct the pages with XHTML. I do my best to keep form seperate from function.
Basically, I let fireworks give me an idea of what the page needs to look like but I wait to get detail oriented until I am coding. Why? Well, I may get into coding and find that I need to make a slice a differnt size, or something just doesn’t work in my design. So I go into Fireworks and make my adjustments to the images/slices. By the end of the project my Fireworks file may not look pretty at all for I have made little edits here and there to make things render correctly.
I’m not a big fan of going directly to XHTML because my view is that the code executes the design and not the other way around. I’m not trying to reach some “coding ideal”, but I *am* trying to reach a *communication* ideal, which comes mainly from the design and layout.
If I’m hearing you correctly, I think the advantage you see in going to XHTML quickly is the templatization of it all. Change a nav element and it’s changed across all pages instantly. If you have 20 PS or AI comps, you have to manually propagate that change out, and yes, it sucks. It sounds like what’s necessary is a symbol-based approach to design comps. This is prevalent in Flash as everything you create is a symbol and whenever you change the look of the symbol in your library, it is instantly changed wherever it may appear in your comps.
I don’t believe Photoshop has this sort of functionality, but I seem to remember Illustrator putting it in somewhere in the last few years. I’m too lazy to have investigated it, but it may be worth checking out at this point. Fireworks, I believe, might have it too. The key is for the symbol to work across multiple documents though. Not sure if this is built in or not.
I wrote a brief post you may find interesting about a way that I am doing something similar, trying to bypass or automate the production work using some open source technology. In short, I’m using a wiki to keep the content separate from the design, and customizing the wiki’s HTML export feature to produce the final product.