Slashdot Mirror
Ask Slashdot: When Is the User Experience Too Good?
gadzook33 writes "I had an interesting experience at work recently. A colleague suggested during a meeting that we were building something that would make it far too easy for the customer to perform a certain task; a task that my colleague felt was deleterious. Without going into specifics, I believe an apt analogy would be giving everyone in the country a flying car. While this would no doubt be enjoyable, without proper training and regulation it would also be tremendously dangerous (also assume training and regulating is not practical in this case). I retorted that ours is not to reason why, and that we had the responsibility to develop the best possible solution, end of story. However, in the following days I have begun to doubt my position and wonder if we don't have some responsibility to artificially 'cripple' the solution and in doing so protect the user from themselves (build a car that stays on the ground). I do not for a second imagine that I am playing the part of Oppenheimer; this is a much more practical issue and less of an ethical one. But is there something to this?"
I assume you work for Zynga?
Are you sure you want to delete that file?
If your interface would allow a user to shoot themselves in the foot without proper precautions, then your user experience is, by definition, *not good*.
The goal of any application is to let the user perform a function FASTER than manipulating the data themselves, manually. If your UI enables the user to destroy a significant portion of that effort easily, then you have failed to achieve your goal.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Who is the target market for your product?
If it's for Joe Sixpack, and he might metaphorically poke out an eye with it, then maybe.
If it's for system admins and the like who neither need nor want training wheels, not so much.
You certainly can expose too much functionality to people who shouldn't have it. But you can also make something useless to the people who actually do need to do it.
Lost at C:>. Found at C.
If it were a case of causing physical, emotional or economic harm, possibly.. but if it just makes aunt sally think she's a programmer, where is the harm in that?
He tried to kill me with a forklift!
I suppose this is the rationalization that Apple uses internally to justify their walled garden. Gotta protect users from themselves whether they want it or not.
Rather than being assholes like Apple, perhaps you could make this configurable in some fashion? Whatever the hell "this" is?
I can't imagine a UX issue ever being apt to giving everyone flying cars.
Plus why are you asking the FOSS crowd about UX? Have you seen the GIMP?
Have you ever tried to unlike something? It's not easy and I'm sure it's that way by design. Feature must be there, but obscuring it makes people unlike less pages. This is profit driven decision.
I see this more of an area you can utilize roles and only give properly trained people who know how to "fly" the car access to do so.
So utilize an annoying animated Paperclip that asks the user if they are sure they want to do that three or four times.
This is just like every time software asks you, "are you sure?" before deleting a file or record.
Since 1984.
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
Are we talking about a Wernher von Braun "The rocket worked perfectly except for landing on the wrong planet." kind of experience, or disable ads kind of experience? Why wouldn't you want your users to have a good experience? Are you making spy software and making too good?
http://www.youtube.com/watch?v=EDv0W3peMxM
NO... a better user experience is better. However, if what you're doing leads the user to an experience that is NOT what they wanted to do, then it's NOT a "good" user experience. There was a cartoon, pre-web, with two unlabelled buttons on the wall... this one turns off all the lights, that one destroys the world. Easy to turn off all the lights, but also easy to make a fatal mistake.
Wordpress has a 'shoot-yourself-in-the-foot' option in the admin settings. You can just enter a path to point your entire Wordpress site to a new root folder... which if you get wrong means you can't access your settings anymore to change it.
Put a button that toggles your program's "dangerous flying car" interface, with a nice warning about they can now wipe their system with a single click, and you aren't responsible if they misuse the software.
The flying car could be a couple of different things:
(1) Flexibility to adjust parameters in your system allowing end users to customize or tweak things to their heart's content.
(2) An intuitive way to interact with the system, that does not increase or decrease the scope of access to parameters in the system.
In #1 above, there are many possibilities beyond those you may have considered or tested. Are all possibilities going to work, or will most users get confused or bewildered by the complexity of the system?
In #2 above, there is essentially no risk in giving the user the flying car. You will empower them to do things in a more intuitive manner, without letting their level of confusion or bewilderment be increased.
The reality probably lies somewhere between #1 and #2 above. By looking at these as opposite ends of a spectrum, perhaps you can see your way through to a compromise that looks more like #2.
Yes, there is. Part of the UI is to protect the users from inadvertent operations. That's part of why various destructive operations in programs have the "are you sure?" dialog box. The good ones also have a checkbox that says "Don't ask this again". There's a difference between making it hard to do a task, vs preventing the task altogether. There may be legitimate reasons why one may need to do the said task. Also, provide a way for the user to consciously remove the speed bumps you're putting in. I don't mind software that wants to hold your hand by default, but I want a way to tell it to get the heck out of my way and let me do my task.
This is a debate that has raged ever since the first user mod was made for Minecraft: ease of use vs. making life too easy.
On one side you have people praising you for making things easy for them, and on the other you have people accusing you of cheating them out of a sense of accomplishment. (The latter are, in return, frequently accused of being autistic.)
Ultimately I don't think it's the developer's place to decide if something is too easy. Your attempts to correct this "problem" will always be to the detriment of your users.
We can't know what it is you're creating, but it's akin to giving everyone a flying car.... Yet we are supposed to answer if that would be bad or good when we don't what your product is? When your question is already hard to read.... I honestly don't get what is going on with Slashdot anymore.
How is this is even answerable? Am I missing something here?
Learn to think in the wiki way.
Rather than make it hard for users to do what they want to do, on the (very valid) assumption that some of them will do bad things, or things they don't really want to do, it is better to make it easy for users to recover from those mistakes, and for others to recover easily from any side effects of those mistakes.
This is not always possible. But it usually is.
Jimmy Wales - Wikipedia.org
Wikia
Remember when Slashdot featured interesting news articles rather than stupid questions from stupid people? Pepperidge Farm remembers.
I've heard this before and every time it was about letting the software bypass some business rule important to an external process.
Well yeah of course I could let you add a negative Debit for an Asset but your accounting department will come at you with sharpened coffee mug or something.
Well, I guess the other time I hear "this software is too good" usually comes from sales and it makes my skin crawl every time.
crazy dynamite monkey
... bring Gandalf, the Wizard, to guide the user into making sure the user understands how to use it properly. For examples that fit the car analogy, look into aircraft autopilot systems, or Google's self-guided cars.
I don't want my cat walking across my keyboard/trackpad to be able to format my hard drive. Making an improbable action easy to take is pretty much the opposite of a good user experience (especially when it has consequences).
Don't make it real easy for an untrained user to shoot him/herself in the foot.
Now, what about "rm -rf *.*"? An untrained user wouldn't run that command unless they were coached, or it was part of someone else's script (app).
With software, I think too many things are considered in isolation, without considering the impacts of what's being done. The features themselves should be good, but so should the impact.
For instance, if a forum has the optoin to report users for spam, phishing, and other nefarious activity, and it's really easy to use, this is good. However, if some part of the process makes it likely that the user being reported will be inadvertently added to the reporting user's friends list, bypassing all filters, then something about the reporting feature needs to be changed. Whether it's an acceptable trade off to lose some usability or fun of a feature to prevent bad things from happening is a judgement call. It the OP's case, it's impossible to say for sure because we lack details, but there's nothing at all wrong with considering whether or not a feature has unwanted side effects.
Ease of use and good user experience are not always synonymous. In most cases they are, but if you're making it easy to do something that can't be easily undone, someone will do that accidentally and then have the frustration of fixing that. For example, I was recently working on allowing some software to interface with a connected scale. One of the things you can do through that interface is tare the scale, but after implementing that I decided that it was too easy to accidentally hit the tare button instead of the weigh button with the consequence that the person using the software would then have to re-tare the scale and re-weigh to get the correct measurement. So I took the tare button out figuring that people would generally rather do that at the scale itself anyway. I'll probably put it back in at some point, but it will be a little harder to hit that accidentally when I do. Your example is too vague to say who is right in your particular case.
Remember RFC 873!
Monetize it. Sell the "car", but if someone wants their "flying car", that's $25 per mo. extra.
If your interface would allow a user to shoot themselves in the foot without proper precautions, then your user experience is, by definition, *not good*.
What if the user interface lets them shoot everyone else in the foot at no cost to themselves, while accomplishing their task quickly and with ease.
It's a great user interface from the user's point of view, but a really terrible system to have.
SJW n. One who posts facts.
"If your UI enables the user to destroy a significant portion of that effort easily, then you have failed to achieve your goal."
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
It is acceptable to try to dissuade them. It is acceptable to warn them. But document it when you do. And if they still want it despite all your warnings and attempts to convince, then give it to them. That's what you're getting paid for. If they complain later, show them your documentation and where they insisted even though you advised against it.
I once worked for a company that demanded the ability to do X in the software, despite my warnings that it was a bad idea. So I put in confirmations. When they first clicked the button to do X, it first popped up a message saying "This will result in _____. Are you sure you want to do this?". If they clicked Yes, then another confirmation popped up: "Are you really sure?" And if they clicked yes again, a third confirmation popped up: "Are you really, really, REALLY sure?"
An administrator mentioned to me later that he thought the warnings were funny, but he liked the fact they were there.
You User Interface design should take account of the users. Some users want to be able to type rm -fr * and others want six modal dialogue boxes warning them not to do it before it happens..... Know your users, then define your interface :-)
We can argue the exact extent of the responsibility and how strongly to favor the group over the individual (or visa-versa), but the consideration is very real.
-1, Too Many Layers Of Abstraction
It's a good idea to help protect the user from themselves. But is it really difficult to give a warning message saying 'Be careful....blah, blah are you sure you want to proceed?'.
Also have a simple mode, and an advanced mode, then let the user decide whether they want more power. You don't have to force a single ideology upon anyone.
Why OpalCalc is the best Windows calc
that asks you I see you are trying to do X do you need help?
First up, making features artificially bad is not only a badtechnical case, but its also a bad technical case. We engineers have a tendency to thibk that othet littlings aren't as smart as we are, but give them a week or two with the new system and they'll adapt. Then again, your flying car analogy is inaccurate. As an aerospace engineer, flying cars need to be autonomous. That will reduce training, so wrong assumption on your part. As for regulation,heard of GPS? Safety, hmm... How about a parachute that is deployed by rockets when the power goes out, akin to canopies popping out of fighter planes in peril, as found in the terrafugia models? Wrong analogy and wrong assumptions.
No.
What business are you in -- product development or behavior modification? Hint: one of those is good for your bottom line; indulging in the other is deleterious to it.
If you're concerned about inadvertent consequences, make sure there are adequate warnings. After that, you're done.
How about stop trying to mold your users, remove your head from the cloud and help reverse a numbifying trend by thinking about something concrete - UI design instead?
Design a UI which teaches users, and let them create the only experience which matters, their own, thank you very much
One wonders if the fine folks at Google had this thought before they released ContentID for Youtube, and made the content removal process amazingly easy for content providers to stifle free speech and fair use.
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
What if the ability to do X harmed others?
The Kruger Dunning explains most post on
Really really hard to say without knowing the specifics of the project. I we're talking in abstracts, then you can argue either side and be correct. Without actually knowing what the project is, however, it's kind of an academic exercise. ie. Won't give you much actionable input in the real world, if that's what you're looking for.
This signature has Super Cow Powers
The question isn't how easy it is for a user to do something bad; the question is how easy is it for a user to inadvertently do something bad. If the application is properly designed, all tasks should not only be easy to perform, but easy to perform accurately. Presumably, this deleterious task is something that does potentially need to be done, so it should be easy to do. But it should only be easy to do if the end user actually wants to do it, and not easy to do if the intention of the end user is to do something else. Your problem as a designer is to figure out how to accurately assess the user's intent.
I make ze rockets go UP,
who cares where zey come DOWN!
Zat is not my department".
says Wernher Von Braun.
http://www.youtube.com/watch?v=TjDEsGZLbio&feature=youtu.be
(Tom Lehrer)
Chapter 1 of Spolsky's "User Interface Design for Programmers", which is basically this article from his site: http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html/. You should try to decide for yourself how much this applies to your situation, but there's another set of articles, one called "Choices = Headaches" that you should look at as well. You may not agree with everything you read, and you won't get a simple answer to your question, but these will be food for thought.
Agreed. At the end of the day, those who write the checks get what they want.. I was speaking more of the theory rather than the practical.
In those situations where I've recommended and warned against the functionality, and the user still demands it, I have considered it more my failure to communicate the risk than the user's failure. But, as you say, I wanted to get paid so I delivered what the user requested.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
I'd say build the feature and deal with the consequences in an evolutionary fashion. To use your flying car example, if everybody bought a flying car, there would quickly arise a need for regulation and airspace control - and that need would just as quickly be filled. Even in your hypothetical situation where there's no mechanism for regulation and control, if the problem got out of hand, someone or some organization would quickly create that mechanism. The end result would be that people would have their flying cars, but only be able to operate them in a restricted but safe fashion. That's still better than not building the flying cars because you're afraid of the consequences.
So I'd say build whatever it is, and let things adapt as necessary to deal with the consequences.
It's simple, really: either your users should be doing it, or they shouldn't. If they should, it should be easy to do. If they shouldn't, well, they shouldn't. Any gray area just means you need to better define the parameters.
Mod parrent up.
Think about the typical user – then subtract 20 points of IQ. It is always somebody's first day.
Think about the the worst case scenario – what is it and what is the overall effect.
I have found a good method is to have a “user” mode and a “admin” mode when the stakes are modest to high. Everybody uses the user mode which, in your case, would keep the car on the ground. If somebody needs to take off they can enter admin mode – but it is clearly in admin mode. And add lots of soft stops – power users always think more then they actually do.
This sounds entirely too much like IBM in the 1960s and 1970s. The user really didn't need to know how things worked; IBM would take care of them.
I would agree with this. If the user can do something very easily, but it turns out that may not have really been what they wanted to do (and there is no way to undo it), then that is not a good user experience.
Stakeholder management needed. Bring in the users, the people who are managing the users, etc, and ask them.
Quality is defined as the degree to which a deliverable meets requirements. If the feature, as-is, meets requirements better than the feature not-as-is, then this is the best situation. Imagine if rm didn't offer a -f option. I have this source code directory, a git clone I no longer need... rm -rf and ... yes ... yes... yes... yes | rm -r and I get "screw you for piping stuff at me!" Shell scripts suddenly suck because rm operates in -i by default, even in shell scripts. This is not a quality rm implementation because it fails a ton of usability requirements; but it'll stop me from shooting myself in the face, right?
Support my political activism on Patreon.
So you were responsible for the Windows Vista's endless warnings.
Time to offend someone
But if the action can easily be undone, then keep it easy to do.
If you are talking about something like permanently deleting a database, then YES, MAKE IT HARDER.
excitingthingstodo.blogspot.com
It's obvious that you can't put every tool in the hands of every consumer. This is a subset of the fact that a certain level of technical control isn't fitting or wise for every user.
All the same, I believe the best app offers the most power to the user, even if that takes awhile longer to code in.
The best app offers the most controls no matter what. And "no matter what" does qualify you to place them behind some "advanced options" control, or inside a plain text (or, why not, hexadecimal) config file, or in a registry entry, or wherever you need to hide it to feel that it's safe from "everybody but not everybody-everybody".
If it's freeware, consider charging for the added feature, and even requiring the customer send in a handwritten form with their tax ID and other business credentials, and signing their agreement to a series of legal disclaimers. Then you'll have their alleged good-will in writing, too, and protect yourself from damages.
Or, make it an undocumented command-line option. Then you could tie the user to having to settle with whatever they set this thing to for that session, and they couldn't just variably change it mid-session. And, if they want to know how to get to the solution, they can ask the company and the company can tell that customer how to get it done.
Is it a Windows app? If you have any pangs of guilt, I believe an "allow advanced features" checkbox that forces the operating system to validate their administrative credentials (even if it's not necessary for the purposes of the app's interaction with the operating system) is a decent enough way to go.
"Stratigraphically the origin of agriculture and thermonuclear destruction will appear essentially simultaneous" -- Lee
"Trigger Locks"
Sometimes, a point-and-click interface is too simple.
In a UI class I took, we learned that you should focus on 3 (main) things when designing a UI:
- Learnability
- Efficiency
- Security
Often times, you'll have to make design trade-offs between the three. Look at the slides I link to to learn the differences (you might want to look through all the slides for the class, some good stuff there):
http://stellar.mit.edu/S/course/6/sp13/6.813/courseMaterial/topics/topic2/lectureNotes/L02-learnability/L02-learnability.pdf
http://stellar.mit.edu/S/course/6/sp13/6.813/courseMaterial/topics/topic2/lectureNotes/L04-efficiency/L04-efficiency.pdf
http://stellar.mit.edu/S/course/6/sp13/6.813/courseMaterial/topics/topic2/lectureNotes/L05-safety/L05-safety.pdf
All slides (I believe it is open to the public):
http://stellar.mit.edu/S/course/6/sp13/6.813/materials.html
If it needs to do something critical or troubleshoot something make it easy and obvious to take the appropriate steps. Don't obfuscate controls or code.
The only reason you might want to tone down these things is if it makes the software too complex by overwhelming a user with options. Even then it should still be easy to get the more advanced functionality.
This is my number one pet peeve with software. Windows included. The network dialog for wireless connections gives back no sane feedback unless you click through 4 or 5 dialogs. Because Microsoft believes "You do not need that information". Well how else am I to figure out what my NIC is doing?
Anyway. The more deep and open your softwares interface is. The better it will be.
I can create an application that displays a big red button on the desktop which, when pressed, will completely wipe the hard drive without an annoying modal confirmation dialog box. Sure it'll give great "user experience" to those that would like to wipe their drive but is that reason enough to install and use something like this on a daily basis?
Giving users easy access to something destructive is not good UX design. It's the definition of bad UX design.
Quality is defined as the degree to which a deliverable meets requirements.
Ever notice that when you deliver something, they've managed to change the requirements?
I don't have mod points today so I'll just say I like your attitude. :-) This is, in my opinion, a professional mentality.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
I suppose this is the rationalization that Apple uses internally to justify their walled garden. Gotta protect users from themselves whether they want it or not.
Yes, the users don't want that sort of product, which is why Apple's products sell so poorly despite being so cheap.
This is the sort of braindead thinking that leads rm to really being rm -i on so many server OS.
Sometimes I really do want data gone faster.
If your interface would allow a user to shoot themselves in the foot without proper precautions, then your user experience is, by definition, *not good*.
I would respectfully disagree. I would much prefer a way to unshoot my foot than be bothered by "proper precautions." Why does every action have to be so final? It's not like disk space is at a premium anymore. I know, that programming an undo is hard and tedious, but it's far more helpful than constantly putting up warnings that people learn to ignore.
A lot of times you build a UI and you can do a lot of things. I have worked on systems that have many, many ways to configure them. A good UI guides the user down the most likely path while allowing an advanced user that needs something specific access to what they need. An example is a windows property window. Many of these have an "Advanced" button. Most users will only be interested in what is on the initial window, but advanced users could access what they need. You could put everything on the first window, but that actually decreases the value. So you may have things you want to have configurable, but you don't want to make them extremely visible because it makes more important things less visible.
...and the lawyers will love you.
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal. What if the ability to do X harmed others?
Many companies exhibit sociopathic behaviors in pursuit of maximizing shareholder value.
If you want news from today, you have to come back tomorrow.
Not to use the flying car analogy again, but a lot of systems that used to be manual are now automated in aviation, shipping, or in power generation. On the surface, automation should make us all safer, but it creates new hazards. To take aviation as an example, earlier a typical aircrew consisted of two pilots, a flight engineer, a navigator, and sometimes a radio operator, etc. They were all very busy and involved in piloting the aircraft. With automation, that aircrew has been replaced by two pilots who are really there to monitor and make some good decisions when things go wrong. But many studies have shown that humans are really bad at monitoring things and a lot of modern mishaps have inattention, or lack of good airmanship as casual factors.
It should be noted that your whole post has the caveat "unless someone could get hurt". Working in heavy industry, we quite frequently tell our clients "No, you do not want X. X does not make sense, and you will hurt yourselves. You want Z instead." If the client insists, we stop doing business with them. If the crane you built collapses because the customer wanted a "press here to collapse crane" button, nobody is going to give a damn that you have documentation proving the client really really wanted the button.
When it comes to health and safety, the customer is not always right.
Everything is better with chainsaws.
That is just an alias and easy to fix, but yeah a huge PITA.
I can see it on a desktop but on a server OS that sort of handholding should not exist.
Pure innovation is dead. Litigation and the resulting liability has killed it. Unless you want your career to follow, you can and should CYA whenever and wherever possible. A sad, but very true fact of our world today.
This sounds like a question more pertinent for your legal counsel to answer, and let them be the judge on whether this is a practical, moral, or ethical issue.
Then it still has crappy UX, because "everyone else" are users too.
I worked making industrial control software for years. The system that we controlled was large and complex, lots of moving parts, hydraulics, pneumatics, tonnes of moving aluminum and steel tens of thousands of electrical connections and hundreds of sensors. We found that if we automated the process of setting up and running a test with this system the operators would ignore mechanical problems (worn break pads, low hydraulic fluid, bent aluminium) because they just saw the system as static and never changing, like a dvd player. Push button, make go. But if you prompted them for input that required looking at data and assessing how the system was performing they became more aware of problems, so they could be tweaked before things got so out of hand that parts started breaking.
Do a job that let's your customer destroy their own data quickly = getting paid once 'cause they won't hire you again.
Do a job that protects your customer from themselves (and making sure they know it) = getting paid for this job and the next ones they give you.
If you are just a code monkey pounding out code to spec- then sure. Shut, up do it, get paid, and then get replaced by someone in India who will do the exact same thing for a quarter your price.
If you want to help your customer and improve your business (and if they do well odds are better you will get even more business from them) then you let them know of the risk and offer suggestions to mitigate it. Now you've shown you are proactive and willing to help out. Which customers usually like.
It makes me remember when MS brought NT server in the market. A server with a GUI! Before that, there were only Unix, Netware and the like, and administrative tasks were carried out from a text console only. We were prudent. I thought using icons and a mouse would make these tasks too easy, it would prevent sysadmin newbies from really understanding what was behind the checkboxes, and it would make mistakes more frequent.
I wasn't totally wrong, but well, I must admit that GUIs help...
If your interface would allow a user to shoot themselves in the foot without proper precautions, then your user experience is, by definition, *not good*.
The goal of any application is to let the user perform a function FASTER than manipulating the data themselves, manually. If your UI enables the user to destroy a significant portion of that effort easily, then you have failed to achieve your goal.
it sounds to me that there was a "good for who" discussion in the company.
if it's something like making unsubscribing hard or so.. or send a message to everyone in-game. so, is it good for the particular user but not others? in that case, it probably doesn't make much difference if it's hidden in menus, if it can be abused to annoy other users and the whole feature would need a rethink.
then there's modern services, where getting the user to log in is viewed more important by the company than the user using the system - so they might opt to make it hard to turn off social network sharing of activities(to advertise the app), the user would view that as bad of course but the company as good.
if it was just protecting the user from shooting themselves in the foot I doubt he would be having second thoughts about it, it's probably something that will be pretty obvious and annoying to a "power user" but that's something they don't want to guide the users to do, it's easy to have second thoughts about it because if it's not protecting the user but just trying to get stupid users to do something beneficial for the company then it will annoy the power users and core users and ultimately at some point the newbie users as well who learn the system later, because there's a chance it will make the company look like greedy bastards.
world was created 5 seconds before this post as it is.
No, it's not. Existing rm implementations have a -f flag. What if -f was removed because people are stupid and rm -rf / a lot?
Support my political activism on Patreon.
Please correct me if I'm wrong, but doesn't the bittorrent protocol contain a "feature" that prevents a client from being a 100% leecher, and requires all clients to offer some data for upload while the download is in progress?
Or do some bittorrent clients exist that would allow me to completely disable uploading, which would protect me from legal liability for unauthorized uploading?
If I'm right, then it means that the bittorrent protocol was "crippled" (i.e. subjecting me to increased legal liability) in exchange for increased sharing of data.
Can somebody confirm this? Or correct me if I'm wrong?
Writing software has to be about more than getting paid.
For instance: Remote start cars are awesome. Putting a remote start in a manual can have unintended consequences. For instance, the car might jump forward crushing a person between two parallel parked cars.
True story, and actually, the designers of that software were sued.
At some point liability for your code will fall back on you, and it's your responsibility to say no and not take the money if you are actually creating a dangerous situation.
Think BitTorrent clients. It will always be technically possible to download without uploading, but should the client make it easy to do this?
The obvious answer is to add "Are You Sure?" popups to the UI . . . Users love those.
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal. What if the ability to do X harmed others?
Many companies exhibit sociopathic behaviors in pursuit of maximizing shareholder value.
See also: fast-food industry, oil industry, pharma, music industry. The list is infinite.
You're perfectly valid in questioning whether a user interface task should be throttled to counteract the ability to be about to dangerously do too many things too quickly. This is common with electrical systems where you need to de-bounce a button such that a switch state can only be changed if the change in state lasts longer than a few microseconds and that you can't repeat a button press for a different value of other few microseconds. In analog systems, this filtering is called hysteresis. You're filtering out the input noise so that intermittent transient changes in input value are filtered out if they do not exist long enough to change the hysteresis system to a different state. Much like many other electrical engineering principles, this can be applied to digital systems very easily through timers and event states and there doesn't exist an actual analog component if the system is a UI.
You know, all engineering fields have faced this question, and there is a correct answer.
IEEE Code of Ethics, Â1 and Â9.
Do not endanger your client. If a feature is that dangerous, either it should have every safety measure required to make sure only a deliberate, informed decision to use it can happen, or it should not be possible to do it in the first place.
Ref. http://www.ieee.org/about/corporate/governance/p7-8.html
There is a vital difference between user experience and user results. Where the result will land is a matter of the project itself. The user experience should always be good, but the results have to rank higher than some conveniences. Beyond those vague criteria, I have little I can add without more specifics on the project itself.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
What do you mean no it's not? Did you have trouble fixing it?
Actually many servers now protect against that actually. Again very annoying.
...If your UI enables the user to destroy a significant portion of that effort easily, then you have failed to achieve your goal.
Uh, that's a bit extreme of a mentality. Shift-Delete and rm -f still exist today. Users shoot themselves in the foot all the time. IT professionals are there to bandage that foot and teach them how to not do that again. Warning messages and pop-ups sometimes help, but not really with the attention span we have today.
At some point, user responsibility kicks in. Now liability on the other hand, is a whole other legal nightmare to address.
Ever delivered something which met the formal requirements and had them say "well, that's not what we wanted"?
There is often an unbelievable disconnect between what users tell you they want versus what they actually really really wanted but had no idea until it was too late.
End users will often help you design unusable software which is exactly what they asked for.
Lost at C:>. Found at C.
Build it. We have cars that fly. They are called airplanes. J. Random Citizen cannot just buy a plane and fly it. In the early days of aviation they could. But it quickly became clear that some form of training and licensing was required. If it is anything like your analogy, sure -- not everyone will be qualified. And they may put other people in danger. But we have laws to protect us from the most egregious idiocy and the regulatory framework, if needed, will be put in place quickly enough. (I say that and yet believe that we should have already instituted a "port 25" license, a "port 80" license, an "amateur internet operator license", and a "white hat security" license.)
the growth in cynicism and rebellion has not been without cause
Since you felt it would be tedious to explain specifics, you create a huge hole in our ability to give you a serious answer that is relevant to your situation. So to speak on a purely generic level, there's no such thing as too good a user experience.. The notion that you might make the user of your product TOO happy, or make their lives TOO easy, is the sort of sadistic logic that I would normally attribute to someone whose just shitty at developing user interfaces and wants some kind of perverse rationalization to justify their shortcomings.
However... this whole "flying car" analogy leads me to believe that you're not really talking about "user experience" in terms of user interfaces, ergonomics, and the like. It seems to me that you're talking about feature sets and what you are empowering the user to accomplish with your software. For example, some advanced text editors may enable global search and replace. That same text editor may support using regular expressions in a variety of ways. With this hypothetical text editor, it might be possible to combine the application of these features and modify dozens of critical files in unexpected ways, really wrecking the local PC.I'm wondering if this is the scenario that's really behind this question? If so, referring to this as "user experience" is misleading.
I'm fully in agreement that you want to be careful about what sort of capacities you grant the users of your application. If that particular feature has a crappy risk/benefit ratio, then drop it altogether. On the other hand, if you have powerful but risky features that you believe the software needs, then you should be working hard to improve the user experience in such a way that inexperienced users don't stumble across those features accidentally. Although I have personally railed against Microsoft's history of nesting options under multiple layers of dialog boxes, part of the intent there is to segregate "power user" options where they will not distract casual users from the features they actually care about.
Microsoft, Tivo, Sony, and EA have all acted in the 'best interest of customers' by crippling their users experience to some extent. based upon their past actions, you may be mistaken in assuming your user isnt intelligent enough to not only sidestep your endeavors but challenge your hubris as well.
Good people go to bed earlier.
Not if you demand payment in advance.
Paying taxes to buy civilization is like paying a hooker to buy love.
Yes, there is, and it's well-known in the field of usability, etc.
The very short summary is that humans have various decision circuits. Some are made for snap-second usually-right decisions and some are made for well-thought-out and as often right as you can hope for ones.
Many technical systems are intentionally designed to be just slightly more complicated to use than is strictly necessary, in order to force the user to slow down so the slower, but more reliable, thought processes have a chance to activate.
Assorted stuff I do sometimes: Lemuria.org
exactly in the "flying car" thing you would put the control to enable flightmode
1 Inside the GloveBox
2 require a special key THAT MUST BE PURCHASED SEPARATELY be inserted (and the key burns out after say 18 hours)
3 require that the car be accelerated to say 70 mph (in first gear)
4 have special warning lights light up (maybe aircraft style red and blue? strobish things)
in short make it so that Legal is satisfied that flightmode will not enable by accident
Any person using FTFY or editing my postings agrees to a US$50.00 charge
I don't think IQ goes into the negatives.
Paying taxes to buy civilization is like paying a hooker to buy love.
http://www.youtube.com/watch?v=EwTeiFm-ETI
Or um... not.
I think the real problem with warning messages is that they're so overused that people ignore them. If UI designers had saved warning messages for things that were actually important ("You're about to delete a file") rather than stupid things ("You are loading a web page with unsecured elements") then people might actually pay attention to them.
Hell, back when Vista first came out I had to go through FOUR, yes four UAC dialogs to create a folder in program files and rename it.
I don't think remote start was the issue as much as poor software design, i.e. not disabling the feature if the car is in gear. (Yes I know it's a manual. I almost always used the parking brake only for the 20+ years I drove a manual and never had an issue.) At least your example made some sense. I'm still not clear what the OP was on about as his example was meaningless.
don't have some responsibility to artificially 'cripple' the solution
No.
Using the Internet as an analogy ...
The Internet turned out to be about as powerful and dangerous as suddenly giving everyone a flying car without lessons.
Certain people have badly hurt themselves as a result of their unwise Internet usage.
And certain industries have been frantically trying to cripple the Internet because it caused their business models to fail.
But in no way does all of this collateral damage mean that the developers of the Internet had a "responsibility" to cripple its functionality.
Agreed. It seems a primary attribute of good usability that you don't let your users "commit suicide" (lose data, kill the app . . .)
. . . except when the user end up doing wrong by mistake. You must also consider the expert user, the one who knows exactly what he is doing. Do not hamper him with extra "are you sure" questions. But feel free to include training wheels for those who don't know how to tick "don't show this dialog again".
Making things easy is not bad, just make sure they understand the risks. Consider a gun - it is trivially easy to murder someone. But they can be sold legally anyway. Your software is probably not that dangerous?
What if the ability to do X harmed others?
That responsibility/consequence fall to the user, not the tool used.
It must have been something you assimilated. . . .
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
That assumes the only way to get paid is to do what the customer wants.
and give me my flying car! :)
Easy enough to get to, but most people don't know about it or use is. Never more than "click - delete - confirm" from bricking your machine once in the registry but in my experience that rarely happens. Make it relatively easy to get to but not at the top 1-2 levels where people will stumble into it. Maybe add a dire warning when one tries to access it, and maybe a couple confirmations before do something destructive. Having and "undo" button is good. If it's too omni and can phuck up other people unintentionally or deliberately then take it out - function should either exist or not exist and have sufficient warnings to stop accidental usage. Obnoxious wait-timers can be useful in these cases (but they really are obnoxious).
"The real issue is that I'm far too good looking and make too much money. It's a real burden, but somehow I trudge on."
I don't have mod points today so I'll just say I like your attitude. :-) This is, in my opinion, a professional mentality.
Sure, but everyone defines their own level of acceptable risk. Unless you're (for example) their parent, it's not your job to define it for them. I believe it's my job to make benefits/risks known (and, perhaps, documented) but not to decide for the customer what's acceptable for them. If they want something stupid/dangerous (and if I agree to build it), I'll explain/warn them as best as I can, but if they still want it, they get it - along with a note that says I'll be standing by to say, "I told you so."
I'm not my employer's / customer's keeper or even their nanny.
It must have been something you assimilated. . . .
You shouldn't ever cripple the user interface, but that doesn't mean that it should be easy to make dramatic irreversible changes to what the user is working on. It's also a matter of space optimization. Simple tasks that your users will do often should appear on the main user interface, other features that will be used less frequently should still be easy to find, but they shouldn't be accomplished by simply clicking a button.
"Are you sure?"
Oh. Sorry. Somebody probably has a patent on that...
The question is ... if the user changes their mind, how easy is it to recover.
I help out with an online forum, we get requests every day from people who requested to delete their accounts and then changed their mind. (Okay, not every day ... but too often.) This isn't something the user can do themselves, one of the administrators has to go into the backups to find the data.
Conversely, we do have a legal requirement to delete user data upon proper request, we can't just make this option unavailable.
So the option is there and is fairly hard to find (I've never used it myself and can't say how hard it is to actually use), that's the best we can do.
Good grief. Is. it. really. that. hard. to do?!
Unfortunately many features that can be destructive or super useful have very bad descriptions of what they do and how it will affect usability of the system. Most users will make good decisions when they know whats at stake. So instead of the are you sure? How about a couple of paragraphs or a whole page describing what the function does, when you should use it and when you should not use it. In other words you are trying to fix a corrupted index file and there is a function that wipes out the file and builds a new one. That might be fine on a small data base that will only take a short while to rebuild but a disaster for a large one that could take days to rebuild. You are the programmer you are in the best position to explain what a function will do, Why someone would need to use the function and what bad effects will happen if they use it when they should not. Like wise if your program starts a bunch of services and processes give the users a clue about what they are for. Its very frustrating when you have many many services and processes running and you are trying to track down a problem. You have traced it to a process but no clue where it came from and what it does. Anyone selling software should be required to have a website with a database of all the processes and services their program uses and a detailed description of what each one does and known incompatibilities. It would save so much time.
The goal of a user interface is to make it easy for a user to do _what they want_. If the thing you made it easy to do is what they wanted done, then it isn't possible for it to be too good. If you made it easy for them to do something they didn't want done by mistake, then its not "too good", its not good enough.
Ever delivered something which met the formal requirements and had them say "well, that's not what we wanted"?
There is often an unbelievable disconnect between what users tell you they want versus what they actually really really wanted but had no idea until it was too late.
End users will often help you design unusable software which is exactly what they asked for.
Don't be too hard on them. Often, it's working with what they asked for that shows what they should have really asked for had they been able to see in advance what was actually possible.
One of the advantages of being Agile. Don't invest too much in the "final" solution. Because it probably won't be. Unfortunately, that particular nuance tends to get lost in the Cult of Agile.
I'm assuming that the company that created the app did it for some profitable reason. So, it's in their best interest that the user is protected, even from themselves - for the best future of the app. If, for example, the engineers built a "delete my account" button that offered a one-click solution - I can see the company taking issue with that. In my own applications, I would never create a one-click "delete my account" option. It would be a two-step, maybe even a three step process - just to discourage users from deleting on a whim (or accident)
There are good reasons to slow down certain processes. Performance isn't always the goal.
"Lame" - Galaxar
In fact I came across this very issue today: the internal struggle between, "this is technically possible and optimal, so it should be done," and, "users are at the peak of Mount Stupid and will screw everything up if you do that." Sometimes, limitations are a feature because the user's perception when something gets screwed up is that it's a "bug". In a way, in maybe kinda sorta is a "user experience" bug, but definitely not in the technical sense.
Your summary is deliberately vague, but I assume you're talking about software development. Your job is to find the ideal balance between "feature" and "stupid", ie.: in my custom-developed CMS, I allow certain HTML via a rich text editor, but parse it fairly heavily so that clients who know nothing about website development don't bugger up their website's design. Which direction and by how far you you tip that scale depends whether your project is destined for mass deployment or if it's a custom software package for a limited subset of users (and how technically sophisticated those users are).
I don't think your car analogy is very adept; there are already cars on the road today that already have built-in artificial limitations. The MazdaSpeed 3, for example, artificially restricts the power output in 1st and 2nd gears because most drivers don't know how to manage the torque steer that would be caused by the amount of power output at full throttle. You could argue that it is bad engineering decision to put almost 300hp and lb/ft torque in a front-wheel-drive drive car, and you'd basically be right, except that customers in that segment don't want an expensive and complicated all-wheel-drive system that would be far more suited to that amount of power. Hence, the power is restricted so that dumb drivers don't end up cliff-diving off Mount Stupid without a parachute.
For example, making it easy to screw up something important is not good.
User Interfaces aren't just about making things easier. They are about making the user's job and experience eaiser, which includes not making mistakes. If a task is dangerous, then the user should be warned or restricted in some way.
Clasic example, "Are you sure you want to delete this fie?"
It can be annoying if I relaly want to delete a file, but its also saved me a bunch of times.
When a task becomes easier and easier, people are definitly more likely to perform that task and perform it more often. They are also less likely to consider the consequences.
It is fine that you have automated some difficult and also dangerous task, but you might want to consider some spead bumps and some warnings to make your users stop and think before they do something they might regret.
I guess you've never heard of Oracle... Talk about a product designed to be intentionally difficult to use to make it seem more special and powerful.
Yeah, but that's a pretty unrealistic analogy as it's going to be unlikely that shooting everyone else in the foot will have no repercussions to said "shooter". At worst case that user will be held directly responsible, and at best case everyone will forever avoid/shun him (limping around just outside of foot-shooting range...) Doesn't sound like a great interface to anyone's point of view (except maybe the podiatrists).
Come on, this is America! Here the responsibility/consequence falls to whoever has the worst lawyer.
Take this analogy: It is simple. It should be simple. It can be abused. It can hurt or kill. It can also be used to save lives.
You can literally shoot yourself in the foot.
It is a handgun.
It is simple, reliable. and easy to use and also to abuse. People have a hard time dealing with that scenario too.
Come on guys, we slashdotters practically worship the UI that allows commands like sudo \rm -rf /. Foolproof UI, bah! humbug. Meant for fools anyway.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
As long as the user understands what is being done FOR them and TO them, the user interface shouldn't matter. You only run into problems when assumptions are made that are never made clear to the user. I come from a structural analysis/finite element background and some of the programs seem very easy, but make too many sweeping assumption to be used as a professional tool.
If part of what you're selling is the network effect of your product, then this very well may be a time when "crippling" a feature makes the product better.
I don't think IQ goes into the negatives.
No, the IQ SCALE doesn't go into the negatives. People's actual intelligence, sadly, does.
Doing good is often nothing more than an emotional event. We say a man should feel great as he ran into traffic and saved a babies life. He is called a hero. A few years later that baby, named Adolph causes the death of sixty million people. We had the same problem with a revolution in farming when we sent the tools to India. India was starving at the time and suddenly they were able to raise crops like never before and dismiss almost all of the farm laborers. At the time most people in India worked on farms so now they had an abundance of food but the people had no jobs and starved even worse than before the technology arrived.
We normally can not predict the true effects of what we do. So create the product and let society determine whether it is useful or awful. Or more clearly "It ain't yo yob man"..
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
The customer may express their desire in terms of features; but no feature is actually what the customer wants. The customer wants joy and prosperity. The feature is a means to that end. If you know that what the customer wants will not lead to that end, and you fail to provide an alternative and explain why they should want that instead, you've failed on some level. If they come back after realizing it themselves, you're not entirely guilty. You're just not excellent. Your goal isn't to get paid. It's to serve the customer in the most ethical way possible. Getting paid, building an excellent reputation, and attracting bigger and better clients is a fantastic side effect of that. Most people are just struggling to give the customer what they ask for instead of truly serving them. That's why most companies are not great.
If so, you're doing nothing wrong, and please ship me a device with the latest firmware. kthxbye
Replying to undo my accidental mod because you made a damn good point here. Too many people are in the cult of "Perfection upon initial demand" and do not take into account that iterations are often needed to achieve a maximally optimal solution.
Here's to hot beer, cold women, and Glaswegian kisses for all.
Easily and unintentionally is the key. Also important is the difficulty in reverting the damage. If it is easy to reverse it is not as big of a deal.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
The concern here is that the task is bad so let's assume so.
Is the fact that you are getting paid to do something excempts you from any ethical repercutions?
No I don't think so. I don't accept so.
Are you allowed to do a subpar job?
Yes. One is never obligated be perfect. Nor are we obligated to do our best effort, You can do the worst possible job the client will still accept.
So one can do a bad job. But can you do it on purpose?
For the most part the legality of an action depends on the action, not intent. Some proffesions do make requirements about intent. Doctors for instance make an oath to do no harm (intentionally). Judges, Presidents and other public servants make an oath to do their job to their best of their abilities. Do programmers make such oath? Well... Do insurance agent make them? do real state agents? Do bankers? And, do they actually follow them up?
The answer no in every case. So no. Unless you make an oath to serve to the best of your abilities, you have a right to do the worst possible job that still satisfies your contract. And abilities imply responsability so I'd say you must. However don't be outspoken about it. The law is unfair and I can see some lawyers finding a way to implicate that you do have such an obligation.
But... the future refused to change.
I can't believe that someone with such a low ID still spouts this kind of crap. It's fucking 2013. If you don't understand why Apple does what it does by now, you might as well suck on a tailpipe. If you have a tesla, lick the plug.
In any case, you should get out of the tech industry. Apple's rationale is perfectly well known, so an oldfag bitching about it is intentional obtuseness.
Look, I hate the abdication of personal responsibility as much as the next guy, but the buck does not *always* stop at the user. And also, as nice as it is to have a single person to blame unconditionally, excoriating and then firing them still doesn't make the customer database re-appear (or whatever analogy you want to use).
we haven't got there yet.
Ever delivered something which met the formal requirements and had them say "well, that's not what we wanted"?
Of course, who hasn't seen this? Honestly, I think this is pretty much the main differentiation between a developer living in the same city as the client and a developer living on another continent.
The developer on the other continent delivers items that will literally meet the formal requirements; however, they often lack the cultural aptitude to question those formal requirements because they make terrible sense.
The developer living a couple miles away is more likely to maintain the necessary cultural aptitude to acknowledge when a customer's requirement is incredibly ill-conceived.
It could be as simple as recognizing an innocuous typo. What if the PM for a new Los Angeles Dodgers web site had sent the style guide to a developer overseas and there was a typo in the hex code for the color of a header? The overseas developer probably wouldn't pick up on the fact that the color they asked for was similar to the orange used by the rival Giants, while someone more familiar with the culture might notice right away that the Dodgers should not be using orange for their header color.
So... yeah... hire local developers! Rah rah rah!
Someone flopped a steamer in the gene pool.
Completely missing the point, launching misiles at targets is fine if it's a highly trained and by defintion responsible military personel being the user but what if you made it so easy a monkey could bomb our civilisation - that's the kind of question original poster meant. There's lots of things someone can do but really shouldn't be doing without proper instructions and training which is why we do not label essential controls in a car and certainly never post detailed instructions - if you haven't had the training to know what each pedal or lever does you are not supposed to be operating that vehicle. Think of it as using a keyboard without key labels.
In those situations where I've recommended and warned against the functionality, and the user still demands it...
Is the "user" you speak of the client commissioning the software or the guy or gal who will be working on site at the chemical plant when it blows?
I thought the topic was UI design, not career maintenance.
Computer: "Target out of range."
Hahahahaha! Good one.
It should be noted that your whole post has the caveat "unless someone could get hurt".
Yes, very definitely. My comment was only meant in the context of accidentally destroying important data, or some such. Certainly if it could result in personal harm you would not want to do it. In most circumstances, anyway. I can think of a few exceptions.
More accurately the problem is that users treat computers like a personal assistant not like a tool. They expect the computer to be responsible for it's own actions, and will blame it for following their orders if those orders turn out to have negative consequences.
No one expects hammers to prevent you from hammering your hand, but they will complain if the computer lets them run a program that emails their bank account info to a Nigerian prince.
Actually, the customer is not always right about MOST things, because "the customer" is actually a euphemism for "every single unique individual out there who we can get to purchase our product". There's no WAY you can get a consensus on practically any feature or function you'd put in a product that's used by a wide variety of people, all in unique situations.
What you can (and really should) do is try your best to offer a product or service that your design team believes offers the best possible experience for the customer. THEN get customer feedback and make changes whenever you can tell a significant number of individuals want them.
IMO, "health and safety" is only different because we have a legal system which, all too often, rewards individuals and punishes manufacturers, whenever it can be shown an injury occurred using the product, and someone argues in court that a different design could have avoided said injury. (I recall the story of lawnmowers requiring a warning label cautioning not to attempt to hold them up off the ground and use them to trim hedges or other shrubs -- ever since some idiot won a lawsuit for injuring himself doing just that.)
My point is, if most of your customers want that "collapse crane" button, it's probably for a very good reason (a need for it for storage purposes). You can either pretend you know better than they do what's best for them and refuse to provide it -- or you can put some thought into it, and provide it so it only functions along with other safeguards in place. (EG. Heat and motion sensor must not detect presence of a person on or within so many feet of the crane, or the operation cancels with an audible warning alert. Crane must not have anything attached to the end of it when button is pressed or again, it cancels.) A fear of our legal system probably causes many good ideas not to even be attempted, which is unfortunate.
Submitter has provided too vague a situation to make a determination or give advice. Please iterate ask again.
For example. All the responses to this topic are equally as valid were the question to have been: "Should I make UI good or bad?"
1984 as in the book, or as in the year of the Macintosh?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Same was said about the dangerous car when it replaced the slow horse.
You have to remember that in UI design, the "Best Possible Solution" is different for different groups of people. For trained pilots (expert users), a flying car might just be the best thing for them. For those with no flying experience (new users) perhaps an automated flight system is best, such that they input where they want to go and the system gets them there, while avoiding other flying cars and adjusting for weather, traffic, and other things (the analogy would be a simplified interface or a good deal of wizards for common tasks). As Alan Cooper said, design for the intermediate user: somewhere between expert and newbie. Provide advanced tools that are optional and not necessarily immediately visible on the UI until they are summoned. Provide wizards and tutorials to get the new users up to speed.
SS would be envious
Without going into specifics, I believe an apt analogy would be giving everyone in the country a flying car. While this would no doubt be enjoyable, without proper training and regulation it would also be tremendously dangerous (also assume training and regulating is not practical in this case).
In the day of the horse and buggy, many people were against horseless carriages. They were loud, spooked horses on the road, and much more prone to accidents... especially without "proper training and regulation". Yes, imaging how bad things would be if everyone had a horseless carriage.
GNU Emacs protects some exotic functions that you more likely triggered by fat-fingering the keys than intentionally invoking them. Most people would probably never use these functions. You can tell it to stop protecting you.
The Marching Morons by Cyril Kornbluth. I think you would enjoy it in the context of your conundrum.
What if the user interface lets them shoot everyone else in the foot at no cost to themselves, while accomplishing their task quickly and with ease.
It's a great user interface from the user's point of view, but a really terrible system to have.
As I recall, Microsoft found themselves in that situation once. I think it was with one of the service packs for Windows XP (it might have been SP2; I don't remember which.) In that release, MS removed the capability to do a certain kind of packet sniffing (might have been promiscuous mode, or port scanning, or something like that.) This capability wouldn't have allowed the user to do any harm to their own system, but would have made it easier to possibly invade the privacy of others. The problem is, after that "fix", certain security tools no longer ran under Windows XP, so people that wanted to use those tools either had to run an old version, or install Linux (or BSD, or some other system.) I don't recall if people on the whole thought that was a good thing or a bad thing. It was certainly an inconvenience for network security admins.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
What if the ability to do X harmed others?
And more to the point: what if those others sued?
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
Sounds more like a failure to understand what the customer is asking for and either a) deliver what they actually want or b) decline to deliver what they want because you believe it is not worth developing.
Wish I had mod points.
There are several high end sports cars with "track mode" that's a more practical version of this. To put the car in this mode (with suspension and engine settings that with frankly be stupid and destructive for normal driving) requires a special key in a lock while the car is off - deliberately designed to be too awkward to switch if your waiting at a light and another sports car pulls up next to you.
Several cars also have a way to put your engine into "waiting at a light and another sports car pulls up next to you" mode that puts you into some sort of fast launch mode for the next minute or whatever, but you're only allow e.g. two per month. The Nissan GTR famously made it too easy to get launch mode, and ruined a lot of engines while still under warrantee in early models.
Socialism: a lie told by totalitarians and believed by fools.
Well, there's a special word for getting paid for NOT doing something.
It's "extortion."
Welcome to the Panopticon. Used to be a prison, now it's your home.
> Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
If your ultimate goal in life is to get paid, I'm sad for you. What a pointless, meaningless existence that must be.
Perhaps you're saying that's your ultimate goal AT WORK. The time you spend working is most of your waking hours, so still, that makes me sad for you.
You might get a lot from reading Viktor Frankl's 184 page book "Man's Search for Meaning".
you can't make monkey punching too easy.
Agreed. I was providing FPGA programming services for a company making safety critical hardware. When the hardware guy failed to run the processor bus clock to the FPGA as I had told him to do, his response was "sample at double the clock rate and harden the signals." I told him and the company owner that doing that would make the system unreliable due to potential flip-flop metastability. The owner's response was "work it out with him" which to me meant he didn't really believe it was an issue and wanted to press on regardless. So I quit.
Many slashtards exhibit sociopathic behavior in the pursuit of getting modded up but I see that kind of thinking hasn't stopped your punk ass.
Trick.
Make the interface for the dangerous function easy to use, but make the user have to go through some sort of difficult/obscure process to enable that functionality, such as having to check a checkbox in the preferences and acknowledging a dialog box warning them of the dangers.
Or, make a dialog box pop up every time they attempt to do a dangerous function, but provide them with a "Don't show this warning" checkbox if efficiency is important to the user.
It is always somebody's first day.
That's great insight. I remember back maybe 20 years ago when I got my hands on my first Intel based PC and within hours hosed the MBR.
Thankfully, back in those days, they actually came with OS installation diskettes and let me fix my problem. Today they'd probably make me pay $20 and wait two weeks to special order recovery discs.
More Twoson than Cupertino
...when it includes drugs or hookers.
i believe it is 88mph, not 70.
Ever delivered something which met the formal requirements and had them say "well, that's not what we wanted"?
Which is a huge problem that usually starts from being an Obedient Butler. If the users ask for a ridiculous requirement, you need the experience to be able to not only say it won't work, but why it won't work.
So many are afraid to confront bad requirements, but challenging these things not only reduces the amount of wasted work, but it also shows that you're engaged in solving their problems as if they are your problems as well.
Then again, you've also got Consultant-ware that has a vested interest in implementing bad requirements to a T so they can generate more billable hours later to refactor it.
More Twoson than Cupertino
Yes, you were wrong, that strange almost unnatural feeling you've got is normal for most people, so just rescind your remark and admit your mistake, as you should've done in the first place rather than going to the Internet and hoping to get back an answer ambiguous enough that you could return to work and say "For this project you guys might be right, but it's a topic of great debate on the Internet. Now if you really don't know why you're wrong then consider the confirmation popup, is asking the user if they really want to do something required somehow? No it isn't it's a road block that we put in to make the user think for a moment before blindly continuing their action... That being said, don't make it ridiculous users can tell when you've sent them through 5 nested windows for no good reasons to do a task... And make sure to have excessive confirmations either silence themselves or have a off switch somewhere just in case their use case for the product doesn't match what you envisioned.
I have found that this is the sort of problem that actually comes up a lot. You have a system with an ask-for feature that will cause harm to the system as a whole.
Some examples I've seen:
A "Message all" button on a company wide email alert system
A "repeat buy" on a commodity trade for a financial customer
A generic "approve" button for a social service app
A lot of times we want to force the user to take steps to insure that they fully consider the ramifications of their decision. For some of these we just force them to put in a one line comment in order to do the action. If it is not worth a single sentence to explain why an action is done, then they don't need to take the action.
This is obviously only for functions with some gravitas. It would be cruel to ask why someone wanted to save a word do. ;-)
Now is it really what the customer wants, or just someone in the company assuming that's what the customer wants? How I read the grandparent is that the request for the ability to do X came from within the company.
Also consider that even if the request comes from customer A, implementing that feature could cause customer B to become unhappy. It only makes sense to be a slave to what the customer wants if the customer is just one entity. In practice "the customer" can include hundreds or thousands of entities. One set of "the customer" wants McDonalds to deep fry everything and one set of "the customer" wants healthier choices.
"the customer" is actually a euphemism for "every single unique individual out there who we can get to purchase our product". There's no WAY you can get a consensus on practically any feature or function you'd put in a product that's used by a wide variety of people, all in unique situations.
Only if you design products to be made in a cookie cutter and then stocked on a shelf to be pulled off by anyone who wants one. Not everyone works that way. Large structures like ships, cranes, bridges, etc. are often made as one-offs for a specific customer and designed to that customer's requested technical specification. Even ones that are "copies" of a previous project ("I really liked the last one, make me another!") are tweaked a bit based on expected environment, new standards, etc.
In software terms it's the difference between writing a program for mass distribution, like MSWord, and writing a payrolls processing database for some accounting firm somewhere. The MSWord team has to take "the customer" as a euphemism for the varied hordes that will use the program, whereas the accounting firm team can have daily contact with their customer and know exactly what they want.
So yes, we can easily tell them that they don't want the fancy-schmancy system they're asking for ("you want a collapsible crane? What else, should it play the Transformers theme song when it deploys?"), because we can talk face-to-face and show them exactly how much it will add to their final bill in both engineering time and added safety procedures.
Everything is better with chainsaws.
I use this analogy. Ask yourself why there are brakes on a car? "Well so that I can stop" you say. But actually you will stop without brakes, it just takes much longer. When you boil it down. Brakes are needed on the car so we can go faster, and don't have to coast the second half of your trip.
Some medical devices include a lot of extra checks to make sure everything is ok. Ie, double and triple check that the patient really is the patient, verify the ID number with the patient's name, ask the patients for their name in case the wrist band is wrong, and so forth.
One example I heard was a radiation theraphy machine that required two operators. In order to perform some operations they had to hold down two buttons or controls, which were widely separated. Thus no one could override the machine by him or herself, you always needed a partner to agree that everything was being done correctly. However a representative of the company noticed while visiting a hospital that they kept a weight near the console, and deduced that they would use the weight to hold down one button so that only one operator was required.
Sometimes I hear this stuff coming from product managers, not the actual customers or users. So I wonder many times if it is really a customer who is asking for the "disassemble crane" button, or if it's just someone in the company who is saying "wouldn't it be a cool value add if it had this feature."
But sometimes destroy is the goal. If the program is called "Puppy Maintainer" then the shredder should be hard to use. If the program is called "Animal shredder" then shredding the wrong animal should be hard. But if the program is called "Puppy Shredder" ... ? I guess you need to make sure you're shredding the right puppy, double-checking that they picked the right conscious/live-but-unconscious/already_dead option, double-check the "in front of the children" option was really intended to be selected, but the destruction itself can't really be avoided.
According to one common definition of IQ, it is defined as having a population mean of 100 and a standard deviation of 15. Someone would need to be -6.66... standard deviations to reach an IQ of zero. Unless I've messed up the math, there'd need to be approximately 76.5 billion people for us to start seeing negative IQs.
So, yeah. IQ doesn't go negative... yet.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
I once deleted a crucial directory required by my operating system thinking it was not needed. After the 'Oh, SHIT!' moment, I realized my son's computer had exactly the same version of Linux I had, and simply copied his. Fortunately, there were only a couple of trivial hiccups as a result.
At the time I had over 20 years professional IT experience, and about 10 with Linux - so even experienced people can stuff up!
Dangerous things should not be allowed for normal users, but okay for admins - like in Linux, some things are reserved for root. Although, I _WAS_ root when I stupidly deleted the directory above. However, when I'm in root, I'm automatically more cautious. For things like 'rm -rf *', I always (see note 1) check VERY CAREFULLY!
Note 1: Almost always!
It seems that you confuse the terms "good user experience", "best solution" and "efficient to use". A good user experience is if the user likes what happens, which isn't the case if he launched the nukes accidentally. The "best solution" depends on the situation, e.g. in something like facebook, the user experience isn't a direct goal, since the "best solution" for the "delete account" function is to hide it deep down somewhere unexpected. "Efficient" seems to be what you like and what your colleague objected to in case of the "launch nukes" button that you can trigger via eye tracking by looking at it (insanely efficient!).
The question is way too vague to get a single answer. Here are some:
- Yes, doing something that is usually bad thus isn't something you want to do most of the time should not be so simple that you can trigger it accidentally or faster than you can anticipate the consequences (no simple "launch nukes" button, put a lid on it)
- No, if it's for qualified users who got some mandatory training the app should be as efficient as typing sudo rm -rf /
- Depends, if you have a broader userbase hide the dangerous stuff but add an option to enable it so after it's enabled advanced users will have an efficient way to use it.
You really need to read this: http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.html
The guts of it is that how easy and hard it is to do various things within your system will determine how often those things are done and that will have a whole raft of consequences.
You need to start thinking of the users as part of the overall system and designing the UI part of the system so that when it's combined with the users the overall system achieves the desired outcomes.
I think one root of the problem is the point-and-click-interface. It's difficult to automatically check the semantics of user inputs if they don't have to acknowledge them explicitly, like they have to with a command line interface.
One possible solution would be a transactional GUI with transaction a log, which would it make possible to roll back any changes you have done to the system.
To be fair, loading a webpage with unsecured elements is actually a pretty big security gap. It's just that the average user doesn't understand this and just wants to get though to the page.
I see a lot of replies where "deleterious" seems taken to suggest "will cause immediate harm to your own data or system," but it occurs to me that the flying car analogy suggests the possibility of something more socially deleterious, like using facial recognition and aggregated social networking and other data to print out the personal home address of a random individual from a snapshot. In a case like that, I would make a not obvious to find setting that turns on easy for those who have shown that they could get the results the hard way if they wanted. I doubt you'll need to leave the feature undocumented, just have the documentation leave out the sentence that makes the "but that means you can..." part obvious. You can trust that most who would casually abuse the ability won't consider to read the documentation at all, and those who get the implication will likely figure out how to do it the hard way, regardless.
A man comes to your used car sales agency wanting to buy a cheap van to blow up a building. Do you let him go down the street to the next dealer who will gladly sell him a van because they're unethical greedy assholes, or do you go ahead and sell him the van because one way or another he's going to get a van so it might as well be from you, so why not lower your standards because you pretty much have to in order to compete?
Great now I just wrote myself into a corner.
You can, you just need to do in the database... still not something 99% of the users would know how to fix
(name withheld by request)
If your interface would allow a user to shoot themselves in the foot without proper precautions, then your user experience is, by definition, *not good*.
I would respectfully disagree. I would much prefer a way to unshoot my foot than be bothered by "proper precautions." Why does every action have to be so final? It's not like disk space is at a premium anymore. I know, that programming an undo is hard and tedious, but it's far more helpful than constantly putting up warnings that people learn to ignore.
Your mistake is that you are using the wrong tool. You wanted: /data /trash/data /data
mv
but you typed:
rm -rf
The first has an undo: mv /trash/data /data
The latter does not.
And before you (or another AC argues), I want a command that immediately deletes data when I tell it to, irrecoverably so no one can get it, not even me if ordered by a court. Do you propose to give me that tool and then violate a basic requirement (irrevocability) by adding an undo in case I didn't mean it?
True story, eh? Smells like BS. Starting in the 90s, manual transmission vehicles have a lock-out feature that prevents starter operation unless the clutch pedal is depressed. If it happened before then, or even now, they weren't dealing with software but hardware.
Unfortunately, it's also every other mobile ad or pop-up disguised to look like a dialong box telling them they need to click this or else...
(name withheld by request)
If there is an ethical issue, take it very seriously. To choose what I hope is an extreme example, Enron employees who suspected something wrong and did not react wound up unemployed.
Decide the ethical issue first....the practical answer will follow neatly. Here's a cheat sheet:
You don't want to enable fraud -> sorry, it is time to take another job, even if it means a pay cut.
You don't want to enable big mistakes -> See entire discussion above.
You don't want people to see a Rick Astley video -> Go volunteer in a soup kitchen...this is not a valid concern
Not true. Not even in my '06 Volvo
to they are externalities , learn accounting....
Yes, this is the general class of error where you need to think about making the individual user's experience less flexible than would be possible for a single-user system. For a concrete example, if a user activity can cause sustained high usage of system resources such as memory or CPU, and enough users "abuse" this feature, it will bring down usability/performance/system response for the majority of the users and should probably be re-thought.
We are the 198 proof..
"I was only following orders." is not usually a valid criminal defense, it just adds conspiracy charges.
We are the 198 proof..
This does not sound like doing what the customer wants, and rather that it is a system req for a lesser used feature such as "reset settings" or "delete X" but that its far too easy to click on perhaps accidentally..
The problem with the original question is that it assumes that somehow this is "good UI design" when in point of fact making it hard to do things that are dangerous is good design.. despite what people think of "choice" and "freedom" if we have learned anything from windows and its users.. its that giving users the power to install whatever they want results in nothing but headaches for everyone who has to clean up after the spyware, adware, and accidentally deleted windows folders..
In actual point of fact there is no reason why anything "negative" needs to be within any app or its settings (a second app protected under admin rights is where that sort of thing should live if it exists at all.. better still would be in a config file that must be created and set for the action to take place from the command line)
At some point, any action will become final, eg. once you send the report off to the client, you can't edit it any more. "Undo" is simply a way to delay that point; saving the undo stack to the disk (or otherwise saving previous versions) is merely an extension to that.
If the "shooting in the foot" involves running a CNC mill in a way the user probably didn't intend, or placing an unusually large order with a supplier, or sending out a half-written press release, it's easier to make it a difficult task than it is to figure out how to add an "undo" feature to the program.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
The GTR did not have a "launch mode", and specifically warned users not to use it as such. It was a mode intended to allow you to accelerate out of low-traction conditions like getting stuck in snow or loose gravel. They specifically warned people not to use it on dry pavement as it could damage the transmission if used that way, and would explicitly void the warranty. Nobody listened.
Nowadays, they did add real launch control so people would stop using the VDC-off mode wrong, which is kind of the opposite solution as what TFS talks about.
Hmm...the poster is being incredibly vague, which makes this difficult to gauge.
Are we talking about unwanted behavior in the form of a user accidentally deleting their install / corrupting something important, or are we talking unwanted behavior ala 'You didn't read the fine print at the bottom of the EULA' & the default setup option installs a bazillion adware apps? Or are we talking unwanted behavior as in borderline illegal...probably going to get a call from the DoJ / FBI / DoD (with a tank parked outside) kind of illegal?
I am John Hurt.
Many slashtards exhibit sociopathic behavior in the pursuit of getting modded up but I see that kind of thinking hasn't stopped your punk ass.
So says an "Anonymous Coward". Left you balls some place else?
If you want news from today, you have to come back tomorrow.
"Lets create the folder first, and immediately start a rename operation, because writing the code that way will be easier"
I can't say that I agree with that design decision.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Maybe
and wonder if we don't have some responsibility to artificially 'cripple' the solution and in doing so protect the user from themselves
You are working for Microsoft on Windows 9, right?
Have gnu, will travel.
"I was only following orders." is not usually a valid criminal defense, it just adds conspiracy charges.
Even if it isn't a defense, it could be the beginning of a plea bargain for someone willing to turn state's evidence against the one giving the orders.
But that is a simple query away from fixing the entire issue, that any web developer worth a shit can fix in 30 seconds with the proper information. I would assume "catastrophic" would consist of at least allowing users to delete content permanently, change settings without revisioning, or change their own UI beyond their own expectations (i.e. I dragged my taskbar to the top and now it's up there!)
Has got to be when this new funky slashdot mobile site was released!!!!
I couldn't be more happy. We have too many functionally great websites, and moving to this new strange failure of an application interface is definitely the future of user experience
However a representative of the company noticed while visiting a hospital that they kept a weight near the console, and deduced that they would use the weight to hold down one button so that only one operator was required.
Puzzle adventure game fan?
a second app protected under admin rights is where that sort of thing should live if it exists at all
Provided that the target platform allows one application to modify the private data of another application.
better still would be in a config file that must be created and set for the action to take place from the command line
Provided that the target platform even has a command line.
Why does every action have to be so final? It's not like disk space is at a premium anymore.
It still is. The OS takes up half the SSD space on Windows 8 tablets.
If UI designers had saved warning messages for things that were actually important ("You're about to delete a file") rather than stupid things ("You are loading a web page with unsecured elements") then people might actually pay attention to them.
In some environments, "You're about to disclose business-critical confidential information by allowing an unsecured element to modify the behavior of a secured element" is in fact more important than "You're about to delete something that you can restore from your backup repository".
I would never create a one-click "delete my account" option. It would be a two-step, maybe even a three step process - just to discourage users from deleting on a whim (or accident)
I agree that unsubscribing from a service should take two steps:
Logging in between step 1 and 2 would show a button to keep the account open.
And just how do you undo a hard drive format?
By backing up the entire contents of the disk before formatting. This could even be done in place by making a compressed image and storing it in a file on the freshly formatted volume. A "trim" or "shred" command that FF's out all unused blocks (assuming that the previous contents were in a known file system) would improve the performance of this compression.
My boss at the time was a very wise man and suggested that as nice and clever those 22 lines of 4GL were, about 6 people would be out of work
Ideally they'd be retrained for other positions within the company. Some companies prefer to hire from within to save training costs because existing employees will already be more familiar with the company's practices.
This could be anything but my guess is that it's a product being delivered by a company that makes a significant revenue selling support for the product. If it works too flawlessly, people won't need to buy support for it.
The analogy is not selling a flying car, but rather a car that doesn't need maintenance.
A (cheapskate) friend of mine had an old Russian Lada which inexplicably came with a keyhole for engaging a 'launch mode'. Of course, he didn't have the key, but eventually he managed to pick the lock.
It would appear there'd been some kind of mixup in the relevant Soviet factories and it actually was a launch mode - and this peculiar Lada-Soyuz hybrid launched straight up into the sky, friend included.
He's probably still up there. Wonder if he ever tried docking with Mir?
Tedious Bloggy Stuff - hooray?
We have some things in one of our internal products that require the user to actually type the word "YES" in a fieldnto get it to Continue.
They still manage to do it "accidentally".
The preferred solution is to not have a problem.
... giving everyone in the country a flying car. While this would no doubt be enjoyable, without proper training and regulation it would also be tremendously dangerous (also assume training and regulating is not practical in this case)
- or giving everybody the right to own firearms. I would say, if your argument is valid when it comes to flying cars or drugs, then it is valid for gun-ownership as well. The funny thing, though, is that a lot of the people who are wildly in favour of gun-ownership are also rabidly against ligitimising drugs. I'm not sayign that one or the other is "right", only that you have to be for or against both, unless you are a hypocrite.
Apple has a front-line customer support model. That means that they have to directly deal with every grandmother, novice, etc that touches their products
By sending them to a web page? Heavily moderating Apple's forums?
I am intrigued by this idea they have customer support. Can I subscribe to your newsletter?
Completely agree with that first bit, but I think you're thinking the wrong way about Vista. The whole point of its crazy UAC wasn't to warn you about hazards, but literally to piss you off. Pre-Vista, software developers used all manner of nasty hacks and often requested full-time admin privileges when they didn't need them. So, Microsoft added the UAC to annoy the hell out of users every time some poorly-written program requested privileges for the nth time in the hopes that they would bitch about it and the developers would change things.
"It's a great user interface from the user's point of view, but a really terrible system to have."
I feel as though you are attacking our banking system somehow...
"I was only following orders." is not usually a valid criminal defense, it just adds conspiracy charges.
If there's no law against it, it's not criminal. There are laws against manufacturing firearms without a license, so making one is criminal. But making a meat cleaver that can cut through something of the same size, weight and density as a human skull is not illegal. If you do so knowing it's going to be used to split a human skull, that's conspiracy, and criminal. If you do so think the guy is a butcher and wants to cut up sheep and pigs, but it later turns out the business cards were fake, you've not broken any laws.
A medical system that can deliver a potentially lethal dose of painkillers on the express command of a trained operator is acceptable if there is a clinical situation in which such a dose may be required. If someone later uses it for murder, the manufacturer can't be held liable.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Yes, but you're forgetting about "yes dear" syndrome. Humans have a remarkable ability to just say "yes" without thinking, just to keep their lives ticking over. It's a very passive word, because you don't have to specify a verb. If you have to say "do it", you accept responsibility. If you just have to say "yes", in your mind you're letting someone else take responsibility and you're just keeping out of their way.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
No, it's not. Existing rm implementations have a -f flag. What if -f was removed because people are stupid and rm -rf / a lot?
The GP said "alias" (although the GGP didn't), which leads to an important distinction:
Using a flag for the "dangerous" feature makes it a more complicated operation than the "safe" version. If you alias the "dangerous" version (eg mapping "rm -f" to "del") you remove that complexity, and risk people using the dangerous version by default.
This leads back to the OP's question: can a feature be too easy to use? Yes; if another feature is more appropriate in the the given circumstance, and this feature is easier to use than the correct one, it is too easy.
In most circumstances it will be impossible to follow this rule for every function and use case of the software, though, so at some point you'll just have to accept a compromise....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
I would respectfully disagree. I would much prefer a way to unshoot my foot than be bothered by "proper precautions." Why does every action have to be so final? It's not like disk space is at a premium anymore. I know, that programming an undo is hard and tedious, but it's far more helpful than constantly putting up warnings that people learn to ignore.
Donald Knuth, is that you? Why don't you have a /. account yet?
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
If that's the criterion, we need to disable all spreadsheets and decision support systems.
That's why you should be agile but never Agile.
That analogy is anything but apt, and it's really difficult to address your question in absentia of any specifics.
The flying car analogy is not an example of the deleterious effects of making a process too efficient, but of unintended consequences of the circumstances that achieving that creates.
What the flying car achieves is allowing people to travel faster than ground transportation by reducing friction and utilizing three dimensional space more efficiently.
Its deleterious effects derive from the greater complexity of navigating three dimensional space, insufficient familiarity with that task among the general public, and the greater risk to drivers, passengers, and bystanders resulting from air collisions as opposed to traffic accidents.
However, you don't address this problem by not making flying cars. You address it by providing proper training, by making flying cars smarter and more autonomous than regular cars with regard to following proper procedures and avoiding accidents, and by setting and enforcing standards for manufacture, operation, and maintenance of flying cars. Those things make the flying car better by making it safer and more, rather than less, efficient (although there may certainly be some tradeoffs).
It sounds like what you are talking about is enabling the most efficient execution of a task that by itself is deleterious, and wishing to curb this tendency by making the task itself harder to achieve. I don't think your analogy fits, and at the moment I can't think of one that does. Is this so super duper top secret that you just can't actually say, without reference to specific entities, what the task is?
Yes, there is. Part of the UI is to protect the users from inadvertent operations. That's part of why various destructive operations in programs have the "are you sure?" dialog box. The good ones also have a checkbox that says "Don't ask this again".
Unfortunately, the first time I delete a folder I get the warning "this will delete all contents" and I click "don't ask me this again", because it's a bunch of classwork for an old university course, or a local copy of the files from an old project repository at work, or just a pile of stupid joke JPEGs a friend emailed me. Clicking "don't ask this again" only guarantees that when I do finally accidentally delete a live folder, it won't make me stop and think about it. "Don't ask this again" is not a safety feature, it's pure user appeasement: imagine if the seat-belt warning in your car had a "don't ask again" option. Millions of people would be more comfortable during their daily commute, but the rise in fatality rates in car crashes would be non-negligible.....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
The biggest issue here is that they have mixed up "easy" with "a good User Experience"; these are two different things. A good "User Experience" is pleasurable and enjoyable, "easy" is just easy. It easy to drive a 1976 Volvo with automatic transmission and just as easy to drive a 2011 Maybach but the "User Experience" is quite different.
I am wondering if you have lost sight of the goal a little bit. Goals and objectives can sometimes get a bit confused and we can lose sight of what we are fundamentally trying to do.
What is the goal of the flying car? To transport a person from A to B.
But putting this into more detail we start to break it down into a number of objectives, some of which will conflict. Our person wants to get there quickly, but we know that in order to get there at all there needs to be some degree of safety.
The "best possible solution" to transport a person from A to B will involve a balance of sacrificing speed for safety and vice-versa. If your customer specifically states he wants to be able to get from A to B as quickly as possible, it is your job not to take that literally and to understand what he really means is to get there as quickly as possible within the greater of what he considers an acceptable safety risk. It is also your job to understand that the acceptable safety risk is the greater of what he, you, industry and government standards state is an acceptable safety risk.
Being professional involves knowing what your client needs even if they do not say or know they want it.
This kind of thinking (Training wheels) is why I don't have mod points today :D
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Make it so the things people need the most are easy to do and the things that people should never ever do as hard as possible.
One example of doing it wrong is found on many browsers on Windows (or also Android and probably a lot of other badly designed interfaces). If you click a link leading you to an executable file you will be asked if you wanted to execute it. Executing a random executable file is also known as remote code execution and one of the things which must never ever happen. Yet it is offered to the user which is trained to just click yes, because even simple harmless operations have tout him to always click on yes if he wants a job done.
Most Linux distros solve the problem in another way. They offer a package manager which gives you a broad selection of packages to choose from. You just search for what you want, and with very few clicks it will be installed. Executing downloaded executables is harder. You first need to store them somewhere, then set them executable. That is the reason why (outside PHP websites) there is no malware on Linux systems.
Yeah. Which is why I would rather the western world get some culture :P
I can throw myself at the ground, and miss.
And all the time I was thinking the setup function of WordPress was the shoot self in foot option, given the amount of phishing sites that are hidden on servers hosting WordPress.
But that is a nice example of what gadzook33 means. It's very easy to set up a site, but actually maintaining and securing it requires more knowledge about servers and security. But hey, setup, ok, ok, ok and it works, so we're done. Not.
Privacy is terrorism.
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
Kill yourself.
If you are talking about something like permanently deleting a database, then YES, MAKE IT HARDER.
Ha ha. At my work a developer put a drop table button in the application to make testing easier. It turns out that he forgot to take it out before putting it into production. One day someone actually pressed it, and me and my boss learnt how to roll back the database quick smart.
was not a back to the future reference i was going for 1 high speed 2 abnormally low gear
Any person using FTFY or editing my postings agrees to a US$50.00 charge
What if the something in question is a return machine?
Instead of having to wait in line, answer awkward questions from the sales person regarding the reason for return, a person could just scan the bar code on the item, and drop it into a return tray. It would save the labor, customer's time, and improve user experience. However, it might negatively impact the company's return rate, sales .. .etc. There are definitely items that I purchased out of curiosity, and didn't bother to return because I was too lazy to do so. Make it easier, would negatively impact the maker of the improvement.
In this case, should the dev team still make the improvement regardless of how it impacts them?
yes i think the CLI really needs to be toned down ... use a mouse to make it more ... inefficient!
Well, there's a special word for getting paid for NOT doing something.
It's "extortion."
Speaking as a government contractor, I can assure you there's at least one more way to get paid for not doing something.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
You and your collegue are falling into the very "Microsoftien" thought process that brought about the "Recycle Bin". "Our users are too stupid to be expected to actually stop and THINK before they delete something, so we will take the decision out of their hands, and simply HIDE files when they say 'delete'. Besides, I too have deleted files, then regretted it."
The problem with this is that it actually encourages the users to NOT think before doing something destructive, and encourages misuse of the delete and recycle bin. This means that when someone goes in to the bin to actually delete a file, they are less likely to give THAT act the thought it needs, meaning you can STILL delete something you shouldn't have. Making your product no safer, while at the same time making it more of a pain to use.
So to me it seems stupid to have a recycle bin because it does not remove the danger of accidental or thoughtless deletio, it only postpones it, while encouraging sloppy deletion practice, and making both file and freespace fragmentation more of an issue to boot.
Crippeling your product makes it less usefull, while probably not really providing any real protection. Nothing teaches people to think before they act like a catistrophic loss or two. And hiding or obscuring the user's responsibility to THINK before doing will only make it easier for them to shift the blame onto YOU, or your product. And you can't make sloppy thinkers THINK, just bytelling them to, THEY have to come to that conclusion all by themselves, or else they won't do it at all.
Even a long string of "are you really really really sure?" questions just teaches your fingers the sequence of "yes, yes, of course" to type or click on. One or two chances to stop are enough. Any more than that just makes the user want to get through it as fast as possible.
THINK! It's patriotic
A good UI is one that enables you to accomplish human-computer interaction so well/easily that the task is efficient. Any UI that is "too good" either means the UI is NOT good because you become entranced with the UI rather than the task, OR you are mistaking the task (the ends) with the UI (the means) and perhaps it's ONLY the task that is good or bad.
You mean email then?
I think your problem is not that you made a dangerous feature too easy to use, nothing is too easy. The questions should be :
- Why is this feature dangerous in the first place ?
- Why do users feel the need to use this feature ? Aren't there safer alternatives ? If they are, why aren't they more accessible / easier to use ?
It's no problem giving flying cars to everybody, if the roads are good enough so that people rarely need to fly. Or that flight mode ships with a reliable auto-pilot.
The GTR did not have a "launch mode",
Just because Nissan didn't call it "launch mode" doesn't mean everyone else didn't. It was used in a completely predictable manner by people buying a supercar, with completely predictable results.
Socialism: a lie told by totalitarians and believed by fools.
Usability is one facet of UX design, but it isn't the whole story. As your own example shows, sometimes making something easy means making it excessively dangerous. If your *real* goal is to create a great user experience, then you need to ask yourself about what the best possible experience looks like (or, even better, run a usability test to find out for sure). It's unclear from your short description, but if the action could cause data loss or some unexpected side effect, then it certainly would make sense to put up some level of barrier to the user committing that action. That doesn't mean you should hide the function or make it confusing. Maybe just use a confirmation dialog, or explain the potential downside before letting the user complete the action.
: Don't invest too much in the "final" solution. Because it probably won't be.
Ah, if only you could have tutored Heydrich.
A GTR isn't a supercar. Close, but not quite.
Each situation is different, but sometimes slowing the user down can reduce errors/improve accuracy. It's not that the user experience is "too good," but moreso that certain UX and design decisions can make the outcome of an interaction less than desirable. Luke Wroblewski talks a bit about this in his book Web Form Design (Rosenfeld Media). He discusses the placement of labels with regard to fields and how each option affects completion in terms of speed and accuracy. O'Reilly also uses similar logic in the creation of their Head First series. They use Comic Sans (and other design tricks) to slow down the reading experience as studies have shown it aids with retention. There's nothing wrong with slowing a user down if it's in their best interest.
If you're concerned about how users will use it, then by definition your user experience is just not good enough.
A good user experience is not only about making things simpler, it's also about making them intelligible. If your user does not understand the seriousness of the action he is taking, the user experience has to be improved...