Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I come from stackoverflow and have no answers for this one, so I turn to the UI guys for assistance.

Let's say I have a library application that allows a user (librarian) to add a book to the database. One of the features is tagging an author to a certain book. A book can have more than one author, so a UI that allows multiple tags is required. I really want it to follow the progressive enhancement approach, from a basic functional site to a JS/CSS enhanced version.

I already have a database of at least 450 authors. For the enhanced version an auto-complete and editable select is in my arsenal and has proven effective. The problem is with the basic version, especially for mobile devices and incapable browsers (like opera mini perhaps?).

From a programmer's view, a multiple-select <select> box should do. But by reading at least 3 UX books, a multiple-select <select> is a "no go" since there is no indication (unless explicitly mentioned) that a select is multiple-enabled. Also not good for the physically-challenged people since you have to hold down Command (Mac) or Ctrl (PC) to multiple select. Mobile browsers have none of those keys also! To add to that, 450+ selections in one box?

In summary:

  • 450+ items to choose from
  • selecting multiple items
  • progressive enhancement approach
  • this is for the basic view (No Javascript, limited CSS)
  • mainly targeted to non-modern and limited feature browsing devices (like opera mini and mobile browsers that have no JavaScript capability)

What's the best way to tackle this situation? How did they even do this prior to web 2.0?

share|improve this question
1  
The "No JS" requirement limits your options for making things usable/responsive in a web app severely, can you elaborate on that pre-req? –  Jeroen Jan 16 '12 at 11:31
1  
I wouldn't assume mobile browsers can't do javascript or CSS. Opera Mini butchers Javascript but Safari, Android's browser, Firefox mobile and Dolphin all run JS pretty well best I can tell. Don't limit those users because someone might be browsing on his 5 year old palm pilot. –  Ben Brocka Jan 16 '12 at 14:16
1  
@zzzzBov that would be the "graceful degradation" approach - which, as the book "designing with progressive enhancement" states is like saying to the user "just upgrade". but what if they can't? what if they prefer old hardware/software coz they can't afford to buy new tech? what if i also wanted a "mobile-enabled administration from anywhere" some time in the future? that's why i turned to the web as my platform (and left Java and Flash+AIR) where it's decentralized, where all control and adaptivity is passed on the developer and the service provider. –  Joseph the Dreamer Jan 16 '12 at 17:31
1  
@fskreuz: Your customers are libraries. Their only constraint on upgrades is budget, not preference for old hardware. –  dnbrv Jan 16 '12 at 17:51
1  
from the same book i read, they are different also. progressive enhancement builds a functional foundation and enhances it while having that functional fall-back in case things won't work. graceful degradation on the other hand is creating a modern functionality and adapts it backwards with a possibility that they won't work on all devices in that direction. and like i said "Let's say I have a library application that allows a user (librarian) to add a book to the database" - the library is just an example of the type of field where i will hopefully deploy. but i get your point –  Joseph the Dreamer Jan 16 '12 at 19:15
show 4 more comments

7 Answers 7

up vote 15 down vote accepted

A dropdown with 450+ values is extremely unusable on any device, including desktop. But you say that you're only looking for a solution for the basic mobile version, so let's stick to that.

Probably the best way to simplify this for the mobile is to have a first screen/popup display the alphabet, then as you tap a letter you drill down to the list of authors beginning with that letter. Your largest list per letter, even for the most common letters, should be at about 30-40 values, which can be scrolled easily. Then you tap a name to select it, press Back to return to the alphabet and proceed to select additional authors until you press Done. That's the most standard approach for mobile, based on simple linear navigation.

A better way would be to develop something resembling a phone book app, but I guess you can't do that on a web app without JS.

share|improve this answer
2  
This works only if they build a separate version of the app for both low-end mobiles & desktops. The changes in the navigation structure are too drastic. –  dnbrv Jan 16 '12 at 12:56
2  
This is only for mobiles, and that's the solution that can work without JS, as requested by the OP. –  Vitaly Mijiritsky Jan 16 '12 at 13:16
    
this one i see in mobile web email and mobile facebook. –  Joseph the Dreamer Jan 16 '12 at 17:36
add comment

Unless you have auto complete, a list with 450+ options is never very user friendly, and always hard to use, especially when you even allow multiple selections.

Given that the task to add books to the library is a very common one, that should be done fast, I would propose a more simpler backend-powered solution using two simple steps:

  1. First the user is presented with a simple input field where he simply enters author names. For multiple authors they are simply comma-separated.
  2. On submit, the backend splits those entries and tries to find existing database entries for them. If you find a unique match, choose that author. If you find multiple possibilities, retain them all.
  3. Present the user your results for him to check. In case of multiple possibilites, make him choose the correct match using a simple select box. When no match was found, allow him to create the author in that step (and maybe ask for more detailed information as well). Do that for each comma-separated value you have found.
  4. On the final submit, you should have all your information.
share|improve this answer
    
i'm actually doing this for the mean time. but i have never thought of steps 3 and 4. –  Joseph the Dreamer Jan 16 '12 at 17:16
add comment

Why not try something like what you get in the iOS Mail app.

enter image description here

  1. A simple text input field
  2. Drop down auto suggest (just like in Google Search)
  3. When you have added a single item (like author in your case), you can type another one, by pushing the + button at the end of the input field (and previously entered items can be deleted ony by one.)

This solution could easily be used on a smart phone and desktop as well. I think that for 100+ elements some kind of "search" solution has to be used.

share|improve this answer
6  
This is exactly what the OP is doing on high-end devices. However, he is asking for a low-end solution. –  dnbrv Jan 16 '12 at 12:57
    
i know that some devices have a mandatory "auto-complete" feature because they can do it. but don't take back the answer. it might be useful soon. –  Joseph the Dreamer Jan 16 '12 at 17:19
add comment

It's great that you're doing progressive enhancement! However, you're creating a creating a problem for yourself where there's none.

The UX approach is to think about the user and the environment where the product is being used. So let's look at your concerns:

  • List box requires to hold down CTRL or Command to select multiple items, which isn't too accessible for disabled users.

    1. How many of your users (librarians) have severe motor disability that prevents them from holding down the required keys with one hand and moving the mouse with the other hand? - Not that many.
    2. Is there any assistive technology that allows people with motor disabilities use keyboards efficiently? - Yes (on-screen keyboards & special physical keyboards).
  • Multiple selection in list box has low affordance because users don't know about holding down CTRL or Command.

    1. Can you improve the affordance of multiple selection? - Yes, you can include explicit instructions about it.
  • Mobile devices don't have CTRL or Command keys or may have JavaScript-unfriendly browsers.

    1. How often will the system be used from a mobile device? - Maybe occasionally.
    2. What devices don't have CTRL or Command keys? - Nearly all of them.
    3. What devices use primarily Opera Mini and other JavaScript-unfriendly browsers? - Older devices.
    4. What other characteristics do those older devices have? - They have less powerful CPUs, smaller screens, and slower Internet connections.
    5. How usable will a 450+ item list be on such devices? - Highly unusable because it would render & scroll slowly.
    6. What kind of device is likely to be used to enter book information away from the desk? - A tablet or similar because of the amount of text entry necessary.
    7. Do those devices support modern JavaScript? - Absolutely.

Consolidating all of the above, you shouldn't worry about list boxes for mobile devices or disabled users. In fact, you should make the simplest mobile version read-only and remove editing & creation capabilities from it so that users don't even try it. At the same time, a list box will be completely usable to anyone in the simplest version for desktop browsers as long as you instruct users on how to select multiple items.

share|improve this answer
    
+1 for make it read only and creating a problem where there isn't one. –  s_hewitt Jan 16 '12 at 17:45
    
Really thorough analysis. Great answer. If you could make the degraded experience great without JavaScript, why build the enhanced version? –  Christopher James Calo Jan 20 '12 at 16:18
    
@ChristopherJamesCalo: Thanks. The thing with progressive enhancement is that some interactions can't go below a certain level. It's impossible to make large lists of data usable without JS and CSS tricks, so when those aren't available the feature has to be dropped. –  dnbrv Jan 20 '12 at 16:39
    
Agreed, @dnbrv. Sorry if it sounded like I was asking you a clarifying question. My question was rhetorical and meant to support your answer. –  Christopher James Calo Jan 21 '12 at 20:42
add comment

I would start the web page wih a single drop down box which would include all authors. Then, under that, have a check box that says 'add another author'. This would do what is expected, probably through javascript, and the user would be able to continue adding authors.

share|improve this answer
    
Hi austen, welcome to UX! Could you explain how you arrived at this conclusion? Perhaps by referencing a project you did, or a book you read? Thanks! –  Rahul Jan 16 '12 at 20:03
add comment

I recently had to do multiple selection and a multi select box didn't allow for columns to display more data and the users do not know how to use a mulit select box in any case.

So I created a div with scroll bars, and in your case you could create multiple divs to suit your style (e.g. a div per letter of alphabet for authors).

Here is how mine came out to give you an idea:

enter image description here

Obviously you will have to play with the spacing and size to match your preferred device.

Please note that this is only a suggestion.

share|improve this answer
2  
Can't stand scrollbars in webpages... usually ends up feeling like I have to browse a webpage through a key-hole. I'd say, either just show the whole thing, or do it in a separate step. –  Svish Jan 16 '12 at 12:12
1  
And most of the time they don’t work on touch devices… –  poke Jan 16 '12 at 12:28
    
Svish: I haven't worked with a touch device before, but I can see where you are coming from. poke: How can a web compliant device not handle standard/basic html and css2? IE7 handles it (can't test on lower settings) –  Nightwolf Jan 16 '12 at 13:49
    
interesting approach compared to the "sea of checkboxes" answer. as far as i know, this won't be that "nice" on small screen devices. quite bulky. but it work work well on a PC. i'll take note of this. –  Joseph the Dreamer Jan 16 '12 at 17:11
add comment

Even without the use of javascript you could try using some kind of autocomplete on the server side.

The user inputs the name (or part of it) manually and hits search.
That information is processed by the server and gives back a simple html list (with checkboxes) of possible answers.

On the bottom there would be 2 buttons: add and add & complete

This allows the user to add the name(s) from the current list and then go back to add more, or add the name(s) from this list and complete adding authors.

I'm not a UI expert so I don't know how intuitive it would be to use, but the technical side of it should be fine!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.