Sure you can say anything you want. Just try and word it in the form of "this is what
we want" instead of "this is how we'll do it"

Do you see the difference?

A good game to play is to pretend it's all magical. like "The information is saved"
where? how? when? is it fast enough? All of those questions wouldn't matter if it was
magical.

We can worry about reality later. Programmers often want to offer numerous edge cases
like "what if X happens or what if Y happens?" They say "I'm just being a devil's
advocate". Reality doesn't need a devil's advocate, because it can't be ignored. So
don't worry about how you're going to make it all work, just figure out what the
client is looking for.

Steve Nelson

Erki Esken wrote:

> Fair enough.
>
> But lets take that example further. Lets say my client wants that
> login action to do more. Like if user is logging in with wrong credentials
> for the third time in a row within 15 mins then that use should be locked
> out and email sent to admin. Then you just add that info to DevNotes and
> that's it for the prototype phase? Do you ask more questions from the
> client, like should that minute amount be configurable or fixed at 15 and
> mark it again in DevNotes?
>
> .erki
>
> ----- Original Message -----
> From: "Steve Nelson" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 12, 2002 12:38 AM
> Subject: Re: FLiP and Prototyping
>
> > I stay away from anything that gets technical enough that my clients might have
> > the slightest confusion about, even if they're technical themselves. Getting
> > technical means your solving problems, instead you should be defining what those
> > problems are. It's generally quite hard to create solutions before you know the
> > problems.
> >
> > Sometimes if I feel it's ultra necessary to document something behind the scenes
> > I'll add it to the prototype. Usually only if there is a choice to be made of
> > the next prototype page, but i keep it as simple as possible.
> >
> > This is bad:
> > -----------------------
> > I check the "users" table in the database looking to see if the email address
> > and password they typed in matches up with the "email_addr" and "Pword" fields.
> > If I found a recordset I set the client variable to this user_id....
> > Links:
> > [Successful Login]
> > [Failed Login]
> >
> > This is better:
> > -----------------------
> > I check to see if this user has been here before
> > Links:
> > [Successful Login]
> > [Failed Login]
> >
> >
> > Do you see the difference? The bad version is solving a problem, possibly
> > solving the wrong problem. The better version is presenting a problem to be
> > solved by the programmer. I'm sure there is an "even better" version than what i
> > have above.
> >
> > 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
==^================================================================

Reply via email to