Re: frysk ui concall

[Rick Moseley <rmoseley@redhat.com>]

Kris Van Hees wrote:
> 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
>   

Please see the http://sourceware.org/frysk, at the top of the page are 
links for "Work Flows" and "Use Cases".  That should give you an idea as 
to what audience we are pointing at.

> 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.
>   
See above repsonse.
> 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
>   
The processes being displayed in the list are the processes owned by the 
currently logged in user as you have to own the task before you can 
attach to it.
> 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
>   
A treeview was used in the past and deemed too messy.
> 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
>