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: [EMAIL PROTECTED] Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
