I personally like your last suggestion best: Allow the user to leave your
application, and save the current state.
When the user returns, she sees the same record awaiting a zip code.
It seems the most 'Palm-Zen', as you put it.
-Mike Ethetton-
-----Original Message-----
From: Scott Johnson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 31, 1999 1:19 PM
To: Palm Dev Forum
Subject: Strategy for navigation & validation
Here's a problem to think about. Say I'm writing an address book style
application for the 2000 census. It has a Done button on the Edit form,
uses edit-in-place on its records, the usual stuff. When the user edits
a record and then presses (say) the Calc button, then the current record
is saved and the organizer switches to Calc. So far so good.
But then I find that if the user happens to get a record only half
entered and forgets the ZIP (postal) code, and saves the record by
pressing Calc, then does a HotSync, it sadly causes the government's
Microsoft SQL Server 7.0 database to crash and lose tens of millions of
records of 2000 census data. Not good.
So we need to >force< the user to enter the ZIP code (somehow) before
the record gets synchronized, but in a Palm Zen-like manner, where force
is not usually considered a good thing. How?
I could change the logic so when the user taps Calc the current ZIPless
record is >discarded< before switching to Calc, with no alerts. Then
the user gets his Calc but also loses a record he thought got saved.
Or I could do something like the previous, but pop up an alert
confirming that the record is to be discarded before switching to Calc.
Again, an intrusive alert and not a seamless user experience.
Hey, I could even "save" the ZIPless record in a sort of limbo state
where it won't synchronize but will be editable after the user finishes
Calc and returns to my program.
I'm not finding an elegant hand held solution. Suggestions, discussion,
official guidelines would be appreciated.
-slj-
