I think it depends a great deal on the type of client you are dealing with. I have one client who is a systems analyst, who comes to me with a butt-ugly NetObjects Fusion html prototype of what he wants to create - I'm supposed to both make it pretty and make it work. He would be comfortable using a wireframe with technical info and business process descriptions in it.
Another client organisation consists of arts managers. They hated the wireframe when I forced it on them, so I tried to make that stage as quick as possible. I was too scared to talk to them about what was happening in between the pages, so for them it was short descriptions of display pages only. K. > -----Original Message----- > From: Lee Borkman [mailto:[EMAIL PROTECTED]] > Sent: Monday, 3 June 2002 10:43 PM > To: [EMAIL PROTECTED] > Subject: Re: Wireframe tools and Wikis > > > Hey Steven, > > There are many different approaches to wireframing in the > Fusebox community. There are two basic elements to the way > you might approach wireframing: > 1) What kinds of page/state do you include in the wireframe? > 2) How much information do you include in the > responsibilities/description of each page/state? > > My personal practice is to wireframe ALL page/states, > including non-display states, but to put little information > into each page. The benefit I am trying to achieve is to > "map" the proposed application. The vital elements of the > map are the pages/states, and the connections between them. > The information contained in each page/state is *relatively* > uninformative. In other words, the text-based descriptions > take 5 times as long to create as the simple pages and > interconnections, without greatly helping me to understand > the application, nor to express my understanding to the > client. If I want to describe business rules, I try to do > this by using multiple states with alternative pathways > through the interconnections. Thus the information is > directly contained in the connections, instead of being > buried in the text. > > Of course, other people approach it differently. Hal, I > think, only wireframes the display pages, so that the > wireframe is a bare-bones version of what the user *sees*. > That's certainly a fast way to build a wireframe, and can be > less confusing for the non-tech clients. I couldn't really > say how much detail he puts into each page, though. ;-) > > I have not seen or done any wireframing with the level of > detail in your example. I think that the common practice is > to defer those considerations for the static prototype, and > its DevNotes annotations. Steve likes to talk about 2 hours > for the wireframing, and while I believe that that's > excessively restrictive, I take his point, ie clients don't > really know what they want until they see it. > > Sorry, it's getting late, and I'm beginning to froth at the > mouth and blather incoherently. If you like, contact me > off-list, and we can swap some actual wireframes, and compare notes. > > See ya loater, > LeeBB > > > > ----- Original Message ----- > From: Steven Ringo <[EMAIL PROTECTED]> > > > Hi, > > > > Is my notion of a wireframe somewhat different to what the general > > community understands? > > > > I use "wireframes" for development planning. To understand the ins > > and outs of an application's behaviour, as opposed to a one- or > > two-liner for each screen. > > > > As an example lets say I have: > > > > ----- >8 snip ----- > > > > Page Title: Check In > > > > Page Entry: > > When checking in an entry, a user can: > > * Optionally change the stage of the entry (default is from the > > previous > > version) > > * Optionally change the deadline for the stage (default is from the > > previous version) > > * Optionally select to flag the entry (default is from the previous > > version) > > * Opt not to select a stage or to flag (default is from the previous > > version) > > * Notes: Deadline or stage can't be changed without > checking a document > > in. Also any user with editing rights (not just the author) > can change > > the stage or the deadline. > > > > ----- >8 snip ----- > > > > If this kind of information is not laid out in a wireframe, > where is > > it / should it be laid out? Should it be in the fusedocs? I don't > > think so, as this is still planning - understanding the issues > > involved, e.g. "I cant do this, before I do that". > > > > Cheers, > > > > Steve > > > > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
