Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Navigation Buttons in Container
Message
 
To
12/12/2006 22:16:44
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 6
OS:
Windows 2000 SP4
Network:
Windows 2000 Server
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01176887
Message ID:
01177740
Views:
23
>>>There's a save button, sure. But editing is enabled by default. And depending on the type of the form, a new record or editing an old record depends on what the user enters in the first field etc. There's no Edit button, no New button. The user is always presented with a blank, editable record, and a way to get to an old record.
>>>
>>>If a form is read-only, there's a reason for that - it may be a view form, or a lookup form or whatever. A data entry form is not read only by default.
>>
>>So, if the user is on an existing record, and wants to add a new record, he must click on or select a field and enter something (I'm guessing some kind of ID). How is this better than clicking on 'New' and selecting the field in code? How does the user know which field to enter / select for a new record (color, label, tool tip,...)?
>
>Haven't decided yet :).

That says something... I suggest you reconsider your beliefs about 'New'. This shouldn't be too hard (especially for a non believer type like you), so bring back the 'New' button from the UI hell. After this, all you need is the 'Edit' button, and you'll be truly saved ;)
I find the UI with Save/Cancel explicit, Edit implicit, and Add somewhere in between, inconsistent.
Also, with editing implicit, are Save/Cancel buttons enabled at all times, even if there is nothing to save or cancel? Or, do you run code for every keystroke to check if there is a change or not, and enable/disable Save/Cancel?


>... In frameworks which had this, the user would have to either cancel or save (so to decide the destiny of the record being currently edited), or press a predefined key (and it was the Home key last time, which annoyed me and the author of the code as well, but too late - users got used to it, which is why they are called so). I still prefer the Save/Cancel (accompanied with Enter/Esc for hotkeys, or even better nothing and Esc).
>
We have shortcut keys for all buttons. Esc cancels the adding/editing, or exits the form when not adding/editing (we use the 'Cancel' property to do this). We use the Enter (‘Default’ property) mostly in dialog forms.

>This IS better when you're doing heavy data entry - once you save, the form is ready for the next document. No need to tell it that you want another one. I was watching professional data entry gals & guys for a while, and if I may speak for them, whoever decided that Enter was supposed to mean "I'm done with this FORM" and Tab "I'm done with this field" obviously has never seen one-hand, digits-only entry. They'd use their left hand to go over a paper document, and the right hand was just fuzzy over the numeric keypad. But I digress. The fewer trips between mouse and keyboard, the better.

Heavy data entry forms are special cases, and we do have very specific UI for each case. During data entry, 'New' and 'Save' occur transparently to the user 99.99% of times. If you need to go back an edit a record entered 15 minutes ago, that is no longer ‘heavy data entry’, so you will need look-up, edit, save… buttons.
However, the OP did not ask about heavy data entry, specifically... If you said that “This IS better when you’re doing heavy data entry” from the beginning, you would have saved me from trying to save you. I know how much you like being saved without asking ;)
Doru
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform