Hi, Steve wrote: >Usually I toss the wireframe and don't look back. I spend >no more than 2 hours on the wireframe. I try to >use it as almost a sales pitch. The minute the client sees >the application in HTML, they get excited. Too >much wireframing and the best of clients will still zone out.
I have been following the thread and saw Steve, Hal and a few of you mentioning that the wireframe is used mainly as a sales tool and usually "dumped" after working about 2 hours on it. So I am wondering if it would be general guideline or for a small to medium (subjective) project? I am working on a rather complex logistic related "Portal" and have been stuck at the wireframe stage for the past week. Fortunately, my client is rather happy working with the tool as it showed the flow of the portal processes. That's where I am confused. Have I dwelled on wireframing for too long? Should I just get into the prototype? Wouldn't it be a longer process if we try to work out the process flow in the prototype stage? My idea was to get the flow established, agreed by the client, then get the HTML guy to work on the prototype. Wouldn't that be faster and cause less unhappiness for my HTML guy? Thank you and regards David Siew Webthings Internet Services www.webthings.com.sg -----Original Message----- From: Steve Nelson [mailto:[EMAIL PROTECTED]] Sent: 10 June 2002 01:52 To: [EMAIL PROTECTED] Subject: Re: FLiP and Prototyping Richard Tugwell wrote: > Hi Steve > > I'm not sure if your post was in response to mine or not. > > Can I ask a few questions Ask away, i love to talk about this stuff. > Does the HTML prototype determine functionality, or > appearance/navigation? Both. The HTML prototype determines what the client wants. They have a hard time telling you exactly what they want without seeing something. "Should that form field be a checkbox or a radio button?" They won't know until they see it. The answer dramatically changes the design of the database. Is that appearance or is that functionality? Does it matter? > Does it show/allow functionality not uncovered in the requirements > gathering/wireframe process? yes absolutely. A wireframe gives you a quick sketch of the prototype, but the wireframe is terrible at uncovering issues like the checkbox vs. radio button. Without seeing the two, your client will have a hard time understand the difference between the two. > If you change the prototype, do you change the wireframe, or have you > thrown the wireframe away by this time? Usually I toss the wireframe and don't look back. I spend no more than 2 hours on the wireframe. I try to use it as almost a sales pitch. The minute the client sees the application in HTML, they get excited. Too much wireframing and the best of clients will still zone out. > I find overlaying HTML layout on a "wireframe" functional skeleton > very easy with FB3, so why delay the coding/DB design? Yes, that's exactly the reason for the wireframe. It gives you a starting point for the prototype. I generally start my prototype by translating each page in the wireframe into an HTML page, and I give that wireframe a skin. Suddenly i realize "oops i forget so and so when i built the wireframe" Then I add that into the prototype. > Cheers > > Richard > Steve Nelson wrote: > > FLiP may feel a little confusing at first because it feels like > > sometimes you're doing things backwards. Hear me out.... > > > > Design the database last. > > > > Don't sign off on the wireframe. Instead sign off on the prototype. > > > > Build the ENTIRE prototype before your touch a line of CFML. > > > > Let the client get touchy feely about the prototype > > > > Let them go on and on and on (Don't do this for free, charge them.) > > until they say "THAT'S IT! THAT IS WHAT I WANT!" > > > > When they say that, move on to fusedocs, fusecoding and database. > > > > Building the prototype could take days, weeks, even months. But when > > you finish, the application will be exactly what the client wants. > > During that time you > > generally do not need a staff of a dozen programmers, what you need are > > $15-20/hour pure HTML programmers. For those guys, HTML coding does not > > take a > > long time. > > > > Give this process a try, it's weird, but it REALLY works! > > > > In the words of the great Dr. Seuss > > > > You do not like them. > > So you say. > > Try them! Try them! > > And you may > > Try them and you may, I say. > > > > Steve Nelson > > > > Richard Tugwell wrote: > > > > > Hi > > > > > > I'm late in this thread, but I may be missing something. It seems > > > that wireframes are used to find out what the client requirements > > > are as regards the navigational and functional architecture of a > > > site is concerned. The output from the wireframe stage, or some > > > other stage should be a signed-off functional specification, (with > > > some caveats about changes made later in the process). Some > > > clients are better than others at providing input to this stage. > > > Some other requirements are gathered otherwise (DB model for > > > example) from more other methods such as use case modelling E/R > > > and various other modellling techniques. > > > > > > I always thought an HTML prototype ONLY showed people what the > > > site would look like within that already "accepted" architecture. > > > If clients start changing requirements at this prototype stage, > > > then you have problems - back to wireframe. I can also sympathise > > > with people who think that HTML coding takes longer than all the > > > other stuff. It can take longer, because HTML formatting is a > > > pain, and the client will always be wanting to make "little" > > > changes which are very time consuming. I tend to do functional > > > coding, based on a signed-off functional specification in parallel > > > with the prototype touchy feely bit. > > > > > > I try and make sure that design wise the site appearance is as > > > much as possible separated from the functionality. Fusebox 3 is a > > > great help here for me withthe api and nested layouts. If the > > > client says "menu down the left side" instead of "menu across the > > > top" no problem. > > > > > > I have been involved in software development projects for 25 > > > years, now doing website stuff as a kind of hobby, but it is > > > obvious that we always have the same problems. Most methodolgies > > > acknowledge that requirements cannot be specified absolutely at > > > stage one. However every project has to be managed on it's merits, > > > and it is not possible to generalise and say that prototyping > > > takes 60% etc etc. I think the phases of Flip are appropriate, but > > > we cannot always be prescriptive about things > > > > > > Off the top of my head thoughts - this topic will run and run, > > > there is no absolute answer Steve Nelson wrote: > > > > > I am creating Montreal's CFUG website right now and this is > > > > > the first project I am using the FLiP process. I have done > > > > > the wireframe and now I am on to the prototype. One of the > > > > > people I work with who does the HTML integration always tells > > > > > me I should program only after having the first template > > > > > because coding HTML takes so long compared to programming. > > > > > What do you say to a person like that? > > > > > > > > Race them. Say: "Let's pick one template, you build the CFML > > > > and the Database THEN build the HTML interface that we will > > > > 'slap' on, I'll build just the HTML. > > > > Whoever finishes first wins and we'll do it that way." > > > > > > > > Then tell them that you could show both versions to the client > > > > and 99% of the time the client won't see the difference. But > > > > will understand the application > > > > enough to tell you they want something slightly different. > > > > > > > > Steve Nelson > > > > > > > > > > > > > > > > > > > > > > ==^================================================================ 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 ==^================================================================
