[300] in Athena User Interface
Re: Current thinking on gZephyr
daemon@ATHENA.MIT.EDU (Richard Tibbetts)
Wed Jul 19 22:43:01 2000
Message-Id: <200007200242.WAA04776@hikari-no-ken.mit.edu>
To: Bill Cattey <wdc@MIT.EDU>
cc: aui@MIT.EDU, "Christopher D. Beland" <beland@MIT.EDU>, tibbetts@MIT.EDU
In-reply-to: Your message of "Wed, 19 Jul 2000 22:20:22 EDT."
<otRa7aoGgE6e17cZo0@mit.edu>
Date: Wed, 19 Jul 2000 22:42:55 -0400
From: Richard Tibbetts <tibbetts@MIT.EDU>
SUMMARY (this isn't long, but it has more than one point)
- Object/Model/View terminology
- The problem with zephyr
- A solution.
On 7/19 Bill Cattey <wdc@MIT.EDU> wrote:
> My point is, "Can we re-express the group messaging such that users can
> easily understand the button they need to press for what they want to
> do?"
>
> Why ever did 6.170 get made into an instance, but fenway made into a
> class anyway?
>
> How might we provide TWO buttons: [send to individual] [send to group]?
>
> Maybe we can't, but if not then it's because our interface is too wedded
> to the Zephyr protocol, and not wedded enough to user needs.
OBJECT/MODEL/VIEW TERMINOLOGY
A useful thing to consider here is the object/model/view paradigm for
looking at computers (and gui's specifically).
Take writing a paper:
LaTeX & emacs: M$ Word:
object: paper paper
model: type setting primitives type setting primitives
view: type setting primitives paper
In classic unix, view (the user's experience) follows model (the
programmer's abstraction). In GUI's, view should follow object (the
user's abstraction). Everyone understand object/model/view, at least
as I think of it? Good.
THE PROBLEM
Using these terms, the problem with zephyr becomes clear. The model is
obviously one of classes and instances. Using zwrite the view is also
of classes and instances. As a result, the object (what a current
power user of classes and instances) thinks about is classes and
instances.
For the novice user, however, the object is sending to a group of
people. Thus, it makes sense to design a system the way Bill described
it, with a more general "send to group" button.
The problem, of course, is all these zephyr power users. For one
thing, there are both classes and instances, and new users are going
to lose if they don't have a way to differentiate. For another thing,
the power users are going to stay attached to their old structure if
we try and change it.
A SOLUTION
Currently some groups use classes and some groups use instances.
However, apart from class MESSAGE and a few other special cases,
*class* refers to the group (sipb, assassin, help, rsi-talk, etc) and
*instance* refers to topic (or is not used).
The only reason people use instances is 1) because they have been for
a long time and 2) because class MESSAGE is logged.
Solution:
1) Create a GUI with a send to group button that sends to classes, and
prompts the user to enter a topic.
Groups which want to continue using their instance can tell their
novice users to send to (for example) group MESSAGE topic APO.
2) Encourage people to move from instances of class message to real
classes. Number one thing to do is to offer zephyr logging for classes
which want it.
FEATURES:
- No flag day.
- No sweeping infrastructure changes.
BUGS:
- Allowing people to log classes will likely create a political
problem for Ops. For example, if someone asks that class
seekrit-stuff be logged, how will Ops deal if the majority of
subscribers of seekrit-stuff don't want it to be logged.
Other bugs I am missing?
tibbetts
PS: I don't consider this to be part of AUI's job, but if Bill says it
is, then I guess it is.
-*- http://www.mit.edu/~tibbetts -*- finger tibbetts@monk.mit.edu -*-
