|
I've been using code to calculate UK public holidays for over ten years now.
Every system, everywhere I have worked, that was not created by me has a lookup table of the holidays, and at some point each and every one of them has failed to work properly because it has run out of data and taken time for someone to notice.
Although my code (not really my code, I borrowed it initially) did fail in Easter 2013 when it attempted to set Easter Monday as the 32nd of March. In 2018 it would have attempted to set Good Friday to -1st of April if the bug had not been fixed.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
I inherited a system like that. I rewrote it to generate public holidays for multiple countries in perpetuity. Unfortunately, it became a company mandated product used globally. Why was that unfortunate? Because they implemented a forked version that predated my mods and still required manual annual table updates. When I left the company in 2013, it was still waiting the manual updates for 2004!
P.S. I know that this is not a coding forum, but I have a nice algorithm for Easter that I have used since the mid 1970s. The version below was transpiled to JS in the late 1990s and is still in use today. Do not repost this to the Weird and Wonderful (aka Hall of Shame) forum - the unmeaningful variable names are from the original unoptimised version that I plagiarised based it on.
if (! Date.prototype.Easter)
{
Date.prototype.Easter =
function()
{
var year = this.getFullYear();
var a = year % 19;
var b = Math.floor(year / 100);
var c = year % 100;
var d = Math.floor(b / 4);
var h = (19 * a + b - d - Math.floor((8 * b + 13) / 25) + 15) % 30;
var mu = Math.floor((a + 11 * h) / 319) - h;
var lambda = (2 * (b - d * 4) + Math.floor(c / 4) * 6 - c + mu + 32) % 7 - mu;
var month = Math.floor((lambda + 90) / 25);
return new Date(year, month - 1, (lambda + month + 19) % 32);
};
Date.Easter = function(optYear) { return (new Date(optYear)).Easter(); };
}
|
|
|
|
|
chriselst wrote: Although my code (not really my code, I borrowed it initially) did fail in Easter 2013 when it attempted to set Easter Monday as the 32nd of March.
Curious as that year Easter was Sun May 5 2013 Easter Day
My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
