Forgot your password?
typodupeerror
Software

Ask Slashdot: When Is the User Experience Too Good? 397

Posted by Soulskill
from the thought-process-behind-drm dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: When Is the User Experience Too Good?

Comments Filter:
  • I assume... (Score:5, Funny)

    by Anonymous Coward on Friday May 24, 2013 @12:26PM (#43813819)

    I assume you work for Zynga?

  • by Anonymous Coward on Friday May 24, 2013 @12:27PM (#43813831)

    Are you sure you want to delete that file?

    • that asks you I see you are trying to do X do you need help?

    • Re:like Windows? (Score:5, Insightful)

      by jellomizer (103300) on Friday May 24, 2013 @01:01PM (#43814321)

      Most software you need to do the following.

      Create Date
      Read Data
      Update Data
      Delete Data.

      CRUD for short. However in terms of the UI
      you need to change the order to RCUD Read, Create, Update, Delete. As those are in the order of damage you can create from low to high.

      So Reading data should be the easiest to do on your system, as most people should just be reading data.
      Secondly create new data, should be the next step, as if you created something wrong typically it is the easiest to remove.
      Updating data can cause more problems as you could change correct data to bad data, and often most systems you will not know what happened after you changed it.
      Then Delete data, which is obviously could be bad if it was too easy.

      • I prefer DERP. Delete, Edit, Read and Produce. Users are actually well ahead of the technology curve here - ask any tech support worker, customers have been DERPing for years...

  • by grasshoppa (657393) <skennedy@@@tpno-co...org> on Friday May 24, 2013 @12:28PM (#43813833) Homepage

    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.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      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.

    • by serviscope_minor (664417) on Friday May 24, 2013 @12:38PM (#43813981) Journal

      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.

      • What if the user interface lets them shoot everyone else in the foot at no cost to themselves

        Then it still has crappy UX, because "everyone else" are users too.

    • by Jane Q. Public (1010737) on Friday May 24, 2013 @12:38PM (#43813985)

      "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.

      • by geekoid (135745)

        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?

        • by Frosty Piss (770223) * on Friday May 24, 2013 @01:00PM (#43814303)

          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.

        • by fahrbot-bot (874524) on Friday May 24, 2013 @01:55PM (#43815007)

          What if the ability to do X harmed others?

          That responsibility/consequence fall to the user, not the tool used.

          • User: "Computer, detonate the warhead."
          • Computer: "This will result in destruction and many deaths. Are you sure you want to do this?".
          • User: "Yes."
          • Computer: "Are you really sure?"
          • User: "Yes."
          • Computer: "Are you really, really, REALLY sure?"
          • User: "Yes."
          • Computer: "Target out of range."
      • by grasshoppa (657393) <skennedy@@@tpno-co...org> on Friday May 24, 2013 @12:45PM (#43814099) Homepage

        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.

        • by SirGarlon (845873)

          I have considered it more my failure to communicate the risk than the user's failure

          I don't have mod points today so I'll just say I like your attitude. :-) This is, in my opinion, a professional mentality.

          • I have considered it more my failure to communicate the risk than the user's failure

            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."

      • So you were responsible for the Windows Vista's endless warnings.
      • by Antipater (2053064) on Friday May 24, 2013 @01:01PM (#43814309)

        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.

        • by King_TJ (85913) on Friday May 24, 2013 @03:14PM (#43815831) Journal

          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.

      • by Anonymous Coward on Friday May 24, 2013 @01:09PM (#43814395)

        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.

    • 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

      • 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

        • by lgw (121541) on Friday May 24, 2013 @04:02PM (#43816205) Journal

          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.

          • 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 opposi

    • 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 scri

      • 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?

        • by gstoddart (321705) on Friday May 24, 2013 @01:22PM (#43814587) Homepage

          Ever notice that when you deliver something, they've managed to change the requirements?

          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.

          • by RabidReindeer (2625839) on Friday May 24, 2013 @02:16PM (#43815235)

            Ever notice that when you deliver something, they've managed to change the requirements?

            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.

      • by h4rr4r (612664)

        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.

    • by h4rr4r (612664)

      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.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

    • good for who? (Score:4, Insightful)

      by gl4ss (559668) on Friday May 24, 2013 @01:07PM (#43814373) Homepage Journal

      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.

    • by geekmux (1040042)

      ...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.

      • by mattventura (1408229) on Friday May 24, 2013 @01:39PM (#43814811) Homepage
        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'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 discoura

    • by Altus (1034)

      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.

  • Depends ... (Score:5, Insightful)

    by gstoddart (321705) on Friday May 24, 2013 @12:28PM (#43813835) Homepage

    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.

    • by Java Pimp (98454)
      I worked on a piece of software that gathered data from various sensors. The application stored the calibration settings in the system registry which were configured at installation time and should never need to be touched by the user. To make life easy (for us) we created a fancy interface in the application to enter the data but hid it behind a weird hot key combination so the user wouldn't find it and be tempted to monkey with it. AFAIK no one has ever stumbled upon it.
      • To make life easy (for us) we created a fancy interface in the application to enter the data but hid it behind a weird hot key combination so the user wouldn't find it and be tempted to monkey with it. AFAIK no one has ever stumbled upon it.

        In general, security by obscurity is the incorrect approach. Better to make the option known, like "Vendor Maintenance", with hardware and/or software access protection (and logging).

  • 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?

    • by geekoid (135745)

      one word:
      Access

    • It's absolutely far too ambiguous. If he has to do it by analogy because of NDA concerns he could have at least done it with an imaginary software feature that we could consider properly. But to compare it with the existence of a physical machine. Pointless.

    • 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?

      Too many people think they are programmers already. They learned how to do something in BASIC that prints "Hello" and think that that means that they know as much about software development as people who do it as a full-time job. Then they make demands based on that "knowledge".

  • by Microlith (54737) on Friday May 24, 2013 @12:28PM (#43813843)

    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 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?

    • by D1G1T (1136467)
      Because people hate apple's interface designs. Oh, wait...
    • by UnknowingFool (672806) on Friday May 24, 2013 @12:49PM (#43814167)

      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.

      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. So yes they make things so that they can't be tampered with. As a power user, you dislike it, but if you had to deal with direct customer support, I suppose you'd change your tune really quick. You don't like it, don't buy Apple products. And I suppose you don't use OS X. I spend more time using Terminal in OS X than I anything else.

      Rather than being assholes like Apple, perhaps you could make this configurable in some fashion? Whatever the hell "this" is?

      As long as he is willing to deal with any support nightmares that come with that decision.

      • by unrtst (777550)

        Rather than being assholes like Apple, perhaps you could make this configurable in some fashion? Whatever the hell "this" is?

        As long as he is willing to deal with any support nightmares that come with that decision.

        He doesn't have to deal with it. Do it like "about:config" in firefox, and have a "restore defaults" button. If they break things because they said, "I know what I'm doing and want to be able to break things", and then things break, you just tell them they shouldn't have broke stuff... please see your local backup administrator :-)

        In the Apple case, a simple checkbox burried in an advanced settings area that enabled other software sources would work fine. They could even treat them like apt sources - others

  • this (Score:4, Funny)

    by Joe_Dragon (2206452) on Friday May 24, 2013 @12:30PM (#43813871)
  • by Anonymous Coward

    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.

  • Power User mode (Score:5, Insightful)

    by FrostDust (1009075) on Friday May 24, 2013 @12:31PM (#43813891)

    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.

  • by Imagix (695350) on Friday May 24, 2013 @12:32PM (#43813909)
    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.
    • by gstoddart (321705)

      The good ones also have a checkbox that says "Don't ask this again".

      Please, the presence of a checkbox which says don't ask me again doesn't signify anything useful.

      Out of the box, IE more or less says "you are about to access the internet now, are you sure?" unless you check the damned box.

    • by SQL Error (16383) on Friday May 24, 2013 @01:26PM (#43814653)

      The bad ones have "Are you sure?" The awful ones have "Don't ask this again." The good ones have "Undo."

    • by Tom (822) on Friday May 24, 2013 @01:33PM (#43814729) Homepage Journal

      Actually, while confirmation dialogs started out this way, it's 2013 and their main purpose has evolved into cover-your-ass for the software designers. Well designed software today does not give you a popup dialog (which by now almost all users have been trained to ignore due to the massive amount of misuse), but an additional step like a checkbox you have to enter, or the need to enter, say, your account username or your passowrd to delete the account instead of just clicking a button.

  • by jwales (97533) on Friday May 24, 2013 @12:33PM (#43813915) Homepage

    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

    • Learn to think in the wiki way.

      Or just have an undo button...

      The thing that leads me to think this isn't the whole story is the flying car analogy at the beginning. The trouble is that if users can crash their flying car into someone else's house, then it's no longer just their problem, even if they could undo the damage to their own car (somewhat stretching the analogy there).

      Jimmy Wales - Wikipedia.org

      Say what? Is this guy the real deal? The skeptic in me says no, but the rather low user ID makes me doubt

  • by decipher_saint (72686) on Friday May 24, 2013 @12:33PM (#43813921) Homepage

    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.

    • by David Gould (4938)

      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.

      If you're very, very lucky.

  • 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 inste

  • by Twinbee (767046) on Friday May 24, 2013 @12:41PM (#43814023) Homepage
    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.
  • 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.

  • 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.

    Ah, building a porn site, are you?

  • 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.

  • by cloudmaster (10662) on Friday May 24, 2013 @12:44PM (#43814077) Homepage Journal

    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.

  • by Slartibartfast (3395) <`gro.stoj' `ta' `nek'> on Friday May 24, 2013 @12:45PM (#43814115) Homepage Journal

    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.

  • 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.
  • When installing the "Launch Nuclear Missiles" button, yes, you make it hard to do my mistake. You don't make it a single, large button easy to hit by accident. Instead you put a locking plastic case around it, and require two users to activate.

    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.

  • 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 i

  • by flayzernax (1060680) on Friday May 24, 2013 @12:54PM (#43814227)

    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.

  • ...and the lawyers will love you.

  • 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
  • by geekmux (1040042)

    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.

  • by conspirator23 (207097) on Friday May 24, 2013 @01:24PM (#43814615)

    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.

  • by sgunhouse (1050564) on Friday May 24, 2013 @02:10PM (#43815169)

    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.

  • by Requiem18th (742389) on Friday May 24, 2013 @02:49PM (#43815585)

    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.

  • by marciot (598356) on Friday May 24, 2013 @04:38PM (#43816489)

    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.

"Never give in. Never give in. Never. Never. Never." -- Winston Churchill

Working...