Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!sunic!news.funet.fi!
klaava!kypros!wirzeniu
From: wirze...@cs.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.unix.user-friendly
Subject: Quick notes on user-friendly Unix
Date: 5 Oct 1993 20:39:16 GMT
Organization: /usr/lib/news/organization
Lines: 114
Message-ID: <28sm1k$g49@klaava.Helsinki.FI>
NNTP-Posting-Host: kypros.helsinki.fi
Some things that a user friendly Unix would need, in my opinion. All of
these have probably been mentioned already, but I thought I'd collect
them together and add some thoughts of mine.
* a GUI user interface
This is required because all the users want it. Even if it
isn't _really_ required, having to deal with a text-only
environment gives many people an instant "hey, this is
difficult" reaction. (Many of the same people enter a
"super stupid" mode when they encounter anything that has
with computers to do, but that is the topic of another
discussion.)
Also, since people will assume it friendly if it uses a
mouse and has windows, it doesn't matter as much what the
rest of the system is like. About the only other requirement
is that it looks good.
* consistent user interfaces
Consistent user interfaces make the system as a whole
easier to learn and use.
Even traditional Unix has some consistency, e.g., options are
introduced by a hyphen, and are always at the after the command
word. (There are exceptions, but the most commands obey this
format.)
Some systems can't even agree on the option character or
the placement of the options -- plenty of MS-DOS commands
work differently from each other in this regard.
Unix also has consistent globbing (the shell does it, not
each command), and a little consistency in commands for
moving around (there's hjkl from vi, and ^n^p^f^b from emacs).
How could a consistent user interface be established? If we
accept my first premise -- that a GUI is required -- and if
what I hear about COSE (or whatever), Open Look is dying and
Motif is the choice of most of the commercial vendors. While
I have little experience with Motif (a bit more with OL), and
can't say anything definitive, I assume it is good enough as a
GUI, so that it's mostly universal acceptance shouldn't be that
bad a thing.
The only really bad thing I know of Motif is that it is a
commercial product. A large amount of the Unix software many
people use is freeware, and using Motif might prove to become
a hindrance for the development of well-accepted X freeware
(if Motif becomes universal and most freeware isn't Motifish,
it's not going to be attractive to the users). Hence, I would
expect that the development of a source-code-compatible freeware
Motif library would be a very good thing to happen.
* efficient user interfaces
Efficiency in this case means that it shouldn't require a lot
of work (keypresses, mouse clicks, mouse movements) to do the
common things. Most GUIs are very bad at this -- even common
things require moving the mouse and possibly selecting from
several menus. (A typical example is textedit in Open Windows
which requires going to the submenu of a popup menu to be able
to select "Cut". It's probably doable with a keyboard shortcut
but those aren't self-evident from the menus.)
* no loss of synergy
One of the major attractions the Unix command line has is that
it is so easy to combine tools, and that most tools work
so easily together. This results in a lot of synergy: the system
as a whole is much more than the sum of the tools it contains.
A user-friendly Unix should not loose this synergy. Although
all the metaphors used with the command line need not be carried
to the GUI, and although new metaphors for GUIs may need to be
developed, the basic principles should remain. Each tool should
do one thing, but do it very well, and the tools should be
usable together.
* good documentation: tutorial _and_ reference
Even with megabytes after megabytes of man pages on disk and
meter after meter of books on the shelves, the quality of
documentation for Unix is not what I would call good.
One problem is just the volume: there's too much documentation,
which makes it hard to know where to search for more information
until one has read all of it (and it will take a while until
one reads a few tens of thousands of pages).
My opinion is that no more than a few hundred pages of general
documentation, plus a reference manual that covers all the
commands (the man pages, if you wish) should be required.
The documentation should also be relatively easy to read: there
should be a (as in one) book that one can read, and then assume
that one has the required knowledge for using the system. Now,
for most systems, the documentation is scattered all over the
place.
I'm not certain what format the documentation should be in. Sometimes
I think I prefer Texinfo-style documents, sometimes man pages and
separate tutorials.
* good tools for browsing documentation
On-line documentation is a must, and something rather more
sophisticated than your traditional man is needed for
browsing it.
--
Lars.Wirzen...@helsinki.fi (finger wirze...@klaava.helsinki.fi)
It doesn't matter who you are, it's what you do that takes you far. --Madonna
Path: gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!
cis.ohio-state.edu!bounce-bounce
From: f...@cis.ohio-state.edu (Thomas A Fine)
Newsgroups: comp.unix.user-friendly
Subject: There's more than one answer
Date: 5 Oct 1993 16:01:07 -0400
Organization: Ohio State University Computer and Information Science
Lines: 128
Distribution: world
Message-ID: <28sjq3INNsrb@soccer.cis.ohio-state.edu>
Reply-To: Thomas A. Fine <f...@news.cis.ohio-state.edu>
NNTP-Posting-Host: soccer.cis.ohio-state.edu
I think it's obvious that the level of complexity of the task you are
doing dictates the learning curve. For example, compare MacWrite to
FrameMaker. MacWrite is much easier to use than FrameMaker, and does
the job for most simple documents. But eventually, you reach a point
where you say "I need this, and MacWrite doesn't do it". FrameMaker
will likely do it, but the cost is that this one fringe feature you need
is included with lots of other fringe features that other people need,
and because of this FrameMaker is much more complicated. FrameMaker
actually has a nice user interface - it's just that there is so much
more there, the clutter makes the learning curve much steeper for
FrameMaker than for MacWrite.
Since different users have different needs, there is also a need for
different levels of user-friendliness. Basically there are two major
categories of people that need to interface with the computer. Those
that need all of the tools UNIX provides, and those that don't.
THEM THAT DO
------------
Those that need the tools are programmers, developers, and sysadmins.
these people need the command line interface. There's just too many
tools to include in a GUI. Imagine a menu of every UNIX command you
have in your path. I have 2494 commands in my path. That will fill
a menu structure either too wide, or too deep, or both. If the menu
is that big, you just have to know where things are. Which is no
different than the command line interface: I just have to know which
commands I need. Even the menus wouldn't explain what each item did.
You'd have the same problem with the options for each command - huge
sets of checkboxes without any meaning.
Regardless of whether you have a GUI or a command line interface,
the problem is only when you don't know how to do something. So
what's really needed here is an easier way to get up the learning
curve. What new users generally consider the most unfriendly things
are the lack of responsiveness of the shell, and the poor (for them)
documentation.
A few people have already mentioned the need for secondary help. Here
at OSU, we've started using the World Wide Web as a hypertext structure
for providing documentation. The applications TkWWW, and XMosaic both
provide good interfaces. Our intended audience is new majors who will
be using UNIX in most of their courses at OSU, but have no prior
experience. The only task that remains is to complete the
documentation in an organized fashion. This turns out to be a larger
task than you might think, and we've barely made a dent. But WWW is
certainly a realistic choice thats functional today.
The other thing that can be done is a better shell. For starters, tcsh
can be configured to do a heck of a lot. Command completion and file
completion are just the start. It can be configured to do different
completions with different commands, for instance rlogin could be
configured to give a completion list of host names that could be used
for its second argument. Most important, a precmd alias can be set up
to indicate the success or failure of each command as it happens. The
brand new user will appreciate seeing "Command succeeded" after they
type "rm foo", rather than seeing nothing. Tcsh also will provide
configurable help for every command (defaults to the man page), command
line editing (of course), and spell correction.
The work needed to configure tcsh in this way is not trivial. But it
only needs to be done four or five times before we get it about right. :-)
Once it is done, you'd have something that even the tradition-bound
experts would be interested in.
There are other small things that can also be done to help the new user.
Obviously, they don't need 2494 commands in their path when they first
start. They should start out with an environment set up for them already,
but something they can modify as they gain experience.
THEM THAT DON'T
---------------
The other major class of user is the person who never needs to see UNIX
as long as they live. They have an application or applications which
they need, and these applications run on UNIX machines. They don't
care about awk, or mount, and they'd prefer to avoid ls, rm, and cd.
First let me say that these people exist, and have every right to use
UNIX boxes. I find it insulting that people feel UNIX is only for
those "in the know". UNIX is useful because it is a powerful software
development environment. If you aren't developing applications under
UNIX, even user-friendly applications, then I don't know what you are
doing.
Currently it is largely up to the application to provide an interface that
doesn't require UNIX. But once the application is written, someone still
needs to set up an environment where a user can select these applications,
organize files, and other things. And some applications may not play well
together. This is one of the most unexplored areas of making UNIX
user-friendly. The two things needed the most here are a file manager
so the user can organize his files outside of the applications, and a
communications protocol that applications can use to interact with the
file manager and each other (for instance drag-n-drop, notification of
file changes).
At OSU-CIS, we are working on a major project in this area. We offer
programming courses to non-majors. The idea for these courses is to give
a general overview of how computers are programmed. These students will
likely only take one or two computer courses, so it is not in their best
interest to be inflicted with UNIX. We've developed an environment that
hides UNIX 100% - a command line is never seen by these students. We do
have a file manager, and applications that all know about a few basic
protocols. Drag-n-drop works with every application, and some
applications have strong interactions (the bugs found by the compiler(s)
are displayed in the editor). I think that it is important to note that
this system is user-friendly largely because of how little it actual
does. The small learning curve contributes more to the user-friendliness
than does the GUI. (This environment will be available to the public
in January of 94, it is currently being tested on 125 students).
Another major area of work for this type of user is system administration.
People continue to hope for a turnkey UNIX system, that can be administered
by an amateur. These systems exist as standalone systems, but once you
get into the networked UNIX business (especially heterogeneous networks)
we're still miles away. Again, this is because of the level of complexity
involved in heterogeneous network administration. It's worth noting that
the reason Windows NT doesn't provide for multi-user use is that the
sysadmin work of the multi-user aspects in combination with everything
else was deemed to complex for the casual user.
One very significant issue I haven't mentioned yet is portability. Every
system has its own idiosyncrasies - slightly different command line options,
different paths to executables, different output formats, different system
calls and library calls, different window systems, different window managers,
and on and on. In our case we avoid the problem by using Tcl/Tk, which
provides a consistent layer on top of everything else. Perl does the same
for system administration tasks. But it is still a big problem.
tom
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!sunic!
news.funet.fi!klaava!kypros!wirzeniu
From: wirze...@cs.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.unix.user-friendly
Subject: Re: There's more than one answer
Date: 5 Oct 1993 20:47:54 GMT
Organization: /usr/lib/news/organization
Lines: 20
Distribution: world
Message-ID: <28smhq$gdr@klaava.Helsinki.FI>
References: <28sjq3INNsrb@soccer.cis.ohio-state.edu>
NNTP-Posting-Host: kypros.helsinki.fi
Bcc: lars.wirzen...@helsinki.fi
Thomas A. Fine <f...@news.cis.ohio-state.edu> writes:
> The other thing that can be done is a better shell.
Absolutely. The traditional shells -- sh, csh, and probably ksh
although I have little experience with it, and most definitely zsh --
are all way too complex as programming languages. About the only
shell I've seen that is actually nice to program in is rc (from Plan9).
Imagine, not having to worry about whether $foo expands to something
that has star in it: in rc, the expansion is not re-scanned, so it
stays as one word, and does not have to be quoted.
Csh in particular is too complex for ordinary use. Even if many people
don't ever have to write shell scripts as such, most people do have
to update the moral equivalent of .profile and that requires knowing
at least the basics of the syntax for shell scripts. rc's syntax is
much simpler than that of the other shells.
--
Lars.Wirzen...@helsinki.fi (finger wirze...@klaava.helsinki.fi)
It doesn't matter who you are, it's what you do that takes you far. --Madonna