|
When the form is dirty, I would have the Cancel button labelled "Reset", or even clearer, "Clear", and coloured in a warning colour like orange, that won't turn black for colour blind people, but will still indicate the button has a special purpose. Maybe even a warning icon in the corner of the button.
Do what thou wilt shall be the whole of the Law. - Liber AL vel Legis 1:40, Aleister Crowley
|
|
|
|
|
All good ideas; Clear isn't right as, when modifying data, you're not clearing - but Reset is probably better (although I don't see anything wrong with cancel, personally- you are cancelling your changes)
warning icons, changing colours etc. really aren't good in this sort of application, simply because people will be using these forms all day every day - and things like that get ignored with familiarity.
PooperPig - Coming Soon
|
|
|
|
|
OK, how about a Reset/Cancel button that jumps around a bit when you try and click it? 
Do what thou wilt shall be the whole of the Law. - Liber AL vel Legis 1:40, Aleister Crowley
|
|
|
|
|
D'ya know, I'd think you were joking if I hadn't seen the software running ....
PooperPig - Coming Soon
|
|
|
|
|
Firstly, having a dual function on the button is contrary to good UX. Each element should be required to perform a single task. 
That said you have your design. I would suggest having two buttons, something like this:
Maxxx Dialog
[####] [####] [####] [####] [####]
[####] [####] [####] [####] [####]
[####] [####] [####] [####] [####]
[####] [####] [####] [####] [####]
[Submit] [Reset] [Close]
The buttons should only be enabled when they are active and then have configuration settings to hide disabled buttons and confirm actions. If you have hide disabled set, then the [bad] behaviour you already have is maintained.
My preferred behavior would be to remove the reset option and require the user to reopen the dialog to reset it to base state. I have experienced this with pinned dialogs that needed to handle a reset and somehow they always got messed up; the dialogs had a very compliminated state engine.
Whichever way you choose, leave the optional behaviour under the control of the user. Remember, happy users means happy Maxxx!
veni bibi saltavi
|
|
|
|
|
Good ideas.
In your example, though, if I want to save and then enter another what to I click? then what do I click when I want to save then close?
Original behaviour in at least some of the screens in this application was that Cancel:
Warned the user
Closed the View
So your re-open option was used.
But
the code was so poorly written that opening a View took friggin' ages - so to save the delay in closing/reopening they changed the behaviour of the Cancel button - rather than fixing hte underlying problem!!!!!!!
Happy customers? We have very very few of those!
PooperPig - Coming Soon
|
|
|
|
|
Yuk, you're getting into multiple behaviour territory and there be dragons!
Going back to the 'one thing == one action' concept, the submit control should do just that, submit the action.
Then what happens? It depends on the state of the dialog. If you allow the dialog to be pinned then when you submit the dialog will remain if it's pinned and otherwise it closes. Actually, with pinned dialogs, you can get rid of the ugly clear/close behaviour. When the dialog is pinned, the button clears the dialog, otherwise it closes; tell the dirty/clean to FOAD.
To get around slow loading, why not early load them? After starting up, the UI container should be able to pre-load any dialogs that may be needed and that you know are slow loaders. Even better would be to take a bloody big hammer and review how the dialog loads. What is needed to get it into a safe state? The normal problem here is getting in context data, populating look-ups and validators. This can, and should, be done later in the cycle. Load the dialog, show it and then start the network traffic to get the look-ups.
There you go, my 483p worth.
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: you're getting into multiple behaviour territory and there be dragons
Not really - it's a matter of perspective. It's like "UNDO" - you don't want an "Undo Typing" and an "Undo Drawing" and an "Undo Adding" etc. - just Undo
Same here
Cancel functions slightly differently depending on circumstances, but if consistent I don't see a prob.
Nagy Vilmos wrote: To get around slow loading, why not early load them?
Oh - there's loads we can do to fix - but sooooooo many things that need fixing and sooooo little time!
The main reason for the slowness is that the complete gits that wrote it used an ORM and didn't seem to appreciate that, if they want a drop down selection of (say) types, then they can retrieve just the ID and Description of the type - and don't need to bring back 4 squillion tetrabytes of additional information
I exaggerate not!
PooperPig - Coming Soon
|
|
|
|
|
|
Nagy Vilmos wrote: having a dual function on the button is contrary to good UX. Each element should be required to perform a single task.
Just sorry, but really, just not true. At all.
Think right-click, swipe left/right, double-tap, long click etc. etc. etc. etc.
Multiple functionality of UI elements is almost the norm!
PooperPig - Coming Soon
|
|
|
|
|
I stand by my original statement, if you change it to an action on an element should have a single outcome then I am, as expected, perfectly correct. 
veni bibi saltavi
|
|
|
|
|
I wholeheartedly agree but, sadly, the hardware world has gone this way for cheapness and it looks as if some software designers imagine this is ok.
I honestly can't see the point of a reset button. The user should have enough gumption to alter any erroneous fields. Ah! There I go, assuming the user has a brain cell or two...
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
In one solution I had the same setup I gave the user the opportunity to turn off the warning (check on the message popup)...consider it...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Which is the correct answer. Don't force these things, but allow the user [or at least the client] to decide.
veni bibi saltavi
|
|
|
|
|
yeah - I implemented that for a couple of specific instances.
Issue then becomes whether to persist that over sessions, have a 'reset all' function somewhere, by user or machine, across the network or not ...
I suspect we will end p implementing this sort of thing across the applications, though.
PooperPig - Coming Soon
|
|
|
|
|
An age-old question.
- Add undo/redo buttons and the complexity of said implementation?
- Confirm the cancel, but give expert users a "don't ask me this ever again" option?
- Validate inputs as they are entered, or when the data is saved?
- Track change history, allowing the user to revert to a previous state?
etc...
Ultimately, it always depends on the specific use-case requirements. For example, when editing a wirelist for a satellite (tens of thousands of wires and connectors) we implemented all four of those, because:
- The user really wanted the ability to undo when they realized that there was a bigger systemic issue in the wiring
- New users would often cancel by accident (go figure) but expert users wanted to make changes as fast as possible
- People loved validation up front, but we also had automated wirelist generators and batch imports where data needed to be validated on submittal.
4a. For auditing purposes and revision control, all part of the overarching contractual requirements, we needed change revision tracking
4b. For cost analysis, we needed to be able to test several different wirelist models. And by "cost", I don't just mean $, but weight (mass, technically) is always a consideration, as well as complexity, creating test harnesses, etc.
Granted, creating a wirelist for a satellite is not your typical application, but it gives you an interesting example at least.
Marc
|
|
|
|
|
If you're worried about the dialog being annoying, then how about default behaviour to prompt, but include a "don't show again" tick box.
As is evident by this thread, everyone has different preferences, so this way the control is in the user's domain.
|
|
|
|
|
A good idea - but as I"ve said elsewhere, what preference do you save? The application probably has 50+ forms - so need a setting saved for each... and saved for the machine its running on, or for the user? If for the user, then how to persist over the network etc.
All easy peasy stuff once defined - but to retrofit to many forms isn't cheap!
PooperPig - Coming Soon
|
|
|
|
|
How about for the first time they click cancel, you prompt them and have a check mark to remember their choice?
|
|
|
|
|
Id rename "Cancel" to "Reset Form"
|
|
|
|
|
Hello Maxxx, I have very strong feelings about this subject! Were I god-of-web-design I would travel back in time and turn the programmer who released the
<input type=reset> feature into a newt. And there wouldn't be any getting better, either. I don't know this for a fact, but my guess is that it exists only to aid early HTML coders test their forms. There are very, very few scenarios where a casual user filling out a web form needs to reset it. I absolutely cringe whenever I see "reset" and "submit" at the bottom of a form.
If a web form is designed to be used by someone doing data entry there are plenty of ways to clear out the form when finished with an item. Banish reset, whether it's labeled "cancel" or something else. You never need it. You never need it. You never need it!
P.S. Labeling a reset button cancel is bad UI practice in my esteemed and unquestionable opinion. Canceling a form should take you away from the form page, or hide the form or otherwise make it not be there any more.
|
|
|
|
|
While it is generally frowned upon (today), if I'm targeting a large number of users and "data entry", I resort to "modes".
The default is "browse".
You want to a add a record? CNTRL+N (for example) to enter "new record mode".
etc.
ESC to cancel (or revert to browse mode); or CTRL+S to save; etc. ...
(With corresponding toolbar buttons).
The user has no doubts about what "mode" they are in and what their options are. And the perception that there may be "more" key strokes / actions involved is an illusion (since the app will always know where to put focus, etc.).
If I'm dealing with a custom app for a few users, then the standard is "their" standard / demands / requirements (with the appropriate arguments on my part).
|
|
|
|
|
is there room for some text near the buttons to explain what will happen? or longer text on the buttons themselves? 'Cancel/Clear Current Entries' or similar. i know people don't read but carefully done it could work and save on coding.
'Undo' instead of cancel could be useful too. but you would then need an extra msg if someone attempts to 'Close' a dirty form. (Edit: or not, if it's not enabled at that point.)
|
|
|
|
|
I would imagine the complaints from users would be about breaking up the flow of their work. Perhaps from a delay displaying another dialog and/or having to re-task their attention to another UI element.
Maybe a button control is a bit too basic. A left to right slider or circular control that has to be fully activated to discard changes?
Or perhaps a two step click such as click once, button goes orange. Very slight delay on a disabled button. Click again to discard changes or, after a couple of more seconds, the button reverts to its original state and the user carry's on with modifications to the data.
Not sure how well this will work. I'm no UI expert and just an idea off the top of my head.
|
|
|
|
|
Is it wrong that I'm sat sitting here rejoicing in this Christmas madness[^]!  Suddenly being on me tod and having nobody to buy presents or food for looks like a very good deal!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
