From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13555 invoked by alias); 13 Feb 2007 22:26:18 -0000 Received: (qmail 13546 invoked by uid 22791); 13 Feb 2007 22:26:16 -0000 X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Feb 2007 22:26:11 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1DMQ6QX010813; Tue, 13 Feb 2007 17:26:06 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1DMQ6e0015134; Tue, 13 Feb 2007 17:26:06 -0500 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1DMQ5aQ013281; Tue, 13 Feb 2007 17:26:05 -0500 Message-ID: <45D23AF3.6020005@redhat.com> Date: Tue, 13 Feb 2007 22:26:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Kris Van Hees CC: frysk@sourceware.org Subject: Re: frysk ui concall References: <45CA94F2.2000707@redhat.com> <20070212211157.GA14346@ca-server1.us.oracle.com> In-Reply-To: <20070212211157.GA14346@ca-server1.us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00123.txt.bz2 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 >