Part 1 of this HTML wireframing tutorial can be found here
We’ll take these changes one at a time.
The first is an easy fix and makes sense; we can do it just by moving the markup in the page around – no problems there, this doesn’t move us outside the realm of what a standard wireframe would produce.
The second starts to bring in more functionality than we would normally be comfortable with in a wireframe. While it’s certainly possible for wireframes to visually show tabs or accordions or carousels or any number of design elements, it’s difficult for a static wireframe to accurately depict how each one of these will actually work or what content each of them will reveal.
Luckily, with HTML wireframes we have a series of tools that help us turn the static wireframes into a functional prototype that clarifies these issues with very little effort.
Adding functionality with jquery
Using any one of the standard javascript libraries allows us to quickly and easily add functionality to static wireframes that will allow the client to really get a sense of how certain design patterns you may choose to use will actually work with their content.
In this case adding the functionality is as simple as wrapping the three elements in a separate div with an id of ‘accordion’ and adding
<script src="http://jqueryui.com/latest/jquery-1.3.2.js" type="text/javascript"></script>
<script src="http://jqueryui.com/latest/ui/ui.core.js" type="text/javascript"></script>
<script src="http://jqueryui.com/latest/ui/ui.accordion.js" type="text/javascript"></script>
<script type="text/javascript"></script>
To the head of the page. See it in action here by clicking on the titles in the right section. It’s important not to get too caught up in this part, it’s likely that the client may well want quite a lot of implied javascript functionality in any modern site. You will need to keep close watch on time to make sure you don’t spend hours adding functionality for little gain – if it can’t be added quickly to the wireframes then make a note of it and move on, don’t get caught up with fiddly issues that are better dealt with during development after the wireframes have been signed off.
This procedure does, however, highlight one of the major advantages of HTML wireframing over other wireframing techniques – it clearly and accurately shows exactly how a page or element is supposed to look and function without active javascript. Developers will find it enormously advantageous to see exactly how something is supposed to work under its simplest conditions before they start adding the usability frills of javascript. It’s a wireframe version of
Progressive Enhancement.
The third issue is a bigger problem for static wireframes than the second and highlights one of the main issues regarding wireframes in general: how do you handle alterations in state? How does a user in different states impact the elements on the page? It is possible to create multiple static wireframes showing the different states, but this can quickly grow out of hand and can make it hard for clients to recognise that separate wireframes relate to the same page. It’s also confusing for developers and designers who have to search through large numbers of files to find the specific state they’re interested in.
Adding annotations or notes can also quickly grow unwieldy and confusing. This is where prototyping tools such as Axure really start to come into their own, allowing for startlingly complex prototypes to be created. Luckily HTML wireframers have their own little bag of tricks they can reach into to help solve this problem.
Adding state with polypage
The fact we’re already using jquery to add a few useful flourishes and touches to the existing wireframe means we can now reach for a slightly more complex jquery plugin called ‘polypage’. When activated polypage parses the class names of the page looking for any that begin with pp_ and create a menu consisting of the string following the pp_ in the class name.
Download polypage from its github repo.
Extract so that your wireframes can access the files and from there it’s a remarkably simple process to add the logged in/out states to the markup itself.
Adding a class of ‘pp_logged_in’ to the ‘user_nav’ ul is all we need to create a new state on the page of ‘logged in’. If we create a second ‘user_nav’ ul and populate it with the list items that a non logged in user would see then we can add a class of ‘pp_not_logged_in’ and polypage will know to display that state when the logged_in state in is not true. With this example you can see how easy it is to add more states to your page simply by adding appropriate markup and class names. Let’s say that we also want to indicate that people who are administrators get links under all the document names in the list that allow them to edit the document. Well simply add the appropriate markup, add the class ‘pp_logged_in_and_admin_or_admin’ to the element and we now have an extra state to select in the polypage menu – clicking both or just clicking admin reveals the new state related elements on the page.
Polypage accepts a certain amount of logic in establishing states.
You can use as class names:
- ‘pp_<state_name>’ to display something when that state is activated
- ‘pp_not_<state_name>’ for displaying something when that state is deactivated
- ‘pp_<state_name>_and_<state_name2>’ for displaying something
when both states are selected.
- ‘pp_<state_name>_or_<state_name2>’ for displaying something
when either one of the states is selected.
- As shown above, we can also chain those logic states together for
more complex states
(ie, ‘pp_<state_name>_and_<state_name2>_or_<state_name2>’).
Looking at the new wireframe it becomes apparent that the ‘Logout’ link when you’re logged in and the ‘Log in’ button when you’re not should both trigger state changes as well. Polypage makes this possible by adding
< a href="#pp_toggle_logged_in">
To the ‘Log out’ href add
< form action="#pp_toggle_logged_in">
</ form>
Around the ‘Log in’ fields. Take a look at the expanded example we’ve been creating here.
As you can see, polypage is an incredibly simple, powerful and useful tool for taking HTML wireframing from a basic display to an incredibly useful and detailed prototype. Developers, designers and clients all like it because it simply and clearly shows interactions that have traditionally been difficult to explain to all three domains without vastly different documentation. It supports some very advanced features and you can easily use it add notes or annotations to a wireframe to provide clients, developers and designers extra information targeted specifically to them. Its ease of use and the speed at which you can add complex states to a wireframe make the initial extra time needed to develop a wireframe in HTML worthwhile.
A few wireframe Dos and Don’ts
Do make wireframes and prototypes – they will help you clarify user journeys and the relative importance of elements
with clients. Prototypes will help everyone involved nail down functionality and states before the serious development begins.
Do not spend hours getting them looking ‘perfect’ – clients can find over designed wireframes confusing and may mistakenly focus on design elements rather than the issues wireframes are supposed to clarify.
Do share wireframes with Developers and Designers – they will be able spot potential issues that you can fix before passing them on to the client. Developers especially can find the polypage state classes indispensible when developing a functional specification.
Do not become too attached to your HTML wireframes – getting wireframes done quickly tends to produce sloppy HTML and it’s better to start again with a clean slate when it comes to the final product rather than try and reuse the markup you’ve already produced.
Do use the appropriate tool for the job – if you can get the get what you need from a few simple diagrams on some A3
paper there’s no point spending days developing complex prototypes in advanced software.
With luck this article will have planted a few seeds in your mind regarding including some kind of wirefraimg stage in your development process. The potential benefits for low outlay make it well worth it.