4

My team and I are building a mobile app where the user will need to input a human-readable unique identifier (the serial number) of a single unit of inventory. Our system tracks the serial numbers that the user can access. We have considered three possible input modes:

1. We show the user the entire list of serial numbers they can access and allow him to select one from the list (like how a select element would work on an HTML page).

Pros:

  • The user doesn't have to type anything in.
  • The user can't enter an invalid serial number.

Cons:

  • The list is likely to be overwhelmingly large.
  • The serial numbers usually have the same format and are often sequential, so it might be hard to read the list.
  • Data usage for downloading the entire list of serial numbers

2. We allow the user to start entering the serial number in a text input and have an auto-suggest drop-down with a filtered list of serial numbers the user can access.

Pros:

  • The user doesn't have to type in a complete serial number.
  • The user is unlikely to enter an invalid serial number.
  • Smaller list to choose from than Option 1.

Cons:

  • The serial numbers usually have the same format and are often sequential, so it might be hard to read the list.
  • Auto-suggest may have limited value since the unit has a barcode that we could read.
  • Data usage for downloading a sizable list of serial numbers

3. We require the entire serial number to be entered, and once we recognize the correct number of characters, we validate the serial number against the user's accessible list and show feedback.

Pros:

  • The unit has a barcode that we could read, so this has the potential to be simpler than an auto-suggest or select-from-list paradigm.
  • Simpler implementation
  • Significantly reduced data usage vs. Option 1 and Option 2

Cons:

  • The unit has multiple barcodes, so it might take a couple of tries for the user to capture the correct one.
  • Typing manually would be tedious if the camera is unavailable or barcode scanner isn't working for whatever reason (lighting, etc.)

Which of these three is the best approach? Is there a better approach than what we have considered?

  • 1
    Does the list of serial numbers change frequently? Either way you could include the entire list in the app itself and update as needed to avoid over burdening your users with data usage. – DaveAlger May 1 '15 at 19:02
  • 2
    How long is a serial number? Is it alphabetical, numerical, or both? Does it have punctuation like periods, dashes, etc? Also, how often will this interface be used? Every 10 seconds? 10 minutes? 10 hours? – tohster May 1 '15 at 22:05
4

Let's face it, serial numbers weren't meant to be consumed by humans. Can you imagine going to the grocery store and waiting for someone to manually enter each and every bar code number for all your items?

In your situation I think option 3 is your best bet but I don't see why you couldn't combine option 3 with option 2. If the bar code scanner is failing for any reason the user can at least get auto-complete help while falling back to entering the string of digits manually.

Don't prevent the user from entering an invalid number but do provide instant feedback when the input string isn't valid.

1

We provide retail and stock control systems so accurate capture of barcodes and serial numbers at high speed is important to us. For what its worth, here's what we do, but our target market might be slightly different to yours.

Use a barcode scanner. There are bluetooth ones that interface easily to most mobile devices. Of course this costs the end user money so might not be an option.

Allow use of camera to capture barcode and/or OCR. Not that hard programming wise but is not actually that fast overall. Good for consumers but not a receiving dock. (Nb quality of cameras varies by device, so this does not work for all devices) Despite some drawbacks for high volume use, cameras do allow us to keep a photo as proof of entry forever, which is useful.

If keyboard entry is required, we present a text box input and display a series of tiles with valid options that can be pressed. The list of tiles changes dynamically on every keystroke. We find the tiles are better than a classic drop list as (a) bigger and easier to press (b) let us display a bit more info such as description (c) have more options to colour code the background as a signal too.

Personally I would not just display a list of barcodes, try and display something else to help the user. As DaveAlger says in his answer barcodes and serial numbers aren't designed for humans. Display a product description, date it was first seen, anything.

For barcodes, the most useful parts are generally the first and last few characters. We allow users to enter any characters they can see in the barcode, skipping whatever they wish. They just cannot jumble the order. If you are using sql, and my input is "9412" then the query is something like

 Select ... From barcodes where barcode like '%9%4%1%2%'

Rather than the typically used

 Select ... From barcodes where barcode like '9412%'

Once users learn this, and it isn't obvious I admit, they really appreciate it. Try reading 94100000000192 and entering it correctly. This technique means I can just enter 941192 and picklist will show it.

(Actually, we use both the above sql queries with the second sql doing the first half the results and the other doing all remaining gaps. This is to ensure the order looks right to users, but the second sql quickly resolves to no records as users enter more characters.)

We put a lot of effort into making the pick list tiles as relevant as possible, eg if you just used supplier #1, then barcodes from supplier number #1 have higher priority. Not sure this will be possible for you, but sometimes it is. Imagine you are entering serial numbers of watches. After the user has entered "9412", you may know that the only brands possible (with 9412) are Seiko and Swatch, so two buttons appear on the pick list to select these as an additional filter if the user wishes. Lots of work to make this seemless, but for us 1/4 second and less friction from user entry is worth the effort.

  • Thank you. That part where you allow users to enter any characters as long as they are in order is very useful. I hadn't thought about that before. – Mayo May 3 '15 at 12:18
0

Well, if you can do this using barcode OR manual input, and you say serial numbers are sequential, so both teh barcode AND teh serial numbers will have common characters, you can do something like this:

1- Offer the user to scan the barcode (include some hint message)
   1.1 - If user scans barcode
      1.1.1 - on success --> stop
      1.1.2 - on failure --> goto 2
2- Offer the user to manually input the value. Here you can ask to enter barcode or SN number. Strip all common elements and ask your user to input the values that are not common. 
    2.1- If sequentially generated series: ask to enter the last 3, 4, 5 numbers (based on the pattern structure of your serial number)
    2.2- If barcode number, you'll have quite some common numbers. For example, on UPC based barcodes, you'll probably need to ask for the last 4 numbers
3- Validate and provide instant feedback
    3.1 - If correct, stop process and display success message
    --else
    3.2 - Ask user to correct input, go to 3

Sorry about the very basic explanation, but hope it's enough to understand the idea

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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