|
cpkilekofp wrote: I've seen what you suggest in actual implementation for truly critical application paths, and it has its place there, but for general use in all applications your user base would rise up in arms and depose you for a less educated but more practical developer.
If you're gonna argue, at least attempt to address the point I was making. You ain't. Thus, arguing with yourself you are.
cpkilekofp wrote: BTW, as part of my Master's Degree in Computer Science, I took the User Interface Seminar, so I'm familiar with the principles you expose. Many of them fail miserably in general practice because they interfere with getting things done as quickly as humanly posssible for the least cost, which are principles from another discipline entirely called BUSINESS.
Nice generic references there with no solidity. Btw, as part of my real life BUSINESS experience making multi-million dollar software instead of some intangible academia references where it's impossible to have 1,000s of users for your software, I disagree.
Please, continue spewing more generic fluff that sounds religious. Kids these days.
Jeremy Falcon
|
|
|
|
|
I've seen the point you're making numerous times. I've seen software successfully implement that idea. I didn't say it wasn't a good idea in many circumstances. When the decision to commit or cancel cannot be undone afterward, your assertion makes a great deal of sense. When the decision to commit or cancel can easily be undone, say, through an edit screen accessed later, it is far less critical, and when the goal of the interface is speedy manual input of large amounts of information, randomly changing the position of screen controls forces the operator to make time-wasting decisions. This is not acceptable in many business contexts.
Further, if you have two hundred items to change, that's two hundred points of failure you now have to test for, and that's a lot of man-hours you now have to pay for - and for what? Are you gaining in safety what you lose in time to change the code, time to test it, and time for your user base to get used to the new entry pattern?
Both of these points have to be addressed in order to justify to a business an extensive change like this. You justify the decision because the current control order "shows a complete lack of disregard (??) for standards and poor UI design" because "the whole reasoning behind Cancel | OK is completely invalidated by changing its order." How about some statistics? What is the level of acceptance or cancellation in error due to the fact that these buttons are in a particular order at all times in this application? In short, can you at least suggest a technique to prove or even support your assertion in a way that bears some resemblance to science and not doctrine?
Because that's what you are promoting - and yes, it does "sound religious", doesn't it? Nearly 30 years of development experience in businesses from four employee startups to 60,000 employee companies in the Fortune 100 has made me a development atheist - I don't believe it until I've tested it. Nor do I make decisions without considering the context in which the decision will be made and the cost of implementing that decision - I show a "complete lack of disregard" (that is to say, I place great regard) for the business consequences of a software doctrinal decision.
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
I've lost interest. Chances of me actually reading this: 0.5%.
Jeremy Falcon
|
|
|
|
|
LMAO kids these days have no attention span whatsoever.
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
I have a long one, I just don't value what you have to say. Ta ta.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Cancel | OK
Thanks Jeremy!!
I just finally understand what this 'OK | Cancel' order is about, after all those years! 
|
|
|
|
|
Will Rogers never met me.
|
|
|
|
|
|
He might annoy you and all the other devs, but he DOES have a point...
I've dealt with customers who wanted me to change my software because it was not compliant with the Microsoft standard (small things like the order of OK and Cancel, an icon etc.).
I'm now pretty keen on keeping things consistent with the OS I'm aiming at and, when there's no standard yet, keeping things consistent within my application.
Perhaps now your customers are used to it it's not a good idea to change it though... Although new customers may benefit from it.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Quote: Perhaps now your customers are used to it it's not a good idea to change it though... Although new customers may benefit from it.
Cost versus benefits...if your current user base is very small compared to the new user base, and your new user base is more likely to purchase your product if you change, then it may make sense.
These changes do not come for free.
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
To add to what Jeremy and Sander said, how do you know your users are used to it? If they use more than one application on a regular basis, your inconsistency with the established standard could already be irritating them - just nobody told you because they thought it "was just them".
Your QA guy has a point: standards are there for a reason - consistency!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
We switched the order internally for one day, and every single person that used it clicked Cancel at least a dozen times when they meant to hit OK, including the tester that wants it switched.
So, despite knowing about the change and being a regular user of other applications with the OK | Cancel standard, I had to consciously make sure I clicked the correct button, rather than using my "muscle memory" of clicking on the bottom right corner.
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
|
|
|
|
|
Colin Mullikin wrote: So, despite knowing about the change and being a regular user of other applications with the OK | Cancel standard, I had to consciously make sure I clicked the correct button, rather than using my "muscle memory" of clicking on the bottom right corner.
But they'll get used to it in a matter of days. That's like saying; "well we shot one foot off, may as well get the other." Tell them it's an enhanced feature to be Y3K compliant or something. 
Jeremy Falcon
|
|
|
|
|
Fine...YOU pay for it 
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
If Microsoft worked by that logic we'd still be using MS-DOS. Change takes getting used to. That doesn't mean it's bad.
|
|
|
|
|
In my experience if the form elements, like button, have some visual significance it does not matter where they are on the form. The eye goes after what it sees...
However if the design is flat (what is very 'cool' today) the standard place is a must-have for form elements.
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Now... before you go and do something crazy.... grab a camera and be sure to record it. We'll wait right here (for the vids)... 
|
|
|
|
|
Colin Mullikin wrote: that uses our software (thousands of people).
So say you have 10,000 users.
In 10 years how many of those same users will be using it?
How many new users will be using it?
If say 9,000 of 11,000 total users will still be using it have 10 years then I can see your argument.
However if after 10 years there will be 5,000 original users and 95,000 new users then the other person has a valid argument.
But other than that this is a requirement/improvement and not a bug so a QA role shouldn't be driving that sort of change anyways so their view is irrelevant and ignorable.
|
|
|
|
|
jschell wrote: If say 9,000 of 11,000 total users will still be using it have 10 years then I can see your argument.
However if after 10 years there will be 5,000 original users and 95,000 new users then the other person has a valid argument.
We are growing, but no where near at that rate. I'm just spitballing numbers here, but I would guess we have roughly 15000-20000 users currently and gain a little less than 1000/year at our current pace.
jschell wrote: But other than that this is a requirement/improvement and not a bug so a QA role shouldn't be driving that sort of change anyways so their view is irrelevant and ignorable.
We are a fairly small development team (~15 devs, 4 QA), so as much as I would like to agree with you, everyone kinda has their hands in everything.
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
modified 20-May-14 15:53pm.
|
|
|
|
|
At that rate (of new users coming in) I'm inclined to agree that changing any parts of the UI should better be based on a strong argument/benefit. If your numbers are halfway accurate, I'd not disregard this request entirely, but postpone it unto a time when you incorporate a major overhaul of the UI, or at least the dialog structure. Such redesigns are really helpful to keep up to date with modern UI standards, and to adapt to new OS versions - unless your company is SAP, of course
|
|
|
|
|
Remove the Cancel button.
Or how about one of those apps where the button moves whenever the mouse gets near it?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I prefer the latter!  Or may be a variant where OK and Cancel switch places when your mouse pointer gets near 
|
|
|
|
|
Acknowledge it is a bug and resolve it as "won't fix".
|
|
|
|
|
Alternatively, you could acknowledge that this has been raised as a defect and put a ticket in your bug tracking system. Now, don't just treat this as meaning you've finished with your responsibility. The action to come out of this is to investigate the impact of reversing the change - and this means talking to your customers. I pretty much guarantee you that this is a feature that would be greeted with joy by them. Do the maths, and see what the cost of making the change would be.
Finally, someone in authority needs to decide whether the cost of the change is worth it. If the answer is no, then you have the ticket to smack the tester with.
|
|
|
|
|
In my experience the customers rarely know whats good for them. Microsoft realized that a long time ago and keeps pushing changes that many beta testers vocally argued against. Sometimes the beta testers turn out to be right. But just as often they're wrong.
In the end, it probably doesn't matter all that much which way you go - just don't waste too much time discussing it. The worst decision is always no decision!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
