View Single Post
Benson's Avatar
Posts: 4,930 | Thanked: 2,272 times | Joined on Oct 2007
#96
Originally Posted by fallenguru View Post
Thank you, now I know what's been (slightly) bothering me about many maemo UIs: some of the toolbar buttons at the bottom of the screen.
Take deleting a file in file manager as an example. First you have to select the file, then go to a different part of the screen and press a spatially unrelated button (the trashcan). Why isn't [delete] on the context menu, right by the affected file, so to speak? Isn't that non-direct, in a way? At the very least the static toolbar takes up precious screen real estate even when not needed.
Before someone complains that the context menu would get too complex, yes it would. Off the top of my head: Replace the textual context menu entries with symbols where established symbols exist and show those in a *circle* around the affected object to minimize stylus/finger travel time. For the more advanced options that require textual descriptions, put those in a third-layer menu (that pops up if you press down on an object even longer).
First, delete is on the context menu, and when using a stylus, I tend to go that way for it. Context menus, as implemented, are somewhat riskier when in finger-mode, so I might slap the toolbar button (or menu + d-pad on the hardware keys, especially when I'm using one hand).

Better finger-mode context menus would be nice; although the implementation can't simply be to replace all popup menus, it could hopefully be patterned closely enough to permit easy conversion (where existing menu items are suitable).

Can one test-drive these alternate input methods somewhere?
The only alternate (latin-centric) input method implementation I'm aware of is QwikScript, but any method with open-source implementations could be ported to Maemo... Some of them have Java and similar online tech demos.