Layout for on-screen hexadecimal keyboard

Question

I am to design a web-based, on-screen keyboard for a touch interface. Users will only need to input 0-9 and the letters A-F. In addition to this, they need a backspace, and possibly a "clear" button. So, I have begun toying around by modifying this keyboard by Vasili.

My first proposal was this:

Which has an unnecessary dash and a space bar that is there more for tradition and coherence than anything else. So I decided it was not good enough. In removing the dash and the space bar, I would be left with 16 buttons, plus backspace. Now, 16 is pretty neat for ordering things, but 17 isn't. So, in adding a "clear" button, I thought of arranging the hex characters in a 4x4 pattern, and then having bigger "removal" buttons underneath:

But this still doesn't feel right! In particular, because mixing letters and numbers seems confusing. So then I thought: What if I put numbers on 2 rows of 5, and then add removal buttons onto one letter row of 3 each? And this is probably the one I'm the most satisfied with:

But I should probably flip the order, right? Starting the top row with 1, 2, etc. and the third row with A, B, etc.

Anyone else have a better idea?

Answer 1

Why don't simply improve the standard numerical keyboard by adding the missing characters ?

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 2

You say the keyboard is for hexadecimal input. And that's the reason why your second try doesn't feel right! As @steveverrill also noticed in the comments, the numeric order ABCDEF1234567890 is wrong. So if you want to go with a 4x4 layout, you should choose one of these:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 3

So, as I was writing a couple of pretty long comments on the other answer, I felt inclined to present it as an answer as well. Following are a couple of considerations not made by the other major designs and mockups implementing these considerations:

Mobile virtual keyboards shapes

Notice the shape keyboards take on mobile devices on the mockups drawn below:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Any designs have to work in the restrictions of virtual keyboards. Now in this specific case the top whitespace may be a bit smaller, but still, the basic limitation still applies which rules out extremely tall designs for example.

Rotation lock

Getting to the second point, mobile web apps can not limit the orientation. One could possibly do the following (as showing different content based on rotation is easy)

^{download bmml source}

But I hardly believe anybody here would consider that proper UX design. In other words, we actually need two keyboard layouts: a portrait one and a landscape one.

Normal users vs Programmers/Mathematicians

So, programmers will know about what hexadecimal codes are, normal users on the other hand will not. This is absolutely crucial, because it means the 'numbers' A to F should not be treated as numbers, but rather as letters. And letters are traditionally ordered alphabetically. Any design treating A-F as a continuation after 9 will only look good in the eyes of people aware of it's mathematical meaning, and from the question I understand that the users in this case are normal users entering a code that just happens to be hexadecimal.

Portrait mockup

So, implementing those ideas gives something along the lines of (please note, this is just a possible implementation, some of the other implementations are just as valid, the main point of this post is the theory):

^{download bmml source}

I made two designs as I was torn between putting the letters and [ok] button to the left or right. The phone is held primarily in the right hand, so entering with one hand the numbers will be used more often than the [ok] button, but [submit] and [enter] like buttons tend to be to the right on desktop systems. Now I do believe that breaking this on mobile is within reason, but I am not sure it's worth the second look it will take.

Landscape mockup

As with the above design the backspace and ok button could be mirrored to the other side, but at least it gets the concept across:

^{download bmml source}

Additionally I was torn between whether to start or end with the zero. Once again on traditional keyboards the zero comes at the end similar to the mockups, but when presented without the rest of the keyboard a strong argument could be made to count from 0 to 9.

Answer 4

Based on Renaud's idea of extending the standard numeric keypad, but wide instead of tall. Also illustrating that it's OK (even beneficial) to leave space between groups of keys.

+--------------------------------------------------+
|                                                  |
+--------------------------------------------------+

+-------+-------+-------+  +-------+-------+-------+
|   7   |   8   |   9   |  |   A   |   B   |   C   |
+-------+-------+-------+  +-------+-------+-------+
|   4   |   5   |   6   |  |   D   |   E   |   F   |
+-------+-------+-------+  +-------+-------+-------+
|   1   |   2   |   3   |                        
+-------+-------+-------+  +-------+-------+-------+
        |       0       |  | DEL.  | CLEAR | ENTER |
        +-------+-------+  +-------+-------+-------+

Answer 5

Personally I like how the Windows Calculator does it:

I understand this does have extra keys that you do not need, but I do like having the letters in alphabetical order to the left of the keys. This also does not change the expected behavior for a keypad.

Answer 6

I noticed myself having to actualy search where were the numbers on your last two design.

I would definitely choose a design where the numbers are ordered and not mixed with letters.

Here is my attempt:

Here is another one, inspired by the default Windows calculator.

+-----------------------------------------------+
|                                               |
+-------+-------+-------+-------+-------+-------+
|   A   |   D   |   6   |   7   |   8   |   9   |
+-------+-------+-------+-------+-------+-------+
|   B   |   E   |   2   |   3   |   4   |   5   |
+-------+-------+-------+-------+-------+-------+
|   C   |   F   |   0   |   1   | DEL.  | CLEAR |
+-------+-------+-------+-------+-------+-------+

I recommend distinguishing visually the letters from the numbers with this design (different background or font color), like the Windows one. But still, I find the first one more readable.

Edit: Added a picture made with balsamiq re-using @Renaud file

Answer 7

For what kind of screen is the interface? You say touch, but that can mean a multitude of things. For example, on a smartphone, a square-ish keyboard may be acceptable, but on a tablet you want the width of the keyboard more than the height.

For a wide keyboard, I like steveverrill's idea (not enough points to upvote...), but I would tweak it a little bit like this:

+-------+-------+-------+  +-------+-------+
|   7   |   8   |   9   |  |   A   |   B   |
+-------+-------+-------+  +-------+-------+
|   4   |   5   |   6   |  |   C   |   D   |
+-------+-------+-------+  +-------+-------+
|   1   |   2   |   3   |  |   E   |   F   |                      
+-------+-------+-------+  +-------+-------+
| DEL.  |   0   |CLEAR  |  | Possibly Enter|
+-------+-------+-------+  +-------+-------+

Answer 8

_{Warning: Unsubstantiated non-expert opinion ahead.}

You say hexadecimal keyboard in your question, but your users are not actually doing calculations with these numbers, or even really thinking of them as numbers at all: they’re booking references, merely alphanumeric codes. They just happen to be alphanumeric codes which use only the first six letters of the alphabet.

The idea of expanding a numeric keypad to include the hexadecimal digits, as suggested by Renaud, would probably be excellent for people actually working with hexadecimal calculations, but for people merely typing in letters and numbers, I would keep the letters and the digits distinct. The wide layout suggested by steveverrill seems the best for your use case: the numbers are in the standard layout of a numeric keypad, with which everyone is familiar, and the letters are separate and easy to find (there are only six of them, after all).

If you need a tall one, perhaps put the letters above the numbers, in a layout like Renaud’s, but separate the two with a gap, and perhaps a change of colour.

Answer 9

I have two points to note about your layouts:

I. People are used to the existing decimal numpad layout for numbers, and I would not miss the opportunity to give the users the satisfaction of feeling familiar with this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

II. Trying to force the extra characters in is not necessarily the best solution. I would try to group them in a way that makes them quick to use on their own.

Keeping with the "standard" of the numpad, two rows of three seems like the obvious choice for me. Also for some reason I want them to the right of the numpad, sort of giving them equal importance with the familiar numpad taking a little presidence.

The result is then:

^{download bmml source}

Answer 10

A few constraints arise that direct our design:

• We want the number keys to be in the same order as we're all used to them being in.
• The keys should be located as close to each other as possible so that fingers travel the shortest distance when using the keypad.
• The 'clear' and 'backspace' keys should be located away from each other so that the user traverses a different qualitative direction to access that particular functionality.
• The 'clear' and 'backspace' keys should be located at outermost points (corners) to minimize accidental pressings.

With these constraints I've mocked-up a design comp that should fulfill your needs.

I also think that a valid design could be moving the 'Clear' button to the top left so the top row reads "Clear, A, B, C". Depends on which you like.

Answer 11

Would it be possible to make the keys look like this... 1, 2, 3, 4, 5, 6, 7, 8, 9, A/10, B/11, C/12, D/13, E/14, F/15, 0/16 I use hexadecimal dice, and this would be helpful in my app.