Support and General Use > User Interface and Voice

vkeyboard suggestion (corrected for dodgy diagram alignment)

<< < (2/3) > >>

JdGordon:
I *really* Like this idea! I'm not sure how well it owuld work on non-wheel targets (presumably better than the current keyboard though)

point 13 about the snaking is a very interesting idea but I'm not sure it wouldn't make it more confusing. Also it isnt a very good use of screen space. (on the small screen targets anyway)

having a paging system is probably more important than a delete key, so my suggestion would be that it only needs (minimum), left/right, up/down (or wheel), ok/cancel, "change page".

By pages I mean a small set of common chars (lower case, upper, number, punctuation, symbols, etc), where there is enough screen space we can display the page number/total.

If there is no spare key for del we can maybe add a new page which has "keys" for del, insert, copy/paste?

One thing to consider is touchscreens, if we can do very simple up/down sliding then it should be workable with a few on screen buttons.


For the speed argument, I think that the vast majority of uses is just naming a file which cuts alot of possible letters out.

seani:
I think the wheel targets are a no brainer - certainly the characteristics of the scroll wheel on an e280 make me think it would be a lot faster. Other acceleration characteristics for non wheel targets and a lot of small details would close the gap there I think.

I'm now thinking in terms of short select for insert and short power for delete, with long versions for accept and cancel. That just leaves a key to find for "cycle chosen character page" to alter the current vertically scrolling list.

If you can find a cycle key for all targets, the snaking may be unnecessary anyway (although I might just try for fun)

JdGordon:
My suggestion would be "Bloody go for it!" and we can figure out the buttons later. the ondio might cause problems, but I think all others should have enough buttons.

soap:
Very nicely presented, and fleshed out, proposal.

seani:
Well I had a go at a quick and dirty patch to feel things out a bit. It *was* actually surprisingly easy to bend the current kbd_input method in an unpleasant way to at least get an idea, but I wandered down a few rabbit holes and wasted a load of time.

The disposable frig I've attached is really designed to work on an E280 only, although other screens could be made to work if the attached keyboard definition was amended to suit.

You need to load the keyboard file before trying.


1) The "#"  and "<" are symbols reserved at the start and end of each list. Hitting Select on "<" will backspace and delete the character to the left of the cursor on the edit line, "#" will flip pages.

Yes, that means you can't insert those characters, but remember this is just a convenience to play with the feel of the thing. Special chars / symbols await in the "real" version.


2) Wheel scroll up and down advances through the character selected, changing the current edit character


3) Cursor left and right moves left and right through the edit line.


4) Enter will insert the character currently under selection in the picker at the current point in the edit string


5) You can't save your changes!



Although it's been interesting to think through some of the issues and get a bit more familiar with the code, a few things have become very apparent.

1) The block cursor moving through the picker and the character changing in the edit string to the left of the insert cursor in synch. makes for a disjointed experience. Attention is constantly flicking between the two; up to the picker to see where the block cursor is, down to the edit line to see what the change looks like.

2) The mismatch between the block cursor operating *on* a specific character and the edit cursor *between* two characters with an implicit focus character is also distracting.


But both of these issues are artefacts of it being a sandbox and not real code; I'm still convinced that a single point of intersection between picker and editor will play much more nicely; one point of focus.


3) The method for insertion in this patch is meh. Hitting Enter selects and inserts the current focus char on the picker and then wheel-scrolling changes it, and this doesn't flow well at all

4) Inserting at the end of a string is also counterintuitive; you need to cursor to the end, hit Select to effectively insert a copy of the last character and then scroll to change.


But again, 3 and 4 are explicitly addressed in a different way in the originally post (insertion of a "null" character and changing or moving off) and I think doing this properly and getting the detail right will sort it out.


I also think that it would be easy to accommodate more "special" actions in the picker to address the issues of restricted controls where required; accept entry, cancel entry, delete-to-end, delete-to-beginning, restore-to-original, etc. etc. Also pretty easily taken care of in the keyboard definition.


So now worth spending the time to do it properly I think.


(files may need extensions renaming - only .txt accepted)

Navigation

[0] Message Index

[#] Next page

[*] Previous page