Steve Nelson wrote: > 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? >
Hey - that is clearly functionality, and should come out of the functional spec- When I do a prototype with CFML/DB and this requirement changes, we just log it as a change to the functional spec and code as appropriate, charge it if it appears to be a clear change to the signed-off requirements > > 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. > I don't normally use any wireframe tool, but use a traditional method of requirements gathering and storyboarding. Sometime the FB wireframe tool is great, other times I don't bother. It depends on the client. The bottom line is to get the firts cut of the requirements and functional sepc. > > 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. > As soon as the client sees HTML they get excited. How true! Then they think they have a real application. Clients differ however and I think the success of a project hinges on managing the client, their expectations and their capability to visualise it in terms other than just a webpage. This is where you come in, and how you manage the client matters. They are all mostly different, although most want to see the vissuals at some point early in the process. This is why I "mock up" the visuals, and educate them on what the functioning prototype actaully represents > > 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 ==^================================================================
