Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!wuarchive!zaphod.mps.ohio-state.edu!ncar!gatech!bloom-beacon!eru!hagbard!sunic!sics.se!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.lang.c Subject: User input vs program input (Re: Simple question.) Message-ID: Date: 3 May 91 16:57:05 GMT References: <6131@gara.une.oz.au> <24528@well.sf.ca.us> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 145 In-Reply-To: ron@well.sf.ca.us's message of 1 May 91 05: 18:23 GMT 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 Naggum Software Electronic Text 0118 OSLO, NORWAY Computer Communications +47-2-836-863