On Wed, 31 Mar 1999, Scott Johnson wrote:
> 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?
Error #1 (if I may be so bold): I presume you are using a custom Conduit.
Therefore, the user must enter a ZIP code before the record is inserted
into the SQL database, which is not the same as before the record is
synchronized.
Corollary #1: If a record cannot be sent to the SQL database, it must be
edited to insert the missing ZIP code. Perhaps you can edit it on the
desktop, but you can definitely edit it on the device.
Conclusion #1: If a record is missing the ZIP code, it should be left on
the device, and not sent to the SQL server. Otherwise, the device user
could not add a ZIP. (If you have a desktop app to edit these census
records, it should have a copy of the record that is syncronized with the
on-device record.) Adding a ZIP on the device or desktop should then
complete the record, cause send it to the SQL server at next HotSync, and
erasing it from the device at the first opportunity (if the ZIP was added
on the desktop).
> 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.
Otherwise known as a "forcing condition". Congratulations, I think you've
invented the first good excuse for using a forcing condition on a Palm
device. :-)
> 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.
As others have said, the record should be available when they switch back.
This is good.
> 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.
You're kidding, right?
> 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.
Yes, but you do have an excuse for a forcing condition here, so this does
fit the pattern. It would be extremely unusual, and I'd worry about
border-line conditions with alarm dialogs, auto power-offs, etc. But I'm
willing to consider that the data might be important to warrant a "don't
forget to finish this!" message.
Have you considered setting up an alarm to pop up in five minutes to tell
the person to complete the census record? I'm not sure that would make any
sense, but it seems a logical extension.
> 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.
Indeed, yes, this seems ideal. I'd probably suggest two display modes
(perhaps using the category picker?), one showing a list of all records on
the device, and the other only showing records that are incomplete (one
way or another). It might even be desirable to have the census recorder
app automatically go to the first incomplete record when you start it up,
and I wouldn't mind seeing it highlight the first field that needs filled.
Of course, you could then consider normal record entry to be a case of
displaying an incomplete record (blank, in fact) that needs to have
certain fields filled before it will register as "complete".
> I'm not finding an elegant hand held solution. Suggestions, discussion,
> official guidelines would be appreciated.
As they say, "hope this helped".
> -slj-
--
Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
