[285] in Athena User Interface

home help back first fref pref prev next nref lref last post

Re: GNOME 2.0/Helix for Athena

daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Fri Jul 14 12:27:49 2000

Message-Id: <200007141627.MAA05562@No-Whammies.mit.edu>
To: aui@MIT.EDU
Date: Fri, 14 Jul 2000 12:27:45 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>


If you're in any doubt that nothing usable is ever going to come out
of Gnome, log in on dig-dug in the test cluster and experience the
glory of Helix Code pre-release 2.  8)

Even with the rudimentary functionality that the AUI pre-alpha login
has right now, Athena is about ten times more enjoyable for me to use
versus the old default - or even with my customizations.  Seeing the
old Athena login is downright *painful* compared to what I'm used to
now.  I'd recommend switching over to my friends *today* if the thing
wasn't being destabilized by active development. 

Thomas is right; *any* mainstream IDE is better than none for Athena.

The only question in my mind is, which IDE is the right one for
Athena?  Sure, KDE is a bit ahead of Gnome - they already have a file
manager that kicks ass, and a couple of other things that are farther
along.  But Gnome shows all indications of catching up.

I think there is no danger of Gnome being left by the wayside.  It has
a successful company actively developing it, in addition to an
incredible amount of attention in the wider community.  It's Redhat's
primary IDE, and non-I/S folk around Cambridge (like LCS) are already
using it in the workplace.  If Athena doesn't go forward with Gnome
adoption, *it* will be what's left by the wayside.

If there's any question in the minds of those with the purse strings
about this project, we can give them a demo right now that will
convince them utterly.  Make them spend 15 minutes on Athena 8.4, and
15 minutes on Helix Code Gnome, and tell them to imagine how much
better Athena would be if Gnome were adapted to it.

I could show them, say, my current login sequence, which is probably
pretty close to what the default 8.5 will be, show off how nicely all
the existing Athena infrastructure still works, and demo the bits and
pieces we've engineered that are improvements on the old system.

If the real question is, "why don't we get a commercial Qt license and
do AUI with KDE" (which for me it is) then I would answer "because
Gnome and KDE are neck-and-neck, and we've already starting working on
Gnome."  I'd also put in a good word about how we have a really good
working relationships with various people working on Gnome and would
be throwing that all away if we switched.


With regard to Helix Code's offer...

What Helix Code can offer us is bodies.  Warm, brain-laden bodies for
hire, ready and waiting to customize their software for us.  

If anything, I think that the AUI project is understaffed - but then
again, isn't all of I/S?  Especially when the summer ends, we'll have
a ton of designs waiting to be implemented, results from usability
testing, and a system that's partway between vanilla Gnome and Athena
8.5.  And all of the people who are working on it will be going back
to school, and progress will slow to a crawl.

Right now, we're doing all the customization work ourselves,
submitting some number of bug fixes, and submitting most things
requiring more than a little work back to the maintainers as
suggestions.  We have a team of four people working at UROP wages and
an army of unseen developers giving us a free ride by freely
distributing their software.  

The alternative for MIT is to pay Helix Code consulting wages to do
customizations, or speed along improvements they'd probably get around
to eventually anyway.  Personally, I think it makes sense to do the
custom work interally, seeing as people know our systems and are
rubbing elbows with the people who helped create and are maintaining
them.  As for major mainline features we'd like to see sooner rather
than later - well, I would put at the top of that list file manager
and mail reader, two projects that are already proceeding full steam
ahead.  Better session management would be really cool, but I think
we'll scrape by OK on that for now.  On the back end, getting the
system integrated with the Athena build system and working on IRIX
seem to have been our biggest challenges, but I'm hardly an expert
there.

Actually, I was wondering why we're using vanilla Gnome 1.2 and not
the Helix Code distriution, which seems to be updated more frequently
and have some bug fixes the mainline doesn't.


With regard to the alleged show-stoppers:

 - Login time is now entirely reasonable.

 - File manager: We can show them gmc and say "Even though this is 100
times better than the command line for novice users, it will be
replaced by something even better come fall!  How much would you pay
now?"  Some minimal amount of work does need to go into gmc to make it
Athena-happy enough not to cause major frustration.  In fact, I think
we should go public with gmc as an interim FM...but that's a
discussion we have yet to have as a team.

 - Sawfish: Is currently kicking ass on two out of three platforms on
any given day.  8) Certainly stable enough for a smooth demo (or for
that matter, daily use) on Solaris or Linux.

 - Help browser: I like the Gnome help system a lot.  The biggest
problem with it right now is that much of the Gnome documentation
isn't installed.  And from a high-level usability standpoint, the IDE
approach is to make similar interfaces for similar tasks.  Thus,
displaying help-related hypertext should be done the same way as
displaying slashdot-related hypertext.  This is entirely appropriate,
and despite my reservations when Microsoft started pushing the idea,
I'm starting to look forward to the day when I have *one* display
engine which is my web browser, help systemm, file viewer, and kitchen
sink (but which is not Emacs).  The current help system also handles
info files, and is context-sensitive, which are absolute miracles
compared to Athena help, which barely deserves the name.


And on a meta-level...


I'm just today trying to get the component list updated so we can nail
down the list o' things that we have to ship with alpha, internal
beta, public beta, etc.  (I'll be in for cleanup day, and we all can
shoot the breeze about this in person...)

But I feel generally uninformed about the high-level direction of the
AUI project.  Do we actually have a firm date for an inspection from
the decision makers?  It would be useful to know now exactly who those
people are, and what criteria they will be judging the system on.  

And what role does usability testing play?  Does anyone seriously
think that the Gnome-Athena will be harder to use than the current
system?  I don't think we should waste a lot of time designing tests
to determine that.  I'd go about as far as "How easy to use is this
prototype compared to {Athena as you first encountered it, Athena now,
Windows, Mac, vanilla Linux, whatever else you've used}?" and leave it
at that.

As for usability testing for product improvement...I'm still wrestling
with exactly what questions will be useful to ask.  The problem is
that formal testing on unfinished components is generally not nearly
as useful as on a developers-are-happy-to-release-this version.  So
the testing procudure depends a lot on project progress, in addition
to how much we and/or users actually care about which icons are where,
etc.

-B.

===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
   Got spam?  Stop it at the source.  http://spamcop.net
===============================================================





home help back first fref pref prev next nref lref last post