• Jason (unregistered)

    Wow I wish I could get away with putting that in the documentation for our Access frankenstein applications.

  • Ilya (unregistered)

    lol captchaL burned - yeah, from thinking RUUP!

  • Fulippo (unregistered)

    You should always to read FAQ before using a program..

  • (cs)

    maybe it should say "it throws me up"...

  • Pilothaz (unregistered)

    This is exactly what I shall put in documentation for the application I am creating.

    It confuses the user, but tickles the funny bone of any IT person that needs to look into it.

  • SilverEyes (unregistered)

    Another shining example that documentation solves everything. Remember, rushing things to production (even if only one person) is more important, because with agile it's OK to have bugs/features in post-prod. (i.e. maintenance programming department... which may be the same people as the developers)

  • AdT (unregistered)

    In Soviet Russia, applications crash YOU!

  • Tommy (unregistered) in reply to AdT

    Tommy, you are permanently expelled!

  • Unanimous Coward (unregistered)

    Reminds me of THGTTG "Please do not push this button again"

  • SnapShot (unregistered)

    Reminds me of the old doctor joke:

    Patient: Doctor it hurt with I do this. Doctor: Well, don't do that any more.

  • Da' Man (unregistered) in reply to AdT
    AdT:
    In Soviet Russia, applications crash YOU!
    Rarely. Usually it was the Vodka that crashed you. Sometimes the pott.
  • (cs) in reply to SnapShot
    SnapShot:
    Reminds me of the old doctor joke:

    Patient: Doctor it hurt with I do this. Doctor: Well, don't do that any more.

    http://help.station.sony.com/cgi-bin/soe.cfg/php/enduser/std_adp.php?p_faqid=16305&p_created=1145581333&p_sid=kL_k1OFi&p_accessibility=0&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MSZwX3Byb2RzPSZwX2NhdHM9JnBfcHY9JnBfY3Y9JnBfc2VhcmNoX3R5cGU9c2VhcmNoX25sJnBfcGFnZT0xJnBfc2VhcmNoX3RleHQ9aHVydHM*&p_li=&p_topview=1

  • maht (unregistered) in reply to Unanimous Coward

    or "do not look into laser with remaining eye"

  • (cs)

    Brilliant

  • (cs)

    Hey, that's a genius idea. Think of all the hours of bugfixing that can be done away with once we realize that all those crashes are the fault of the stupid users, and intended behavior!

    I'll never have to release another patch! Yay!

  • DKleinsc (unregistered)

    From the Jargon File (http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-.html):

    Don't do that then!: imp.

    [from an old doctor's office joke about a patient with a trivial complaint] Stock response to a user complaint. “When I type control-S, the whole system comes to a halt for thirty seconds.” “Don't do that, then!” (or “So don't do that!”). Compare RTFM.

    Here's a classic example of “Don't do that then!” from Neal Stephenson's In The Beginning Was The Command Line. A friend of his built a network with a load of Macs and a few high-powered database servers. He found that from time to time the whole network would lock up for no apparent reason. The problem was eventually tracked down to MacOS's cooperative multitasking: when a user held down the mouse button for too long, the network stack wouldn't get a chance to run...

  • (cs)

    That reminds me of an email I got where someone found one of my informal messages.

    "Hey I deleted a widget. Then I decided I didn't want to delete it so I clicked the back button and it wouldn't let me update it. Something about 'This widget does not exist. I'm not sure what you did, but never do it again.'"

    That was also the week before I implemented a change control to remove all the SQL Delete commands in favor of having a 'deleted' boolean. Sucks to be him.

  • Edss (unregistered) in reply to SnapShot
    SnapShot:
    Reminds me of the old doctor joke:

    Patient: Doctor it hurt with I do this. Doctor: Well, don't do that any more.

    Similar one in House:

    Patient: My arm hurts when I wake up, because I sleep on it House: OK, well don't sleep on it then Patient: But.. That's how I sleep! House: Well, there's always surgery... Patient: What, like, go in and remove some cartilage or something? House: Some cartilage isn't what's hurting.

  • (cs) in reply to Unanimous Coward
    Unanimous Coward:
    Reminds me of THGTTG "Please do not push this button again"

    Thinking in terms of a user interface, I can actually see justification of that message. Say there's a button which has a specific function and only actually does anything at all provided some other complicated process has already been initiated. Were someone who didn't know what they were doing poking around, they may push the button without knowing what it did. You could either give a long-ass message explaining that there is no conceivable way they could have known what they were doing /and/ pushed that button, you could give something cryptic that only one who would already know not to push that button would understand anyway, or you could just give a nod to the more likely option, and tell this person "look, I know you're just fucking around here, but while you've not actually fucked anything up, if you pushed that button in another situation you could very well have fucked things up. Please do not push that button again."

  • Maciej (unregistered) in reply to skztr
    skztr:
    Thinking in terms of a user interface, I can actually see justification of that message. Say there's a button which has a specific function and only actually does anything at all provided some other complicated process has already been initiated. Were someone who didn't know what they were doing poking around, they may push the button without knowing what it did. You could either give a long-ass message explaining that there is no conceivable way they could have known what they were doing /and/ pushed that button, you could give something cryptic that only one who would already know not to push that button would understand anyway, or you could just give a nod to the more likely option, and tell this person "look, I know you're just fucking around here, but while you've not actually fucked anything up, if you pushed that button in another situation you could very well have fucked things up. Please do not push that button again."

    Or you could do something sane like disabling/hiding a button that has no conceivable purpose.

  • (cs) in reply to Maciej
    Maciej:
    skztr:
    Thinking in terms of a user interface, I can actually see justification of that message. Say there's a button which has a specific function and only actually does anything at all provided some other complicated process has already been initiated. Were someone who didn't know what they were doing poking around, they may push the button without knowing what it did. You could either give a long-ass message explaining that there is no conceivable way they could have known what they were doing /and/ pushed that button, you could give something cryptic that only one who would already know not to push that button would understand anyway, or you could just give a nod to the more likely option, and tell this person "look, I know you're just fucking around here, but while you've not actually fucked anything up, if you pushed that button in another situation you could very well have fucked things up. Please do not push that button again."

    Or you could do something sane like disabling/hiding a button that has no conceivable purpose.

    I had several grayed-out buttons on a form that would un-gray them when the pre-requisites had been completed. Just for fun, I set it so that, if the user clicked the button while it was grayed-out, it would pop up a message that said, "Grayed-Out Buttons are Disabled for your Own Safety. Click again at your own risk." Some of them would give an evil laugh when they popped up that message. Of course, in the same application, I also had a button labeled, "Does Nothing", which, of course, had no code assigned to it at all. Wouldn't even depress when clicked. Had a few tech support calls about that. Then I started getting suggestions for other humorous things to add to the program.

  • dolo54 (unregistered) in reply to Gsquared
    Gsquared:
    Maciej:
    skztr:
    Thinking in terms of a user interface, I can actually see justification of that message. Say there's a button which has a specific function and only actually does anything at all provided some other complicated process has already been initiated. Were someone who didn't know what they were doing poking around, they may push the button without knowing what it did. You could either give a long-ass message explaining that there is no conceivable way they could have known what they were doing /and/ pushed that button, you could give something cryptic that only one who would already know not to push that button would understand anyway, or you could just give a nod to the more likely option, and tell this person "look, I know you're just fucking around here, but while you've not actually fucked anything up, if you pushed that button in another situation you could very well have fucked things up. Please do not push that button again."

    Or you could do something sane like disabling/hiding a button that has no conceivable purpose.

    I had several grayed-out buttons on a form that would un-gray them when the pre-requisites had been completed. Just for fun, I set it so that, if the user clicked the button while it was grayed-out, it would pop up a message that said, "Grayed-Out Buttons are Disabled for your Own Safety. Click again at your own risk." Some of them would give an evil laugh when they popped up that message. Of course, in the same application, I also had a button labeled, "Does Nothing", which, of course, had no code assigned to it at all. Wouldn't even depress when clicked. Had a few tech support calls about that. Then I started getting suggestions for other humorous things to add to the program.

    remind me not to hire you!

  • Gsquared (unregistered) in reply to dolo54

    don't forget not to hire me

  • (cs)

    I've completed a new database app, and it's rolled out to the users. In the first training session app, the trainer walks the users up to a point where they dismiss a dialog box. "Hey," says a user in the back, "It crashes when I hit Escape." "So don't hit Escape," says the trainer, without skipping a beat, and proceeds to the next step in the training.

    Fortunately I was in the room at the time, and told them I'd look into it and fix it.

    --RA

  • Steve (unregistered)

    They should have just told the users to See Figure 1.

    (. . . how many readers of this blog even know what VMS is?)

  • (cs) in reply to SnapShot
    SnapShot:
    Reminds me of the old doctor joke:

    Patient: Doctor it hurt with I do this. Doctor: Well, don't do that any more.

    Patient: I keep getting stiff in the joints. Doctor: Then stay out of the joints.

  • Bob (unregistered) in reply to SnapShot
    SnapShot:
    Reminds me of the old doctor joke:

    Patient: Doctor it hurt with I do this. Doctor: Well, don't do that any more.

    Or this variant:

    Patient: Doctor it hurt with I do this. Doctor: You don't make any sense. Patient: I mean when I do this. Doctor: Well, don't do that any more. Patient: OK, but I can still do this? Doctor: Here's a prescription for some pills. Now go away.

  • (cs) in reply to dolo54
    dolo54:
    Gsquared:
    Maciej:
    skztr:
    Thinking in terms of a user interface, I can actually see justification of that message. Say there's a button which has a specific function and only actually does anything at all provided some other complicated process has already been initiated. Were someone who didn't know what they were doing poking around, they may push the button without knowing what it did. You could either give a long-ass message explaining that there is no conceivable way they could have known what they were doing /and/ pushed that button, you could give something cryptic that only one who would already know not to push that button would understand anyway, or you could just give a nod to the more likely option, and tell this person "look, I know you're just fucking around here, but while you've not actually fucked anything up, if you pushed that button in another situation you could very well have fucked things up. Please do not push that button again."

    Or you could do something sane like disabling/hiding a button that has no conceivable purpose.

    I had several grayed-out buttons on a form that would un-gray them when the pre-requisites had been completed. Just for fun, I set it so that, if the user clicked the button while it was grayed-out, it would pop up a message that said, "Grayed-Out Buttons are Disabled for your Own Safety. Click again at your own risk." Some of them would give an evil laugh when they popped up that message. Of course, in the same application, I also had a button labeled, "Does Nothing", which, of course, had no code assigned to it at all. Wouldn't even depress when clicked. Had a few tech support calls about that. Then I started getting suggestions for other humorous things to add to the program.

    remind me not to hire you!

    Remind me to join your company

  • Porpus (unregistered)

    I have always had a problem with the dictum that inappropriate or unavailable UI elements should be grayed out (or otherwise visibly disabled). According to this dictum (to which most posters here seem to subscribe), it's subpar to allow the user to click, say, a button when that button's usual action will not occur.

    Having been frustrated many, many times by GUIs in which things were disabled for no apparent reason, I have decided the dictum is bogus. In such frustrating situations, I would much rather click the button and get some kind of message. At least then, there would be some chance I could figure out why my desired button was gray.

    Am I alone in this opinion? To me, this seems like a clear case where the prevailing wisdom is 100% wrong.

  • (cs) in reply to Porpus
    Porpus:
    I have always had a problem with the dictum that inappropriate or unavailable UI elements should be grayed out (or otherwise visibly disabled). According to this dictum (to which most posters here seem to subscribe), it's subpar to allow the user to click, say, a button when that button's usual action will not occur.

    Having been frustrated many, many times by GUIs in which things were disabled for no apparent reason, I have decided the dictum is bogus. In such frustrating situations, I would much rather click the button and get some kind of message. At least then, there would be some chance I could figure out why my desired button was gray.

    Am I alone in this opinion? To me, this seems like a clear case where the prevailing wisdom is 100% wrong.

    Sadly, I don't think you're alone.

    You would be expecting an informative message like "This button used to be grayed out until QA told us they were failing tests and we had to put a dialog box in for production, because it's company policy. There is some chance that you can figure out why your desired button is gray. Share and enjoy!"

    Most computer programs, in my limited experience, do not work this way. It is either because

    (a) It is impossible, using current technology, to determine what the user was trying to do when they chose an option that was specifically prohibited.

    (b) GUIs, like any other interface, are inherently state-driven. Written correctly, each state in the state machine will only allow triggers that produce an acceptable action and result in a well-defined end state. Written incorrectly, they will eat your hard drive. But hey! You got to click on that button, and you can probably figure out what went wrong after that ...

    (c) Most GUI programmers are illiterate idiots who wouldn't understand a state machine if it slapped them across the face with a wet halibut.

    Not sure myself. It's probably a combination of the three.

  • Porpus (unregistered) in reply to real_aardvark

    So you advocate the prevailing wisdom, i.e. graying things out? You've still not convinced me, at least not for command buttons and the like.

    Item (a) is a straw man argument... it's true but irrelevant. I don't need to figure out everything the user was thinking. I just need to describe whatever aspect of the program's state prohibits the user from using one button.

    Item (b) really misinterprets what I wrote... I don't expect the user to actually be able to do anything inappropriate. I just think that sharing a little info about the nature of the state machine might be helpful to the user after an inappropriate or unexpected click.

    Item (c) a sort of ad hominem attack that is unfortunately common in this field of work. I agree that competence is a real problem in computing right now... I submit that attitude is almost as big a problem, and I for one am looking for other mountains to climb.

  • Christophe (unregistered) in reply to FredSaw
    FredSaw:
    SnapShot:
    Reminds me of the old doctor joke:

    Patient: Doctor it hurt with I do this. Doctor: Well, don't do that any more.

    Patient: I keep getting stiff in the joints. Doctor: Then stay out of the joints.

    How 'bout this one:

    Doctor: Take one of these pills each day. They will cure you, but also make you very ugly.

    Patient, after 6 months of therapy: You are a terrible doctor! I am cured, but am not yet ugly!

  • GryMor (unregistered) in reply to Porpus

    Grey them out, but put in a hover/tooltip that explains (in as much as it's possible), why the button is disabled in the current state.

    It beats the tar out of modal error dialogs.

  • Robert Payne (unregistered) in reply to DKleinsc

    Ahhh, the joys of token ring.

    DKleinsc:
    Here's a classic example of “Don't do that then!” from Neal Stephenson's In The Beginning Was The Command Line. A friend of his built a network with a load of Macs and a few high-powered database servers. He found that from time to time the whole network would lock up for no apparent reason. The problem was eventually tracked down to MacOS's cooperative multitasking: when a user held down the mouse button for too long, the network stack wouldn't get a chance to run...
  • Chris Cormie (unregistered)

    When code provided by our parent company crashed when the user hit a certain GUI button, we naturally asked them for a solution. Which they provided: "User must not."

    This of course became the team response to any problem whatsover: "User must not."

Leave a comment on “When will users learn?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article