> [...]
> > > There have been discussions of doing this before, but just think of
the
> > > security implications of that.
> > > --
> > > Brian Mathis
> >
> > It should be an option. I'd rather have the feature and decide to use
it or
> > not to use it, than to be told I can't have it because it poses risks.
> >
> > Ed
>
> Yes, this is often the view that many developers have about products.
> However, adding more options doesn't really help, here's why:
>
> 1. It confuses users. In theory, the people developing the system (Palm,
> Inc.) know what the "right" setting is for most users. Asking users what
> the setting should be, when most of them should be choosing "option a",
> doesn't really help anyone.
In applications that I develop, I have to sometimes add features because
some users want them. Sometimes it requires some sort of preference for the
option. I always make the changes to my app in such a way that the new
feature is enabled or disabled in such a way that the functionality of the
application doesn't change for the typical user, and the feature gets
documented in the manual so that the users who need the feature can activate
it.
>
> 2. It makes developer's lives harder. If your developing an app that
> relies on this option being enabled, and the user can turn it off, you
> need to find a way to do it if it's disabled as well. In turn, your code
> becomes more complex, bigger, harder to maintain, etc., and in reality,
> there's really no reason for it to be that way. If you force the 5% who
> might change the option to use it, now you know that 100% of the users
> have it enabled.
It's too bad this approach isn't taken for all issues. Just about every
application I write requires MathLib.prc. So I have error testing built in,
plus alerts that tell the user what is missing and how to go about getting
it. HandSpring includes MathLib.prc, I think the rest should as well.
Unfortunately, MathLib.prc testing has to be done by every individual
application, and if you do alot of scientific or math related work with
Trig, MathLib.prc is required for any high accuracy calculations.
As far as an application requiring a certain feature enabled to perform it's
functions, it's simply a matter of the application testing to see if the
feature is enabled and to give the user a message saying that "hey you
should enable this before continuing". I already have to do it with
MathLib.prc. So, my code is already bigger and more complex, when having
MathLib.prc in the ROMs on 100% of the users machines would make life easier
for me the developer, and for the user (because it's an additional PRC that
has to be installed).
>
> 3. I think 1 & 2 are pretty good.. :)
>
I agree the choices should not be too complex for the average user :)
>
> Kind of related to this...
>
> I made an observation recently that there aren't too many apps out there
> that perform a simple "checkbook" function. However, there are many that
> provide a very complex way to manage your money, with all sorts of
> accounts, etc.. I wondered why this is.
>
> In thinking about it a little bit, I came to the conclusion that it's
> because a simple "checkbook" app isn't very challenging to write. The
> temptation to throw in more features becomes very great for something so
> simple. It's all those other features, however, that keeps most people
> from using them.
I would argue that a simple checkbook application is the checkbook itself.
The simplest form of electronic checkbook would probably keep track of your
balance for you. When writing a check, I have to plug in the numbers, and
since I use the top stub form of checks, it's easy to plug the numbers in
above the check, and I am done. To have to turn on my Palm device, and
record that same information using Graffiti or the pop up keyboard at the
time of the transaction would be far too complicated and time consuming.
Therefore, a simple check book application has no value to me. The existing
paper solution is enough. In my opinion of course. :)
After writing that paragraph, I though about it more... what would a simple
checkbook application have to do for me to use it? Balance tracking isn't
enough because it would never be right... It would need to be able to take
out non check payments, such as ATM withdrawals. debit card use, you have to
make deposits, automatic payroll deposits, electronic transfers from other
accounts, and you also have to have the ability to take out automatic
drafts... My house payment, directv, insurance, etc. is all taken out of my
checking account automagically. I'd want my hand held check book to be
accurate, so it would need to do these things and at the end of the month,
I'd have to be able to reconcile my checking account with my bank statement.
But more than that, it would need to functionally integrate with my desktop
application, and I use Quicken. So it turns out, that it probably isn't that
simple after all :)
Ed
>
> --
> Brian Mathis
> Direct Edge
> http://www.directedge.com
>
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/tech/support/forums/
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
