On Sunday, Dec 29, 2002, at 04:30 Australia/Sydney, Rob Cozens wrote:
OenoLog takes a middle ground: while the field cursor tabs to the open field (leaving the mouse cursor in its original location as David noted),...further refining this difference between data entry and general mouse movement, the cursor will hide as soon as the user then starts typing. If the cursor is "lost" to the user then you are probably entitled to make it reappear wherever makes sense when they tab or press enter from the last field, or next move the mouse, as the user's last focus was the entry point. So, you might move it yourself on closeField (the cursor has already vanished) but not on exitField or mouseMove (it was still visible). (I just tried this and the cursor did not move anyway but I am not going to explore that as I don't have a user for it).
I also find this question of how data entry is done interesting. We have the approach of entering directly in fields, doing it in a second set where the original fields are columnar or group-scrolling, and using separate dialogs. For columnar/group scrolling fields I have preferred the separate fields approach, because sync scrolling for data entry jammed at the bottom of the field is a bit messy. It also allows me to use a concept from Dataflex to get rid of "New" and "Edit" modalities previously mentioned. Adjacent to the entry fields are "Clear", "Delete" and "Save" buttons.
... This is displayed in a manner that appears to be columnar; but I don't want people tabbing into the whole table, so to accommodate adding and editing table rows there is an individual field below each column. If I were to use Alan's technique, I could eliminate those individual fields and construct/deconstruct individual rows behind the scene.
If the user enters new data in empty fields then (assuming no autofind) pressing save will add a record while delete is not available.
If they call up an existing record (autofind or click on the list to put it in the entry fields) then they can delete it or modify and save, in which case it will be an update.
After any save, the data is left in the fields (not auto-cleared) but internal status is set to new record so you can enter a new variation of the previous one. Depending on the application it can be better to leave state as found record until they press Clear.
Clear obviously sets internal status for a new record as well as clearing data.
The advantage is simply that you work on the data, with mode determined after the fact (and a little behind the scenes work) rather pressing a button to select new or edit modes before doing anything. It is a little faster for the user, being more data oriented rather than computer-mode oriented.
Based on Alan's comments about using ask/answer data entry, I am now considering using modeless dialogs rather than additional fields on the same card as the data entry point, bringing up the right dialog (field set) for the logical sub-group of fields selected on this card. This will reduce clutter on the card and localise entry and validation.
just more thinking out loud in response to yours.
cheers
David
Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm"And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee." from "The Triple Foole" by John Donne (1572-1631) _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
