Subject: RE: [hackers-il] Comments on "In the beginning there was the comm and line"

From: Chen Shapira <[email-masked]>
Date: Sun, 18 Feb 2001 09:31:39 +0200

> Someone who uses shell does not need to learn a new interface to do
> more complex things. But someone who uses Word often does. That's been
> my point from the beginning. You gave the example of you dad who knows
> Gnome/KDE but doesn't know shell. I am saying that Gnome/KDE is
> irrelevant to the shell discussion.

I'm not sure which is better:
Learning a difficult enviroment from the begining, to do even simple tasks,
and then no learning curve for more difficult tasks. (high learning curve in
the beginning, stabilizing later)
Or learning incramently, learning something new everytime you need a new
thing, but having almost no learning at the beginning.

> I don't know TeX. If you consider Word with all of its actions and
> scripting bindings, it might. Anyhow, that wasn't my point. The entire
> UNIX environment (including ls) might well be more complicated than
> Word, but it works entirely differently. With all of its thousand
> icons and menu items, you still don't have a simple way to say "turn
> all paragraphs into tables" from the GUI. I'd like to see a word
> processor that can. Maybe LyX can.

I don't know if any Word processor can do it, but I know how I'd design the
GUI for it.
Having more buttons of course would be a disaster (for reasons we both agree
on, the more buttons we have the less usable the program is) but perhaps
having a sort of drag/drop motion that would signal that would be a good
idea.

I'm thinking of Palm Pilot now.
You know, they have 2 input systems for words, their grafit handwriting way,
and the virtual keyboard one.
Grafit has a high learning curve, you need to learn a lot of hand motions
for letters, but later its faster and easier than the virtual keyboard,
where you have to memorize locations, and small/precise ones at that.

So this seems like a sweeping argument in favor of shell - high learning
curve and good benefits, except that I believe that learning motions and
directions (especially if the engine isn't too picky) is easier than
learning words and symbols.

And again I go back to my original argument - a gesture based UI will be a
great solution.

> > And see, Word uses the same file search as Explorer, find 
> and everything
> > else. With the same interface, so users can learn it only once.
> 
> That's good. Common dialog boxes is one of my favourite GUI
> features. Note that it's exactly the same way how UNIX shares searches
> -- be delegating the job to a separate and shared component. Maybe
> there are other such parallels that have not been used yet? I'm
> thinking that exposing the user to the high level structure of his or
> her document can be useful in GUI just as it is useful in textual
> markup. Do you think it can be done?

Certainly.
I think corel pagemaker does a good step in the direction.
The problem is that it is only high level structure editing (DOM
manipulation if you may). It sucks as a wp and most of the functionality is
*sob* patented.

> A flexible, simple, powerful GUI is better, but neither have it.

Here are my preferences:

1) Flexible - depends where, some decisions can be taken by a designer, and
most people couldn't care less about them (the little pictures on the
maximize, minimize, close, buttons). In many places consistancy is far more
important than flexibility, you can get used to anything, but you should
only get used to it once. On the other hand menus should be infinitly
consisten. and keyboard bindings.

2) Simple - yes, but a better term would be - "a correct learning curve"
where the value of correct would be determined by user testings

3) Powerful - ofcourse, while keeping the learning curve "correct".

4) Architecturally right: as we said, each component should be a seperate
process, with a consistent ui, capable of being reused withing scripts, with
redirecting, or as an object in a complete program.

I'd love to write on on Linux, but the problem in Linux UI is mostly that
there are too many of them, which violets the law of consistancy before you
even start. You have no way to decide "Consistant with what?"

Thanks,
Chen.

---

From: "Nadav Har'El" <[email-masked]>
Date: Sun, 18 Feb 2001 11:24:52 +0200

> thing, but having almost no learning at the beginning.

Let's take a case study: me. [Unfortunately,] a couple of years ago I spent
several months writing a very long and complex document in Microsoft Word.
I learned the various graphical features like autmatic TOC, references, and
stuff like that, but never used VB. Why? Remember, this is me, Nadav, the
guy who loves scripting and command lines, who started his computing experience
with a completely-GUI-less Unix machine (over 15 years ago), who trys to
learn every computer language he sees, and already knows at least N such
languages.

So, why didn't I learn VB? As someone (sorry, I lost the attribution) already
metioned, because there's simply no continuation between the "normal" interface
of Word and the VB interface. Let's say I've learned all the GUI tricks,
and now I want to write a macro that takes 10 files and prints them. How
on earth do I do that? It has nothing to do with any experience I already
have with Word. Sure, I can get a book (or look at the online help) and try
to learn how to do it, but it isn't natural. It's not like Emacs, where
you're forced to learn many "M-x lisp-command" idioms, and then it's quite
natural to write a macro that simply does several of them in a row, and when
you already know how to that you also look in the manual how to do an "if"
statement, and before you know it you have written a 1000 lines of Emacs
Lisp code to customize your editor (that's what happened to me :)).

So it isn't impossible to learn VB. Maybe it's even a great language. I don't
know. It simply isn't a "natural" extension to the GUI, and you don't learn
it unless you explicitly decide to do so.

By the way, there's a big difference between "natural" and "easy". When
someone learns, perhaps like a parrot, simple Unix idioms like
	ls -l
or	du | sort -n

It is a natural extension to write something like
	ls -ls | sort -n

Before you know it, you can do more and more complicated stuff! The VBA
parallel in good-old-Unix is perhaps AWK (and now, perhaps Perl): knowing
how to write pipelines using standard Unix utilities doesn't help much in
writing an AWK script: this is a completely new skill that you'll have to
learn. But there's one small (but important) difference: Most books that
teach Unix (I think) also have a chapter on simple awk usage, so somebody
who cares enough to read the entire book will also get an introduction to
awk. On the other hand, 95% of the MS-Office users I know (including good
programmers) never saw an introduction to VB, and most likely never will
use it.

> having a sort of drag/drop motion that would signal that would be a good

The huge number of buttons in MS-Word is a GUI disaster, and I don't believe
I'm the only one seeing that. Most MS-Word users have on their screen about
50-100 buttons, each one smaller than a single character, with cryptic
pictures on them. Does that remind you of anything? To me it reminds of the
pictographic writing system of the Chinese and Japanese. I consider the
alphabetic system more logical and natural (at least to me) - and the
"alphabet" equivalent in a GUI is a menu system - each operation [word] is
composed of a small number of menu movements [characters].
An alphabetic system can have a small number of shortcut symbols, like "&" for
"and", or "$" for "Dollar", but this number has to be small when compared to
the number of alphabet characters. Similarly a GUI can (and should) have a
toolbar, but the number of buttons on it should be small, say in the order
of 10 (or maybe maximum 20).

I think that when you have 50 small icons on the screen, it becomes very
hard for your brain to search for a specific icon. So you either memorize
their relative position on the screen, or move the useful buttons to a
specific position - in any case you don't actually use all those 50 buttons,
or use some of them so rarely that finding these operations in the menu
system will be quicker than searching for them in the toolbar.

When I wrote a GUI a couple of years ago, I used that philosophy: buttons were
relatively large and easy to see (I'd say about 5 times the area of MS-Word
buttons on-screen), and there were a small number of them (usually about 10)
displayed at a time. The users had all operations (say, 50 of them) in the
menu system, and were expected to choose the operations they most commonly
use and put them in the toolbar.

> where you have to memorize locations, and small/precise ones at that.

It took me about 1 hour to learn Grafiti (perhaps a little more to learn some
special, rarely used, symbols - I'm not sure I remember all of them even now).
So this "high learning curve" is very overrated.

One of the things I love about the Palm Pilot is how its user interface is
so refreshingly different from other systems I used in the past. I'm not
talking only about grafiti, and the fact that you have a touchscreen rather
then a mouse - another very interesting feature of the standard Palm interface
is it's non-modality: you're never "in a program" or need to "stop the program
and run something else" - you can switch in a second between programs (e.g.,
the calendar and phone book) and all the context that you had last time
remains. You can leave a game in the middle, and come back to see it exactly
as it were.

> consisten. and keyboard bindings.

To me, what you just said is true only for programs you use very rarely.
When you use one program very often and for a long time, e.g.,:
  1. You're a programmer and use the same editor (or compiler or debugger)
     all the time.
  2. You're a writer and use the same word processor all the time
  3. You're an artist and use the same graphic program all the time

Then you couldn't care less about this "consistency". If this program wasn't
consistent, then true, it would have been strange and take you a (say) week
to learn the different interface, but when compared to the years you'll be
using it, this week is negligable. On the other hand, configurability is
of great importance to you. If you find yourself, 10 times a day, wishing
that you had a button that, say, "changes a complete word to uppercase",
then you better have the capability to add such a shortcut.

-- 
Nadav Har'El                        |      Sunday, Feb 18 2001, 25 Shevat 5761
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Why are you looking down here? The joke
http://nadav.harel.org.il           |is above!