Hi, I'm a big fan of the method that Steve outlined (well, I don't follow it exactly). All I want to add is that your HTML dude has no right to be disgruntled. If the client wants to change things, that's what they are paying for. Try working with a client on even a small static html site - they change things all the time. We do fixed price quotes. We build some time into our price for small changes, because it is a fact of the business that clients will want changes. Any major structural changes are charged for additionally, that's mentioned in the quote. If your employees are getting disgruntled it might be time for an attitude adjustment - we have a big foam covered bat in our office just for this purpose :)
K. > -----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 ==^================================================================
