Hall of Bright Carvings

Most websites nowadays incorporate some kind of community aspect that allows users to provide feedback to the site’s owners and to each other. In fact, ‘building community’ is one of the most important aspects of any modern website. Websites that focus on their community or group nature are described as being social sites, an umbrella term that can cover a great number of disparate services. This article will describe how Developers can utilise social design patterns on a site in order to promote or dull certain behaviours in an online community.

So What is Social Media?

Social Media is a fancy term to describe how people have been using the internet since its inception. Before the web, social media was BBS (Bulletin Board Systems) and multiplayer text based games. More recently the rise of site aggregators such as digg, reddit and metafilter or social aggregators such as facebook, linkedin or myspace are more well known, the social principles behind these sites however, are as old as networked computers. Social Media is community – it’s individuals coming together to share their interests and to engage as people.

So What are Design Patterns?

Design Patterns are common principles that developers use as shorthand to describe a technique they intend to use to solve a given problem. They are a shared terminology that describe an optimal solution to a commonly encountered problem.

How do they fit together?

When developing a site that is supposed to encourage a sense of community it is important to recognise what kind of community you’re trying to encourage. People using your site will end up doing things that you never expected so using design patterns will allow you to nudge your users towards certain types of behaviour that you wish to promote.

This is best illustrated by an example.
Consider a forum designed for people who are interested in talking about carpentry. The topic itself isn’t really important; it could be anyone of the millions of social forums or systems that are designed to encourage community interaction over a specific topic. When the forum is first created it may quickly fill with people who are excited and enthused to find likeminded people, many conversations start covering thousands of aspects of carpentry and related topics. Time progresses and posts grow more detailed, broad topics are narrowed into specific subjects. People begin to recognise distinct individuals; personalities emerge and direct conversations in their own ways. Topics that previously had created debate and interest have now been discussed over and over, people begin to grow disillusioned with the cyclical nature of the conversations they are having, conversations that have little or nothing to do with carpentry become the predominant topics. New users feel lost and confused at the lack of carpentry discussions and when they try to start new topics about dovetails and joins are shouted down by older users who are tired of the same conversation happening again and again, pointing to various past discussions the new user can find the information they want. The community begins to disintegrate into factions of users, splintering between old and new, carpentry purists and people more interested in maintaining the personable conversations between people, and often, between administrators and users. People begin to leave and a once vibrant online community fades away, not with a bang, but with a whimper, a few remaining souls lingering until the system administrator finally turns the power off on the servers.

The number of online communities that have experienced that life-death cycle is beyond counting. It has occurred since the internet’s inception, it’s been occurring for so long and so often that it’s possible to see the similarities inherent in every one of them – to map the patterns and to track the changes that work to make sure that the self-destruction doesn’t occur. Navigating this user-cycle can be a delicate game, but it is possible to implement patterns that give a social site the best possible chance to survive.

How do we implement Patterns that work?

The first step to implementing patterns that work, and through them, a community that will survive long term use, is to determine what kind of community you wish to encourage. Certain kinds of patterns will help promote certain kinds of behaviour. Patterns such as ‘Reputation’ can help foster a sense of competition between users, which can be beneficial, but can also be detrimental if you’re not attempting to cultivate a competitive spirit. Likewise, providing users with a advanced options to create unique and personalised identities with a ‘Profile’ pattern can result in improved user engagement and personal investment, but can also lead to users being more concerned with their personal identities on the site than producing content for consumption. Being aware of how different patterns influence behaviour allows developers to implement the right solution to reach the right result for you and your users.

Purpose: The nature of the internet is that not everyone will receive JavaScript in the way intended. Therefore JavaScript should be applied in a way that enhances the page, rather than requiring it.

Use un-obtrusive JavaScript
Type: Maintenance, robustness, accessibility
The three pillars of web development are:

• Content and structure: HTML         <h1>Main heading</h1>
• Presentation: CSS             h1 {color: black}
• Behaviour: JavaScript         getElementsByTagName(“h1”)

The only required part of that triumvirate is HTML, which has the content and controls. Both CSS and JavaScript should in essence be enhancements.

An ‘unobtrusive’ script will:

• Not make assumptions about what methods browsers support.
• Check that the correct HTML is there to act upon, otherwise do nothing.
• Keep the functionality independent of the input device.
• Keep the scope of the script self contained.

For example, to create a show/hide area with this HTML:
<div id=”container”>
<h2>Heading</h2>
<p>Some text…</p>
</p>

The script could hide the text, wrap the heading content in a link, and attach an event to that link that shows the paragraph below.

If the script does not function, the text is shown. Just about any situation can be dealt with in this way, by planning for the scripts from the start, but implementing them at the end (i.e. building the back-end functionality as though there was no JavaScript available).

Once the back-end functionality is in place, layering on the behaviour (front-end scripts) can greatly enhance pages without requiring JavaScript. With this technique in place, you can also provide a mechanism to turn-off scripts where they are causing difficulties for people with partial JavaScript support.

Further reading:
http://dev.opera.com/articles/view/the-seven-rules-of-unobtrusive-javascrip/

Use standard HTML controls
Type: Accessibility, robustness
It must be possible for assistive technologies to identify the name, role, state and properties of all user interface components such as form elements, links and components generated by scripts. The easiest way to achieve this is to use standard HTML controls for web user interface components.

Accessibility guideline: WCAG 2 – 4.1.2

Use a library for complex scripts and cross-browser event-handling
Type: Robustness, maintenance
A JavaScript library will not take away the need for cross-browser testing, however, it will considerably reduce the time required to make a script cross-browser compatible. For short scripts with limited functionality a library is not needed, this requirement is aimed at sites with more extensive JavaScript functionality.

The exact library used is at the discretion of the developer, but it should support unobtrusive JavaScript.
Libraries can impact the download speed of a web site, however following these practices should minimise that impact:

• Make scripts external files, therefore cacheable.
• Put the scripts at the bottom of the HTML page, so that the page loads before the script.
• Minify the scripts (the library probably has a minified version already). http://crockford.com/javascript/jsmin
• Set the server to use Gzip for HTML/CSS/JavaScript files (not image or binary files).
• Use a library that is either small, or does not require a large initial download. (I.e. some libraries only call the components needed.)

Do not use onchange for navigation
Type: Accessibility
Using “onfocus” or “onchange” events to open a new page can cause a lot of confusion, so do not initiate a change of page or a pop-up with those events. This means that a menu using a select drop-down should have a ‘go’ button.

Accessibility guideline: WCAG 2 – 3.2.1, 3.2.2

Do not enforce timing in pages
Type: Accessibility
Given the different ways that people use pages, it is impossible to tell how long someone will take to get to a particular part of the page. Therefore any time limit set on a page will be too long for some people, and too short for others.

It is difficult to provide very specific guidance, but the principle is that there should be no time limits unless:

• The user can turn off the limit.
• The user can adjust the limit over a wide range.
• The user is given at least 20 seconds to extend the time limit with a simple action.
• The limit is needed for a real time event, such as an auction.
• The limit is greater than 20 hours.

For HTML and JavaScript, it can help to:

• Prevent session time outs: Provide a checkbox at the beginning of long forms that allow the user to specify a longer session time limit, or no limit with a logout link instead.
• Give the user control over scripts with time limits: Allow the user to turn off a time limit, set it at up to 10 times the original time, or to pause the time limit.

Accessibility guideline: WCAG 2 – 2.2.1

Avoid movement, blinking or updating pages
Purpose: Prevent distracting people with cognitive disabilities.
Movement in pages can be very distracting for many people, but particularly for people with learning difficulties, or conditions such as Dyslexia. Continuous movement can be distracting to the point that it becomes impossible for some people to carry out the task they have come to the website to accomplish.

Animation, moving areas of the page, or even video should not start automatically and continue playing for longer than a few seconds without giving the user a method of stopping them. An exception is made for loading indicators where there is limited interaction and it might appear to be broken if it were not included.

Accessibility guideline: WCAG 2 – 2.2.2

Do not use more than 3 flashes a second
Type: Accessibility
Flashes in pages may also cause seizures in people with photosensitive epilepsy. Seizures can be triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (such as strobe lights).

For any area of flashing or blinking content, it should not be:

• More than 341 x 256 pixels (approximately 10% of a 1024 x 768 pixel screen), or
• Flashing more than 3 times per second.

Accessibility guideline: WCAG 2 – 2.3.1

Clearly display errors in form entry
Type: Accessibility, Usability
If client-side (JavaScript) validation is used, it should include a pop-up saying which fields had errors, and an error indicator in each label which had an error. Ideally, when the pop-up is dismissed the focus would be put just above the top error message.

WCAG 2 – 3.3.1, 3.3.3
Ensure inserted code is valid
Type: Accessibility
When HTML is added to a page through JavaScript, the resulting HTML should be valid. This can be tested with the “View rendered source” feature in browsers such as Firefox.

Accessibility guideline: WCAG 2 – 4.1.1
Ensure AJAX (partial page updates) is accessible
Type: Accessibility
When part of a page is updated, people using screen readers or screen magnifiers may not be aware that something has changed.

The first issue is that screen readers often use a cached copy of the page, and unless that is updated the user may not have the updated area. This can be solved by adding this script, and calling the function after an update:
http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

The second issue is that, even when available, the person may not know about the updated area of the page.

Making sure that someone using a screen reader knows of an update is tricky. Currently, you can only use content (including a hidden statement to refresh the page after making a change), or allow people to select an option where updates cause JavaScript pop-ups, or an option to turn off scripts.
To make sure people using a screen magnifier can tell something has updated, it is good practice to make it apparent that something is happening where they clicked, as their view follows the mouse very closely.
Use ARIA for custom applications
Type: Accessibility
If custom elements are used, there needs to be a mechanism in the code that identifies what that element is supposed to do. For example, if a custom button is created that shows when it is pressed, then access technology needs know about the name, role, state, properties, and values of that button.

In both HTML and Flash, the default controls already support this, but if non-standard controls are being used, this has to be taken into account.

If there is not an option to ‘turn off scripts’, then the Accessible Rich Internet Applications (ARIA) specification should be used: http://www.w3.org/WAI/intro/aria.php

ARIA provides methods to make the JavaScript and AJAX widgets work with access technologies.

ARIA works by simply adding attributes to HTML elements. For example, you could define a ‘tree’ menu with:
<ul role=”tree” tabindex=”0″ >
<li role=”treeitem”>First item</li>
[…]
</ul>

The role defines what type of control it is, the tabindex is used to allow keyboard navigation.
There are various roles defined in the spec that should cover most situations, such as menu, toolbar, slider, tooltip, tree etc.

When using ARIA the tabindex attribute can be used, and is used to add or remove things from the tab order. An un-ordered list cannot normally be focused on when using a keyboard, but adding tabindex=”0” will mean that you can, and in the normal order. Using a value of -1 (or less) will allow you to remove things from the tab order, and this can be done dynamically with JavaScript.

You can also say when something has a ‘state’, such as checked, expanded, and selected. For things that are not links or traditional form controls, this will be vital to match the visual representation.

Using the ARIA attributes, updates to the content can be announced through the ‘live’ attribute. This can be off, polite, assertive, or rude.  For example, the following section of HTML would have its updates announced:
<div id=”myLiveRegion1″ aria-live=”assertive”>
[updating content]
</div>

The screen reader software can then decide how to deal with the update, announcing a polite update when the user stops what they are doing, or interrupting them with a rude announcement.

NB: Use of ARIA attributes does make the HTML invalid (until HTML5 becomes supported), but it is recommended for the purpose of making a scripted interface accessible.

Accessibility guideline: WCAG 2 – 4.1.2

Here’s an interesting flowchart from the United States Airforce on how to approach social media taking an interest in your organisation.

A debug stylesheet I threw together to try and give a few basic rules for helping to debug css issues.

@charset "utf-8";

@media all {
/**
*  DEBUG RULES: For easy debugging. Just stick id="debug" in the  tag
*  and then the debugging classes you want to turn on. Options are:
*  class="colours"     [Makes each div a seperate vibrant colour]
*  class="names"       [Prints the ids at the begining of each div with black font on a white
*                      background as well as displays the class name of every element on the page
*                      on a blackground with white font]
*  class="border"      [Turns on coloured borders depending the hierachy of each element on the page]
*  class="margin-off"  [Turns off all margins]
*  class="padding-off" [Turns off all padding]
*  Combinations of these classes can also be used (ie: body id="debug" class="border names padding-off")
*/
#debug.colours #container {
    background: grey;
}
#debug.colours #header {
    background: green;
}
#debug.colours #main {
    background: yellow;
}
#debug.colours #sideNav {
    background: blue;
}
#debug.colours #content {
    background: purple;
}
#debug.colours #sideBar {
    background: pink;
}
#debug.colours #footer {
    background: orange;
}
#debug.names div::before {
    content: attr(id);
    background-color: white;
    color: black;
}
#debug.names * [class]::before {
    content: attr(class);
    background-color: black;
    color: white;
}
#debug.border * { outline: 2px dotted red }
#debug.border * * { outline: 2px dotted green }
#debug.border * * * { outline: 2px dotted orange }
#debug.border * * * * { outline: 2px dotted blue }
#debug.border * * * * * { outline: 1px solid red }
#debug.border * * * * * * { outline: 1px solid green }
#debug.border * * * * * * * { outline: 1px solid orange }
#debug.border * * * * * * * * { outline: 1px solid blue }

#debug.margin-off * {
    margin: 0;
}
#debug.padding-off * {
    padding: 0;
}
/**
*  End Debug rules.
*/
} /* @media rule; end of */

I’ve been spending a bit of spare time contributing to the designing Social Interfaces Wiki, which I’m really intrigued by. I’m a strong believer that selecting certain usability patterns for a site will direct the type of user personality that you’re likely to get and I’m very much interested to see if anyone has any answers to the swathe of problems that can overwhelm an online community.

This is kind of where the ARIA stuff gets a bit more confusing. Landscape and widget roles are kind of common sense for the most part. The states and properties however can be pretty damn specific and it’s actually quite difficult to gat clear information on how best to use them. The W3 best practices does its best, but personally I find W3 documentation incredibly boring to wade through.

Until the spec moves beyond work draft however, it’s probably not in anyones best interests to try and capture massive amounts of information that’s liable to change dramatically. The W3 Supported States and Properties is probably the best source for information at the moment.

As simultaneously upset and excited as I am by the HTML5 spec, one thing I’m very happy about it how easy it is to set up a base HTML page now.

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">

    </head>
    <body>

    </body>
</html>
    

(See also: Mark Pilgrim’s post on this)

Basically there are two ‘types’ of roles. ‘Landmark’ which allow assistive technology to provide context to a user, and what can generally be thought of as ‘widget’ roles, which help users of Assistive Technology (AT) navigate and utilise more specialised parts of a web page such as menu listings, tab navigation or alert popups.

The following is a list of WAI-ARIA landmark roles.

• application A region declared as a web application, as opposed to a web document. On a practical level this tells AT to stay in ‘focus’ mode which works a little differently to its standard mode.
• banner A region that contains the primary heading or web site title.
• complementary A supporting section of the document that remains meaningful even when separated from the main content.
• contentinfo Metadata that applies to the parent document.
• main The main content of a document.
• navigation A collection of navigational elements (usually links) for navigating the document or related documents.
• search The search tool of a web document.

There’s a bit of overlap between some of the landmark roles and HTML5, but don’t worry about it. The Assistive Tech guys apparently haven’t even come to the table to discuss HTML5 yet but they are actively implementing landmark roles and providing users ways of navigating them so even if you’re using HTML5 now it’s probably a good idea to add the ARIA roles to them as well.

Landmark roles can be added straight to the HTML markup without any problems, in fact in a lot of cases the browser doesn’t even need to understand them (IE6-7 for example don’t have a clue about ARIA) as several AT readers are capable of using them anyway. (JAWS10 for example will provide landscape navigation in IE6 if the roles are available).

Widget roles are different though and should really only be added by javascript:

node.setAttribute("role", "value");

This is because you’re usually adding widget roles because you want to perform some kind of extra functionality and it would be confusing to an AT user if they encountered a block of markup assigned a certain role that didn’t function as expected because they had javascript off.

The following is a list of WAI-ARIA widget roles.

• alert A message with important, and usually time-sensitive, information. Also see alertdialog and status.
• alertdialog A type of dialog that contains an alert message, where initial focus goes to the dialog or an element within it. Also see alert and dialog.
• article A section of a page consisting of an independent part of a document, page, or site.
• button An input that allows for user-triggered actions when clicked or pressed.
• checkbox An checkable input that has three possible values: true, false, or mixed.
• columnheader A cell containing header information for a column.
• combobox A presentation of a select; usually similar to a textbox where users can type ahead to select an option, or type to enter arbitrary text as a new item in the list.
• composite (abstract role) A widget that may contain navigable descendants or owned children.
• definition A definition of a term or concept.
• dialog A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response. Also see alertdialog.
• directory A list of references to members of a group, such as a static table of contents.
• document A region containing related information that is declared as document content, as opposed to a web application.
• grid A grid contains cells of tabular data arranged in rows and columns, like a table.
• gridcell A cell in a grid or treegrid.
• group A set of user interface objects which would not be included in a page summary or table of contents by an assistive technology.
• heading A heading for a section of the page.
• img A container for a collection of elements that form an image.
• input (abstract role) A generic type of widget that allows user input.
• landmark (abstract role) A region of the page intended as a navigational landmark.
• link An interactive reference to an internal or external resource.
• list A group of non-interactive list items.
• listbox A widget that allows the user to select one or more items from a list of choices.
• listitem A single item in a list, listbox, or directory.
• log A type of live region where new information is added in meaningful order and old information may disappear. Also see marquee.
• marquee A type of live region where non-essential information changes frequently. Also see log.
• math An element that represents a mathematical expression.
• menu A type of widget that offers a list of choices to the user.
• menubar A presentation of menu that usually remains visible and is usually presented horizontally.
• menuitem An option in a group of choices contained by a menu or menubar.
• menuitemcheckbox A checkable menuitem that has three possible values: true, false, or mixed.
• menuitemradio A checkable menuitem in a group of menuitemradio roles, only one of which can be checked at a time.
• note A section whose content is parenthetic or ancillary to the main content of the resource.
• option A selectable item in a select list.
• presentation An element whose role is presentational and does not need to be mapped to the accessibility API.
• progressbar An element that displays the progress status for tasks that take a long time.
• radio A checkable input in a group of radio roles, only one of which can be checked at a time.
• radiogroup A group of radio buttons.
• range (abstract role) An input representing a range of values that can be set by the user.
• region A large perceivable section of a web page or document, that the author feels should be included in a summary of page features.
• roletype (abstract role) The base role from which all other roles in this taxonomy inherit.
• row A row of cells in a grid.
• rowheader A cell containing header information for a row in a grid.
• section (abstract role) A renderable structural containment unit in a document or application.
• sectionhead (abstract role) A structure that labels or summarizes the topic of its related section.
• select (abstract role) A form widget that allows the user to make selections from a set of choices.
• separator A divider that separates and distinguishes sections of content or groups of menuitems.
• slider A user input where the user selects a value from within a given range.
• spinbutton A form of range that expects a user to select from amongst discrete choices.
• status A container whose content is advisory information for the user but is not important enough to justify an alert. Also see alert.
• structure (abstract role) A document structural element.
• tab A header for a tabpanel.
• tablist A list of tab elements, which are references to tabpanel elements.
• tabpanel A container for the resources associated with a tab.
• textbox Input that allows free-form text as their value.
• timer A numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point.
• toolbar A collection of commonly used function buttons represented in compact visual form.
• tooltip A contextual popup that displays a description for an element in a mouse hover or keyboard focused state. Supplement to the normal tooltip processing of the user agent.
• tree A type of list that may contain sub-level nested groups that can be collapsed and expanded.
• treegrid A grid whose rows can be expanded and collapsed in the same manner as for a tree.
• treeitem An option item of a tree. This is an element within a tree that may be expanded or collapsed if it contains a sub-level group of treeitems.
• widget (abstract role) An interactive component of a graphical user interface (GUI).
• window (abstract role) A browser or application window.

The ‘presentation’ role is a pretty interesting one as it basically allows for extra markup to be ignored by AT. For example consider the following markup:

<ul role="menu">
	<li>< a href="page1" role="menuitem">Home</li>
	<li>< a href="page2" role="menuitem">News</li>
	<li>< a href="page3" role="menuitem">About us</li>
	<li>< a href="page4" role="menuitem">Contact us</li>
</ul>

The li’s are between the menu container and its associated menu items which means AT wont know to group those items together. Changing the markup to:

<ul role="menu">
	<li role="presentation">< a href="page1" role="menuitem">Home</li>
	<li role="presentation">< a href="page2" role="menuitem">News</li>
	<li role="presentation">< a href="page3" role="menuitem">About us</li>
	<li role="presentation">< a href="page4" role="menuitem">Contact us</li>
</ul>

tells the AT to ignore the li’s which then allows the AT to find and group approriate menus and their items.

Wireframing and prototyping are increasingly important steps in the
development process, they allow you to clearly and definitively establish the requirements for a project before anyone has invested too much into it. They provide clients and developers with a clear and well defined road map of what the project will deliver and what a user can expect when it comes to using the resulting site. In this article we’ll take a look at some of the more common ways Information Architects create wireframes as well as a way for web developers to develop practical, effective and relevant wireframes and prototypes using the skills they use every day.

Traditionally, wireframing sits between gathering client requirements and design. It allows clients, developers and designers to all be clear as to the site structure, page structure and, to a certain extent, the functionality involved in developing the project. Wireframes can be anything from complex prototypes through to a few sketches on the back of  napkin.

Imagine a client who wants to develop a site called ‘Document World’. A place where authors and editors can upload  documents, share resources and collaborate with each other to edit their documents. The client wants the site to be  community driven and simple for non-technically minded people to use. We spend some time chatting with the client,  taking notes and gathering the various requirements and elements she would like to see on the site.

Once we’ve documented these requirements and different elements we can start producing wireframes that will help  the client confirm that we’ve understood what they want.

We can use any number of tools to produce those wireframes. Some popular choices, in increasing level of fidelity, are:

Pencil & Paper

There’s nothing wrong with simply sitting down with a notepad and a pencil and just sketching out a few basic ideas. It’s cheap, fast and incredibly productive.

In fact, whatever your eventual tools, your first step should always be some quick paper diagrams. They will help to get your thoughts into a coherent shape quickly and effectively.

Pencil

A firefox addon that allows for development of quick and easy wireframes that are a step up from pen and paper. For very simple sites this addon is an excellent tool.

Visio, Omnigraffle, InDesign, DIA

Traditional wireframing tools for windows or mac. These are excellent tools for developing standard wireframes, but tend to lack the features that allow for the development of functional prototypes.

Once an industry standard, there is a growing trend away from these tools as wireframes lose ground to prototypes and the need for increasing complexity to take into account user interactions and states.

Axure RP, iRise, Balsamiq Mockups

Prototyping tools that can replicate some very complex interactivity. As usability becomes more and more refined in web projects, it’s becoming increasingly important for develoeprs and clients to get a sense of how things will work  before committing to what may be an expensive and complex development process.

Other

There’s another option, one that more and more people are starting to turn to as they look for the best way of  wireframing and prototyping elements and interactions on a website: HTML, css and javascript. It makes sense that one of the best ways of modelling behaviour is to use the languages you will be using to develop the project itself.

Implementing an HTML wireframe

To begin with an HTML wireframe we need to start with a layout. You can either use any standard css template you have that is appropriate or find one from the plethora of css support sites that provide suitable templates.

An HTML wireframe is not a website, as such browser compatability is not a high priority. Pick a single browser your  client should view the wireframes in and build to that. The focus should be on speed, the time for progressive  enhancement, accessibility and compatability comes later; during development.

What will likely slow you down initially is establishing some standard rules and templates for laying out the various page elements but if you try a few practice wireframes and keep track of elements you find you use again and again you should very rapidly generate a library of classes and rules that allow for some very complex layouts and elements
to be assembled with startling ease. Once you’ve written a single login or registration form, for example, make sure that you store the markup for it somewhere easily accessible so you can use it again in your next wireframe.

At the very least you should be developing two wireframes for a client – a homepage and a standard content page. Make sure that the standard content page has examples of every HTML element that can be styled so that when the designer gets the wireframes they will know they need to produce designs for them all. A list of HTML elements
can be found at the W3 site.
Some of them you can ignore, but you should strongly consider including any that have a visual element.

An example HTML wireframe for this project can be seen here

Once you’ve produced the appropriate wireframes for the client you can bring in the client to show them because one of the first rules to wireframing is that clients never get to see wireframes on their own. Being there to walk them through the user journeys and explain the decisions regarding why certain elements need greater weight or a certain location is a very important part of the process which can easily get confused and muddy if the client isn’t kept focused on the main responsibilities of a wireframe. The client seems happy, then they turn and say ‘I really like these, but if I could just make one or two suggestions?’

The fine line between wireframe and prototype

Depending on the nature of the client’s suggestions you’re almost certainly going to have to make a choice at this point. If the suggestions relate simply to the issues wireframes are responsible for clarifying; that is, weight of elements, grouping of related components, or illustrations of paths of navigation then you should be able to deal with them with a few changes or annotations. More likely however the client will want to bring in either some design or interaction issues that are not the responsibility of a wireframe. At this point you either need to help the client understand the nature of the wireframe process and concentrate only on the issues it relates to, or you need to make the decision to progress the wireframes from being static wireframes and into interactive prototypes.

There’s a fine line between wireframes and prototypes and frankly, the line is getting thinner everyday and it’s made thinner again by the very nature of HTML wireframes, but it is important to understand that there is a line between them and that they serve different purposes. A wireframe is a static tool while a prototype is a much more open-ended and interactive exploration of how certain functionality and elements are supposed to work.

Let’s pretend that the changes the client is asking for consist of the following

• “In the right column it would be nice if the ‘Recent Editors Comments’
  was above ‘Your Recent Documents’ to give it more weight.”
• “Can we have the ‘Documents, Comments, Resources’ sections in the
  right column work like an accordion with the ‘Editors Recent Comments’
  open as default?”
• “How does the page look when the user is logged out?”

Part 2 of this HTML wireframing tutorial can be found here