Re: [Usability] HIG proposals are bad for PDA and small screen devices

[Stanislav Brabec <sbrabec suse cz>]

Calum Benson wrote:
> On 9 Jan 2008, at 15:21, Stanislav Brabec wrote:

> > HIG conforming application must use 12 pixel spacing and ignore screen
> > dimensions. It sounds broken by design.
> 
> It's a known issue, but the main 'broken-ness' is in gtk[1],

> [1] Or at least, it was when the HIG was written-- was this ever fixed?

No, or at least not completely. Search for string "12" for example in
gtkfilechooserdefault.c [2]

> That said, updating the guidelines with mobile devices in mind is  
> definitely something we need to consider for the next release of the  
> HIG.  It may be that a separate or supplementary document is more  
> appropriate, though (as with the Java mobile device guidelines, the  
> Windows CE guidelines etc.)

I agree. But creating such general guidelines is a complex task.
Implementing it is even more complex.

Here is only a few hints:

- Small screen, which can have unexpectedly low or high resolution.

- XRandR friendly applications.

- Devices without any pointing device.

- Device with stylus (no middle button, no right button, needs to handle
  pop-ups and context menu, maybe detaching stylus).

- Devices with limited set of keys (and possible combination with no
  pointing device) and multi-press input (mobile phone style input
  method already exist).

- Devices designed for finger tapping (e. g. Neo 1973 [3]). Standard
  focus design does not even think about the fact, that pointing device
  (finger) can completely hide the widget. Especially custom press
  feedback is required.

- Maximized window only window manager operations (DnD from another
  window is not possible).

- How to handle full screen mode (e. g. image displaying) for device
  without any key.

- Extreme space saving (e. g. single button for the whole menu, allow to
  combine window manager controls and menu or toolbar in the same row
  etc.).

- Roll out combos and menus as tables instead of very tall lists with
  rollers.

- Uncomfortable pointing devices (i. e. need for unpacking stylus
  just for one tap to change focus).

- Option to not show accelerator keys in the menu, especially when the
  keys don't exist, but allow to display them on request.

- Devices with more displays of different size (for example controls
  display + large image display, standard display + status display,
  standard display + key binding display,...).

- Show accelerator key icons for keys with long name but small icon.

... Many other possible ideas.


I can even imagine several helpers implemented in the low GUI level:

- Helper to display active accelerator keys (in dedicated area or on
  request or on a second display, may be also usable as part of the
  driver for devices like Optimus Maximus keyboard [4]).

- Helper to easily bind accelerators to available keys.

- Helper that displays pop-ups.

- Helper to replace right and middle click somehow (special button, long
  tap - such one already exists).


[1] http://mail.gnome.org/archives/gtk-devel-list/2003-February/msg00009.html

[2] http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkfilechooserdefault.c?rev=1.338&view=markup

[3] http://www.openmoko.com/products-neo-base-00-stdkit.html

[4] http://www.artlebedev.com/everything/optimus/

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec suse cz
Lihovarská 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/