Is there a better way to input one of many similar values?

8 Dec 2011 - 4:14pm
2 years ago
11 replies
555 reads
DrWex
2006

text string. The values for these strings are quite similar; ABCDEF1, ABCDEF2, etc. Our present solution is an autocomplete widget that gives suggestions as the user types. If you type A it may suggest AB, AC, AD, AD1, and so on. Each letter typed narrows the selection.

This works very well for both sparse and normal distributions of input strings. However, for our data it's not helping that much since all the variation in the strings is at the end, meaning users have to type the majority of the string anyway and then get presented with a still-long list of undifferentiated options. In fact, some parts of the app might have values ABCDEF1 - ABCDEF50 which means the auto-complete suggestion pattern isn't giving much value.

The problem is that I don't know of a better mechanism. Selection of any sort seems out of the question. I've thought about adding shortcut keys but I can't figure out how to make them discoverable.

Anyone have any thoughts?

Comments

9 Dec 2011 - 8:25am
Jochen Wolters
2010

Have you tested a combination of popup menu and free-form text field right next to each other?

The user would then pick the first, similar-across-many-items half from the menu and freely enter the second half in the text field, that might still provide auto-completion, if that's useful for the kind of data you gather.

Greetings,

J.

9 Dec 2011 - 11:15am
Paul Pinkney
2009

How about grouping by prefix to make it scannable and findable?  Using your example, you could have a list like:

ABCDEF

                1

                2

                3

               ...

              50

FEDCBA

                1

                 2

                ...

9 Dec 2011 - 11:56am
Brian Mila
2009

Thats an interesting problem.  How many items in total do you have?  100s?  1000s?  10000s?   And how many of those items have similar prefixes?  In other words, if I grouped all of your items together by prefix, how many groups would I have?  Are the prefixes all the same length, or do they vary?   Does the total length of the string vary?   What is the experience level of the users?  Are they intimately familiar with the list of items?  Are they only familar with some of the items (perhaps frequently use a subset of the items, and infrequently or never use the rest).  Sorry for all the questions, but its important to understand your data and your context better before offering a possible solution. 

Brian

9 Dec 2011 - 2:05pm
DrWex
2006

On Fri, Dec 9, 2011 at 1:22 PM, Brian Mila wrote: > Thats an interesting problem.  How many items in total do you have?  100s?

Hundreds. Currently the system supports 300+ prefixes and we expect a factor of 2-3x growth in the next couple years. I'm designing for a factor of 10x to give myself a safety margin

> And how many of those items have similar prefixes?

It's highly variable. Some items are unique to a prefix. At the extreme other end there are a couple of prefixes with ~100 suffixes. The mean is about 5.

> Are the prefixes all the same length, or do they vary?   Does the total length of the string vary?

Variable in both respects. Our shortest string is 4 (ABC1) and our longest is 20.

>  What is the experience level of the users?  Are they intimately familiar with the list of items?

Also variable. Most users are familiar with most of the prefixes. On a simple scale I would say that the majority of our users are infrequent users. Only the upper quartile could be considered 'expert'.

> Are they only familar with some of the items (perhaps frequently use a > subset of the items, and infrequently or never use the rest).

Yes, that's a very accurate description of the situation. The frequency of use of the prefixes is related to the activity of the customer that is represented and customers have highly variable levels of activity.

9 Dec 2011 - 4:03pm
Brian Mila
2009

Gotcha.   This sounds very familiar to me, in the healthcare industry that I'm currently working in ICD and CPT codes are similarly structured.  ICD-10 has about 70000 codes, to give you some scale.  You could take a look at some of those to see if you can find any parallels. One thing to note there is that each code also has a text description associated with it. That can be useful for searching if a user doesn't know the exact code number.   In fact, alot of our code dropdowns have two columns in the dropdown part, one for the code and one for the description.  When the dropdown is collapsed its just the single code of course.  Seeing the description helps ensure they selected the correct code.

 Another option for you could be to segregate the values into ones the user's use most frequently (basically maintain a most-frequently used list,  and tie that into your autocomplete so that most frequently used items are returned first).  That should allow you to highlight the correct prefix with just one or two keystrokes so that a user can hit tab to autocomplete the prefix, and then can enter the suffix.   Obviously this option would require you to build in some way to store user-specific data either through cookies or store in a db or some other way to maintain that most frequently used list, but if you can get that done it might be a good option for you.

9 Dec 2011 - 5:05pm
DrWex
2006

Thank you again Brian. I won't quote the reply here but I do want to pick up on a point you made which was what I referred to as "hotkeying" to help with prefix completion.

We might, for example, allow a user to type AB1 rather than ABCDEF1. The action of is to expand the user-typed prefix into the full code value in the input box. I have two concerns with this:

  1. Discoverability. How would a user know that is a legal input here? I suppose we can just tell them, but I worry that it won't stick unless it's obvious in context, somehow.

  2. Overlap of functionality. generally moves users from one form field to another; making it mean something different while in an input operation might cause confusion. An unused key such as might be better but I worry that's even less discoverable than .

Do you have any examples of forms that allow input of ICD and CPT codes?

12 Dec 2011 - 1:25pm
Brian Mila
2009

I'm sorry but I can't give you any examples from our apps (proprietary) :(   As to your concerns though:

Discoverability:  This really depends on your user.  If these are numbers that they use over and over again and task completion time is a high priority for them, then they won't need discoverability.  Just train them on the shortcuts and if they find that it helps them accomplish tasks quicker they will probably use them.   I think your biggest trick will be to pick shortcuts that are applicable.  If you can come up with a mnemonic that is widely applicable, you'll probably have better results.  For example, if the mnemonic is the first 3 letters of the prefix + the suffix, that would be easy.  But if what I understand about your data is correct, that might not be an option for you, because you'd have a bunch of ambiguous entries like ABCD1 and ABCDEF1.   However, you might be able to use that to drive your autocomplete.  In that case, your autocomplete list would be much smaller and manageable. 

Overlap:  I would definitely try to be consistent if possible with whatever you use.  We have some consistency issues in some areas.  As workarounds I have seen users maintain a separate spreadsheet of code numbers that they can copy/paste into the app (they basically maintain their own short list of recently used numbers).  Which brings to mind another question, where are the users getting these numbers from in the first place?  Are these numbers on paper forms that they are entering, or do they come in from some electronic source that they could maybe copy/paste into the input field?

10 Dec 2011 - 8:08am
penguinstorm
2005

Break the numbers up visually and for input into smaller chunks. It doesn't matter how you store them on the back end, when they're entered and displayed people are going to have a much easier time entering them and reading them if they can be broken up.

Phone numbers are a good example. Where this:

6057828989

6057828589

6057828489

6057828789

makes it hard to spot the differences, but the visual display makes it easier

(605) 782-8989

(605) 782-8589

(605) 782-8489

(605) 782-8789

Credit card numbers are a good example as well. A single 16 digit code is show as a patter of 4 blocks of 4 digits.

Thia makes it easier to proces, and reduces data input errors. Your auto-fill option doesn't necessarily help, as the list of auto-filled examples is likely to be visually confusing as well.

11 Dec 2011 - 5:33pm
David More
2010

Is it really necessary to input the codes at all? If they're meaningful, can't you present what they mean in more human-friendly terms?

12 Dec 2011 - 8:05am
DrWex
2006

The codes are account numbers and are shorthand for much longer strings. There are some cases where we can know the intended value ahead of time and pre-fill it, but that's rarely true, and almost never true in the cases where the customer is operating across a large number of accounts.

On Mon, Dec 12, 2011 at 2:24 AM, David More wrote: > Is it really necessary to input the codes at all? If they're meaningful, > can't you present what they mean in more human-friendly terms?

12 Dec 2011 - 3:05pm
abhijith.rao@gm...
2008

DrWex,

The question is can your programmers rewrite the component so that it can search any where in the string? Not just at the start of the code.

Going with your example, if you have 'ABCDEF01' to 'ABCDEF50' then the user seems to know what they are searching for. Else using codes would be wasted.

Give the user an option to input '25' instead of 'ABCDEF25' to bring up the values that match it and then use the arrow keys to select the value. This would narrow down the options greatly, if I understand your concern.

What do you think? Work with dev on this.

Cheers,

------Original Message------ From: DrWex Sender: ixdaor@host.ixda.org To: Abhijith B Rao - Personal ReplyTo: discuss@ixda.org Subject: [IxDA] Is there a better way to input one of many similar values? Sent: Dec 9, 2011 4:24 AM

text string. The values for these strings are quite similar; ABCDEF1, ABCDEF2, etc. Our present solution is an autocomplete widget that gives suggestions as the user types. If you type A it may suggest AB, AC, AD, AD1, and so on. Each letter typed narrows the selection.

This works very well for both sparse and normal distributions of input strings. However, for our data it's not helping that much since all the variation in the strings is at the end, meaning users have to type the majority of the string anyway and then get presented with a still-long list of undifferentiated options. In fact, some parts of the app might have values ABCDEF1 - ABCDEF50 which means the auto-complete suggestion pattern isn't giving much value.

The problem is that I don't know of a better mechanism. Selection of any sort seems out of the question. I've thought about adding shortcut keys but I can't figure out how to make them discoverable.

Anyone have any thoughts?

Syndicate content Get the feed