Wireframes in the web design world are quick sketches of the layout of the content, navigation, images, and other design material within a web page. They can also be used to map out the flow of an interaction to complete a task.
When it comes to wireframes, what is the best methodology to use?
I’ve used paper cutouts, drawings, InDesign, Omnigraffle, and Photoshop. None of the methods is better than the other, but I prefer drawings. Wireframes and prototyping are really useful for understanding the problem and coming up with quick solutions. InDesign, Omnigraffle, and Photoshop tend to be too cumbersome for the purpose. Wireframes and prototypes aren’t deliverables after all. The final product is the deliverable. It doesn’t make much sense building and nice prototype when the work on that prototype will simply be discarded in the long run.
Let me clarify a little bit, like most things in life interaction design is a iterative process. The designer draws an idea, thinks about it, modifies it, redraws it, thinks about it, and repeats. If the process is complex enough or there is a meeting with a non-technical stakeholders, then the wireframes need to be a bit more detailed. If the audience is simply a core set of technical team members, then the designs don’t need to progress pass the initial drawing stage. Once that audience grows beyond the core team, then the designs need to reflect some sense of final design at least in terms of color, buttons, links, and other easy to implement design features. The reason for this is because non-technical managers will get hung up on the design and won’t be able to focus on the real reason for the meeting. Usually the real reason for the meeting is to discuss the flow of pages, the placement of content, and the workflow needed to make the concept a reality. When the meeting gets hung up on the design, little progress is made.
Truth be told it is nearly impossible to separate content from presentation with HTML and CSS while making semantically lean markup. At least that is true if the design of the presentation is complex and unique. Designers tend to like flourishes, embellishments, and other eye candy. Treated right, this is a good thing. Our minds like high-quality, stylized content. But high-quality design will add structures in the the markup that aren’t related to the actual content. These structures or hooks, are great for adding design elements, but bad for long-term maintainability of a site.
Here is an example of a design hook that I used while making the Harris Construction web site.
<div id=“big”> <div id=“little”>div>
<div id=“rightConcrete”>div>
<div id=“topLeft”>
<div id=“topRight”>
<div id=“bottomLeft”>
<div id=“bottomRight”>
In retrospect, I could have developed this code better by using non-design specific ids. That would have been in the mindset of future reusability. Not that the hooks that I used can’t be reusable, but non-specific hooks would have been better. CSS Zen Garden uses a similar approach by adding non-semantic, empty divs much like the ones I used above. The Garden also uses ubiquitous id and class attributes to accommodate nearly every design situation that can be thought of. While this is good for the Garden’s purpose, leaner code means saved bandwidth, more maintainability, and many other thing.
What is the solution to this conundrum? Content Management Systems.
The only true way to separate content from presentation is to rely on a content management system. With a CMS, the possibilities for redesigns, media neutral delivery, and everything in between are limitless. A well-designed, flexible content management system will allow many different views of the content. This means that you can have a couple of HTML views (one for the primary design, one for printing, one for handheld devices), a PDF view, an RSS feed, and much more. Content Management Systems enable website managers to flex their designs in a cost effective manner.
Content management systems do more than just help with separating content from separation. But that is saved for a later post.
With every new web site that I create, I use a very specific directory structure for the ui. This allows the root web directory to not become over saturated with folders that do not contain actual web content. My folder structure is as follows
Essentially, I use one main folder to contain all user interface elements: cascading style sheets, images, and javascript. The css folder can contain numerous files depending on the complexity of the web site and interface. The images folders contains the images for the web site framework. This includes any images needed for the general design, icons, buttons, and any other design imagery. The images folder does not contain images as they relate to a particular page or article. Those images are handled differently depending on the complexity of the site. The js folder is used to hold all javascripts. I thought about separating them out into behaviors and other scripts, but in the end I decided not to. I don’t use a ton of javascript (yet) so I didn’t see the need for the separation.
If there are multiple designs for a project, I use the following structure:
In this case, I give design 1 and design 2 a name that refers to the design. If the design is a retro 50’s design, I use something like stylin50s. If it is an oceanscape sort of thing, I name it something like comotionontheocean. I have a little bit of fun with the names. It keeps me sane somehow.
