Comments on The Guided Wireframe Narrative for Rich Internet Applications

Scott Newcomb — Fri, 26 Jan 2007 14:52:54 GMT

I think wireframes only work when the content is well-known by the client. You’re talking about RIAs. I understand “RIA” is a broad term used very loosely by many in programming and design but when you’re talking about true clientside RIAs, user experience is everything. If the client has not had the experience, you can’t wireframe it for him.

The client will look at any wireframe and imagine html. He’ll imagine every little decision requiring a page to refresh. He’ll imagine old, serverside scripting with a little javascript sprinkled on it to make it a little more tolerable.

I’ve spent many wasted hours trying to explain clientside Actionscripting to programmers, designers, businessmen IN the internet field and THEY don’t get it until they experience it.

For RIAs you must either have previous work or a demo. The simplist/quickest RIA demo will win over the most complex, well-planned wireframe.

ed.j. bowers — Fri, 26 Jan 2007 14:52:52 GMT

Back before I knew any of these concepts had labels I always tried to find the balance between getting the client to understand (and agree to) the process or functional flow and avoiding getting locked into a ‘design’ discussion. (Or the other way around when I was discussing the visuals) I started with yellow pages on the floor, index cards, blackboards. I like powerpoint because it is fast and visually close to a browser look but I have also taken a rough jpeg and used it as background of an html page with basic mapped links so that we can load it into a real browser. It all starts with understanding your audience; which I suppose can apply to everything out there.

rajat julka — Fri, 26 Jan 2007 14:52:52 GMT

This is a nice article which talks about creating wireframes instead of working HTML prototypes for the client to have a better and common understanding at the design level phase of the project.

The approach is best suitable when we are working on not very big project may be around 600-900 hours project. Bruce as you said that Sometimes it takes you a while to figure out which one is new and which ones you have already read. you can also just take the jpg’s for the design (with annotation) and import the same in flash and it will only take maximum of 8 hours to give a little interactions (you can just define click events on actual button area to call next screens)... and that can help the user to understand it better and will be more impressive way to present the UI wireframe (now interactive) to the client.

Suzanne Sheppard — Fri, 26 Jan 2007 14:52:51 GMT

I find that (I believe it’s because Microsoft bought Visio) many of the features from Visio are in PowerPoint 2003 and quite often you can get away without Visio.

kaizan kaizan — Fri, 26 Jan 2007 14:52:51 GMT

Nice. I use powerpoint generally but also provide static PDF snapshops for quick paper based referance. We are looking at moving to Visio now though.

Johnny Welch — Fri, 26 Jan 2007 14:52:50 GMT

When there is little time to build out a prototype (in most cases), I find this approach to be extremely effective. I found this to be an excellent article. Thanks Andres!

Andres Zapata — Fri, 26 Jan 2007 14:52:50 GMT

Some very good – and passionate – discussion around these issues. Clearly, this is a source of anxiety for us all, and we are simply trying to feel our way through it. The second we think we have a handle, something changes and we have to adjust again. And that’s ok, as long as we continue to share and learn from each other. For example, I wish I hadn’t had to spend the time to develop, document and then write about this method. I wish I had read about it here, picked it apart and made it my own.

In response to The Dashboard Spy: I haven’t had much luck designing on the fly with clients. Mainly because one change that we do on the fly might have up or down stream effects that we can’t think about right there on the spot. I see the value in what you are suggesting because it would reduce time – but only the short run. In the long run, it is better to take the time to think it through than to get people excited about something that might have issues as code begins to be written. Although, it might just work for pre-developed and designed products such as yours.

The Dashboard Spy — Fri, 26 Jan 2007 14:52:50 GMT

Thanks for the excellent article. What would you think about the following? Would it be too “dangerous” to also include some powerpoint pages that have some wireframing elements that are editable by the user? I find that, after presenting the type of slide show you describe in your article, the users have lots of ideas that the want to “try out”. Rather than longish cycles of them trying to express their latest thoughts to you and then you adjusting the wireframes and then re-presenting, how about including a powerpoint template that is prepopulated with editable “blanks”. Sorry, I’m not being so clear – maybe I can show you the concept: I work with a lot of enterprise dashboard projects. After determining an initial dashboard layout, I give the users a powerpoint dashboard template “blank” to fool around with. Can you take a look at this dashboard wireframe PowerPoint template and comment on this approach.

AS Ali — Fri, 26 Jan 2007 14:52:50 GMT

I have to respectfully disagree – with Sanjiv – Interactive prototyping done by the C/S Desktop product development folks have been a mess. The typical MS stipulated workflow. Web-native product developers have taken the prototyping to the next level. Prototyping for the C/S world was a subset of project management – killing trees – nothing more than that.

In the C/S desktop world, prototyping means windows forms on Visio and then wait three months to look at the pre-alpha to realize that everything was wrong.

Bubble and numbering are both ineffective ways to show micro connectivity—use the hell out links once the prototyping is done and dump it in your Garage web server and you have the pre-alpha version done for the idiot boss or visually impaired client… .

Just a little frustrated there—sorry… .

Excellent site for InfoVis designers and architects—learning a lot from comments of some very smart people….

srinivas ramshetty — Fri, 26 Jan 2007 14:52:49 GMT

well it is an effective approach to communnications design :)

Sanjiv Sirpal — Fri, 26 Jan 2007 14:52:49 GMT

More ramblings…

Perhaps you can see why the developers may be having problems with the bubble versions of the wireframes. The steps are not clear.

I believe its a fallacy to think that you dont have to create formal design documents. We all know that nature abhors a vacuum. So these stories become the formal UI/UX design doc.

Balancing both audiences needs (Client & Developers) in one artefact is challenging because both are looking for (almost) completely different things. But it seems like you’re already creating two sets of documents (one with bubbles for your clients, and one without for your developers).

What you’re proposing works very welly to communicate the flow of your design to your primary audience. By incorporating the suggestions, you may be able add enough detail for your other audience (and formally recognize that your developers need more :)

Heres what I’m thinking… [http://www.culturesculpture.com/scrap/randomize.jpg]

Last point… powerpoint sucks for writing requirements, I suggest you stick to visio, and just add in navigation buttons to go from one page to the next (slideshow like functionality). When its time to do a slideshow, turn off the ‘requirements layer’, show your story to your client.

Nanotim Nanotim — Sat, 23 Jun 2007 23:03:10 GMT

I first used “annotated” screenshots when I was responsible for Support Documentation. Quickly, I realized that the client really needed this type of information in the beginning of a project…not just the end. So, I stopped writing such verbose functional requirements up front, and started doing more wireframe, maintaining the annotations.

In the last couple of years, I’ve started building wireframes in Flash – with the annotations and prompts to guide the user. While its a bit more work than doing it in PPT or Visio, it begins to portray more accurately the tasks and flows in the application.

The next step for us is to make our prototypes more durable – prototyping in HTML/JavaScript, and iterating right there in the presentation code. We’re going to need to build a toolkit to make it easy to get going quickly – but, I’ve seen some good examples, linked from articles like this one: http://particletree.com/features/ajax-wireframing-approac…

My mission is to give clients a more realistic view of the application earlier in the project (in order to iterate earlier and have a more valuable list of features) while economizing the efforts spent developing IA and controls…to create a more usable/accurate/mature handoff for engineering.

Thanks for showing us how you do your wireframes…looks pretty familiar. Good to know there are lots of folks doing valuable work.

Andres Zapata — Fri, 26 Jan 2007 14:52:49 GMT

Bruce and Sanjiv – both of your comments are along the same vain. The one thing that I am now realizing is that the images included here don’t flow as well as the presentation does in PPT. In PPT, it is very clear which bubble the client should be focusing on at any given point. Future use of this method will include bubble numbering and adding visual focus on the “active” bubble. Good thinking. Cheers, Andres.

Sanjiv Sirpal — Fri, 26 Jan 2007 14:52:48 GMT

Interesting article.

I guess this level of design documentation *is new to the information architecture* field, *but it isnt at all new to those of us who have been designing user interfaces for (desktop) applications*. For us we’ve had to describe the interaction and workflows for complex forms (inter page, and page level) and complex interactions for direct manipulation tools and widgets for eons. I reccommend looking at how this has been done in the past.

The real challenge faced by RIA’s is that they have to blend web-centric patterns with desktop centric patterns.

Back to your storyboard convention. I like the bubbles you have as they indicate on the screen what’s happening. The only problem is that they dont clearly indicate the ‘order’ of events and are visually heavy. I suggest you number your bubbles, and only provide a light description of what you’re trying to show. Then below the wireframe create a numbered list for the bubbles and further desribe the interaction and maybe other thigns that need to be communicated (perhaps to the development community).

This way, you can lighten up the size of the bubbles (you may want to just display a number and title), and have a place to explicity describe the step in detail in the list below (or beside) the diagram.

No use re-inventing the wheel.

Bruce Pomeroy — Fri, 26 Jan 2007 14:52:48 GMT

That’s cool, I think it is most common to present idd’s as PDF files but in a way, PowerPoint is more suitable for presenting designs where there is a flow or process going on between screens. Regarding the bubbles; one thing that would make it even more awesome is if the newly added annotation on each screen was highlighted. Sometimes it takes me a while to figure out which one is new and which ones I have already read.