design pattern documentation/peer review
- From: "Jeff Henrikson" <jehenrik yahoo com>
- To: <usability gnome org>
- Subject: design pattern documentation/peer review
- Date: Fri, 10 Aug 2001 15:53:01 -0400
Hi,
I was posting a usability issue on gtk-list, and I thought maybe I would point out an idea related here.
I was building some prototype code with gtk a few months ago, and I ran across a problem trying to create a simple constrained text
entry box in a nonmodal dialog box/window. In particular, just have the box constrain to always have a number, but allow tweaking
with letters (eg, "e" as in 2e05") and whatever until the box loses focus. Sounds simple enough but it turns out that the right
signals to handle such a thing either don't exist or are not obvious. (Whether the standard behavior can be achieved was the
question for gtk-list, which I have yet to hear a response.)
So on a different note, I am wondering if a useful form of Gnome/GTK documentation and/or Gnome/GTK usability promotion would be a
set of standard examples, like the modeless constrained text entry.
One answer is that this is simply that the API should encourage the correct behavior, and in this case doesn't. No additional
documentation required. Another answer is that my example just belongs in the GTK tutorial, documented in that form. But I'm
wondering if anybody has thought of writing some sort of analog to the Macintosh Human Interface Guidelines, but having code
samples with how to do stuff correctly, with some small/medium sized (but real or connotative of real) test programs being part of
the document.
The best way to get such programs seems to be to find ones already written. Toy programs for this kind of thing never seem to be
realistic. Which leads me to another idea:
Maybe the Gnome usability community should have a way for usability-centric developers to submit their jems for review and
agregation with the other examples? These seems to work with glory seeking hacker mentality, and voluntary submission avoids the
problem of hackers feeling that their projects are being policed. Somehow it seems we need to invent some social mechanism that
does functionally what the "Windows logo" and other programs try to get: peer reviewed quality. (Well, I'm not sure peer is the
right term here. Hackers are not usually CHI specialists, and that's the core of our issue.) Otherwise, hackers are just going to
do stuff whatever which way and Gnome behavior will never converge to uniform. Obviously, you can't force volunteer developers to
submit to any sort of authority, but you might try to make it desirable for them to do so. Project promotion through affiliation
and constructive feedback might be good incentives.
Critique of GUI specifications as well as fully formed programs would also be useful. That would require a standardized way to
informally specify GUIs. Drawing up a metaspecification or at least some example specifications might be good documentation in its
own right.
All right, done making leaps of association from that remote idea at which i started. I hope some people can make some more.
Jeff Henrikson
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]