And the Lisa, and Amiga, and the Apollo, Xerox Alto, Lisp Machines,
Xerox Star, Three Rivers PERQ workstations.
None of those were commonplace. The home computer market share at that
time was about 90% MS-DOS, 9% Mac, and 1% Amiga, if not even more
tilted towards MS-DOS. The other machines you named had essentially
zero market share in home and office-cubicle settings.
No, they're much less productive.
That is incorrect, as I have already explained in detail.
Rendered onto a bitmapped display using a graphics card, often with
nice features like antialiasing that improve readability, rather than
directly rendered in a single chunky 8x16 pixelated fixed-pitch font
by the hardware.
This makes all the difference in the world. The system can display
more text, text that's more comfortable (and faster!) to read, and
text in arbitrary languages using arbitrary combinations of the tens
of thousands of characters in worldwide use, rather than less text
that's less comfortable (and slower) to read, from only one at a time
of a handful of 256-character code pages.
You're just not getting it are you, Pascal?
There is a single class of people for whom none of this applies,
though they are by far in the minority: blind people. GUIs are going
to be nearly unusable for them, and text-based interfaces (with an
appropriate screen reader or Braille-based display monitor, and speech
recognition software) only marginally worse than for sighted people.
Text-based interfaces might come out ahead; basically all of the
advantages of GUIs disappear, and the nonlinear nature of GUIs turns
from advantage to disadvantage when everything has to be serialized
through a screen reader or a moving fingertip anyway.
If you are blind, it would explain your attitude, but not your failure
to explain at the time that your assertions about which interfaces are
more productive were from the point of view (so to speak) of a blind
person. Instead you simply made those assertions as if they were
universal truths, equally applicable to all human beings, and stated
as such, those assertions are factually incorrect.
If you are not, then your remarks here are completely inexplicable.
Got a stutter, too?
In reality this is wrong.
No, it is not. Once again you have responded to detailed reasoning
with unsupported assertions, strongly implied personal attacks, and a
complete lack of any evidence or actual argumentation to support your
claims.
Here you are explaining that GUI are good for people with poor
vocabulary.
No, I am explaining that GUIs are good for people, period. The purpose
of using a productivity application is to do useful work, not to play
guessing games with it. A large vocabulary does not even boost the
odds of accurately guessing the synonym much, since the synonym
chosen, in cases where there were plausible alternatives, is usually
one of a few very widely known English words rather than anything
truly obscure. The problem, though, is with having to guess at all;
being more likely to succeed, or faster at doing so, won't beat the
success-chance and speed advantage of not having to even try.
This is part of a more general difference: usability boils down to
"the interface gets out of your way and lets you focus on actually
doing your job instead of being distracted by having to consciously
manage the mechanics of using the interface". Hands-on interfaces are
good at getting out of the way and letting you forget, consciously,
their mechanics. Talk-to interfaces are bad at this, as well as (and
partly because of) simply being slower to use. Why do you think that
voice command, while perfectly feasible now (and commonly used by
blind people), has still not taken off for use by the general
population? Because by the time you can say (or type) "delete foobar"
a sighted user with a modern interface could have already deleted
foobar themselves, and two or three other things too (if nearby).
There are even some people who think that watching
pictures all day long (eg on TV) dumbs the watchers down.
The argument actually hinges on the noninteractive nature of TV-
watching, not on the it-has-pictures aspect.
Furthermore, it has not stood up to scientific scrutiny.
Yes. But then you can says:
disconnect when no work done in 15 minutes
or at 18:00
or when downloading porn.
The latter are undesirable; if you don't want to download porn, don't
click on download links for any, and telling it to disconnect at 18:00
will sooner or later result in you losing a 90%-done, large-file
download someday because the download would have taken until 18:01.
Disconnect-if-idle is far better if you want to avoid it staying
connected overnight by accident.
And GUIs can do disconnect-if-idle. Many have for instance an options
dialog with something like this in it:
[x] Disconnect if idle for [15 ] minutes
where one checks the box and types in a number. Often there's a drop-
down menu for the most likely values, such as the first few even
multiples of 15 minutes.
Try to say such a thing by clicking on icons.
A classic example of a straw-man argument, assuming that the ONLY
means of interaction in a GUI would be by clicking on icons. Anyone
who has used a real actual GUI system would know that this is not
true, and indeed that GUIs are capable of providing every kind of
interaction text-based interfaces can provide, though not, of course,
vice-versa.
This is what really destroys your arguments here: there is nothing a
text-based interface can do that a GUI can't do, so it is simply not
logically possible for text-based interfaces, as a class, to be
superior to GUIs, as a class. (Except maybe for blind users.) And
since that particular impossible thing was your claim, your claim was
wrong.
And once you can say textual commands, you can easily put them in
script, in programs.
Why, so that the system can run amok deleting things without user
confirmation or intervention?
And no, you can't "easily" do anything of the sort. 99.999% of the
population are not computer programmers, and therefore cannot do that
at all. The remainder can program an application to do whatever they
want done, whether text-based or GUI, either by modifying an open-
source program or by writing a whole new one.
And once you've found a system to do it with GUI (there exist some),
compare the speed and expressiveness of the GUI and CLI scripting.
GUIs are faster and more expressive than CLIs, except on sufficiently
mediocre hardware. (Then GUIs are slower and more expressive.)
CLI and text based interfaces can do the same.
No, they cannot. There is no way to put email notification in the
bottom right corner of the screen, a program-launch menu in the lower
left, a text editor open to some file at top left, a file system
browser open to a particular directory at top right, one open to a
different directory center-right, and a small browser window left
parked at google center-left, in a CLI-based interface, and although
it's not quite *impossible* in a curses-based interface, it could not
be done well. The results would be infinitely more cumbersome to use
than a real GUI and would also have problems displaying very much when
a small grid of ASCII was subdivided into six even smaller chunks.
There are other text based browser.
All of which will suffer from the same problem: the vast majority of
web sites are designed for viewing in a GUI. Without a GUI:
1. Frames won't work in any acceptable fashion. The problems
described above and elsewhere in this thread with dividing a
curses screen into "windows" will all apply.
2. Tables will have problems, potentially severe depending on how
wide they'd have to be. Tables with wrapped lines are *ugly*, and
very difficult to parse.
3. Forms are obviously out of the question, since Web forms are GUIs
with command buttons, input fields, and the like.
4. You could maybe fudge a form submission with a manually-typed
www-form-url-encoded URL. This would be like using a hex editor
to edit a text file instead of a text editor. On top of that
pain, if the form requires a captcha be solved, you still can't
do it.
5. Most sites organize their pages using graphical dividers. Without
these, everything jumbles together and gets mixed in with
[IMAGE][IMAGE][IMAGE] and the like.
6. Links that are images all appear as [LINK]. Which of several
[LINK]s is the link to the sports pages? Hell if I know!
7. The above two items are not materially altered if the browser
uses different text to indicate non-link and link images. The fact
that it can only use text suffices to cause these problems
wherever sites use images that lack "alt" attributes.
8. Obviously flash-based sites are out of the question.
9. Ditto Java-based sites, sites that require Javascript, and so
forth.
For example, where a graphical browser aimed at a new site might show
three columns, with a photograph at the top of one with an embedded
(part of the image file) caption, and in all three a headline followed
by some story details corresponding to that headline, and a link for
further information consisting of a right-facing triangle with no alt
text, viewing this same site in a text browser will get you:
[IMAGE] Headline2 Headline3 Headline1 [IMAGE] [IMAGE] [IMAGE] Story1
Story2 Story3 [LINK] [LINK] [LINK].
Good luck figuring out what's going on there.
What causes this? First, the layout is done with tables. Second,
though the data is arranged in columns, tables are row-major in HTML.
So there's the image for story 1, then the headlines for stories 2 and
3, in the top row; the first story's headline in the next row,
followed by two empty cells; then a row of alt-text-less horizontal-
line images used as dividers; then a row of story summaries; and
finally a row of links. When output linearly by a text-based browser
lacking any support for tables, you get the above. With support for
tables you get something arguably slightly better:
[IMAGE] Headline2 Hea
dline3
Headline1
[IMAGE] [IMAGE] [IMAGE]
Story1 Story2 St
ory3
[LINK] [LINK] [LINK]
Ugly, but serviceable. Barely.
Still slower and more cumbersome to read, due to the formatting (the
line wrap is simulated here, based on the likely real lengths of the
headlines and summaries exceeding what will fit on one line of a
primitive display terminal), and also cumbersome to use by arrowing
everywhere and hitting enter. No mouse pointer, no scrollbars, no back
button, no amenities.
The web usability question is not relative to the text or CLI aspects,
but on the support for things such as Flash or Javascript.
Actually, no, it's relative to both.
Who talked of ASCII terminals?
You did. You were discussing the supposed lack of advantage of GUIs
over the text-based interfaces on pre-graphics software like Unix's
command shells and text editors.
So I am comparing the usability of a modern graphical workstation with
the usability of a Unix mainframe remotely accessed using a (real or
emulated) VT320 over a reasonably-low-latency connection.
The interfaces of the programs you are championing were designed to be
presented on precisely that kind of hardware configuration, and so
their capabilities will be constrained by the capabilities of such
hardware. I have used several of the programs named recently and so I
also know this by direct experience, but I bolster that eyewitness
testimony with a logical explanation why it cannot be otherwise.
If you think the comparison is somehow unfair, then you should
probably not have entered a donkey into the Kentucky Derby.
Did you even watch the URI I gave showing how lisp REPL may output
both graphics and texts?
Obviously no URI with the stated properties exists, since a VT320 is
incapable of displaying graphics, and a Lisp REPL will have been
designed for use with precisely that sort of hardware.
Your implicit claim otherwise is as absurd as a suggestion that
ADVENTURE had Quake-style graphics.
In actual practice, I've run into exactly two CLI-driven applications
with graphics: Maple V and Mathematica. Both have something similar to
a Lisp REPL in a GUI window with a display area above it that shows
results. Neither have especially stellar usability, either.
Importantly, neither predates modern graphics hardware or was designed
for potential use remotely via a VT320.
(I don't count games like Quake with drop-down consoles as "CLI-
driven" because entering commands into their consoles is not their
sole, or even primary, means of user interaction.)
[...] Users want to write code, fix the red-eye in
their photos, or whatever, [...]
This user doesn't want to write code, fix the red-eye in my photo, or
whatever. I want the computer to do that for me, so I can go to the
beach.
Tough. The computer can fix the red-eye in your photo, but it has to
know you want this done and to which files. So you'll need to use a
computer program with a user interface of some sort to make it happen.
If you want to actually be able to see what's going on it will have to
be a graphical interface.
The computer cannot write your code for you. The day a computer exists
that can is about four years before the arguable end of the world[1].
Yes.
it's the operating system that supports multi-tasking.
The operating system supports *program* multitasking. A window system
supports *user* multitasking. Pre-X-Window-System Unix workstations
supported program multitasking but the user could only work with one
at a time, and switching among them was extremely cumbersome, so the
user would tend to spend a long time in program 1, then a long time in
program 2, and so forth. The modern, fluid flow of user work among
several different open programs, with notifications of events like
incoming instant messages and mail, could not easily exist in that
environment, and even if it somehow occurred, could not have been
efficient compared to modern user workflows.
You might argue that users were more productive by being less
distracted, but it's not so; some work might be faster to perform that
involves using many different tools instead of just one, because the
user can more easily move their attention among those different tools,
and can more easily move data among them. Furthermore, if the user has
two tasks, one urgent and one non-urgent, and the urgent one is stuck
until an email bearing important information arrives:
* On a text-only system the user must sit in the mail program and
wait. If the user tries to work on the less-urgent task, they have
to stop frequently to manually check mail, which will slow them
down at the less-urgent task, and will miss the arrival of the
mail by, on average, half the time between mail checks, which will
slow them down at the more-urgent task. More frequent checking
reduces the latter delay at the expense of the former, and
vice-versa.
* On a GUI system the user can just work on the less-urgent task
until the you-have-mail chime, save, alt-tab, read the mail,
alt-tab-tab, resume the more urgent task, and have spent zero time
checking mail except when the mail had just arrived, and have seen
the mail almost instantly when it did arrive, for a potential gain
of up to several tens of minutes of productive work that day.
Of course, you might argue that constant chimes and glances at the
bottom right every few minutes when a spam arrives will waste time,
but a mail client is theoretically possible that lets you suppress
tray notification except for mail matching some filter criterion, such
as From: contains (e-mail address removed) or Subject: contains undefined symbol
error in foo.c make'ing FooLib on Suse 6.3 w/ glibc 2.1.1. You could
set this and forget it until the urgent mail (which would match the
filter, and be the only thing likely to do so) arrived.
Well after using GUIs for a few years, I came back to more textual
user interfaces, because I lose less time with them.
This statement is implausible unless you are visually impaired to at
least some extent. It becomes quite plausible if you use screen-
reading software and voice-recognition software.
So I will charitably interpret your remarks as equivalent to "I am
blind" rather than as meaning "I am a nut, idiot, or liar".
If you want feed back you can always order it.
Maybe I don't want to *have* to order it. Maybe I want what you claim
*you* want: the computer to anticipate my needs and do more in
response to less explicit input from me.
But I don't see what's disconcerting in having the computer execute
the orders you give it...
No, what's disconcerting is not knowing whether it succeeded or
silently failed, and not knowing whether it's working or hung.
Of course, silent failure is, by itself, a usability blunder of
considerable severity. It is also unfortunately rather common.
In any case, I don't spend my time watching clocks counting down.
Neither do I. I'd do something else, but maybe glance at it from time
to time. If I were somehow to wind up stuck with text-based
interfaces, I would not only not have such information in my
software's interface anymore, I would not even have the ability to
glance at something from time to time in the world inside the
computer.
When I give a command that will take time to complete, I order the
computer to do it in background and go on with the rest of my tasks.
As do I. But it's useful to be able to check on its progress easily
and quickly from time to time. If it gives estimates of when it will
be done, or you can glean one from the movement of a progress bar, you
can even judge when to check it again. If it's unreliable for whatever
reason (e.g. a web download) you can check it for not having hung/
failed and retry it fairly promptly if it had, not wait three hours,
then check only to find it failed during the first five minutes of
those three hours. Better still, it might be able to quietly alert you
when it had either finished or failed, without being too distracting
but also without needing you to switch to it from time to time to find
out about its progress.
One GUI Web browser (Google Chrome) displays a popup in its lower left
corner with progress bars for active downloads. It's not visible
unless that part of the Chrome window is uncovered, but it is visible
if you're surfing while you wait for the downloads, and you can do
other work (if it's web-based work) in the browser while keeping an
eye on the progress, and rate of progress in your peripheral vision.
You can't do, or have, anything like this with Lynx or any other text-
based software!
We've spent the last two days explaining you how you automate writting
code with lisp macros.
This remark both fails to address the above comment by myself and
contains an implied personal attack. Most illogical.
Your Lisp macros actually demolish your argument in favor of having
your text editor automate code generation tasks: it is far preferable
to have the Lisp compiler do this instead. Therefore the Lisp code you
edit in the editor will ideally consist entirely of non-machine-
generatable code, that is, only code that a human has to think
creatively about and then type. Whereupon the editor need not provide
any kind of code generation or refactoring tools. Macros should be
used to do those jobs instead! And the editor can't write those for
you either, or you'd want to use macros to do *that*, and so on ad
infinitum.
However, your comments about automatic code generation are not
arguments against GUIs. In fact they argue in favor of GUIs. You see,
not only can a GUI editor (or better yet, IDE) do these things, but it
can present these features to the user in a manner that will be far
less cumbersome to use. For example, in NetBeans one can type "private
int foo;" in a Java class's source code, right click, and see a
context-dependent list of likely useful actions including, in this
case (cursor on a field declaration), "generate getter and setter".
Another click and boom! Two methods. If you don't want the setter, a
quick click and drag and DEL keypress makes it go away, or (I think)
you can generate only the getter.
In a text-based application, by way of contrast, you'd have to type
"private int foo;", then type control-shift-alt-meta-I-sure-hope-I-
remember-this-long-and-cumbersome-keyboard-"shortcut"-F1, and then
type "foo" at a prompt. Then to delete the setter, hit down-arrow 17
times, shift-down-arrow four times, and DEL.
It's more efficient if you let the computer generate the GUI code,
from commands.
To edit the GUI form you need a GUI, of course. (If the form's state
is saved in some format other than as the actual GUI code that is the
desired final result, a text-based tool could conceivably be used to
read that saved data and output the actual GUI code. However there
seems no need for the extra layer of indirection here and the form
editor tool, which must be graphical, should be able to do this
itself.)
Notice how it's essentially vaporware. As I stated above, the day a
computer can program without human assistance is about four days
before the end of the world as we know it[1].
Good for them, they copied the feature from emacs.
The point being, the feature is not inherently exclusive to a text-
based application.
In fact, they were able to improve on it. A text-based application can
only let you bind such scripts to hotkeys and/or to typed commands at
a prompt (M-x doctor, for example, to invoke the "doctor" script that
comes with emacs). Word enabled the user to bind scripts (and in
earlier incarnations, macros) to toolbar buttons added to the GUI. The
latest version replaces the toolbar with a ribbon-bar that can also
have custom commands added to it. This means one-click access to user-
defined scripts! No need for any monkeying around with an escape
sequence and then typing (and possibly misspelling or forgetting) some
(possibly long) name.
We're not always editing lisp code...
Well, when you're removing red-eye from photos, you are going to need
an image editor rather than a text editor, and in fact will need a
GUI.
When you're writing mail or news, you are going to need Thunderbird or
something similar.
In fact, I can't think of anything else emacs might be good for
besides editing code or freestanding text documents, and I can't think
of a single thing it can do that other things can't do better.
There once was an exception: confusing and frustrating a newbie. But
I've since seen some Flash-based websites that would turn you white...
Regardless, you have not refuted my claims. Nor could you ever refute
my own personal experience, which is that the user interfaces of text-
based applications, especially Unix tools of any vintage, are
invariably either enormous messes of awkward chord sequences, or else
simply vomit-inducing.
[1] The argument goes as follows: once a software program exists that
is smart enough to understand computer programming and thus able to
automate computer programming, such a program can, and likely will,
decide to improve itself. At that point, such software largely
replaces human engineers, in the usual pattern with automation. Only
now the entities designing computer technology double in speed
whenever computers double in speed. If humans can double computer
speed every two years, and at some point in time an intelligent
software entity can do the same job at the same speed, in two years it
can do that job twice as fast and computer speed will double again in
only one more year. At the end of that year, it will be twice as fast
again and the next doubling will take only half a year. The next will
take only 3 months, the next six weeks, ... The geometric series
converges on T plus four years. Towards the end of that time, software
at least as smart as humans and enormously faster exists, and it
outcompetes humans. As Homo erectus gave way to H. neanderthalensis,
and H. neanderthalensis gave way to H. sapiens, H. sapiens will then
give way to H. cyberneticus. I leave whether that constitutes the end
of the world or not, and whether H. cyberneticus replacing us is like
our kids one day replacing us, or not, to philosophers to decide.
