[Drafted this a while back, sending now albeit a bit late] Good of you to bring this up but this is one of those unfortunate known deficiencies in the HIG that were less than ideal but good enough at the time.
The Gnome Palmtop enviroment has a HIG http://www.handhelds.org/moin/moin.cgi/GpeHIG It recommends using spacing proportional to those requested in the Gnome HIG. Essentially they are aware of the flaw and work around it as best as possible. I suspect changes would be needed to GTK to allow the HIG to provide more generally applicable advice. In the shorter term we could create a subsection and fold in the existing guidelines from GPE. If I recall correctly Calum Benson wanted to do this but there aren't enough hours in the day. I really love it that some applications such as Gnome Games and a few rare others can run unmodified on both a palmtop device and an ordinary desktop. A few well presented applications keep things elegently simple and are not overburdened by an interface like the cockpit of a jumbo jet* and use things like correctly respecting toolbar settings and cleverly taking advantage of widgets that do scale to fit the available space. More often though it is the simple palmtop applications that can be neatly dropped into a fuller heavyweight desktop. ... (message continues interspersed below) ... * A cockpit of a jumbo jet may be a fine interface if you are a pilot with years of experience but a terrible interface for beginners, especially when Gnome aims to have a shallow learning curve and many beginners use computers or even particular applications so infrequently as to make them perpetual begginers. > > > 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. Desktop applications need to have good and consistent keyboard navigation if they are to satisfy frequent users. Applications which fail to work well without a pointing device are very likely to also fail users with accessibility needs. Considering how often developers get RSI you might think accessiblity would be an even higher priority. > - Device with stylus (no middle button, no right button, needs to handle > pop-ups and context menu, maybe detaching stylus). We may not like the single button mouse but the designers at Apple were very wise to make it the default since it forces developers to be disciplined and come up with applications that by default remain usable in a pen driven interface. I would be very worried by any Gnome application using the tertiary (middle) or even secondary click as anything more than an optional extra. Anything in the context menu will need to be in the main menus anyway if they keyboard navigation is any good. > - Devices with limited set of keys (and possible combination with no > pointing device) and multi-press input (mobile phone style input > method already exist). Clickers for presentations and reusing bluetooth phones for that same purpose are really neat tricks which I hope can be encouraged. (Using a camera phone as a mouse is an impressive by nasty hack.) > - 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. I'm really growing to hate touch screen interfaces that were designed as an afterthought to desktop applications, buttons too small and I'm frequently requried to switch context and *type* things subverting the supposed benfits of the touchscreen interface. Unfortunately some desktop applications are probably also guilty of inflicting this expensive context switch on users. We could give guidelines on how not to create terrible touch screen applications but I wonder if it would be really possible for most applications to work well in touchscreen interfaces without a massive overhaul. On the other hand maybe it is just a few steps up from a good stylus driven interface. > - Maximized window only window manager operations (DnD from another > window is not possible). If anyone were to implement a shelf application (or modification to the panel) it would be popular beyond just users of small devices and it has come up in discussions over the years as a concept users enjoyed from other Operating Systems. > - 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. I'd prefer we killed off rollers entirely. They seem like a nice idea and you think they might encourage developers to be more disciplined and not overcrowd menus but as you can see from small screen devices the menus might not seem crowded on the development plaform and the problem only becomes noticable later. (I always end up overfilling my Bookmarks list and rollers are intolerable once you have more than a handful of extra items in a menu.) > - Uncomfortable pointing devices (i. e. need for unpacking stylus > just for one tap to change focus). Feeds right back to accessiblity. > - Option to not show accelerator keys in the menu, especially when the > keys don't exist, but allow to display them on request. I can understand hiding accelerators on a device with no keyboard but I'd be worried about people hiding them on a Desktop for aesthetics at the small expense of learnability. > - 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). Helper to smack upside the head anyone who hasn't made an interface that has used the extra keys as anything other than _extra_ keys. Finally, I prefer to think of usability as "user optimisation". There are many factors you can consider but by definition you cannot optimise for more than one case. Sure interfaces for portable (or small screen devices) will requires some device specific tweaks but the bulk of the work will be built on the same foundations any good desktop application should already have. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ http://www.linkedin.com/in/alanhorkan http://alanhorkan.livejournal.com/ _______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
