[552] in Athena User Interface
Re: Configuration of sawfish, panel, gnome-terminal, control-center
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Sun Dec 31 23:35:42 2000
Message-Id: <200101010435.XAA24504@ten-thousand-dollar-bill.mit.edu>
To: ghudson@MIT.EDU
cc: aui@MIT.EDU, sbjones@MIT.EDU
Date: Sun, 31 Dec 2000 23:35:36 -0500
From: "Christopher D. Beland" <beland@MIT.EDU>
Just a note, recommended permanent changes (vs. temporary kludges) are
documented in /mit/aui/evaluation/gtest/changes.txt. The master copy
of the gtest dotfiles are also hosted in that directory.
- Sawfish defaults have the system-custom dichotemy, right?
- Panel should use mostly lockers or AFS space
> * Theme
I would also recommend importing the look-alike themes for the Windows
and Mac interfaces, which we don't have in aui right now, but would
probably help multi-platform users transition back and forth and be
happier when they are using Athena.
> * Menus (also determined by the site-defaults file)
> Brad has done a little hacking on the sawfish menus, but I think we
> want to take another look. For one thing, I'm not convinced that
> the sawfish menus should contain yet another short list of
> applications to launch (we can shoehorn "new window" into the window
> operations menu to start gnome-terminal); that's the role of the
> panel launchers.
This is something we actually meant to talk about with the Usability
Team. What should root-window clicks really do? (This has not been
addressed properly in the current AUI prototype; I think some of the
menus you get now are somewhat broken from a usability perspective.)
If you have a file manager (FM) like Nautilus running, the desktop
becomes a place to store files, and the FM starts handling some root
clicks. When you click on an icon, you either open in or get a pop-up
menu; when you click on the background with button X, you should get a
menu for doing things like arranging icons.
It's also a logical place for people to try clicking when they want to
change their background picture; that's a common item found on these
sorts of menus.
Finally, it can be useful to have pop-up menus for common tasks, like
starting frequently used applications, logging out, etc. One could
imagine a miniature version of the panel menu popping up there, but
this seems somewhat redundant since the Gnome foot menu should be
handy anyway.
The most important function of the root menus is to save you when you
accidentally delete the panel or screw up your menu system or
something horrible like that. There should definitely be a way to
start a new xterm, and perhaps to log out, as well. I've also been
saved by the list of all running windows you get from the Sawfish
menus, in the case where tasklist is screwed up or not running or
overloaded with zwgcs or something, and a window I need is stuck under
something or for some other reason not visible.
So in summary, I would advocate allocating one button to FM functions
(perhaps the right one) and another (hopefully left, since most people
try that one first) to escape functions (athena-logout,
athena-default-terminal), utility functions (athena-www and whatever
else appears on the panel by default), background configurations.
Somewhere, whether on the middle or right button, should be a list of
all currently running windows.
> - Terminal
> - Editor
> - Mail reader
> - Web browser
> [ File manager? Perhaps having an icon for the user's
> homedir will be enough. Not sure.]
Well, to reiterate the results of the previous discussion, we
compromised on not having any "Editor" launcher on the panel. The
reasoning was that different editors would be appropriate for
different tasks, and that different people have different preferences
for what editor to use for a given task. For instance, for simply
editing a text file, we've seen advanced users go immediately for
Emacs, and novice users sucessfully fire up Star Office to do it.
Emacs, though currently a supported editor, has been the perrenial
target of both serious usability complaints and high praise from
programmers and certain power users. Since Star Office 5.2 has come
out, a large number of people seem to have adopted it for longer
text-editing tasks, and gEdit is now available as a more user-friendly
alternative to Emacs for simple tasks. What I've tried to do with the
"Productivity" menu is list the entire spectrum of available text
editing applications, sorted by task in order to help new users find
the most appropriate tool.
If there were a single "Editor" launcher, we'd have to settle the
question of which application it would point to come fall. There are
strong arguments for it to be Emacs (power, precedent) and gEdit
(usability), and large constituencies that are demanding each. (Note
that there would still need to be a default application to open text
files when you click on them in, say, the file manager.)
On the other hand, not presenting a default option on the panel will
tend to shift people's usage patterns away from the "supported"
editor, Emacs. (I guess EZ is also "supported" and in the Athena
intro materials, but I didn't even include it on the menu system
because it's so crufty and I think my subconscious was hoping it would
go away. With gEdit and Star Office on the scene, I think the
functionality it offers is probably redundant now.) People will
probably start using a wider variety of editing tools, though there
still might be one "official" way to edit text files whenever such
things need to be explained in the documentation.
In short, this choice has a serious support impact. Shifting to Gnome
is supposed to reduce support and documentation load in the steady
state; there are risks both in keeping Emacs as the hard-to-use
default (and EZ as the bastard editor thrown to the Emacs-haters) AND
in not putting a single default right under people's noses.
(There are also serious future integration issues with the mail reader
and tty logins with regard to supported text editors, no?)
Anyway, we said Gnome-Athena should get some attention in the support
impact department; is this happening or will it happen soon?
> * Menus
I agree with Richard; distributed maintenance is very important and I
personally think the lack thereof was Dash's downfall.
The Gnome Menu/Main Menu distinction is extremely problematic and
should go away. The current practice of making the "Favorites" menu
what comes up from the Gnome footprint is somewhat confusing, but on
the other hand, I really like being able to customize the top-level
menu.
> gnome-terminal (from gnome-core)
I agree; pulldown menus are a win. It also fixes the problem that if
you hit CTRL-s in a regular xterm (which I used to do accidentally
before I figured this all out) your terminal locks until you hit
CTRL-q, I think. This sucks if you are new to the system. 8)
It also has scroll bars on by default, which rocks. I think I
also changed the color scheme to black-on-white to match everything
else on the desktop.
I think the bug you mentioned w.r.t. dialog boxes is a general dialog
box bug which is in the database, but my memory may be faulty there.
---
In general, I think it might be useful to have a clearly-advertised
way (perhaps a command and/or a menu entry) to reset a messed up
account's dotfiles to the system default.
I'm also wondering how users will get the neo-AUI login both during
the testing phase and in the actual release? I'm sure it will be
great fun dealing with users logging in on different versions of Gnome
which live in different Athena releases. 8)
There was also that idea of fixing the login sequence to be more
user-friendly. Has that been pushed off until after summer 2001?
From the left coast,
Beland
===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
MIT STS/Course 6 (EECS) - MIT Athena User Interface Project
===============================================================
