Date: Fri, 27 Feb 1998 14:24:54 -0600
From: escargo@anubis.network.com (David S. Cargo)
Message-Id: <199802272024.OAA11430@brutus.network.com>
To: corey@itlabs.umn.edu, dang0019@tc.umn.edu, bhokanson@che2.che.umn.edu,
I had tried to send this out via our listserv, but I don't think I got
anything back.
Here is my list of problems that I think we need to address. (I'm not
going to suggest solutions for everything yet. Some solutions suggest
themselves.)
1) Confusing navigation.
All of the testers I saw thought that the tabs implied that operations
could be performed in any order. We know that certain orders make more
sense than others.
2) Memory load.
I realized as I was writing my report, I realized that the project page
required that people remember that there were questions there, and that
the answers might be important. People ran into problems doing multiple
mailboxes because they forgot that there was a relevant question on the
project tab.
3) Unnecessary detail.
The working directory could be considered to be an installation
parameter, not an operating parameter. In that sense, it is unnecessary
for it to appear.
4) Mixing concerns.
The current Archive tab mixes two things together (although they are
related, they might be better off separated). The two things are what
appears in the generated HTML pages, and the directories where the
generated pages will go.
5) Incomprehensible choices or lack of feedback.
Consider that the choices that people make on the Archive tab have no
visible effect. There is no feedback for them. The choices are
incomprehensible because the users can't see what they do. I hadn't
thought about this as a lack of feedback issue before, but it clearly
is. (We COULD provide a preview button that would show a mockup of
what the current selections would do.)
6) Other lack of feedback.
The generate tab has some feedback on it (those disabled entry fields).
However, the fact that they are on the generate tab means that they are
NOT where they originate.
7) Terminology or using the users's language.
I talked this over with some of you before. We called our application
the Mail Archive Converter. The problems with this that I see is that
we really don't define what a "mail archive" is, and users couldn't be
expected to know. If we called it "mailbox converter" that would be
better. Given that, our application doesn't have "convert" on it
anywhere. I should have named the "Generate" tab the "Convert" tab.
I said I wasn't going to suggest solutions, but in this case I will.
I think we should call our application the Mailbox Web Publisher. I had
talked with Brad about creating an Tk animation that shows letters going
out of a mailbox onto a spiderweb. (I think there's an animation
available on the widget tour, and if there isn't I know where there's
one based on the tcl plugin at http://sunscript.sun.com/plugin/cup.html
that takes 20 lines of tk.) This animation addresses another problem
that appears below.
This crosses over into our poster and open house materials. I suggested
to Brad that if we had the graphic that was part of the animation, we
could use the picture of the mailbox, the letter, and the spider web as
a graphic for our poster and on a brochure for the open house.
8) Lack of a conceptual model.
The user tests seemed to show that the testers "didn't get it" in terms
of what our application could do. The one tester I saw who looked at my
web site that had pages generated by hypermail commented favorably about
what he saw. The problem is that our testers had no concept of what we
were trying to accomplish. I think that if we grabbed people by the
eyes with our animation, showing a message going out of a mailbox and
onto the web, even if we are using a metaphor, they would have more of a
conceptual model of what we were trying to accomplish. Called the
application the Mailbox Web Publisher would link more firmly with users
ideas of what's possible.
That summarizes what I see as the major problems. My model for problem
solving starts by first defining the problems. There's not much to be
gained by generating solutions if we don't know what the problems to be
actively addressed are.
If we can reach some concensus on the problems via email today or
tomorrow, I can revise some code on Sunday.
dsc