ajax
|
|
response 36 of 83:
|
Feb 27 18:14 UTC 1995 |
I agree wholeheartedly with that, John! As for specifics, in
addition to removing the ctrl-d info, just get rid of the entire
ctrl-d, ctrl-s, ctrl-q screen. Ctrl-s/q are great to know, but the
popular programs on Grex pipe output through a pager by default, so
they're not too necessary.
And make the kill and interrupt keys Ctrl-U and Ctrl-C by default,
and don't even bother asking about or explaining them. If it turns
out a novice can't type those keys, it just doesn't matter that much,
does it? Most pros can type the ctrl keys, can redefine them if not,
and most novices just don't need them that much...without them,
sometimes they'd have to wait for a slow program to finish, but again,
most programs on grex use a pager, and the interactive programs have
regular commands to quit. John's suggestion of making them easily
configurable later on handles cases where people do need them.
I walked my mom through newuser recently, and found myself telling
her what was important and what wasn't, in my experience. Being an
on-line novice, she otherwise would have written down everything, and
the volume is a bit daunting.
|
mdw
|
|
response 46 of 83:
|
Feb 28 11:04 UTC 1995 |
I think Grex is particularly likely to get some of the "el bizarro"
brand devices. A number of people have asked about using grex from
3270's & MVS!
I also feel, pretty strongly, that it's worth it for newuser to go
through those special characters. If they don't find out about
control-C in newuser, they never will. (Ask your average windows user
about control-C, if you dare!) I would also predict that, if the
section on special keys were removed, there would be a sharp upswing in
people trying to use cursor left to edit the input line. This isn't any
new debate- BTW - kite tried virtually the experiment people are
proposing here, with m-net. I think it can be taken as pretty much a
given that, if this is removed from newuser, people will NOT know about
those special keys. If anything, this is much more likely to be true
today.
One of the things I notice here, is a lot of people here are jumping to
conclusions from a very limited sample size. People are not all the
same, and just because user "a" finds it hard, or user "b" finds it
easy, does not mean it's either easy for all, or hard for all. The most
dominant factor in people's perception has nothing to do with grex or
the software at all, but rather, with people's interest in the system,
and their prior experience. Lack of experience is often not a problem -
note that nephi here had no problems. Compatible experience means
people find the stuff superfluous - note remmers & srw (both with
*years* of line oriented timesharing under their belts.) Incompatible
experience can make the experience incomprehensible; note that we have
almost no usenet bigots here, or windows & mac point & click people.
Despite all these obstacles, we have incontestable evidence that
something like 70 people/day succeed in creating accounts, and we also
have an amazingly low rate of complaints (except when it's broken - and
then people manage to complain with no trouble at all.) I think,
instead of jumping to conslusions, it's worthwhile to first step back
and look at it from a systems engineering standpoint, how the users,
steps and pieces integrate to make groups, processes and systems, and to
look at problem solution in terms of the whole.
I think people here are confusing the goals of making newuser easy to
use, and making grex easy to use. The two are not at all the same
thing, and some of the things people have indicated elsewhere that they
value in grex (conferencing, and, (i hope!) the diversity) - are in
direct conflict with some of the ways people are trying to make grex and
newuser easier to use.
From a systems standpoint, what newuser was originally designed for was
this:
user -> term -> direct dial -> newuser -> picospan
(I've simplified here - left out help, csh option, etc.)
what we have today, in many cases, is:
user -> mac,windows,dos,x,? -> telnet -> newuser ->
menu -> picospan
Now, if we look at it from this kind of systems engineering standpoint,
some of the causes of the many problems people are complaining about,
will become clear, and I think it will also become clear that some of
the solutions people have proposed won't really make the problem go
away, they'll just move it about.
For instance, one problem people have complained about, is why more
people aren't getting into the conferences. If you look at the above
system, you'll note that people go from menu into picospan. Now, listen
to what people complain about -- "I can't figure out what to do once I'm
in PicoSpan". There's no mystery in that! You've trained people to
*expect* to be told what to do, from the menu program, and then you
thrust them into an environment where they are expected to figure out
what to do on a more proactive basis. There's nothing wrong with either
system! Many thousands of people have learned how to use PicoSpan
without much trouble - including everyone here reading this response.
And menus too have their place, particularly on high bandwidth human
interfaces. But where you join the two - aye, there's the rub! In
attempting to solve the problem of people coming into grex who are used
to a high speed menu, we've successfully internalized a barrier between
people in menu, and conferencing, and we've also created a new problem
in that we're now pumping high bandwidth human interface stuff across a
low bandwidth network link.
Let's look at another problem - that of the "." problem. In the
original scheme, you'll note that people go from newuser into PicoSpan.
Newuser, PicoSpan, as well as ed, es, ex, ucb/mail, and even rcs, all
share one common pattern for text input - a dot on a line by itself.
Newuser is, in this original scheme, training people about text line
input (hence, all that garbage about erase & kill), followed by training
people how to answer questions, how to input several lines of text, and
how to issue commands ("done"). Just about all of those skills are then
used in PicoSpan, and most apply to ed,es,ex, and ucb/mail. Newuser is
also encouraging people to open up about themselves, and talk about
things that interest them. There is a single and fairly consistent
skill set being used in all of these programs. And perhaps people who
make it through all that will be more likely to participate.
Now, let's look at what we are talking about today: people run from
newuser, into menu - from there, they might get into pine, pico, or
PicoSpan. No wonder people don't understand why they've been taught
about line editting and dot - for someone who uses lynx, pine, and pico
- that line stuff must seem totally pointless. What's more - many of
the people using that "telnet" black box above -- actually, there's a
good chance it's actually lynx or freeport, pine, and pico, before they
even *see* newuser. No wonder they have differing expectations.
Some of the problems people have identified elsewhere in this conference
include: link congestion, system growth, system reliability, "problem
users", and getting more of the people on the system into conferencing.
By using the above systems models to analyze the changes proposed for
newuser, we see that, virtually point by point, the changes do nothing
to solve these problems, but on the countrary, make them worse.
So where do we go from here? Perhaps I'm completely off my rocker. I
don't think I am, but perhaps you do. Perhaps the problems we've
identified aren't really the problems we care about - perhaps we really
do care more about making newuser painless, than about people's problems
once they get online or link lag. Perhaps newuser should acquire a full
screen interface, and use pine to input multi-line input? Perhaps
newuser shouldn't even *ask* for multi-line input? *That* would
certainly make it simpler. Or, we could study it scientifically - have
newuser randomly select a different mode of operation for users, then
study the relative performance of users w/r/t several metrics, such as
number who make a response in a conference, number who use an editor
more than twice, number who become a member, number who use party,
number who need support assistance, number who drop out & are never
heard from again? Or, perhaps, we might want to scale back our
expectations a bit? I made a very deliberate effort to avoid making
more than a very few changes to newuser's user interface (down to and
including preserving the "Please wait 5 minutes" warning before a step
that takes about 5 seconds today), but even I can see things that could
be improved, although I think my list would be a mite different than
others here.
|
popcorn
|
|
response 49 of 83:
|
Feb 28 16:17 UTC 1995 |
(I'd like to get rid of the "please wait 5 minutes" in newuser now
that it really does go by quickly again.)
I'm not ready to respond to #46 on a point-by-point basis, but overall my
impression, from having walked co-workers and telephone-callers through
newuser, is that people *are* very confused by a lot of it, not educated or
socialized by it, and that it's a lot of information to throw at a person
all at once. New users are frustrated because it's so much to take in all
at once. Experienced users are frustrated by the volume of text, when all
they want to do is create a quick account, not wade through volumes of text.
Judging from the responses we're seeing from new users, I don't think
they're learning the socialization Marcus thinks newuser should be
teaching them. On the other hand, some of the folks I've seen who look the
most frustrated with newuser are the ones who wanted to create a quick
e-mail account and have no interest at all in joining the conferences.
Maybe newuser is better suited to people who are going to become conference
users. Which brings us back to the old question about what we want Grex
to be: a conferencing system, a multifaceted system, or something else?
Also, today's computer users have different expectations than the computer
users of yesteryear. Just because macho old-time computer users used
command line interfaces doesn't mean that the only way to access Grex should
be the old-time way. Today's users are used to being presented with easy
menus of choices, and Grex isn't going to be able to turn back the clock to
force today's users to do things the older, harder, way. If Picospan users
of yesteryear were comfortable using command line interfaces on-line, it's
because they were using them off-line as well. Today's users use warm
fuzzy windows and other friendly programs, next to which anything we do
on Grex is going to look difficult-to-use, but at least we can make things
as easy as we can. There's no reason to make users use a difficult
interface just to teach them to continue to use a difficult interface,
when, in fact, we can work to make *all* the interfaces easier to use.
|