I agree. In this situation you either teach HTML people a little CF or CF people a lot of HTML :-) I prefer the HTML people learning a bit of CF but that is not always easy :-).
----- Original Message ----- From: "Scott Sauer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 10, 2002 10:30 AM Subject: RE: FLiP and Prototyping > I've found FB3 itself very useful for creating the "prototype". With an HTML > only proto, you hardcode links to other HTML pages. When a client changes > his/her mind you then have to either go back through the HTML code and > re-link all your HREFs or do a massive search and replace and hope all goes > well. XFAs make it so easy to change exit points... why not use FB3 to mock > up a front end? Only create dsp_pages! Also for a mocked front-end using > just HTML, every page is jammed with the same HTML "framework code" which is > also a big crap in your cornflakes when the client wants the whole site to > look a little different. Using FB3 as your prototyping tool allows the use > of a single layout file... or with a small conditional you can show the > client 2 or 3 versions of layouts. Once the feely-touchy stuff is done, your > switch pages are done, your directory structure is done, and your dsp_pages > are done! > > It's been working for me, so I thought I'd toss it out to the rest of you. > > Scott > > -----Original Message----- > From: John Jonathan Kopanas [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 7:46 AM > To: [EMAIL PROTECTED] > Subject: Re: FLiP and Prototyping > > > I definitely agree that one method does not work for all clients. For some > clients wireframe won't cut it but for the ones that are happy working with > wireframe and continue adding more information to it then why stop them. > Don't progress to the next stage until there is a slow/stoppage in > information gathered from client. Why tell the client: "ok, you have a lot > of great ideas but don't tell me about all the fields you want just yet, let > me build the HTML prototype and then you tell me". One of the reasons > people build sites is to get info from clients. Might as well get them > whenever, or as soon as, you can. > > But yes, it all depends on your client. Don't force them to do something > they are not comfortable with for to long. > > > Boy this gets everyone talkin! > > > > I suspect that I agree with JJK on this. I prefer the wireframe part of > > the process to include a lot more real functional concepts, and the > > ability to gather the functional requirements. Again it depends on the > > client, but also on your ability to educate the client in the process. > > Some people will be more or less comfortable dealing with functional > > concepts, others will have to see the rollovers and the layout before it > > clicks. I know it goes against the grain, but I think you have to adapt > > the methodology depending on the people involved. Not all the clients I > > have worked with are naive when it comes to specifiying requirements. We > > always accept however that we cannot know all the requirements when we > > start building. This is what happens in most of the software projects I > > work with, not just website design, so you have to factor in > > requirements change once you start building. I don't think it > > necessarily saves time to try and nail of all the functional > > requirements with an HTML prototype > > > ==^================================================================ 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 ==^================================================================
