Is user a monkey?



  • I had to laugh at this, from one of the Android API samples:

        if (mAM.isUserAMonkey()) {
            // Don't trust monkeys to do the right thing!
            AlertDialog.Builder builder = new AlertDialog.Builder(Controller.this);
            builder.setMessage("You can't wipe my data because you are a monkey!");
            builder.setPositiveButton("I admit defeat", null);
            builder.show();
            return;
        }
    

     So I looked up the isUserAMonkey() function, and here's what it does:

    public static boolean isUserAMonkey ()
    Since: API Level 8
    

    Returns "true" if the user interface is currently being messed with by a monkey.

     Of course it's referring to an automated test tool, but I've worked on UI projects in the past where it would have been really useful to be able to judge the user's level of sentience like this!

     



  •  I would be actually very happy if many "users" I've had to deal with could class as monkeys: at least a monkey eventually learns by observation/repetition/mimicking.



  • I am sure you could easily concoct a simple test to determine it.

    I use a simple one with confirm dialogs; one dialog says "do you want to continue? [yes] [no]" and the next says "do you want to cancel? Press no to continue. [yes] [no]". The monkeys just click "yes" every time. It takes a more alert user to read the dialogs and follow the instructions. Sure, it may also collect smart-but-bored users as monkeys, but in this case, the only users who I want to treat as smart, are the ones who take the time to read and follow instructions, instead of blindly clicking dialogs.



  • What would actually happen is that monkeys learn "first click Yes, then click No". What would actually actually happen, is that users would say "fuck you and your mind games" and abandon the app.



  • @piskvorr said:

    users would say "fuck you and your mind games" and abandon the app
    I'd agree ... if this were an app. It's a page that Web site visitors will typically encounter only once, ever. If a user says "fuck you" and heads elsewhere, then in my case, I am fortunate enough not to have to care. The intention of it is to block all monkeys from getting past that page, and allowing only the smart ones to continue.

    There are many tests that exist in real life to distinguish dumb users (bots) from smart users; visual/mathematical captchas for contact forms, or entrance exams for education courses. While I agree that my particular test is heavily tailored to my own use case, you could easily use something not so obvious to detect the difference between a smart and monkeyish user, both paths of which would work, but for example you can choose which default layout (simple/advanced) to use based on that. The only problem left is to make sure that your testers test both branches...



  • This is why it's better to use verbs on your buttons rather than just a yes/no/cancel/file-not-found.  For "Do you want to continue?" or "Do you want to cancel?, the buttons should absolutely not be "Yes" and "No", but "Continue" and "Cancel".  That way both monkeys AND impatient humans can enjoy being suckered into buying crappy mobile apps for a few bucks.



  • Yay! [url=http://folklore.org/StoryView.py?project=Macintosh&story=Monkey_Lives.txt&sortOrder=Sort%20by%20Date&detail=medium]The monkey lives on![/url] (naming the symbol "MonkeyLives" has the advantage of being ever so slightly more respectful of the user. Not that the user can see it, anyway.)



  • @Xyro said:

    This is why it's better to use verbs on your buttons rather than just a yes/no/cancel/file-not-found.  For "Do you want to continue?" or "Do you want to cancel?, the buttons should absolutely not be "Yes" and "No", but "Continue" and "Cancel".  That way both monkeys AND impatient humans can enjoy being suckered into buying crappy mobile apps for a few bucks.

     

    I agree that Yes/No buttons need to fucking DIAF.



  • @Xyro said:

    This is why it's better to use verbs on your buttons rather than just a yes/no/cancel/file-not-found.  For "Do you want to continue?" or "Do you want to cancel?, the buttons should absolutely not be "Yes" and "No", but "Continue" and "Cancel". 

    Epiphany. Thanks!

    Something that was an eyeopener to me the other day: instead of  positioning labels/textfields horizontally, for instance

    First name: .............[_________________]

    Last name:..............[_________________]

    it's better to place the labels over the texboxes, like so:

    <FONT size=2>First name...................................Last name</FONT>

    [_________________]..................[_________________]

    This was new to me but it made immediately sense.



  • One way isUserAMonkey () could be implemented is by monitoring keypresses and analyzing the randomness of the keypress pattern.  Have some heuristic that returns true in two cases, (1) a high randomness which indicates aimless keypressing, and (2) a definite pattern repeated say more than 5 times, which indicates a user who keeps trying the same key combination expecting different results.  Also an having access to an accelerometer would be useful to see if the user has recently banged the phone on the ground in an attempt to get at the delicious insides.



  • In my first job I was working at steel plant that had originally recruited a lot of production workers from the local farming community. One of the local farming specialties was apples, so it was common to refer to the production workers as "Apple pickers" in a sort of light hearted way. As such I had edited a program and added a comment about telling the apple pickers about something. Unfortunately one day one of the electrical shift supervisors was flicking through (a several inch thick) printout of that code with the production manager standing next to him. Of course they happened to open it to the one page in the entire code base where I had said "apple pickers". After that I always made sure my code comments were nice and precise and professional.



  • @Xyro said:

    For "Do you want to continue?" or "Do you want to cancel?, the buttons should absolutely not be "Yes" and "No", but "Continue" and "Cancel".

     

    Will Cancel cancel the operation in question or just my request for cancellation? What's wrong with yes/no and do/don't buttons for yes/no questions?


  • @fatbull said:

    @Xyro said:
    For "Do you want to continue?" or "Do you want to cancel?, the buttons should absolutely not be "Yes" and "No", but "Continue" and "Cancel".
    Will Cancel cancel the operation in question or just my request for cancellation? What's wrong with yes/no and do/don't buttons for yes/no questions?
    In short, verbs are better on the boxes because it's easier and faster to read. If you already have a general idea of what the dialog box is going to be complaining about, you can skip to the action without having to read how the programmer or translator phrased the request.

    One such request that seems to be different every time I look is "You have an unsaved document.  Are you sure you want to close?" vs "You have an unsaved document.  Do you want to save it?"  Buttons labeled with "Save"/"Close" rather than "Yes"/"No" would make my life a lot less stressful.

    And canceling cancellation is an action only dreamed up by sadistic programmers.



  • @TarquinWJ said:

    @piskvorr said:
    users would say "fuck you and your mind games" and abandon the app
    I'd agree ... if this were an app. It's a page that Web site visitors will typically encounter only once, ever. If a user says "fuck you" and heads elsewhere, then in my case, I am fortunate enough not to have to care. The intention of it is to block all monkeys from getting past that page, and allowing only the smart ones to continue.

    There are many tests that exist in real life to distinguish dumb users (bots) from smart users; visual/mathematical captchas for contact forms, or entrance exams for education courses. While I agree that my particular test is heavily tailored to my own use case, you could easily use something not so obvious to detect the difference between a smart and monkeyish user, both paths of which would work, but for example you can choose which default layout (simple/advanced) to use based on that. The only problem left is to make sure that your testers test both branches...

    You don't develop anything you expect the general public to use? Christ, your ideas of usability are out of the dark ages.



  • @Xyro said:

    One such request that seems to be different every time I look is "You have an unsaved document.  Are you sure you want to close?" vs "You have an unsaved document.  Do you want to save it?"  Buttons labeled with "Save"/"Close" rather than "Yes"/"No" would make my life a lot less stressful.

    I worked with a CMS where you could input your work online in a opup form; then when you closed the form, the "Are you sure" message basically meant "Are you sure you want to lose all your data". I've forgotten the specifics, but I think the browser close event (2001) didn't allow you to save, only to cancel the closing.

    It was pretty annoying, especially to a colleague who made that mistake at least daily.



  • @Xyro said:

    In short, verbs are better on the boxes because it's easier and faster to read.

    As long as it is clear what those buttons mean, that's OK I guess. But "Cancel" is different.

    @Xyro said:

    And canceling cancellation is an action only dreamed up by sadistic programmers.
     

    Consider a dialog with a progress bar and a "Cancel" button below. Obviously, "Cancel" (or, for that matter, the generic "X" button to close a window) will cancel whatever operation is going on in that dialog, since a "Cancel" button usually applies to the surrounding dialog box.

    But what if you are asked for confirmation to cancel something? Again, by convention, the "Cancel" or "X" buttons apply to the confirmation dialog box and will deny whatever was requested, so you have to press "Continue" instead of "Cancel". Unless you take the button labels literally, in which case you have to press "Cancel" instead of "Continue". Great way to confuse users.

    Do you know the old "stop unresponsive script" confirmation of Mozilla (random picture I found on google)? Guess which button you had to click to actually stop the script!



  • @fatbull said:

    But what if you are asked for confirmation to cancel something? Again, by convention, the "Cancel" or "X" buttons apply to the confirmation dialog box and will deny whatever was requested, so you have to press "Continue" instead of "Cancel". Unless you take the button labels literally, in which case you have to press "Cancel" instead of "Continue". Great way to confuse users.

    Do you know the old "stop unresponsive script" confirmation of Mozilla (random picture I found on google)? Guess which button you had to click to actually stop the script!

    Exactly!  The buttons should be "Abort" or "Continue".  Same deal with an interrupted cancellation.  Instead of buttons that confuse "continue the cancellation" and "cancel the cancellation", a more descriptive layout may be called for.  There's nothing wrong with more than one word on a button so how about, "Abort cancellation" and "Continue cancellation"?

    In the case of that "stop unresponsive script" box, who would think that "Continue" means "continue the abort" and "Abort" means "abort the continue"?  Crazy people and/or blakeyrat, that's who.



  • @blakeyrat said:

    You don't develop anything you expect the general public to use?
    Methinks maybe you should read the tags.



  • @Xyro said:

    Exactly!  The buttons should be "Abort" or "Continue".  Same deal with an interrupted cancellation.  Instead of buttons that confuse "continue the cancellation" and "cancel the cancellation", a more descriptive layout may be called for.  There's nothing wrong with more than one word on a button so how about, "Abort cancellation" and "Continue cancellation"?

    How about simply "Yes" and "No"? Sure, you might have to read the message, but it would be less confusing than this whole cancellation continuation abortion mess. "Stop Task" and "Continue Task" would probably work, too.

    @Xyro said:

    In the case of that "stop unresponsive script" box, who would think that "Continue" means "continue the abort" and "Abort" means "abort the continue"?

     

    (BTW, the buttons actually read "OK" and "Cancel". They have been replaced by "Stop Script" and "Continue" in current versions.)

    People like me who think "leftmost commit button = stop asking and just DO it" and "Cancel = X = just get me out of here" might. Until they actually read the text and get confused.



  • @b-redeker said:

    it's better to place the labels over the texboxes, like so:

    <font size="2">First name...................................Last name</font>

    [_________________]..................[_________________]

    This was new to me but it made immediately sense.

    The Windows User Experience Guidelines—or UX Guidelines—document (which I'd recommend you search for and view on, or download from, MSDN) agrees, though it says either layout is acceptable. I think I would prefer the label-above layout generally, reverting to label-beside only if I didn't have enough space in the dialog/window/whatever to use text-above. That seems to be what MS themselves do nowadays (compare XP dialogs for things like Computer Name to Vista/Win7 ones). Incidentally, the Form Wizard in MS Access has, since V2, used label-above layout when placing textboxes on forms.


  • @fatbull said:

    How about simply "Yes" and "No"?

    While they may be technically correct, many users first (or only) look at those buttons. So if you can make those buttons self-descriptive, that must always be better than just yes/no.


  • Garbage Person

    Amusingly, I have a class that does a bunch of authentication and stores userdata for the currently logged in user (biometrics, contact info, shit like that) - one of the properties on that class is in fact UserIsMonkey - which is true when the currently authenticated user is allowed to meddle with a bunch of low-level, normally hidden or read-only fields in the app.

     

    The same class also features:

    UserIsUser (return true. I suppose at some point that might be implemented, so the app checks it anyway)
    UserIsAdmin (Duh.)
    UserIsGod (Because there are some things even administrators shouldn't fucking touch)
    UserIsBroken (For users which are broken)
    UserHasNoHands (for users which can't have signature biometrics)



  • @OzPeter said:

    In my first job I was working at steel plant that had originally recruited a lot of production workers from the local farming community. One of the local farming specialties was apples, so it was common to refer to the production workers as "Apple pickers" in a sort of light hearted way. As such I had edited a program and added a comment about telling the apple pickers about something. Unfortunately one day one of the electrical shift supervisors was flicking through (a several inch thick) printout of that code with the production manager standing next to him. Of course they happened to open it to the one page in the entire code base where I had said "apple pickers". After that I always made sure my code comments were nice and precise and professional.
     

    One of the most famous comments in a codebase I used to work with described the purpose of the program and read as follows:

     Used as an externally interface for perfecting purposes.

    I feel secure in suggesting that whoever wrote that comment thought at the time that it was "nice and precise and professional".



  • @fatbull said:

    Do you know the old "stop unresponsive script" confirmation of Mozilla (random picture I found on google)? Guess which button you had to click to actually stop the script!

    Well, the buttons should be "Stop" and "Wait". Chromium gets that right (it phrases the question "These pages had become unresponsive. Do you want to kill them?" (there is a list of pages, you can select only some of them) and uses "Kill" and "Wait" for the buttons).

    Note, that both KDE and GNOME have human interface guidelines that both say that the buttons must use descriptive verbs and that Cancel should be used for and used only for the safe option and must always be placed on the same side (GNOME follows Mac so it has cancel left, KDE follows Windows so it has cancel right). I never understood why Microsoft can't design a consistent usable GUI.



  • @Xyro said:

    @fatbull said:

    But what if you are asked for confirmation to cancel something? Again, by convention, the "Cancel" or "X" buttons apply to the confirmation dialog box and will deny whatever was requested, so you have to press "Continue" instead of "Cancel". Unless you take the button labels literally, in which case you have to press "Cancel" instead of "Continue". Great way to confuse users.

    Do you know the old "stop unresponsive script" confirmation of Mozilla (random picture I found on google)? Guess which button you had to click to actually stop the script!

    Exactly!  The buttons should be "Abort" or "Continue".

    While I generally agree that it's a good idea to use verbs as action button labels, I'll make another claim: the verbs of the buttons should relate to those in the text of the dialog. Especially with such generic verbs as "abort". Ideally, the "confirm" button should use the exact same wording as the dialog text (as someone noted, Firefox did this and changed it to read "stop script" in response to "do you want to stop the script?").



  • @frits said:

    One way isUserAMonkey () could be implemented is by monitoring keypresses and analyzing the randomness of the keypress pattern.  Have some heuristic that returns true in two cases, (1) a high randomness which indicates aimless keypressing, and (2) a definite pattern repeated say more than 5 times, which indicates a user who keeps trying the same key combination expecting different results.  Also an having access to an accelerometer would be useful to see if the user has recently banged the phone on the ground in an attempt to get at the delicious insides.

     

    Wasn't there a software intended to filter out keystrokes generated by a cat walking on your keyboard or somesuch?

     

    P.S.: [url=http://www.bitboost.com/pawsense/]it was Pawsense[/url]. No idea if it returned false positives though (e.g. when playing games).



  • @C4I_Officer said:

    @frits said:

    One way isUserAMonkey () could be implemented is by monitoring keypresses and analyzing the randomness of the keypress pattern.  Have some heuristic that returns true in two cases, (1) a high randomness which indicates aimless keypressing, and (2) a definite pattern repeated say more than 5 times, which indicates a user who keeps trying the same key combination expecting different results.  Also an having access to an accelerometer would be useful to see if the user has recently banged the phone on the ground in an attempt to get at the delicious insides.

     

    Wasn't there a software intended to filter out keystrokes generated by a cat walking on your keyboard or somesuch?

     

    P.S.: it was Pawsense. No idea if it returned false positives though (e.g. when playing games).

    That's, wait for it... pawesome.



  • @Bulb said:

    @fatbull said:

    Do you know the old "stop unresponsive script" confirmation of Mozilla (random picture I found on google)? Guess which button you had to click to actually stop the script!

    Well, the buttons should be "Stop" and "Wait". Chromium gets that right (it phrases the question "These pages had become unresponsive. Do you want to kill them?" (there is a list of pages, you can select only some of them) and uses "Kill" and "Wait" for the buttons).

    Note, that both KDE and GNOME have human interface guidelines that both say that the buttons must use descriptive verbs and that Cancel should be used for and used only for the safe option and must always be placed on the same side (GNOME follows Mac so it has cancel left, KDE follows Windows so it has cancel right). I never understood why Microsoft can't design a consistent usable GUI.

    Because open source software is well known for it's quality GUI's. 



  • @DescentJS said:

    I never understood why Microsoft can't design a consistent usable GUI.

    They've designed several. My Xbox has one, for example. Windows Phone 7 seems to be one. Office 2007/2010. Windows Media Center.

    The problem with Microsoft is:
    1) They don't universally recognize the power of usability. Some groups at MS do, other groups do not. Some groups (like SQL Server) have almost IBM-ian levels of hostility towards usable software.
    2) They're constrained by poor decisions made in the past, due to their focus on backwards-compatibility. There are dozens of bugs in Excel that will remain in Excel until the end of time-- such as not being able to open two spreadsheets with the same filename-- because if they were "fixed," VBA applications would fail.
    3) People criticize them whenever they change anything, ever, regardless of whether the change is positive or negative. So even if Microsoft were doing the best job ever as far as usability goes (and I think they're certainly above average), you'd never hear about it. (This happened with the Ribbon in Office 2007, for example. A month after it came out, millions of people who had never seen it or used it could tell you in detail how bad it was.)

    Edit: oh, and they're bad at setting an example to other developers.



  • @blakeyrat said:

    @DescentJS said:
    I never understood why Microsoft can't design a consistent usable GUI.
    They've designed several. My Xbox has one, for example. Windows Phone 7 seems to be one. Office 2007/2010. Windows Media Center.

    The problem with Microsoft is:
    1) They don't universally recognize the power of usability. Some groups at MS do, other groups do not. Some groups (like SQL Server) have almost IBM-ian levels of hostility towards usable software.
    2) They're constrained by poor decisions made in the past, due to their focus on backwards-compatibility. There are dozens of bugs in Excel that will remain in Excel until the end of time-- such as not being able to open two spreadsheets with the same filename-- because if they were "fixed," VBA applications would fail.
    3) People criticize them whenever they change anything, ever, regardless of whether the change is positive or negative. So even if Microsoft were doing the best job ever as far as usability goes (and I think they're certainly above average), you'd never hear about it. (This happened with the Ribbon in Office 2007, for example. A month after it came out, millions of people who had never seen it or used it could tell you in detail how bad it was.)

    Edit: oh, and they're bad at setting an example to other developers.

    You do realize that I didn't say that, right?



  • @DescentJS said:

    @blakeyrat said:

    @Bulb said:
    (Previously attributed to DescentJS) I never understood why Microsoft can't design a consistent usable GUI.
    They've designed several. My Xbox has one, for example. Windows Phone 7 seems to be one. Office 2007/2010. Windows Media Center.

    The problem with Microsoft is:
    1) They don't universally recognize the power of usability. Some groups at MS do, other groups do not. Some groups (like SQL Server) have almost IBM-ian levels of hostility towards usable software.
    2) They're constrained by poor decisions made in the past, due to their focus on backwards-compatibility. There are dozens of bugs in Excel that will remain in Excel until the end of time-- such as not being able to open two spreadsheets with the same filename-- because if they were "fixed," VBA applications would fail.
    3) People criticize them whenever they change anything, ever, regardless of whether the change is positive or negative. So even if Microsoft were doing the best job ever as far as usability goes (and I think they're certainly above average), you'd never hear about it. (This happened with the Ribbon in Office 2007, for example. A month after it came out, millions of people who had never seen it or used it could tell you in detail how bad it was.)

    Edit: oh, and they're bad at setting an example to other developers.

    You do realize that I didn't say that, right?

     

    Here is a repaired version of the quoting.



  • @locallunatic said:

    You do realize that I didn't say that, right?

    Sorry, I'm not trying ti put words in anybody's mouth.

    It's a bug in CS... if I select text in a {quote user="blah"} tag in the original post, then click the "Quote" button, it puts the wrong name in the resulting quote tag.

    Although I guess it's my own stupidity in assuming that anything in CS would work correctly. But I still take no responsibility for CS bugs.

    Edit: See? It did it again in this post.



  • @b-redeker said:

    it's better to place the labels over the texboxes, like so:

    <font size="2">First name...................................Last name</font>

    [_________________]..................[_________________]

    This was new to me but it made immediately sense.

     

     

    I'll have to emphatically disagree with that one; I hate that layout both on paper and on the computer.  When you have a lot of input, and you're looking at the middle of alternating lines of boxes and labels, it's not immediately clear whether the label is associated with the box above or the box below it -- even on paper forms there's no clear standard.

     On the other hand, with left & right, at least for English and other left-to-right languages, it's much more intuitive which box is associated with which label.


Log in to reply