[Usability] Mapping apps for ui-review (Was: display full path in spatial nautilus)
- From: Gregory Merchan <merchan phys lsu edu>
- To: Calum Benson <Calum Benson Sun COM>
- Cc: David Adam Bordoley <bordoley msu edu>, usability gnome org
- Subject: [Usability] Mapping apps for ui-review (Was: display full path in spatial nautilus)
- Date: Mon, 17 Nov 2003 09:38:52 -0600
On Mon, Nov 17, 2003 at 12:58:08PM +0000, Calum Benson wrote:
> On Sun, 2003-11-16 at 23:32, David Adam Bordoley wrote:
>
> > Using the full path as the window title makes the window list thoroughly
> > unusable for *most* users who aren't going to have ten folders with the
> > same name.[1]
>
> Perhaps in general there ought to be a way for a window to suggest a
> sensible "abbreviated" name to any window-list-type app (e.g. just the
> current document's filename, or just the current folder name)?
> Slavishly copying whatever's written in the titlebar has always seemed a
> rather unhelpful idea to me, given that you're almost never going to be
> able to read it all however styleguide-compliant it is.
That's what the tooltips are for.
As soon as we get the many outright bugs in windowing fixed, we'll have
a better basis for evaluating further improvements. So far almost every
"cool idea" is a kluge for a bug.
Metacity, for its part, is steadily improving. I don't know about the
applications.
Windowing bugs are hard to catch and fix during ui-review, especially
since we don't have thorough (or any) design docs for any applications.
Sometimes the fix is too complex to be done during ui-review time.
We need "maps" of applications. Here are two ways to make them:
If you can follow the code:
1) find all the calls that create a top-level window
(skip things that the window manager never controls -
e.g., attached popup menus and tooltips)
2) find all the calls that show, hide, or modify those windows
(sometimes these are hidden - e.g., Gtk+ sets WM_CLASS
automatically)
3) list the results of these
If you can't follow the code:
1) Capture the splashscreen data if it exists:
a) Open a shell (in a virtual terminal) and type, but do not enter:
xprop | grep _NET_WM_WINDOW_TYPE
b) Run the app
c) Quickly go to the terminal and press enter to run the command
typed in step 1.
d) Then quickly place the pointer over the splashscreen and click.
If you're lucky and quick, you'll catch the window in time.
You should see this line in the terminal output:
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_SPLASH
If it's not there, you've found a bug. Close the app and:
e) In the terminal, type, but do not enter:
xwininfo | grep -i over
f) Run the app, quickly switch to the terminal and press enter,
then quickly click on the splashscreen.
The quick and the lucky will see a line like this in the terminal
outut:
Override Redirect State: no
If that line says "yes" instead of "no", you've found a nasty bug.
Find a nice way to say to the app's author:
"You're a dweeb who hasn't kept up with the times. Doubly so for
using a splashscreen at all. If you can't make your app load
fast enough, then at least improve your splashscreen so it isn't
a total pain in the ass. Use the _NET_WM_WINDOW_TYPE
_NET_WM_WINDOW_TYPE_SPLASH specified in the wm-spec at
freedesktop.org, so the user isn't buggered by a window that the
window manager can't control."
2) Create a file to store the data. Let's say the app in
question is named "Foo" and call the file "foo.props"
echo "Window properties for Foo" >> foo.props
3) Proceed to inspect every window you can find in the app.
Don't skip the alerts! It wouldn't hurt to make screenshots as
you do this.
a) Add a line to the file with a brief description of the window
you're looking at:
echo "Main window" >> foo.props
Usually, the title of the window should suffice. Exceptions
include the main window and alerts. When in doubt, describe
how you made the window appear - e.g., "I clicked on the 'x'
in the window frame." "I chose 'Save As...' from the 'File'
menu." If it's not obvious how you made the window appear,
say how you did it - e.g., "I clicked on the 'x' in the
window titlebar, then clicked on the 'Save' button in the
window that appeared, and then I clicked on the 'New Folder'
button in the window that appeared after that."
b) Capture the useful data from the window:
xprop | grep -v _NET_WM_ICON >> foo.props
(Nobody wants to see _NET_WM_ICON)
If any of the size, shape, position, colors, or responses of
the window to actions like resizing seem odd, then run this
and click on the window:
xwininfo >> foo.props
c) Check the output file. You should see one line like this:
WM_CLIENT_LEADER(WINDOW) = window id 0x1c00012
Capture the data from this window in a separate file:
xprop -id 0x1c00012 | grep -v _NET_WM_ICON >> foo.leader
Make a note of this window id and don't recapture the data
when you see it again. It should be the same for every
window of the app you're looking at.
d) Check the main output file again. If you see a line like:
WM_TRANSIENT_FOR(WINDOW): window id # 0x1a00003
Then capture the data from the window specified and add it
to the main file:
echo "Data for parent window:" >> foo.props
xprop -id 0x1a00003 | grep -v _NET_WM_ICON >> foo.props
e) Add a line to the file to break up the data:
echo "--------------------" >> foo.props
f) repeat steps a-e for every window you can make
appear.
4) Append the data from the leader to the main file:
echo "Client leader properties:"
cat foo.leader >> foo.props
You can get rid of the leader properties file now.
5) Put your output file and screenshots somewhere on the web and send
the urls to the usability list for when ui-review rolls around.
Do not send the files to the list! Don't put them in bugzilla.
I'm tired. Perhaps someone can make some programs or scripts to automate
this. I'll try to write up what's expected and what are bugs to watch for
later.
Cheers,
Greg
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]