[253] in Athena User Interface
Re: session management
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Fri Jun 30 12:35:40 2000
Message-Id: <200006301635.MAA01286@No-Whammies.mit.edu>
To: aui@MIT.EDU
Date: Fri, 30 Jun 2000 12:35:26 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
This past week, I couldn't help but ponder the session management
mess. I came up with some ideas about how my very own personal ideal
interface-for-everyone should look. I'm not sure how close this comes
to the maintainer's vision, or something that's easily implementable
given the current code base, but since we're putting time into fixing
the system, I thought I'd weigh in from my own wacky little usability
corner. So for what it's worth...
I think of the session management system as my own personal maid. It
cleans house when I log out, sets things up for me when I log in, and
can even remember where I left things one day, and put them all back
there the next. (Subject to this particular maid's amnesia streak,
blah.)
Most importantly:
- I want to be able to review exactly what the maid's current
instructions are.
- I will be annoyed if this electronic maid does something I haven't
explicitly told it, unless it's obviously necessary. (Like
starting Gnome system processes, restarting them if they crash,
etc.)
- I will also be annoyed if the maid and I don't get along, and it
thinks I told it to do/not do something, and I disagree. Thus, the
management contract should be as explicit as possible.
- I will be annoyed at the maid if it doesn't do something I did tell
it to do, unless I have a disclaimer that something might not be
possible.
One major shortcoming of Gnome is that there's no way for the normal
user to configure a logout sequence. Personally, I need to be able to
do this to ensure that my SMB filesystems always get unmounted (or
else great nastiness will result).
Another problem is that the "Non-session-managed" list (to be
reincarnated below) does not allow full shell syntax. To get around
this problem, and also to make maintainence easier (I can include
comments, etc.) I simply made an entry containing "tcsh
/mit/beland/.startup.gnome" and threw together bits from the standard
Athena startup (zwgc&; from -n -t; xterm&) and the things from my old
.startup.X that weren't handled by Gnome. This ability might be cool
to document (HOTD!) but there may or may not actually be any value to
doing it by default. A better editor would be nice, but people who
have shell-complexity startups probably like editing dotfiles by hand
anyway.
In any case, I suggest the following dialog - or something like it -
as a remedy for the confusion we've been experiencing. I think that
any scheme which obeys the "maid" contract I outlined, or which obeys
some equally or more intuitive metaphor would be successful with
novice users.
Human psychology aside:
I think that the "maid" metaphor is a good one because some variant
of it naturally occurs to humans as a first mental model of what a
system like this might do. The current system might correspond to
some other subliminal metaphor, but it's not one that human brains
can easily fathom, which is why the I/S staff (because they are
skilled) can operate the system but (because they are still mostly
human) don't like wrapping their brains around it. Users who don't
have a knack for such things are much more likely to experience
enough confustion to be unable to operate the system in the way they
would like.
---
Display: ( ---pulldown menu--- )
(Startup Programs )
(Currently Running Programs)
--------------------------------------------------------
PRI Program
--------------------------------------------------------
| 20 (icons) screensaver-properties-capplet |
| 20 (icons) background-properties-capplet |
| 30 (icons) sawfish |
| 40 (icons) gmc |
| 50 (icons) gZephyr |
| 50 (icons) Netscape |
| 50 (icons) from -t -n |
| |
| |
--------------------------------------------------------
[Add] [Edit] [Delete] [Make startup programs the same]
[ as currently running programs]
[Save list as...] [Load list...]
( ) 1. On login, only run commands on the Startup Programs list.
( ) 2. On logout, remember which programs are running. Next time I
log in, start these programs *in addition to* any commands on the
Startup Programs list.
( ) 3. On logout, let me chose from #1 or #2, above.
(Note: Options 2 and 3, and the "Make startup programs the same as
currently running programs" button will not work with
non-Gnome-compliant programs. Please add these to the Startup
Programs list manually.)
---
Implementation notes:
1, 2, and 3 are mutually exclusive; 1 should be default.
"Delete" should become "Terminate" or somesuch when displaying the
list of currently running programs.
---
We would probably add a few more icons, to show the type of program
(respawning, config, etc.) and state (starting, running, etc.) Very
useful would be a "Gnome Compliant" indicator, which theoretically
should be possible to build by stealing the existing "hey program,
give me the command to restart you like you are now" code.
"Add" should allow users to add items from their start menus.
Currently, fully working versions allow you to DND program icons onto
dialogs that ask for a command-line, thus filling the box in with the
proper invokation. This is totally backwards, it's non-ovious, and
it's very hard to mouse. There should be buttons to spawn a
filesystem browserm (as used elsewhere) and a Athena locker-menu
browser.
Having a generic "program chooser" - something that hunts around in
the menu system and maybe the panel, too - is generically useful.
Gmenu has the exact same problem (only worse, since DND doesn't work)
making is a big pain in the ass to throw together custom menus from
bits and pieces from other menus. (Cutting and pasting icon/menu
entry attributes is the best I could do.) I'm suprised Gnome doesn't
have this already. (Maybe I just haven't found it?)
Also, making the function of the respawning, etc. icons much more
obvious would be a good thing, as well as letting people know that
certain things - like gmc and panel - are "supposed" to be
auto-restarted if they die or are killed, and what they as free
citizens of the planet can do to change that.
The save/load functionality could be to either explicit file names, or
an internal named list...right now, I guess there is just One True
List, and there's no way to save that state (say, to experiment with a
new setup) other than grovelling dotfiles.
That's all on session management from me...
-B.
