[4836] in testers
Program launch feedback and launch speed
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Tue Jun 19 08:56:33 2001
Message-Id: <200106191256.IAA27778@Press-Your-Luck.mit.edu>
To: Abby Fox <ajfox@MIT.EDU>
cc: testers@MIT.EDU, aui@MIT.EDU, sbjones@MIT.EDU
In-reply-to: The events that comprise the history of the universe.
Date: Tue, 19 Jun 2001 08:56:24 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
Ok, here's the deal on feedback...
It turns out that the amount of time it takes to start a given program
is highly variable. It depends not only on the type of machine you're
logged in on, but also what else is going on at the same time.
I did most of my playing around on the O2 here on my desk. I did a
couple of trials both with the machine quiet and under load (namely
reloading cnn.com -- which takes tens of seconds -- in Netscape) to
get a range of startup times. These are measured in seconds from
click to any visible sign that the program is starting.
Time Program
(s)
1-3 xmh
1-5 gnome-terminal
1-7 gmenu
3-6 emacs
4-7 netscape
4-10 gnomecc
7-10 Any info page on the menus (with Netscape in the middle of
loading cnn.com)
Then I logged in on a Sunblade (what a cool name) and found that most
things took about a second or so to start up, but some big things
(like Netscape and Mathematica, for instance) took say, 4-7 seconds.
I said before I'd give the naive user literally about 2 seconds of no
visible activity to become worried that they didn't actually select
their target properly, and try again. (Usually resulting in two
copies of the application to start up, causing further confusion
and/or annoyance.) I also recommended using the most tasteful
slashscreen technology possible when feedback is actually needed.
The hourglass is nice, but when the mouse cursor is pointing at
anything but the root window (pretty common), you don't get the
hourglass at all. (I don't think that can be changed easily, can it?)
The slashscreen is unmistakable, and can be moved aside if it sticks
around long enough to get in the way of anything.
Now when an O2 (probably the slowest machines that will be in the
clusters) is under load, the splashscreen takes 1-2 sec to start up,
just under the wire. It's designed to do that quickly, though it does
actually slow down really fast apps (like xterm) by a second or two.
On the other hand, the user may perceive the computer as running
faster if they receive visible feedback sooner, on average.
On a Sunblade the experience is a bit different. When I start
something fast, like Emacs, the splashscreen pops up in the middle of
the screen for about half a second. Just as my eyes are focusing on
it, it disappears, and the Emacs window pops up in another corner of
the screen. It's a bit distracting; I'm sure user reaction to such a
phenomenon would range from complete apathy to complete annoyance.
(Performance on a Sparc 5 is molasses-slow no matter what one does, of
course, and feedback would probably always be welcome for novice
users.)
So the question is, what would be the best type of feedback for the
default in the release?
* Possible Solutions
1. Turn on splashscreen xalf for all menu items. Let users who
usually log in on fast machines and who dislike it to turn it off.
2. Manually enable splashscreens for things that we know are going to
take longer than 2 sec even on the fastest machines. Users wouldn't
be able to disable these slashscreens, though they would be able to
disable hourglass feedback in Control Center.
3. Same as 2, only enable an environment variable by which users could
turn off the extra splashscreens, as well. This might be accomplished
by making a wrapper script that would invoke xalf as needed. (Though
this might slow things down even further on slow machines.)
4. Come up with some kind of scheme whereby splashscreen feedback is
always enabled for large programs, but for small programs, is only
enabled on slow machines. The slowness of a machine could be measured
by simply determining its hardware type.
So to sum up, I need to know whether or not this list of programs that
start too slowly is still needed, and if so, if doing the measurements
on a *fast* machine, as opposed to a slow one, is the right approach.
Thanks!
Beland
P.S. - I love the new Dells. Black computers are beautiful. 8)
===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
MIT STS/Course 6 (EECS) - MIT Athena User Interface Project
===============================================================
