|
I have code to calculate easter in VB6! 
|
|
|
|
|
A very good example of why I always cringe when someone argues with me that "there's many ways to implement something." 
Marc
|
|
|
|
|
Yeah and of course the only right way is their way. 
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
'Tis the season! - Holidays 2015 (Day 1) Google Doodle
The Search Google is showing this Doodle on its homepage on 23rd December, for marking the Holidays. It is the first Doodle in the 2015 Holidays Doodle Series.
In this Doodle, the Doodle artist Robinson Wood has created several festive characters and items that were inspired by papercraft models and cut outs.
'Tis the season!
|
|
|
|
|
|
Today is my last day at work until I return in the New Year. I wish you all a very Merry Christmas and a happy New Year. May your festive season be a peaceful one 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Same here....Wish you Marry Christmas
|
|
|
|
|
Data Entry/Maintenance Form.
Cancel/Close Button, Save Button.
When form is dirty, Button reads Cancel, and action is to clear the form back to its initial state & make it 'clean'.
When form is clean, Button reads Close, and action is to close the form.
Question:
When form is Dirty, and Cancel invoked, should the user be warned about losing changes, or should the form just be cleared?
While I actively elicit your input, arguments etc. I'd be especially interested in any standards/studies that you may be aware of.
FWIW My 2c would be that they should be warned as they are about to lose data - and use of this to abort entry would be in the minority, so inconvenience is minimal.
PooperPig - Coming Soon
|
|
|
|
|
I suppose this has to do with how much typing effort the person has to put in to fill out the form.
If it's mostly drop-downs and there's no heavy typing, then it would be OK to just clear the changes without a warning.
However if there's lots of typing involved, then use a warning.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I tend to agree- but trying to come out with a standard for future development;
Don't really want different behaviour across forms.
PooperPig - Coming Soon
|
|
|
|
|
|
Interesting; why do users keep entering data and changing their minds - apparently often enough that having to confirm it pisses them off?!
PooperPig - Coming Soon
|
|
|
|
|
You want my users, you are most welcome!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I can only echo the opinions of my wise peers, Richard and Mycroft, and say that the use of confirm-to-cancel might be indicated when the user has done significant "work" on the Form, but ...
1. saving state: in many cases I think saving the "state" of the current UI, and any data, is a good thing: what if I need to "go somewhere else," and then come back to working-on the modally shown Form: that, of course, requires me to close the modal Form. Why make me pay a penalty for interrupting my work ? If you give me a 'Clear button, how about assuming I know when to use it ?
And, for bonus points, why not show by some visual indicator whether data-entry controls contain valid data ... or not ?
2. also consider: if you are using a confirm-as-you go model where each time the user changes focus in the modal Form the current data control is validated: you have the means to "estimate" (depending on the specific Form and its context) "work done" by the user.
And yet: I think attempts at generalization break-down in specific cases: in a log-in Form I would not want to "save state" when it's closed, and restore it when it is opened. And, imho, saving state at run-time during one user's session is one thing; saving state of data-entry Form controls when the Application is closed quite another issue.
cheers, Bill
«Tell me and I forget. Teach me and I remember. Involve me and I learn.» Benjamin Franklin
|
|
|
|
|
In the applications I am responsible for there are two conflicting paradigms.
One - A Close button becomes a Cancel button once the form is dirty. Clicking Cancel clears the form and changes it into a Close button. Clicking again closes the form.
Two - same scenario except a warning (Are you sure you want to cancel) is applied.
In neither case is it likely the user is 'stepping away from the form for a while' to return later to continue.
Retaining state is a minefield - where to you save it? Is a 'Contact' record, containing valid data that a user has never actually saved, still a valid contact? What if they come back to the form and click cancel?
Usually (in the sorts of applications I am talking about) the user has some sort of entry document and is entering the information into the system - so I guess they may cancel if they suddenly realise the info is wrong, or insufficient to enable them to continue - but I figure cancelling recent input is pretty rare.
but I can imagine, say, they are part way through entry, drop down a combo then want to 'undrop' it - so press (mistakenly) cancel. Instead of the combo disappearing, they lose all of their data entry.
and your comment on a log-in form? well, I actually think that is one case where it is, in fact, useful to save state! vis "remember me" web pages.
People tell me that users complain if they have to OK a dialog to confirm cancelling input - but I wish they would ask those users why the hell they are entering data they want to throw away in the first place!!
PooperPig - Coming Soon
|
|
|
|
|
I'm afraid we are in such different "zones" in terms of UI design, and user-behavior assumptions, that I can't really assist you here.
Which in no whit diminishes my respect for you as person, programmer, and hierophant of the coming epiphanal eschaton of the reincarnation of Pooper Pig
Merry Xmas, Bill
«Tell me and I forget. Teach me and I remember. Involve me and I learn.» Benjamin Franklin
|
|
|
|
|
BillWoodruff wrote: I'm afraid we are in such different "zones" i
We're using Prism, so it's "regions"
Unfortunately I am currently constrained by a rather poorly thought out design across three project -and the business is pushing UI standards on to us, which I am vainly attempting to validate
I had to look up "hierophant" and giggled at "epiphanal" until I corrected my mind's pronunciation...
And PooperPig shall rise, and they shall say "Lo! It awakes!"
And the world will tremble.
Have a cool yule!
PooperPig - Coming Soon
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
