frysk ui concall

frysk ui concall

[Andrew Cagney]

Hello,

I've set up a concall for discussing UI aspects of frysk.  The game plan 
is to keep the call short and sharp by focusing on only one or two 
aspects of the UI each time.  The call is Thursdays starting by 9:30 US 
East coast time (2:30 gmt) and ends 10:45.

If there are other topics anyone wishes to discuss then please let me 
know, it may be better to set up a less focused call.

The downside here is the lack visual communications media - no way to 
visually follow what is being discussed.  Please have access to an 
up-to-date build.

If interested please contact me off list.

Andrew

Re: frysk ui concall

[Elena Zannoni]

Oracle would like to participate to the conference call, please
send info to Kris and me.

tia
elena

Andrew Cagney wrote:
> Hello,
>
> I've set up a concall for discussing UI aspects of frysk.  The game 
> plan is to keep the call short and sharp by focusing on only one or 
> two aspects of the UI each time.  The call is Thursdays starting by 
> 9:30 US East coast time (2:30 gmt) and ends 10:45.
>
> If there are other topics anyone wishes to discuss then please let me 
> know, it may be better to set up a less focused call.
>
> The downside here is the lack visual communications media - no way to 
> visually follow what is being discussed.  Please have access to an 
> up-to-date build.
>
> If interested please contact me off list.
>
> Andrew
>

Re: frysk ui concall

[Kris Van Hees]

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

Re: frysk ui concall

[Rick Moseley]

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
>   

Re: frysk ui concall

[Andrew Cagney]

Kris,

You asked about accessibility, two pieces of background that might help 
clarify what is going on:

- frysk is using JUnit for unit-level testing
For instance frysk-gui contains a test to verify that the paths to the 
files required by the UI are all valid.

- frysk is using DOGTAIL for UI testing (a.k.a. integration testing)
For instance, sequencing through the operation of selecting a set of 
process and monitoring them, thus ensuring that the entire frysk program 
works as expected.

In the latter case, DOGTAIL uses accessibility information to identify 
and control widgets.  So in addition to the obvious reasons, 
accessibility is important to frysk as it allows us to pursue automated 
testing.

More information on DOGTAIL is available here: 
http://people.redhat.com/zcerza/dogtail/
And you can run the dogtail tests with /usr/lib/frysk/ftail.

Andrew

Re: frysk ui concall

[Andrew Cagney]

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
>