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