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

[Alan Horkan <horkana maths tcd ie>]

[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/