[405] in Athena User Interface
Re: Beta, system, and usability testing, p.s.
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Fri Sep 8 12:13:36 2000
Message-Id: <200009081613.MAA02150@Press-Your-Luck.mit.edu>
To: aui@MIT.EDU
Date: Fri, 08 Sep 2000 12:13:33 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
tibbetts:
> 3) The reason mail gets sent to aui@mit.edu and not cc'd to everyone
> else in the world is because it is one member of the team telling
> the other member of the team that he is wrong. This short of thing is
> best handled internally. In the political climate we are working in,
> it needs to at least look like we have our shit together. Please don't
> keep forcing us to retract statements.
So as I understand it, the usability team exists to work with
developers, providing and helping us obtain useful feedback on the
usability of programs at all stages of their construction. As such, I
consider Susan to be a "part of the team." She's there to provide
useful input while we're in the process of making decisions, so it
seems inappropriate to exclude her from that very process.
With the client relationship we have with the PSB, I can understand
people being upset; I was obviously underinformed about a lot of
technical issues.
tibbetts:
> 1) If we are never going to support a piece of software, and we have
> decided this as a team, then you (and anyone else on AUI) are not
> allowed to tell people to run it. Especially not usability people who
> might decide they like it. Not. Never. Not even a little bit. Not even
> with a "we know this sucks". There are only 2 possible outcomes,
> either they will get a negative impression of it and have a lower
> opinion of AUI or they will like it and force us to support it. No.
> Don't tell them about it. Not. Is the negative nature of this
> statement obvious yet? Good.
I have a problem with this idea in principle. Using gmc helped Susan
get a better idea of what a graphical file manager would be useful for
in the Athena environment, not to mention (as she says herself)
increased her opinion of the project. She's an intelligent person,
and knows that the "real thing" is yet to come, and she's hardly
"forcing us to support it."
In general, just because we don't have plans to support something
doesn't mean we shouldn't consider changing them. This isn't one of
those cases, and so far, no one's tried to change our minds about
that. I think that refusing to tell people how to run software in
that way is a.) counterproductive for the organization and b.) rude.
But anyway, back to the actual problem at hand.
tibbetts:
> There is a lot of sketchy elisp code out there on Athena that
> probably only works with emacs. I agree with Brad that the support
> overhead is not worth it to get a toolbar.
I had suspected as much.
yak:
> You make two assumptions:
> 1) Emacs is not easy to use.
> 2) There is something easy to use that is a valid replacement for
> emacs.
>
> I disagree with both of these.
Perhaps "easy" is an entirely relative (not to mention subjective)
term. Certainly many new students (including myself) find learning
Emacs to be frustrating and time-consuming. Witness this comment from
the recent I/S survey:
> Yes, emacs may be a versatile editor / browser / file manager /
> whatever the hell else it is, but it is completely unintuitive and
> I'd rather spend the time it takes to learn how to use it learning
> the COURSE material instead.
or:
> It took me a long time to learn what is available on athena and how
> to use it. I did not use athena for anything but email and zephyr
> for most of freshman year. I did not even know about file sharing
> or how to use emacs.
A lot of people use Windows for word processing precisely because they
are turned off by the steep learning curve of the currently available
software. (Most people didn't seem to know about Star Office and
Applix.) I ran into one student who preferred using pine on a
non-Athena account for this reason.
Actually, watching her try to use Emacs was very instructive. It was
not, as I would have thought, the menu system that was giving her the
most trouble. She could save and exit the program, even though she
had to hunt through all of the menus twice in order to do. ("Look at
this! This means nothing to me," she said in annoyance at the
"Buffers" menu.) She was thoroughly confused when she started to
save, but interrupted herself to browse the menus and try to run the
"Read Mail" command. She got a perplexing "minibuffer is already
active" or somesuch error, and was unable to run the command. She had
also previously gotten stuck in a help mode by hitting Backspace,
which she was unable to exit.
If only she had known the super-secret cancel command, C-g, which is
not on any of the menus. (Unfortunately, she was also under the
impression that "C-g" would have meant "C dash g" because she had
never read the help screen you get when emacs starts up. This is
because you don't get this screen when you type "comp".) When she did
manage to save, I asked her where the file went, and she said,
"someplace magic?" even though she had typed in a file name. The
confusion arose because emacs' cwd on startup is ~/Mail/drafts. She
would probably have greatly benefitted from a graphical save dialog
(that say, shows you the other files in the directory you are saving
to, and where they are relative to your homedir) rather than a
single-line interface.
This person had been a student at MIT for an entire term, and has her
own web page which she wrote in raw HTML, and she knows how to use ls
and cd, she told me.
yak:
> 2) There is something easy to use that is a valid replacement for
> emacs.
This is the crux of the matter - what if there *isn't* anything easier
to use? Yes, people find Word easier to use, but is that a "valid"
replacement?
I'm going to take a step back and look at the sort of tasks people
generally need to accomplish when they're moving text around:
- Write e-mails
- Make quick edits to a file
- Write a simple paper or a long/formal letter
- Write a thesis
- Make a presentation
- Write a professional paper
- Create a publication (newspaper, magazine, advertisement)
- Make a flyer
- Program
For complex documents (thesis, professional paper, publication), or
for control freaks like me, a "desktop publishing program" is in
order, and Athena has Framemaker (and alas, not Quark Express).
For long documents mostly containing prose, or for people who want to
throw together an uncomplicated flyer, a "word processor" would be the
right tool. Star Office Writer is on the fast track to becoming the
supported solution (TM) here. Presents is the associated slide-making
tool.
For programming, Emacs probably wins hands-down in most arenas, but
the exact choice is of course up to the professor of a class or the
programmer personally.
What we have left are the quick file edits and hastily written
e-mails. The sort of thing that lots of people use frequently but
don't want to invest time to learn how to use.
Gnome's solution here seems to be gedit. I originally didn't like it
because it does word wrap quite poorly (i.e. not at all, when you
write to a file). But perhaps this is fixable.
When you look at it, is has the sort of things you might need. The
basics, plus find-and-replace, spell check, even diffs and splitscreen
views. At first, I thought that if you want something that's
extensible with plugins, like gedit, why not just use Emacs, which has
a far greater variety and selection?
The answer is:
- Emacs has too many features and appears confusing and has difficult
to navigate documentation as a result
- Most of the things Emacs has that gEdit doesn't most people don't
need
- gEdit has a much easier to understand interface. There aren't five
million secret keybindings to memorize, everything you can do is on
the menus, and it's a lot harder to get stuck in a weird mode you
don't understand. The menus and keyboard shortcuts are consistent
with other common (esp. non-Unix) pplications.
So while it might make sense for me (who has involuntarily become
familiar with the program's eccentricies) to compose my mail, edit
files, and code all in Emacs, that is probably not the case for most
new users, or users who frequently use Windows or Mac applications.
To my thinking, then, a gEdit-like application should appear in
contexts where users need to quickly edit files or compose short
messages. Star Office and Framemaker can be advertised for their word
processing and desktop publishing roles, respectively, and Emacs can
be safely left to Course 6.
Once our system is up and running, I think that "default" users will
actually open files they want to quickly edit using the graphical file
manager. (They could create new ones by selecting File/New/Text File,
as well.) So, I would argue that having any launcher whatsoever on
the panel for a text editor is perhaps unnecessary. But if there were
one, I should think it would need to be gEdit-like by default. (I
would probably change it over to Emacs for myself, twisted and broken
as I am.)
Office, Frame, and Emacs would be available through our
easy-to-navigate menu system, however that might be organized.
Not that anyone is actually going to read this far, because they'll
probably be too busy flaming about something in the first four
paragraphs. And not that the usabiltity team will be able to respond
to these remarks, since they've pretty much missed out on the whole
conversation.
Back to my little corner I go.
-B.
(Not that I'm bitter or anything.)
===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
MIT STS/Course 6 (EECS) - MIT Athena User Interface Project
===============================================================
