SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Usability of Singe input box vs multiple boxes

    With recent projects of mine I keep stumbling across a recurring question. And although I have a rather firm opinion on it, I started hearing opposite opinions on this. So I wanted to get some more educated opinions on this.

    Is it 'better' to have a single input box (textarea) with a description on how "structured" the input has to be entered, OR is it better to design a form with a multitude of several little inputboxes, that are arranged and labeled to make it visually easier to understand what goes where?

    A few examples to illustrate this:
    1) Betting-Slip We have a sports-betting game: 11 Matches and for each match you can enter a 1 or 0 or 2 (homewin, draw, guestwin). So "One Guess" consists of 11 numbers (out of [102]). We want the user to be able to enter up to 12 rows/guesses, resulting in a total of up to 132 numbers.
    Now we have several possibilities:
    a) Singe textarea with a description on how the data has to be formed, for example: 11 numbers per row, up to twelve rows.
    b) One textbox for each row, total number of textboxes would be 12.
    c) One textbox for each match and row, total number of textboxes 132.
    d) One Selectbox (choices 1,0,2) for each match and row, total number of selectboxes 132.

    An additional 'challenge' is that there exist (realworld)paper-forms for betting, where you enter one row/guess from top to bottom, which requires the user to reorient them when entering rows left to right (as it is with the textboxes/textarea). See example c) and example a) live.

    2) numbers & keywords: We want the user to be able to enter several numbers (no min or max limit) and for each number he should have the option of entering 0, 1 or x (unlimited) number of keywords which will be associated with that number. We have the following solutions:
    a) A Single textarea. The user is asked to enter one number per row, and can append (sperated with a space) a arbitrary number of keywords in each row.
    b) A couple of textboxes vertically aligned also with one number per box followed by space-seperated keywords. And further a button to add additional textboxes below if he nedds to enter more than the number of textboxes we gave him. (So this needs an extra submitting of the form).
    c) like above ( b) ) but having seprated boxes for numbers and for keywords (ie two textboxes per row)
    d) like above, but having a single textbox for each number and for each keyword, with yet an additional button to add 'columns' for more keywords per number
    e) ...(your idea here)



    Obviously going from a) to d) we have an increase of necessary keystrokes and switches between mouse and keyboard, which leads to needing more time to fill the forms out, but we also have more 'understable' form, which leads to less frustration with the user and less learning time. In both examples we have users that are using these forms (more or less) often.

    I do not want to leave the choice up the user. Usually there is a better way to do it. And I believe that a developer that decides this will take more facts into considerationm which will lead to a better choice, than letting the user choose a preference, who will listen to a gutfeeling and stick with choices even if they are worse, just to avoid change (which the user usually tries to avoid).

    So restating my qeustion: Is it 'better' to have a single input box (textarea) with a description on how "structured" the input has to be entered, OR is it better to design a form with a multitude of several little inputboxes, that are arranged and labeled to make it visually easier to understand what goes where?
    What would your choice be and more important why? I', looking forward to hearing your opinions.

    edit: ok, numbering the lists don't work as I expected. The second 1. should have been a 2.
    edit1: Yuck, what happened to formating with good old BBCode, don't work like it used to with nested lists. This WYSWIYG just won't let me do what I want. *grrrr*
    Last edited by R. U. Serious; Mar 27, 2003 at 02:43.

  2. #2
    blonde.... Sarah's Avatar
    Join Date
    Jul 2001
    Location
    Berkshire, UK
    Posts
    7,442
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    well my thoughts - not just on your two examples but on any form or any website is the 'the user doesn't read the instructions' its the same with emails supply them an email with details and they don't read it correctly and still ask you...

    So my advice would be supply the form as dummy proof as possible only allowing the user to select numbers/dates.

    this I also think saves time on the validation of the code too, for example one project we require the date to be viewed like '25 May 03' but it must be entered into the database as ddmmyyyy, so instead of supplying small text next to the input box I now provide three drop downs which are automatically created and they list day 01-31 and month - names of and years and all they need to do is select them. I can then insert them directly into dB without having to worry they are in wrong order etc etc and also you don't need to be too concerned about people entering in dodgy data.

    Sarah
    Regular user

  3. #3
    gingham dress, army boots... silver trophy redux's Avatar
    Join Date
    Apr 2002
    Location
    Salford / Manchester / UK
    Posts
    4,838
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i have to say that when it comes to things like dates (mostly date of birth), i'd definitely shy away from using dropdown lists where the user has to select the day, the month, and the year. it's better to give them 3 separate input boxes with the relevant number of characters allowed (i.e. 2-2-4) and do some quick checking when they submit the form, to allow for things like users only inputting 2 digits in the year field (which, with a simple if/else, you can then pad out to be either 19xx or 20xx depending on what type of date you're after).
    it may just be my personal thoughts, but if there's one thing i hate when i'm filling in a form, tabbing my way through the various form fields, is having to stop, grab the mouse, and use the the dropdown list (yes, dropdown can be used via keyboard as well, but then it doesn't "open up" to show all the options, and it ends up being a tedious "cursor down, cursors down, cursor down" pressing fest) when i could just as quickly type in my d.o.b. on the numeric keypad without even thinking about it.
    that's my 0.02 GBP, anyway...
    re·dux (adj.): brought back; returned. used postpositively
    [latin : re-, re- + dux, leader; see duke.]
    WaSP Accessibility Task Force Member
    splintered.co.uk | photographia.co.uk | redux.deviantart.com

  4. #4
    blonde.... Sarah's Avatar
    Join Date
    Jul 2001
    Location
    Berkshire, UK
    Posts
    7,442
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    although I can understand teh frustration of having to select from lots of drop down boxes BUT in your scenario you wouldn't be able to tell the difference between 02-03-2003 and 03-02-2003 and which they actually meant, I know that you can check for numbers up to 12 for month etc etc but then I find its an extra step to take my side...

    but it certainly is a valid point especially with keyword strokes for numbers..
    Regular user

  5. #5
    gingham dress, army boots... silver trophy redux's Avatar
    Join Date
    Apr 2002
    Location
    Salford / Manchester / UK
    Posts
    4,838
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ah...a fair point. damned multiple date formats...
    i'd say that, in the worst case, i don't mind selecting months from a dropdown list...but definitely don't create a 1-31 dropdown, and the same for years.
    as always, this is all my subjective preference...
    re·dux (adj.): brought back; returned. used postpositively
    [latin : re-, re- + dux, leader; see duke.]
    WaSP Accessibility Task Force Member
    splintered.co.uk | photographia.co.uk | redux.deviantart.com


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •