[367] in Athena User Interface
Re: Beta, system, and usability testing, p.s.
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Tue Aug 15 06:22:35 2000
Message-Id: <200008151022.GAA16256@No-Whammies.mit.edu>
To: aui@MIT.EDU, jlittell@MIT.EDU, kcahill@MIT.EDU, sbjones@MIT.EDU
Date: Tue, 15 Aug 2000 06:22:20 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
Sorry, yes, WebMoira is not a mail reader, it's an interface to
mailing lists. Other such interfaces include the listmaint,
mailmaint, moira, and blanche commands. 8)
With regard to further testing, I'm not sure I understand exactly what
you mean, Janet. I interpret the usability testing schedule to
consist of the following phases:
1. Formal usability testing in August or September. This involves
running through a fixed version of the procedures we discussed at the
meeting with Susan, and perhaps a few other "insiders", and then
running the tests on a number of students and perhaps other
volunteers.
2. Non-public beta testing. This is where we tell a select group of
mostly experienced Unix users (say, maybe SIPB, the OLC consultants,
and the rest of I/S) to use the system for daily work. We warn them
they may run into glitches, and that we may add (hopefully not break)
functionality as time goes on. We collect feedback about both system
and usability problems (basically, whatever they want to tell us).
3. Public beta testing. Let any Athena user who wants to participate
use the system, and collect whatever feedback they will give us.
Following this plan, there's no real way to separate the informal
parts into system vs. usability testing, since we're just giving it to
people to use and give feedback. We could give them directed
questions to answer, but I think we'd be interested in open-ended
feedback about both aspects.
You're right; doing *formal* usability testing on a stable system is
most useful. Right now, our system is stable as long as subjects
don't stray too far from the list of tasks we give them. Having
people use the system on a regular basis (and giving developers time
to work) during the term should iron out the most frequently
encountered bugs.
So it seems logical to come back and do more formal testing during
IAP, no? I'd certainly like to be able to go back and test some of
the things that won't be ready until then. And we might be able to
incorporate improvements into the Spring term opt-in public beta, if
we did testing at the beginning. (On the other hand, if we did it
near the end, we might be able to squeeze in Naulilus, the graphical
file manager, and Evolution, the mail reader, assuming these are
delivered early enough by the third-party developers.)
I think there will be plenty of time, and plenty of beta-testing to
stabilize changes betwixt IAP and summer. (Hmm, famous last words.)
-B.
===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
Got spam? Stop it at the source. http://spamcop.net
===============================================================
