As Carolyn Wood said in Putting Our Hot Heads Together, web discussions can get pretty heated, with people of differening opinions behaving less like educated gentlemen having a discourse in a palor room, and more like slobbering maniacs accusing each other of acquiring a time machine so they can travel back to 1889 and spawn Adolph Hitler.
Last week, Andy Clarke reignited a discussion about abandoning static Photoshop/Fireworks proofs for dynamic markup/CSS prototypes. I weighed in with my view on the topic, as did several other people. Normally this is where the fireworks begin. However, to my pleasant surprise, overall the discussions I have seen have been healthy, rather than acrimonious. Rather than a digital firestorm, there's been a general agreement that the technique is conceptually better, but has some potential billing/business model drawbacks that people are concerned about.
Deciding that the best teacher is experience, Mindfly decided to try out my modest proposal and give the technique a whirl on one of our newest projects.
The nice thing about proposing changes to the design phase of a project is that I'm not the one that has to do it.
For some reason, perhaps my obsession with making websites that closely resemble avocados, Mindfly leaves the designs usually to more talented artists.
However, as I'm a front-end developer, I usually get involved in working on making the promises designers make into realities after clients have given the go-ahead. So if anything, changing our methodology to CSS prototypes will result in more of the foundation being laid before I get involved.
Nothing to complain about there.
Janae got saddled with the experimental procedure, creating a prototype of a client's e-commerce site rather than prepping a Photoshop proof (which has been our traditional method). It's worth noting that she made use of Photoshop for elements of creating/preparing certain images or visual elements before embedding them in the markup/CSS, but her efforts were focused on setting up the markup and CSS to show the client the prototype.
Seizing the initiative, she also made some non-critical design elements (like rounded corners) via CSS3 properties without full cross-browser support, letting those elements disappear or simplify on non-capable browsers (largely Internet Explorer). This is also a departure from our past methodology, which sometimes would result in effort-intensive or non-semantic messy solutions to provide these small enhancements for IE.
As a note, the protype wasn't built with the fully-functional e-commerce software, but rather an HTML mockup that mimics the basic markup that would be present. I think this is a key technique, using simple non-complete HTML for your design mockups to cut potential time-loss from clients wanting to radically alter things after being presented with a prototype.
The end result? On her first attempt at this technique, Janae's time on the design phase from start to client approval was about three hours more than with static visuals. I expect that with more experience this would be cut down. Furthermore, as all of the CSS and much of the markup will be retained in the final product, most (if not all) of this extra time will be absorbed by the time saved on the post-approval development phase.
I think it's too early to determine the full results of this trial run, but I'm already optimistic. One of the areas of development that I see hours being burned up is after a client sees a site for the first time since they approved a static proof, and various objections begin to roll in about how the anchors don't look the way they thought they would, or the menu behaves differently than they thought it would, or the colors don't look the same as the proof and are bad, etc.
In short, they feel upset or misguided by the differences between a static proof and the finished reality, and we end up tweaking and re-tweaking to help alleviate that disappointment.
My prediciton is that by using this technique we'll end up saving hours on the final product as a result of not having to do these tweaks (or at least many less of them). I'll post again on the topic as the project continues, and get Janae to pipe in with her advice.
I'd like to hear from other people who've either been using this sort of technique in the past or are giving it a try now. What sort of differences did you need to make to your site creation timeline? What sort of change did it cause to development time, hours gained or lost? What lessons did you learn that you'd suggest to others?
