* Re: frysk ui concall
2007-02-12 21:12 ` Kris Van Hees
@ 2007-02-12 21:25 ` Rick Moseley
2007-02-13 21:27 ` Andrew Cagney
2007-02-13 22:26 ` Andrew Cagney
2 siblings, 0 replies; 6+ messages in thread
From: Rick Moseley @ 2007-02-12 21:25 UTC (permalink / raw)
To: Kris Van Hees; +Cc: frysk
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: frysk ui concall
2007-02-12 21:12 ` Kris Van Hees
2007-02-12 21:25 ` Rick Moseley
2007-02-13 21:27 ` Andrew Cagney
@ 2007-02-13 22:26 ` Andrew Cagney
2 siblings, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2007-02-13 22:26 UTC (permalink / raw)
To: Kris Van Hees; +Cc: frysk
Kris,
You are correct, there are several types of user, and they can have
differing needs. As Rick pointed out, we're focusing a number of
senarios. However, lets, for a moment, look at the user not in terms
of their tasks, but in terms of their skill set and experience:
The power hungry, manual reading, keyboard hugging, user:
This user is willing to learn and even take pride in knowing esoteric
interfaces, especially ones that involve obscure command line options,
or key sequences. Further they will happily spend hours on futile
learning exercises, and thus carry with them a vast array of useless
information. They have little time for this artsy graphical stuff. If
visual functionality is missing, they are more than willing to implement
it, badly :-)
The illiterate, mouse clicking, print loving, I want my stack back-trace
now, user:
This just wants to see the back-trace for a crash, they never read a
manual, never do anything beyond what is in front of them, and quickly
tire of poor design or cumbersome interfaces.
The frysk user interface is targeting more at the mainstream or latter
case. If it is well designed then it won't get in the way of the power
user, while poor design will get in the way of everyone. This isn't easy.
For instance. The first cut at the monitor viewer had a tree view and
the entire process tree. It was found to be too unwieldy and confusing,
that observers could be added or controlled was anything but obvious.
Consequently the session assistant was introduced, the process-picker
screen providing a way to quickly identify the processes of interest,
and the observer screen letting the user set up what is being
monitored. These two steps give the user a quick simple way of
selecting, or modifying, what should be monitored (or at least it is
getting close).
The utilities, on the other hand, are targeted at power users.
For instance, fcatch, which prints a stack back-trace for every signal,
is something I used again today, and now I want to modify and fix.
(and, yes, not being able to add the owner / group to what is displayed
is a bug :-)
Andrew
PS: I put myself into both categories, I like my keyboard, yet will will
use a GNOME application if it is simple and effective. I like tools
that do their intended job really well.
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
> 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread