The reason why is because a wireframe is just a very quick, simple way to get a text only based general feel of the site.
As Steve mentioned before, the wireframe is almost just a sales tool that allows you to get a quick feel in a very short amount of time (less than 2 hours) of what the application is to do. If you get into form fields, then you will very quickly get into the placement of the form fields or how the text is arranged around the form fields. Why stop at that, lets figure out the page navigation or maybe the background should be blue .... and now you have lost control and really should be in the prototype where these things can be taken care of. -- Jeff -----Original Message----- From: John Jonathan Kopanas [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 3:08 PM To: [EMAIL PROTECTED] Subject: Re: FLiP and Prototyping Now we get to my argument from a while back. Why don't we just put form fields and a little more info into wireframes so that prototype becomes a graphical/navigational prototype instead of a whole site prototype. I think you could save a lot of money in development doing it this way and still find out exactly what client wants. Wireframing is easy and cheap might as well get as much info from it as possible. > 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 ==^================================================================
