Holy mother, John. You like typing.
> -----Original Message-----
> From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 22, 2001 8:41 AM
> To: Fusebox
> Subject: Re: WireFrame Demo Online
>
>
> > What I'm afraid of is I'll be presenting a wireframe to a client and
> > he'll say, "Can you make that a pop-up window?" or "Can you add a
> > marker that shows which pages are have access restrictions?"
> > Simple little things like that could make the wireframe a much more
> > effective communication tool.
>
> but you can do that with the wireframe, already. You'd simply add a link
> that says something like "after clicking here a popup window will
> appear and
> blah-blah-blah". If you make it actually *do* the popup then you aren't
> wireframing, you're developing. The whole point, I think, is to get
> something in front of the client that mimics the site's work flow and
> business logic. That's the purpose of the wireframe. Anything else is
> development and GUI design, which are handled later.
>
> Further there is a *real* issue with making things too easy to show the
> client, and that is that to many clients what they 'see' means that
> something is working, and if you did it fast then it must've been
> "easy". If
> you show them everything easily, then they are going to wonder (a) "why
> can't I have this done at the end of the week" and (b) "since I
> can have it
> at the end of the week", he thinks, "why are they charging me
> $75000 for it?
> I got a cousin who makes 'web pages' and I bet if I give him $500 he'll do
> it for me"
>
> Seriously, this *is* an issue, and the smarter the client is, usually the
> more they *think* they know about how to do it
> better/cheaper/faster. (As an
> aside, this is also why doctors and lawyers get burnt so easy in the stock
> market)
>
> The wireframe exists to divorce the concept of the GUI from the work flow,
> so that when you present them with a GUI mockup and they sign off on that,
> that they don't then assume that all the work is done. And by breaking the
> entire project in more "show-able" stages the client gets a real
> sense that
> progress is being made in an orderly fashion so he will be much
> more likely
> to not (a) break that progress path and (b) not object when you ask for
> regular payments of real $$$ at various stages of that path. He's got
> something concrete at each stage to put his hands on (and to
> justify up his
> organizational ladder if need be). Also you're showing him 3
> things, rather
> than just one big thing, and again, he perceives having gotten
> more "value"
> thereby.
>
> We have a client currently who has been really easy to work with,
> using this
> technique. They especially like being able to compare the
> wireframe and the
> static GUI mocks and the prototype all at the same time. However, their
> "money people" in accounting just changed and wanted to review everything
> and commented , "well once it's done we'll pay the remainder of the
> invoices, even though they're now 30 days past due." One call to
> the actual
> client (not the new accountants), about how they'd agreed there'd
> be regular
> payments at the various stages of development and this was why they got to
> see the various stages in progress was all it took--they took on
> the payment
> issue as *their* issue, and had their own internal fight about paying
> invoices, and we got a check 4 days later. Guaranteed without having built
> this relationship with the client that he'd have had no "visual" basis for
> going in and telling the accountants to just do what they're told. It
> emboldens the client, to the developer's advantage.
>
> >
> > The danger of course is that there would be tremendous
> opportunity to get
> > carried away with all of the added features.
>
> yeah I totally agree. In a larger organization, it's the project
> manager and
> architect who need be at the wireframing meetings (after all all the
> wireframing should be occuring in the context of collecting specifications
> and understanding the client). usually PM don't have the skill
> set to do all
> this little development extras and architects think it's way to easy to
> bother with their time. That's great since again this is spec phase not
> development phase. There will be plenty of time during the prototype phase
> to throw in that Pop-up window and have the client comment on if
> that works
> for the effectively.
>
> > I think we *can* have power and extensibility (and diuturnity!) without
> > sacrificing simplicity and speed.
>
> I totally agree that you can. Let me present a rational argument
> against it
> (see below)
>
> Keep in mind that Wireframing is for the proto-CLIENT not for the
> DEVELOPER-- you haven't converted him to a client yet because he hasn't
> signed a check. A signed check in my hand defines a client,
> everything else
> is a bunch of noise, a dot-com wanna be who needs everything done
> tomorrow...on credit.
>
> > And if I can get you to bite on that idea, I'll let you in on how I
> > think wireframes could be used as a tool during development -- not as
> > some complex Rational-esque code generator but as a simple
> > communication tool.
>
> here is the reason why I'm unlikely to "bite". :)
>
> First off, I think the difference in opinion relates directly to your
> comment above that "wireframes could be used as a tool during
> development".
> I believe that is in error since no development should be done until
> wireframing is complete. They are two temporally distinct processes and
> development cannot and should not be attempted during specification phase.
> I'll go out on a minor limb and suggest, without proof herein,
> that anytime
> any of us have ever gotten screwed on a project was a project in which the
> distinction between specification phase and development phase was not
> observed.
>
> Second, if you make a substantial improvement to wireframing I'd certainly
> use it...so don't let my own opinion in the matter stop you :)
>
> however, to me, the wireframing occurs as part of the first
> serious contact
> with the client. At this point if the client is a putz I want to
> get out of
> there as fast as possible. But if he is serious, then I want to make the
> path between "ok let's go ahead" and "here is the first payment"
> be as fast
> as possible, because I need a cushion for time spent on this project by my
> various team members. I want to have the minimal work early on but as much
> visual bang-for-the-buck as possible because in the end I need both the
> client to be happy *AND* the bill to get paid promptly. You cannot
> consistently make money by allowing the client to pay only at the "end" of
> the project since then they control what 'end' means. Once I have some
> money in the account, *then* is the time to spend on development with the
> goal being that you are always monetarily ahead of the game--you always
> "owe" them some more work based on monies you've collected, rather than
> their owning you for work already done. The time between wireframing and
> first payment (hey if you're really smart you got a retainer fee
> in advance
> just to sit down and wireframe!) this time should be the only period where
> you're running "in the red". That's why it's got to be short. And
> the way to
> keep it short is to make the wireframe as minimal as possible--the more
> bells and whistles you add the more liekly you are to extend the wireframe
> period and the more likely that extension will be because you're
> showing the
> client "development" and "prototype" stuff, rather than wireframe stuff.
>
> my goal during wireframing is to get as quickly as possible to the
> prototyping stage where the client makes a second or third payment. I got
> plenty of development and auto-code generator tools in hand already that
> can take care of that, bundling them all together is nice and
> might even be
> used internally but it's got nothing to do with the *client*
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
