>> You're dead right on that one. Does it make good business
>sense to tell
>> a client who WANTS another way to exit an application "It's
>not in the
>> Palm Zen, I can't do it"? Not if you're out to lose
>clients, it isn't.
>
>This is where I see the real world hit the artist colony.
>There is very much a middle ground on this and I have done it
>with many a
>client.
>
><soapbox>
>Most clients are exploring how to use a handheld in their
>business when they come to integrators and consultants like you and I,
>they are willing to admit they don't know the exact
>implementation beyond "we want this data in our Palms." There
>are exceptions to
>this of the most egotistical and dictatorial clients of whom I
>refuse to work with -- another reason why I don't mix well with the
>Hollywood machine.
>
>I have found that what they want and what they need are
>sometime two totally separate things. They tell you one thing
>that they
>want which is some half baked solution they got in the shower.
> I find it is very helpful to dig deep and discover the actual need.
>This is the sign of a true problem solver.
>
>One example of this is a client a while ago who said, "I want
>all my techs in the field with Palms to get the new schedules twice a
>day." Later, I went to investigate the whole need and
>discovered that they really needed to get their internal
>scheduling process
>more organized since they were wasting time, gas and labor
>having the techs travel unneeded miles. Thus, they got their
>Palms with
>the special scheduling code but most of all, their back end
>was cleaned up in addition.
></soapbox>
>
>Steve
Of course. If it's an integral part of the functionality of an application,
then it's part of your job as a developer to determine the application
specifications. In fact, many clients will demand this of you. However, if
it's something where the tradeoff is highly negligable (for example, an exit
button...from my point of view, this entire thread was meaningless due to
the highly...minimal...impact this has on the entire "Zen" of Palm
programming,
but I digress), it should be perfectly reasonable and acceptable to give
your client what they want. In my experience, if you find a simpler way to
do something integral to your application, your clients will love you for
it.
If you quibble over something ridiculous, your clients will start looking
elsewhere (and this includes certain other platforms...where the "Zen" is
very, very accepting of all kinds of things.)
I think that if a client wants an extra menu command, or extra button, and
they feel like they're getting more for their money, then that's great. Of
course, doing things that are a bit drastic, like backing up your
application
preferences database into flash simply because your client wants to feel
more
secure about it is definately wrong. It's the developer's call as to what
constitutes "minor" and "major", but here's a good filter: If the
functioning
of your application hinges upon it, or the proper functioning of other apps,
then it's major. If it has no effect on anything except to make the client
happy, then it's minor.
-Rus
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
