Dreamweaver Wireframing Extension

Basically, using Dreamweaver in a pre-Design phase -- a testable, rapid-development phase that often seems lacking.

I first came across "wireframing" in Creative Good's excellent _Holiday 2000 E-Commerce report_
http://www.creativegood.com/holiday2000/

And the need for more creative work *prior to* visual design -- referred to as Interaction Design -- was brought home to me by Alan Cooper's indispensable book _The Inmates are Running the Asylum_.
http://www.amazon.co.uk/exec/obidos/ASIN/0672316498/

I'm posting this as I haven't had the time to investigate it fully yet myself, but it seems potentially very valuable. This is not necessarily a debate, but if someone has experience with similar processes that work, or have a chance to investigate the following links, please follow up!

The exact URL referred to in the forwarded CHI-WEB post below is
http://dynamic.macromedia.com/bin/MM/exchange/extension_detail
.jsp?BV_SessionID=@@@@0395604109.0987071025@@@@&BV_EngineID=de
alkikkleidbfekchjcfjedlg.0&extOid=51463
but it may be easier to just search as recommended, rather
than trying to paste this URL together.

-----Original Message-----
From: Jenni Merrifield [mailto:]
Sent: Wednesday, April 11, 2001 6:18 PM
To:
Subject: Dreamweaver Wireframing Extension

I just wanted to send a note of THANKS to whomever it was
that directed us
to the Wireframing Extension for Dreamweaver.

I've found that it's a wonderful boon to my prototyping
development for a
number of reasons, and not just Wireframing itself. I've
also found that,
with a few modifications, it lends itself well to "lo-fi" dynamic
prototyping -- i.e. setting things up to represent a web or desktop
application that emphasizes the user /interactions/ rather
than the user
/interface/ (i.e., proposed "capabilities" vs. "look and
feel"). This has
the advantage, I find, of helping developers (and others)
understand how the
flow works while not getting all confused into thinking it is
supposed to
represent "the final design"

For anyone who hasn't checked it out yet, It can be downloaded at
<http://www.macromedia.com/exchange/dreamweaver/ Search for
'wireframing'.
Note, however, that if you're not already registered at
Macromedia site
there's a (long) form to fill in first.

Jenni

--
Jenni A.M. Merrifield : User Interaction Designer
jenni @ ncompass.com
phone: (604)633-6663 - fax: (604)633-6501
-=--=--=-
Designing to Requirements and Walking on Water is EASY . . .
. . . As long as they are both Frozen.
-=--=--=-

A subsequent, apparently unrelated, email to CHI-WEB about a new resource dedicated to the above ties in nicely with this thread. Interestingly, the Kelly Goto mentioned below is the same person who created that presentation that I linked to in my last post.

-----Original Message-----
From: Erik Larson [mailto:]
Sent: Wednesday, April 18, 2001 5:58 AM
To:
Subject: Web Site Production Management Techniques

Hello All,

I would like to announce a new resource to this list that is available on
macromedia.com. Although the subject matter is aimed first at web producers
and project managers, it necessarily touches on many of the more general
points of discussion that occupy this list. As such it is a respectable
introduction to the basic craft of information architecture. It is called
Web Site Production Management Techniques, and it is located at:

http://www.macromedia.com/resources/techniques/

We will be building this site out and refining it over time, and we are very
interested in your feedback. The site provides content examples, successful
production workflows, and an online forum at:

news://forums.macromedia.com/macromedia.web.production.management

The content is based on research surrounding product initiatives that I am
involved with at Macromedia, and is based very much on the efforts of Kelly
Goto. Please take a look and let us know what you think by posting to the
online forum. If you know any producers or project managers in search of
information or community, please point them this way as well.

Cheers,

-Erik

Erik Larson
Product Manager
Macromedia

PS We are also in search of web project deliverables that we can share with
others as part of this website and other training initiatives. I know these
are often quite sensitive, but let me know if you would be willing to share
any example documents from this list, and I will be sure to compile any
submissions for the group and pass them on:

Creative brief
Technical brief
Project site
Examples of client goals
Examples of content outline
Content delivery plan
Site map example
Screen schematics/wireframes
Example of user scenarios
Naming conventions document
Project plan (scope document/project charter)
Usability test plan
HTML style guide

"Wireframing" itself can be extremely useful in highlighting potential information architecture considerations, but has risen the following problems in my experience.

1. Who is responsible for wireframing ? As it is such an "easy" process, everyone feels they should be responsible for this.
The strategists feel that they are capable of deciding what elements should remain on each page ensuring the underlying strategy, the producer / project manager feels that they have the best grasp of the functional requirements of the site, and the designers feel that this will have a bearing on the design, and that they should ultimately be responsible.

2. The designers are right to some degree. It is very difficult to take a "wireframe" page and completely re-jig the layout. People become quite particular about where the navigation should be, where the content should lie, and how much relevance each piece of content has. This all has an effect on the designers/creatives, and will hinder their ability to work "outside of the wireframe boxes" as such.

I think with this in mind though, one should still consider "wireframing" as a very useful element in the planning and defining of an interface, as long as the issues above can be managed by including all necessary members of a team.
If good research, focus groups, planning, creative concepts, storyboarding, "wireframing", prototyping and usability testing is performed before the launch of any new product, one will certainly increase the chances of creating a successful and targeted platform.

Yes, I recognise this problem. It exposes a different problem that I see frequently: strategists, producers and designers not working together closely enough.

>1. Who is responsible for wireframing ? As it is such an
>"easy" process, everyone feels they should be
>responsible for this.
>The strategists feel that they are capable of deciding
>what elements should remain on each page ensuring the
>underlying strategy, the producer / project manager feels
>that they have the best grasp of the functional
>requirements of the site, and the designers feel that this
>will have a bearing on the design, and that they should
>ultimately be responsible.

Nevertheless, the earlier definition I posted stated "wireframing attempts to abstractly address the visual design", and in the Creative Good paper they're described as "block diagrams with the location and description of each page element." In other words, wireframes can *only* be created by a designer. It is certainly not an "easy" stage, although this may be belied by its rough appearance. But the broad skillset a designer should possess should be recognized here. At this stage we are talking about something more akin to information design (design of signage, maps, diagrams, etc.) than look&feel design, with full understanding of usability issues, with an understanding of the functional scope, always with a full understanding of the target audience's goals. This exposes another problem: too narrowly-skilled designers.

>2. The designers are right to some degree. It is very
>difficult to take a "wireframe" page and
>completely re-jig the layout.

I disagree here. This is precisely the time during which one should be prepared to "re-jig the layout", because it is so much easier at this stage than in Photoshop or HTML further down the line. For the same reason, this is also the most appropriate stage for other team members to contribute actively (which also goes towards answering your question regarding team roles), as this will only be unhelpful interference later in the creative process.

>People become quite
>particular about where the navigation should be, where the
>content should lie, and how much relevance each piece of
>content has. This all has an effect on the
>designers/creatives, and will hinder their ability to work
>"outside of the wireframe boxes" as such.

The designers should have full control over where any information will go on the page. The boxes are there for them to move. The great thing is nobody, at this stage, will get precious about elements purely for their visual treatment. The only arbiters of appropriateness at this stage is the target audience research that has been done, the communications objectives and usability best practices.

Now the remaining problems I see centre around *where* in the process this should fit.

<speculating>Storyboarding comes before wireframing, and is the appropriate stage in which to address content collation and information architecture. The less storyboards try to be like wireframes, the better. Wireframes are the penultimate stage prior to visual design, but the wireframing process can still feed back to both information architecture and content, and change them if necessary. This is the *last* stage it which that can occur, though.</speculating>

It's made a bit more problematic by the common practice of presenting look & feel at pitch stage, and winning a job on that basis. Work done at that that early should, I feel, be almost regarded as mood boards, subject to be reinterpreted entirely at the post-wireframing stage.

All,

Happy to say that we have used paper versions of wireframes to do usability testing, and it has uncovered numerous usability issues in each case.

See Jared Spool's notes at UIE for more info:
http://world.std.com/~uieweb/paperproto.htm

With regard to the point about who's responsibility it is to look after prototypes, I suppose it is too easy to say that there should be someone on the team who is looking after the HCI side of things.
In my experience, this is usually not the designer because they will tend to come from a fine arts/graphic design background, and therefore be more interested in branding and look and feel.

However, as is also noted here, project managers need to integrate *the whole team* at all points of the project. So I would recommend that the HCI person leads the early prototyping, but ensures input and ideas come from all members of the team. Then the whole team get to meet the users, and see them interacting with early versions of the product.

That's easier to type here than to actually do in real life, mind!

Cheers, d

On 22:16:04 25 April 2001 fjordaan wrote:
>It sounds as if you're still talking of something much
>closer to storyboarding. Wireframing *is* a creative
>stage, but one where the emphasis is on organisation and
>hierarchy of information, and on page function.
>
>>Remember that the goal is sign-off on an initial
>>structure only so it's best to keep it simple:
>>emphasise the elements rather than layout. Don't
>>attempt to define prioritisation and hierarchy of
>>information within the wireframes, leave that for
>>the next step when creative considerations come into
>>play.
>
>What I want to avoid is a situation I'm painfully familiar
>with: too many *decisions postponed* until the creative
>stage, which usually means Photoshop. Photoshop is a
>relatively time-consuming medium, and accommodating for
>possibilities that could've been resolved at a more fluid
>stage (i.e. wireframing) makes it a *lot* more
>ineffective.
>By the time you get to Photoshop you want to know:
>1. Where the navigation and content on the page will be
>positioned
>2. Exact wording of all menu items and other functional
>text (e.g. copyright message, disclaimer, but also things
>like button text)
>3. Into exactly what chunks of content (headings,
>subheadings, body, footer, etc.) content is subdivided
>
>I realize on point 1 above I'm likely to find much
>opposition, but leaving that out of the wireframing stage
>is to render it useless, and further confuse its proper
>place in the workstream.
>
>Finally, another note regarding the value of wireframes,
>if done properly (at least in principle, as I haven't
>tested this): It can be *tested*. It is possible to rig up
>an interactive wireframe with which meaningful usability
>testing can be performed (not necessarily of the entire
>site), at this still very fluid, early design stage. It
>could be the single greatest weakness of the Usability
>discipline that it inevitably comes too late in the
>process. To borrow an analogy from Alan Cooper, usability
>testing is like sandpaper: With sandpaper you can improve
>a table, but no amount of sanding can turn a table into a
>chair.