From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26855 invoked by alias); 12 Feb 2007 21:12:13 -0000 Received: (qmail 26819 invoked by uid 22791); 12 Feb 2007 21:12:11 -0000 X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_50 X-Spam-Check-By: sourceware.org Received: from rgminet01.oracle.com (HELO rgminet01.oracle.com) (148.87.113.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Feb 2007 21:12:02 +0000 Received: from rgmsgw02.us.oracle.com (rgmsgw02.us.oracle.com [138.1.186.52]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l1CLBxhj025806 for ; Mon, 12 Feb 2007 14:11:59 -0700 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmsgw02.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l1CLBwYg003567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 12 Feb 2007 14:11:58 -0700 Received: from kvanhees by ca-server1.us.oracle.com with local (Exim 4.63) (envelope-from ) id 1HGiSr-0005E5-RT for frysk@sourceware.org; Mon, 12 Feb 2007 13:11:57 -0800 Date: Mon, 12 Feb 2007 21:12:00 -0000 From: Kris Van Hees To: frysk@sourceware.org Subject: Re: frysk ui concall Message-ID: <20070212211157.GA14346@ca-server1.us.oracle.com> References: <45CA94F2.2000707@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45CA94F2.2000707@redhat.com> User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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/msg00107.txt.bz2 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