usability: On-screen keyboard

[pabouk]

cyrillic: 66 (three screens/sets of 22 characters each)

Wrong. The language-specific characters are: АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ (and you may even discard Ё, as it is optional). That sums up to 33 (32 without Ё) characters...

Yes but that is just for Russian What about other languages using cyrillic like Belarusian, Serbian, Macedonian, Ukrainian, Bulgarian and many non-slavic languages from ex-soviet union countries? Are they inferior?

I'm of the opinion that the current vkeyboard doesn't have any serious disadvantages other than the characters being too small for some people on the larger screen or higher resolution targets. I think maybe reconsidering the font choice of those and maybe having a larger font and just showing the subset that the H1x0s show is a better solution.

I agree that the keyboard should be simple and I am not supporter of merely fancy-and-non-functional features like boxes aroung characters but I think that on-screen keyboard with space for more than one line of edited text would be very useful.

I do not agree that text editor is not important for Rockbox. It would be very useful for editing configuration files, writing notes about music I am listening on radio or podcast etc. Editing ID3 tags with more than one line visible would be really cool too.

[salival]

Some people have stated they didn't like the borders around the characters. Since I could understand why I created a cleaner mockup.


(click for original)

I firmly believe that the bigger screens need some sort of container for the keyboard, so it may be implemented more easily into plugins. Plus it gives the oppertunity to group buttons, in this case numeric and function keys (shift etc.)

[salival]

When you have a button to toggle between navigating in the keyboard and moving around on the "paper" the on screen arrow keys can be removed, which frees up space for character heavy languages.

I think a selection-button hold would work best for this. (navi-hold/ joystickpress-hold/...)

[salival]

...and it would look something like this for non latin char sets.

(click for original)

note: in this mockup I excluded the arrows. In my current opinion a button-hold to toggle between screen and keyboard seems the best solution.

[salival]

I have started a design document: link

I need help in defining the character sets and rules for non-latin character sets.

Since I posted it in the rockbox wiki, feel free to edit the document. Although this document is intended as a functional design, if someone has suggestions on the technical implementation of this all don't hesitate to add them.

One friendly request though: Until we have come to a design which contain very little flaws, I would like you to put suggested changes in a note (ie. "Note: more columns") or at least tell which section you edited. (I know there's revisioning, this is IMO a little clearer and faster )

When the design is as complete as possible I plan to add it as a feature request.

[moozooh]

Yes but that is just for Russian What about other languages using cyrillic like Belarusian, Serbian, Macedonian, Ukrainian, Bulgarian and many non-slavic languages from ex-soviet union countries? Are they inferior?

No, they aren't. Still, look at your desktop keyboard and think, why would you need all the characters of a given codepage appear simultaneously on it, wasting precious space? I told you about Russian, and I assure you that the russian keyboard layout needs only 33 language-specific characters at max. If I want something else (eg. Macedonian), I'll switch to it, as I can (and must) do on my desktop. Got my point?

[salival]

At the moment I think we have two options for this issue:
1. create menu options on the keyboard to switch between the different cyrillic character groups (i.e. russian, macedonian, etc.)
-pro's: only one cyrillian keyboard layout needed.
-con's: you probably end up having more than 4 menu options, which means you need to scroll the menu (which should be supported)

2. create multiple cyrillic layouts. Which one is shown depends on the language the person has chosen for rockbox.
-pro's: only the character set the person typically would need is shown.
-con's: more layouts to define/design

edit: I forgot the option of one single layout which shows all characters.
-pro's: only one layout
-con's: a lot of characters on screen which the user might not use.

[moozooh]

-con's: more layouts to define/design

Actually, it's easier to design a layout that has fewer characters than otherwise. Moreover, the keyboard layout map is already defined (…many years ago, yeah) and is widely available.
I'd personally go with this option, as it is more reliable to the end user. Other than that, the only option I'd use is the whole UTF-8 range of practically usable symbols combined on the same screen (it would require very small font though, about 6 to 8 px in height)

[salival]

I read my reply again and noticed that the options 1 and 2 are basically the same. the only difference would be how the are accessed (automatic or menu selection.)

As you might have seen, the layout for the onscreen keyboard differs from a standard keyboard. Therefore a standard layout most likely has to be altered in some way. IMHO an alphabetic order is the best option.

[phaedrus961]

I created a patch which allows customizable keyboard layouts. It's not quite what you've been discussing, but maybe some of you will find it useful? Let me know what you think of this approach.

http://www.rockbox.org/tracker/task/4856

[salival]

I haven't tested the patch, but:
The description says it creates new pages when needed. Can the user decide what's on every page, or does the code decides whether to use a new page or not?
If it doesn't, I think using a (multidimensional?) array (layout=[a,b,..,y,z][A,B,..,Y,Z]) would do the trick.

This can bring the "final solution" closer, since most of the code needed for the keyboard as described in the design document is already there.

What that solution IMO needs is: (hardcoded or not)
- definable layouts
- definable menu options
- multipage suport, where the pages are chosen by a menu.
- the option to allow a page to return to the default or previous page when a key is pressed. an example would be "shift", where the layout should return to lowercase when a character is entered.

I am not much of a programmer, but I think the following could work:
One array for the menu options where every position corresponds with a page. So, position [ 0 ], which for instance has the value "sym" (for symbols), corresponds to page 0 in the pagelayout array, which contains the set for the symbols page.

example (pseudo code):
array menu=[default]["shift"]["Caps"]["acc"]["sym"]; (the first position of the array is not shown in the menu.)
array layout=[a,b,c,...,x,y,z][A,B,C,...,X,Y,Z][á,ä,..][@,#,...]

There are some other points, but I think it would be better if those are discussed in a technical design doc, so they can be explained in greater detail.

[markun]

salival: I think your ideas are too complex. phaedrus961's patch works very well regardless of screen size and font size (which I think your probosal does not). Try it and tell us what you think of it.

[salival]

I don't think my proposal is much more complex then the current implementation or the mentioned patch.

The reason they might look complex might be of they way I explain things. (I have the tendency to make things look more complex than they are.)

I try to explain the "philosophy" of my proposal in a few sentences.

1. There should be one keyboard which is optimised on a per target basis, while the basic layout remains the same.
2. There should be one single keyboard that can easily be implemented in any program/plugin, while maintaining the feel of that program.
3. The keyboard should have support for non-latin character sets.
4. The keyboard should have support for multiple character subsets, like accented characters, which can be selected by a menu.

It is about the same concept as used in onscreen keyboards on game consoles.

That's the basic premisse.

The main functions needed for this are:
- multi page support, which is already available in the current keyboard.
- custom layouts, which are (partially) supported by the current keyboard and phaedrus961's patch.

All in all it is more a redesign than a completely new design. I always try to keep in mind how easy or difficult an option is to implement.

[kenshin]

I adjusted the wiki with a more complete Japanese character set. There are 10 small characters in both the Hiragana and Katakana, not just the 1 Hiragana and 4 Katakana that was already there.

[salival]

The hira/katakana layout now occupies 5 rows, which IMO is one too many. Either the small characters have to be fitted between the large ones or, as you suggested and in my eyes the best solution, use a shift button to show a layout with only the small characters.