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?
When the user taps the Done button I can pop up an alert telling them to
go back and enter the missing ZIP code. Easy.
But when the user taps Calc to save >and< exit, should I put up the same
alert and halt the app switch? This feels wrong. The user tapped Calc
and didn't get Calc and doesn't feel the Zen of Palm.
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-
