Subscribe to
Posts
Comments

Keyboard for barcodes

The prototype application will be for devices that run iOS 5. We are developing a proof of concept and can look at developing for a wider range of devices in the future.

The best case scenario means that users can scan barcodes with the camera on their iOS device. In reality, this will only be possible with the iPhone (3GS, 4 and 4S). The iPod Touch and iPad 2 have a fixed focus camera that isn’t suitable for scanning nearby objects. In fact, the Open Source ZBar bar code library we are using says that these devices aren’t supported. The original iPad and older iPod touches have no camera. Even for those devices with suitable cameras, the barcode may be faint or damaged .

We therefore need to allow for the manual entry of barcodes via a keyboard. In iOS you have a number of prebuilt keypad layouts, including default (standard keyboard), email (standard keyboard with an at sign and period) and numeric. The closest suitable pre-built keyboard was numeric (0 – 9, Delete). However, I also need to accommodate the characters ‘x’ and ‘-‘. We don’t actually need the dash (‘-‘) for searching ISBN numbers, but I thought it would be less confusing to allow the user to enter the character if it was on the back of a book.

I therefore created a custom keyboard. The image below was my first attempt:

First attempt at a barcode keyboard

However, it was pointed out that most numeric keyboards only have 3 buttons across. So, this led to my second attempt:

Second attempt at a barcode keyboard

This is more familiar and has larger buttons – especially useful for people with clumsy fingers like myself.

Any thoughts and suggestions welcome :).

Update

Based on some feedback I’ve increased the size of the X. I’ve also nudged up the size of the dash.

Third attempt at a barcode keyboard

The different shade of grey is an artefact of the way I took the screenshot, I think.

10 Responses to “Keyboard for barcodes”

  1. on 05 Mar 2012 at 13:50Ben O'Steen

    The second one is the clear winner, although you might want to make the ‘x’ a little larger (capitalise?) to be the same height as the numbers (eg the 1 or 9)

  2. on 05 Mar 2012 at 14:09Mark Power

    Hey Mike. All I can say is I agree with the decisions you’ve made here. The 3 buttons across is right as it ties to what people are naturally used to and I think bigger buttons are a better move anyway so it’s a nice bonus that you get that from forcing the 3 across approach.

    I think you’re also right to place the “x” button on the right too as then it’s not on top of the delete button which has its own “x”. Best to have distance between the two.

    I can’t help but think “times” and “minus” but that’s only because I’m viewing it out of context and my mind immediately says ‘numeric keyboard…x and dash…calculator’ 😉

  3. on 05 Mar 2012 at 15:32Mike Jones

    Thanks for the comments. I’ve updated the keyboard to increase the size of the X. I’ve also slightly nudged up the size go the dash.

  4. on 06 Mar 2012 at 15:19Julian Hill

    Thanks Mike. Your updated version with X the same size as the letters and larger dash looks fine to me and an improvement on the other versions.

    I do agree that it looks like a calculator, though the lack of an = sign will put a stop to that one…

  5. on 06 Mar 2012 at 15:25Mike Jones

    I’m hoping the context will make sense and people won’t think “calculator”. It will be on a screen with a text field and text that prompts them to enter the barcode number.

  6. on 06 Mar 2012 at 16:06Ben

    Hi Mike,

    Just to echo other comments – much prefer the second option (thank goodness you were forced into the design change by the form of the devices).

    It’s interesting the limitations on scanning the barcode, and the necessity of having a keyboard for manual input. It would be interesting to know the percentages of manual versus scanned, and those percentages across time (i.e., does input move more to scanned as capabilities develop).

  7. on 06 Mar 2012 at 16:15Mike Jones

    I think there are some closed source barcode scanning apps that work with the fixed focus cameras – they must do some image cleanup before processing. Who knows, maybe the iPad 3 has a better camera :-).

  8. on 06 Mar 2012 at 16:25Mark Power

    I was joking about the calculator thing 😉

    Of course it won’t be confusing when used in context 🙂

  9. on 07 Mar 2012 at 03:47Steve Bennett

    I’m late to this bikeshed, but I’m also wary of the X. There’s something about it that looks like an icon (delete, close) rather than a letter. Serifs? Actually I’m sure it will be fine. 🙂

    Incidentally, does a CueCat help you at all? (Save you googling: a $20 USB bar-code scanner that acts like a keyboard). I used one to scan my book collection into librarything. Much better than typing…

    Btw are you doing checksum verification?

  10. on 07 Mar 2012 at 10:28Mike Jones

    Hi Steve. The keyboard is just for cases when a camera isn’t available or suitable. We are looking at how useful smart phones are for capturing citations and iOS doesn’t provide a USB socket.

    Yes, we do checksum verification. It happens on the phone when scanning a barcode with the camera. It also happens server-side before we search with the number. We have a server side component that acts as a proxy to bibliographic databases.