Classic outsourced UI design



  • Okay, so I'm fielding support calls for a web app where development was outsourced.

    One page is a very simple "upload spreadsheet" form. One control on the form is "Overwrite existing file?" and it's... a textbox. 

    Yes, the user must manually type either "Yes" or "No" into a textbox to indicate if the existing file should be overwritten. Hmmm.. if only there were some UI control specifically designed to allow the user to pick one of two possible values. A check.. 
    check.. something.

    Anyway, that's not even the worst part. One of our users called up complaining that after he entered "Yes" in this field and clicked the upload button, nothing happened. No message, no script error, nothing. 

    Turns out the validation on this textbox was failing because the user had the gall to enter "Yes" with a capital Y. When you enter all lowercase "yes", the upload works just fine. And the developer forgot to actually make the error message visible when validation fails, which is why it looked like nothing was happening.

    And the absolute worst part? The label next to the textbox actually says, "Overwrite existing file? (Enter Yes/No)"... with a capital Y.



  • The problem with your idea of using a newfangled checkbox type thingy  is that it's not enterprisey, and it just doesn't scale. How are you supposed to enter "maybe" into a checkbox?

    This guy is just one step ahead of the curve
     



  • That is, indeed, classic.  Another case of the local developers not bothering to check up on the outsourced work (I've been the victim of that several times recently, a few of them doozies).

    I'd be afraid of what would come back if it were submitted to them to be changed. Perhaps a group of radio buttons to prompt the user for the text to be entered in the textbox?

    ( ) Yes

    ( ) No

    ( ) Maybe

    ( ) Ask Again Later

    ( ) FILE_NOT_FOUND

     



  • ( ) CowboyNeal

     



  • Why use radio buttons? That unecessarily forces the user to only one response. Checkboxes would be so much better.



  • @emurphy said:

    ( ) CowboyNeal

    Would then this also be necessary:
    ( ) Profit



  • As would the

    ( ) ... 



  •  Surely a job for a drop-down list with the option to select multiple responses, to allow the users to roll their own Maybe & Don't Know from combinations of responses.



  • @flaquito said:

    Why use radio buttons? That unecessarily forces the user to only one response. Checkboxes would be so much better.

    You're assuming that the (single-selection) radio buttons would be implemented correctly.  Based on the previous implementation, I'm not so sure that's a given.
     



  • You're assuming that the (single-selection) radio buttons would be implemented correctly.  Based on the previous implementation, I'm not so sure that's a given.

    True. I've seen before a whole page of radio buttons all seperate from each other, so you could select any and all of them, but not then deselect. i.e. each radio button was in it's own group of one.

    It may have even been on this site.



  • @cconroy said:

    @flaquito said:

    Why use radio buttons? That unecessarily forces the user to only one response. Checkboxes would be so much better.

    You're assuming that the (single-selection) radio buttons would be implemented correctly.  Based on the previous implementation, I'm not so sure that's a given.
     

    don't forget tri-state radio buttons. hehe.



  • @GeneWitch said:

    @cconroy said:

    @flaquito said:

    Why use radio buttons? That unecessarily forces the user to only one response. Checkboxes would be so much better.

    You're assuming that the (single-selection) radio buttons would be implemented correctly.  Based on the previous implementation, I'm not so sure that's a given.
     

    don't forget tri-state radio buttons. hehe.

    The IDE I use at work (SlickEdit) actually has some tri-state checkboxes in its controls.  For example, on the Find dialog, the "Wrap search" option is tri-state.  Normal checkbox behavior would be wrap if checked, don't wrap if not checked.  The third state (visually, the checkbox appears checked but disabled) causes it to prompt you whether or not to wrap upon reaching the end.  Of course, I never remember what that state means, because it's *completely unintuitive*.  Would it have been so difficult to split it into two coupled checkboxes, or three radio buttons?


Log in to reply