> Scenario 1: > You get the basic flow of the site and then you tell the > graphic artist to create a look and feel, you start building > HTML prototype and your HTML programmer turns around and says > "I know they want a contact us form here but what fields do > they want?"
Go back to the client and ASK them what fields they want. Or..assume a few basic ones and get the client to fill in the rest. Dev Notes is great for that communication. No need to go to step 2 or 3. Stay on step 1. Tom > -----Original Message----- > From: John Jonathan Kopanas [mailto:[EMAIL PROTECTED]] > Sent: Monday, 10 June 2002 4:33 AM > To: [EMAIL PROTECTED] > Subject: Re: FLiP and Prototyping > > > I have heard that argument before but I don't buy it for a > couple reasons. > > Scenario 1: > You get the basic flow of the site and then you tell the > graphic artist to create a look and feel, you start building > HTML prototype and your HTML programmer turns around and says > "I know they want a contact us form here but what fields do > they want?" Arghhhh. What a horrible scenario. > > Scenario 2: > You can prevent scenario 1 from occuring by creating a > requirements document between wireframe and prototype. > Client looks at requirements doc, does not really understand > it so he/she signs off on it. HTML programmer codes what he > thing the client asked for and then client comes back and > says, sorry that is not what I want, can you change x,y,z and > the kitchen sink. Arghhhhh. You get a disgruntled employee. > Not very good. > > Scenario 3: > Wireframe has two modes. First mode just gets general feel > and second mode allows architect to go back and get more > complete data. Client gets to see what is proposed and can > correct some of the errors before you get disgruntled > employees and before you get to the point where you have > spaghetti code because every time the client comes back you > create fixed instead of doing it right from the start. > > I just spent five hours doing stupid HTML for CFUG Montreal > prototype. I hate it. If I have to make changes I will > yell. HTML is not fun no matter what anyone says. I want to > spend more time on something like a wireframe so I spend less > time on html. > > > > 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 ==^================================================================
