Re: frysk ui concall

[Kris Van Hees <kris.van.hees@oracle.com>]

As a newer person on the list, last week's conf call was very useful to
get a better feel for the UI design process.  I'd like to share a few
observations from that call.  If some are wrong, please let me know :)

While the HIG is a quite useful document, and provides a lot of guidance
in designing a UI (which is known to be a rather annoying task), it is
unfortunately only one of many sets of guidelines on UI design, and most
do not tend to agree with one another.  When you throw accessibility
(Design for All, Universal Access, .... [pick your choice]) into the
mix, you enter even more dangerous terrain.  What I am not clear on from
the discussions in the call (e.g. about the assistants) is what target
audience frysk is intended for.  I can guess who would use it, but that
is not always the same as who you would like to see it used by.
Obviously, most novice computer users will not get involved with
application debugging.  Setting a baseline of expected
expertise/knowledge for the user base is likely to help quite a bit in
making decisions about the UI design.  A more experienced users who has
a clue about debugging typically will not need much in terms of
interposed dialogs explaining what is going on, and would rather get on
with the task at hand.  I can see different levels of expertise being
provided, but probably not as wide of a range as the HIG might really be
meant to address.  From an accessibility perspective, informational
dialogs are often a bit of a pain as well (unless they carry necessary
information) because e.g. a screen reader has to read it out loud at
least in part before the user knows what action to take.

Another thing I wondered about is whether there is an established set of
expected workflows for the user base.  I.e. what would a user typically
use frysk for, and what would some representative workflows look like.
That helps a lot with UI design because you can easily determine the
length of the interaction (is it too long to get to what you want).  Is
there too much focus on configuring a debug session in comparison with
the actual debugging task? And so on...  Workflows (albeit a bit of a
pain to come up with) also help with checkpointing the design in terms
of overall usability.

Finally, I noticed (too late - call had moved on to other stuff already)
that the process selection does not list the process owner in any of the
columns.  That could be useful information on multi-user systems where
an engineer has to debug a running process for user X.  Also, it might
be worth considering (may already have taken place in the past) whether
there is a point in providing a tree-view of the processes.  It seems a
bit counter-productive that there is a GUI to select the process to
debug, but one may need to consult a terminal session to look at pstree
output to determine what the correct process is to debug, e.g. in cases
where a parent process (possibly of a whole tree of processes) is
crucial in the investigation.  Determining the correct process may
depend on a lot more than just the process name, command arguments, or
even owner.

	Just thoughts...  Let pies fly :)

	Cheers,
	Kris