enag@ifi.uio.no (Erik Naggum) (05/03/91)
In article <24528@well.sf.ca.us> ron@well.sf.ca.us (Ronald Hayden) writes:
scanf() will always echo the characters, but getchar() won't. If
you're receiving more than one character, though, you'll have to call
getchar() multiple times, as it only processes a character at a time.
After having read the excellent replies by Henry Spencer and Steve
Summit, I would like to add that neither scanf(3S) nor getchar(3S)
have any idea where their input is coming from. They talk to an input
stream in the standard I/O library.
I think it's important to differentiate between input to the program
and input from the user, although the difference is not intuitively
evident in the athmosphere where primacy is given to user interfaces.
A program that requires some input will have to get that input from
somewhere, but shouldn't care from where, just read it and act on it.
Sometimes, it will be a user typing things on his terminal. This is
highly immaterial to a program which requires "some input".
A program which is expected to talk to a user will have to be designed
from a radically different point of view. We're talking about user
interface issues, human-computer interactions, all sorts of things.
All this fancy user interface stuff does is make it easier for human
users to provide the input to programs that could take the same input
from a stack of punched cards, and still do its job well.
Now [enter pet peeve], most programmers who were brought up in the
menu age can't for the best of themselves think of any other way to
write programs than to have them talk to the user directly. Be that
because they have mainly or only used machines which make it very easy
to confuse program input with user input, or other upbringing issues,
I don't really care.
A "computer", to many "modern" users, has come to be "something with a
user interface", and a programmer a user interface twiddler. Good
design, algorithms, security, all go out the window when "user
friendly display features" enter the game. There are literally
thousands of software packages out there which are 99% user interface
and 1% functionality because of this user interface primacy idea.
When people ask about "how do I get red background color", or "how do
I read a string from the terminal without echoing", they're really
asking about user interface questions. Most often, however, they cram
the user interface into their programs and they end up with user
interface bits and pieces all over the place. More often than not,
new functionality becomes dependent on existing user interface
abilities, instead of an adaptive user interface to a good design.
My question to those absorbed in user interfaces, is "how often do you
wish to write the same user interface"? Admittedly, writing a general
user interface package takes a hell of a lot of time. Admittedly,
writing a program or a system with a command-response input language
and then let it be back-end for a different sort of user interface is
difficult. Yet, this is what I think it takes to write good software.
There is an interesting parallell to this user interface vs program
functionality distinction found in electronic documents. SGML, The
Standard Generalized Markup Language, enables a total separation of
information content and presentational layout. SGML lets you define a
structure for the document, which is totally independent from how it's
going to look, if and when it's formatted for some output medium.
Then, some SGML-reading formatter can be informed (still in SGML)
about links between elements of the structure and elements of the
layout parameters. After that, the formatter knows what's best, and
SGML has done its job. The parallell is of course that a well written
user interface takes care of the presentation, while the well written
back-end program takes care of the information.
With electronic documents, the world has seen a period of intense
confusion between the functions of author and typographer. Many view
the advances made in forcing the author to consider typographical
issues during writing as a step forward. In the same way, many view
the advances made in forcing the programmer to consider user interface
issues during design as a step forward.
I saw this parallell only a few days ago when a group of publishers
were debating whether they should go for SGML, e.g. allow authors to
submit documents marked up with SGML, send SGML to printers, etc.
Most questions were related to what the user would see on his screen,
what the user had to type, and many other user interface related
problems. None were really interested in what they could do with
their books, catalogs, databases, etc, once they were able to rely on
the strengths of SGML. Disappointing, but also eye-opening.
To try to get back to the issues at hand, I would like to make another
parallell, in that typography is an art, that making a book look good
requires skills and experience, a sense of aesthetics, and a good
grasp of the function of the book, and that the same is true of the
user interface issues. It's a skill in and by itself, basically
independent of the underlying functions being performed. One user
interface can be as good as another user interface with the same
underlying functonality, just as a book can be read in draft form and
in one of several beautifully set finished versions.
So what I'm saying is that user interface issues should not be
confused with program design issues, that the programmer should think
about the functionality desired, not about what kind of user interface
will be used to call on it, that a user interface designer should
design an interface between user and program, as opposed to make the
program itself attempt to double as interface and functionality, and
that the issues encountered in user interface design are sufficiently
advanced that programmers and designers alike should make a deliberate
choice of with which they wish to work.
The computer user community desperately needs software which solves
real problems, has the necessary functionality, and does not break
when used. The same community also desparately needs good and more or
less common user interfaces which do not constrain them to one mode of
human-computer interaction.
Old, seasoned typographers become elated when a computer language
specialist like myself give their trade its well-deserved honor by
pointing out that I wish to make the job for the author easier, and
their job less tedious and more creative by deferring all typo-
graphical decisions to their domain. (They're _so_sick_ of authors
who have made up their mind about some typographical atrocity becaus
it looked "neat" on their PC-based desktop publishing system.)
Graphics designers have screamed in horror at the graphical user
interfaces that much software presents as its face to the world, and
users often cite "over-friendliness" as a problem in situations where
they use a given piece of software very frequently. Their expertise
is badly needed, and I wonder if we should design languages around the
concepts of client-server interaction (communicating sequential pro-
cesses) at the one end and human-computer interaction at the other. I
imagine that we would all greatly benefit from a cleaner focus on
these issues.
So, to answer the concrete problem implied in the message to which I'm
following up, you shouldn't use scanf(3S) or getchar(3S) or any other
part of the standard I/O library as the basis for the user interface
part of a program or system. They're intended for program input, a
domain for which they are excellently adapted.
This is not really a C language thing, so please consider moving the
discussion to some other newsgroup, if you have any opinions on this.
I'd love to hear from people who have thought more on this. (Also,
I'd like to hear about a more appropriate newsgroup for the kind of
themes I've tried to elucidate.)
--
[Erik Naggum] Professional Programmer <enag@ifi.uio.no>
Naggum Software Electronic Text <erik@naggum.uu.no>
0118 OSLO, NORWAY Computer Communications +47-2-836-863