[Usability] Documenting interaction tips

[Gregory Merchan <merchan phys lsu edu>]

There are at least a few ways for applications to improve interactivity
which are not documented anywhere. Insofar as they can dramatically alter
the user experience they might be HIG topics; but they mostly pertain to
how to write code.

One example is bug #114689 which I filed against Epiphany this morning.

  http://bugzilla.gnome.org/show_bug.cgi?id=114689

Another one would be use of this function to constrain dialog size:

static void
on_realize (GtkWidget *widget)
{
  GtkRequisition requisition;
  GdkGeometry    geometry;
  GdkWindowHints hints;

  gtk_widget_size_request (widget, &requisition);

  geometry.min_width  = requisition.width;
  geometry.max_width  = G_MAXINT;
  geometry.min_height = requisition.height;
  geometry.max_height = requisition.height;

  hints = (GDK_HINT_MIN_SIZE | GDK_HINT_MAX_SIZE);

  gtk_window_set_geometry_hints (GTK_WINDOW (widget), widget,
                                 &geometry, hints);
}

Connected to the dialog:

  g_signal_connect (dialog, "realize", G_CALLBACK (on_realize), NULL);

This function will tell the window manager that the dialog should only
grow wider (or narrower, down to a particular size), and not ever grow
taller.

Note that this size contraint is incomplete as it doesn't compensate for
theme or font changes after the dialog has been realized. I had the
function on hand; I haven't found the complete way to do this, yet.
And maybe it shouldn't be tied to the "realize" signal at all.


We should have a collection of interactivity tips somewhere. They could
be put in the HIG, but perhaps they should just be linked from there.
If they are put in a separate document, there are other parts of the HIG
that should be moved to that document. Had we done this earlier, Seth
and I would've had less to argue about. :-)  The Apple HIGs are "cleaner"
because they have a division like this. Whether they link straight to
API docs or a tips document, I'm not sure.

It's been too long since I've looked at the accessibility guidelines.
If there are code examples in there that the GAP would like moved out,
those can also be put into the tips document.  The GAP might want to do
this so their guidelines aren't fixed on just GNOME/Gtk+; they might
want to link to similar documentation for OpenOffice.org.

Writing a tips document and getting it linked may be a new project in itself.
As every project must have an acronym, I propose this one be called:

  GLUE: GNOME L{ovin'|uxurious|ucious|etc.} User Experience

It's also glue between different parts of GNOME programming.

Note to the English:
 Please no alternative spellings. This should not become the GNOME Loo.


Cheers,
Greg