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

From: Chen Shapira <[email-masked]>
Date: Thu, 15 Feb 2001 10:28:14 +0200

> I actually think Word is the perfect example of how linear interfaces
> can go wrong. It does *not* have four words -- it has probably has
> many hundreds if not thousands of menu options, icons and dialog box
> fields. 

This is caused by the fact that you have 2 words.
If you only had 2 words "this" and "there" you would need many small signs
with pictures to allow real communications.
Word has all those many signs and symbols to allow you to say many things
using 2 words.
More context sensitivity would partially solve the problem

> Yet your interface to it is very linear -- you do not combine
> commands together to create new and more complex documents, 

The fact that you don't know about Word Macros is your problem.
Just like the fact that my dad doesn't know shell doesn't make Linux a bad
OS.
I don't know about other users - but I have no problems creating
automatically many letters each addressed to someone else, from a template I
write once. Even if there's no symbol for it.

Of course GUI can't do everything, and command line presents a heavy
learning curve.
Thats why the best approach is to combine them.

> you simply
> apply one feature after another in the hope that it will all turn out
> well, while the poor software keeps trying to guess what you intended
> and present it that way. 

Why do you think Word does any guessing? each click has a well-defined
function attached.

> Any new feature necessarily means a new set
> of commands, and these need to be learned by users, and their
> interaction with every set of existing commands understood by both the
> users and the developers.

While a new feature added to a command line interface doesn't mean few new
--foo options?

> An illinear interface would have fewer commands, but would let you
> combine them as you work and teach it what you want rather than
> instruct it what do do. Word actually has a few of these, such as
> creating a document from a hierarchial organization, or its style
> system, but it seems like these methods are not the ones receiving
> most attention from the UI designers. A person's first approach to
> Word would be to start typing away and use the toolbar buttons to
> paint their text bold rather than design it while they work.

For one thing, having a program with bad GUI doesn't mean that GUI is bad.
For another, I think we can both agree that both GUI and command interface
can add their side to the usability of a program.
The point is how to combine them well.

> And VB scripting is another symptom of the problem... I don't the like
> the idea of having to learn a new language whenever I reach the point
> where the UI is no longer efficient. In Shell, I dont have to learn
> ShellScript in order to write more complex commands -- the same
> language I use for "ls" can be used for "ls | sort | grep" and for
> more complex scripts. Can't the same be done for Word Processors?

1) In windows you need one language - VB. you just have to learn it once,
not whenever... etc.

2) You skipped the fact that you need to learn a language of | & ; > >> &>
&1> etc. 
And things like ls, sort, grep, sed, awk, uniq - each with its own set of
options, many of which aren't similar to options in other programs. So you
need to learn about 30 diffrent filters and utils, and parts of the shell
feature. While in windows you achieve the same while learning parts of VB
known as VBA, and I claim that this knowledge extends easily to be able to
program complex scripts and guis.

You can look for "the super-easy guide to the outlook object model" to see
how neat VBA really is, when every program on your desktop is an object and
part of an api of an easy language.

Please note, that I'm not saying that the MS way is better, I'm saying that
its more similar to the unix way than you realise.

> I think so. The mouse was so successful because it mimics hand actions
> like touch, move, pick up, drop... More would be better :) 

I want to be able to call help by helplessly waving my arms in the air, and
to cancle a dialog button by pulling my shoulders to indicate "how the hell
would I know?"

To sum it up:
The point I'm trying to make is that GUI can add to the software usability,
and so can command interface and scripting, and better interfaces. The
difficult part is to combine them wisely, to add usability and not substract
from it. This is the real challange, and to meet that, we need to drop the
idea that one of them is so much better that it is the only right solution
and think how we can benefit from the combination.

---

From: Adi Stav <[email-masked]>
Date: Thu, 15 Feb 2001 11:57:28 +0200

> More context sensitivity would partially solve the problem

More conetxt sensitivity is a good idea and I'd like to see it, but
that is not the problem I have. I think drag and drop, context menus
etc should be powerful enough to create better GUIs right now.

> The fact that you don't know about Word Macros is your problem.

Yes, I know about Word macros. You can't really consider them good
solutions for user interface problems. They don't let you combine
actions to create more complex ones, they simply record what is more
or less an abtraction of your mouse and keyboard activity. You can't
record a "turn the following three paragraphs into three columns of a
table", and even if you manage the effort to simulate it with recorded
keystrokes it will be unreliable and unflexible. Don't get me wrong,
macros are needed features, but higher level flexibility is what I
wish existed in GUIs.

> Just like the fact that my dad doesn't know shell doesn't make Linux a bad

If he is using the GUI only, then of course the shell is irrelevant to
him. GNOME or KDE have nothing to do with the shell. But someone who
is familiar with the simple features of the shell will easily be able
to apply his this knowledge in issuing more complex commands or
write scripts.

> write once. Even if there's no symbol for it.

That's the way to go. Like styles and hierarchial documents. If all of
Word worked this way, and thet integrated cleanly and clearly with one
another, I'd be happy.

> Thats why the best approach is to combine them.

Yes... But how? Has anyone worked with LyX? I tried it but didn't do
any actualy work with it.

> Why do you think Word does any guessing? each click has a well-defined

Like auto-numbering. How do you turn it on? Turn it off? Only turn it
on sometimes? The last I tried it (Word '97) it was unusable for me
because Word could not know how to assimilate all the commands that I
gave it properly. So it tried to guess, and failed. Maybe if the Word
team worked more on it it will work better, but I want Word to be
flexible enough so that I can get what I want without waiting for
a full AI engine :)

> While a new feature added to a command line interface doesn't mean few new

An unneeded feature. A Unix utility is bloated if it has over 20
options, while Word has thousands. For instance, a --contains flag to
ls would be a bad idea, because the flexibility that already exists in
the system lets you do this without a special feature. I wonder if
word processors can work this way too.

> The point is how to combine them well.

Yeah :) 

> 1) In windows you need one language - VB. you just have to learn it once,

You need to learn the bindings and the environment of every
applications. And what I think is even more important is that you
don't interface with VB the same way you interface with Word. VB is an
add-on, interface-wise, and so is not as nearly as accessible.

I think scripting is great for customizing applications for
organizations and the like, but they don't solve much in user
interfaces.

> program complex scripts and guis.

Redirection is something you need to know the same way you need to
know about context menus and drag and drop in GUIs. They are the basic
building blocks of the UI language. Can't avoid them.

And it's true that UNIX command line switches are terribly
inconsistent (try GNU long options by the way, they ARE consistent),
but I claim that they are inconsistent exactly because programmers
wanted to add features rather than make the system flexible enough so
that the feature becomes obvious. For example, if it was the shell
that parsed the command line options rather than the programs, and
passed the results to the programs as configuration, consistency would
not only be complete, it would be obvious -- the same way consistency
accross UNIX in filename expansion is obvious.

> its more similar to the unix way than you realise.

Oh, they are both complex software systems that let users interact
with their innards. What I think the difference is that the UNIX way
of interacting with the innards the same way you interact with
anything else, while in Windows there are two or more layers of
interfaces, and it is very difficult to work with all of them at the
same time.

> to cancle a dialog button by pulling my shoulders to indicate "how the hell

And I want to wave my index finger and have the window focus change,
and scroll my word processor or browser window up and down by
waving. Also imagine drag and drop, changing dialog box options,
changing text appearance... 

> and think how we can benefit from the combination.

I never said that command line is inherently a good idea of that a GUI
must by nature be insufficient for complex work. Actually, I find that
most command line interfaces are terribly limited and linear (try
fdisk for example). It is only the shell that I like so much, but that
is a single implementation. Maybe the shell could have been done just
as well with a GUI, were it available.