vkeyboard suggestion (corrected for dodgy diagram alignment)

Support and General Use > User Interface and Voice

(1/3) > >>

seani:
I've been using the vkeyboard a fair bit for the wps announcement patch.

Although it can seem clumsy at first, I think it's an excellent effort at a non-trivial problem.

However it suffers from having a couple of mode switches in there, and voicing the current character under selection / edited content seems like it would be difficult to follow for visually impaired users.

So a suggestion - quite long, sorry, but it's mostly diagrams;

This represents a charcell version of a new kbd_input screen, based on the approx 18 x 9 charcells available on a C240. The shaded blocks were just for alignment, obviously:

Some points:

1) The edit string is always in the centre of the screen. The focus alway stays on the character currently being edited at the centre of the edited string, everything moves around that point.

2) Left and right scroll the whole input string left and right so that the character under consideration is always at the centre of the screen.

3) Up and down scroll up and down through the available strip of characters. There's no select to pick the character; the character is whatever it is when you press left or right to bring a different character into focus

4) Scrolling "past" either end adds an implicit character to either end. Off the end and one is added to the end, off the beginning and one is inserted at the beginning. If you move off that character without selecting anything, the insert is "undone"

5) A short select / play anywhere inserts a new blank character. Again, moving off that space without selecting anything will undo that insert action:

6) A separate key may be required to do a deletion - not certain what that is / should be, but deleting the character in focus moves the edited string and position in the selectable character list as you would expect.

Another option would be to have the "null" character right at the start of the list. So you fast scroll right to the start with the up key, the null character is in focus, and then press left or right, and the deletion effected.

7) A long select commits, and power (or whatever) cancels.

8 ) it would also be particularly well suited to entering time and date, pin numbers etc; maybe some sort of input mask characters would be handy to indicate separator such as "/" and ":" to skip when scrolling left and right.

9) Although the selection is from a one-dimensional list as opposed to a two dimensional array, I think this would be made up for by the speed at which you could scroll through alpha / numeric chars. Maybe slightly worse for punctuation as there's no "natural" order. Not certain. Scrollwheel users may be best off.

10) Custom keymaps become simple lists of characters; omit / repeat / group as you like.

11) I think voicing becomes more consistent:

a) Announce the whole string once when you enter the editor

b) Announce the character under the cursor. This is always part of the edited text, you never need to establish context or make a mental flip between the entered text and available keyboard as this method of entry is essentially modeless.

c) Voice the new string if you confirm, or "CANCELLED" if you don't

12) Offsetting the focus character gives an opportunity for short on-screen explanatory text (although of very limited use on smaller screened targets.

13) Issues with targets with smaller screens, or the fact that there's no "natural" sequence for punctuation etc. could be mitigated in one of two ways:

a) by having a section of the characters scrolling vertically, but "snaking" off to scroll horizontally at the extremes. That way you can fit in a decent preview of the characters available in either direction:

I think this would be quite effective when in motion.

b) And / or by reserving a special character that always occupies the "end" of the available character sequence. Hitting select when this character is in focus would not insert a new character, but would cycle through the available sets of characters - Upper, Lower, Numeric, punctuation etc. These could be soft delimited in the available character string map:

[Saint]:
seani,

Perhaps add some bitmap screenshots/mockups instead....this looks totally warped without a fixed width font (which I assume quite few people are using in their web browsers).

It took me some time to figure out that the alignment I'm seeing isn't intentional.

EDIT: You talk about adding another button instance for "delete"...the iPods don't *have* a spare button in the vkeyboard.

EDIT2: I'm really not 100% convinced this would speed anything up...I actually think it would be quite awkward only having 1 dimension to scroll through...have you seen how many chars are in the default (not using a .kbd file) vkeyboard? I certainly wouldn't like to have to scroll through them all in a 1 dimensional list....personally.

[St.]

[Saint]:

--- Quote from: seani on August 18, 2010, 12:36:59 PM ---Hmm, odd. I'm using the "tt" tag in the post there to indicate it's fixed width, and that's just how it renders here (Firefox / Ubuntu 10.04). It took long time to do, so that's a real irritation.

--- End quote ---

Just tried it in IE8 and it looks a *lot* better there ;)
Google Chrome however makes it look quite warped indeed.

[St.]

seani:

--- Quote from: [St.] on August 18, 2010, 12:32:27 PM ---seani,

Perhaps add some bitmap screenshots/mockups instead....this looks totally warped without a fixed width font (which I assume quite few people are using in their web browsers).

It took me some time to figure out that the alignment I'm seeing isn't intentional.

EDIT: You talk about adding another button instance for "delete"...the iPods don't *have* a spare button in the vkeyboard.

EDIT2: I'm really not 100% convinced this would speed anything up...I actually think it would be quite awkward only having 1 dimension to scroll through...have you seen how many chars are in the default (not using a .kbd file) vkeyboard? I certainly wouldn't like to have to scroll through them all in a 1 dimensional list....personally.

[St.]

--- End quote ---

There are two aims:

1) to make the method of entry generally easier for visually impaired users. At the moment, I think the way that the keyboard is voiced makes is confusing to understand. This is partly because you can either be voicing information from the edited line, or information from the keyboard as you choose a character, and making that distinction is difficult on the basis of announcements.

2) to make the general method easier and more consistent.

I don't think it would take long for it to work in that regard. 4 keys and select would replace the current 4 keys for navigating the keymap, 2 keys for moving left and right through the text and select to insert the chosen character. If anything it should free keys.

I think this would be a lot more intuitive in use; actually navigating to the chosen character for selection is only one part of the experience of editing text. If the *way* that you're meant to achieve something isn't intuitive, that all adds to the time you'll take to do it. The current method means flipping between different sets of controls in a fairly arbitrary (although well defined) way.

3) No way of knowing until I make it work somewhere, but I believe it will still turn out to be faster with a 1d list that scrolls with repeat and appropriate feedback against a 2d map that requires changes in direction. I understand your concern with the number of characters in there by default, but I think that can be mitigated against.

Thanks for the feedback!

Navigation

[0] Message Index

[#] Next page

Go to full version