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 ==^================================================================
