spiffy terminals (was: printf, data presentation)

Brandon S. Allbery allbery at ncoast.UUCP
Mon Jan 16 03:57:00 AEST 1989


As quoted from <590 at dms.UUCP> by albaugh at dms.UUCP (Mike Albaugh):
+---------------
| From article <2117 at van-bc.UUCP>, by sl at van-bc.UUCP (pri=-10 Stuart Lynne):
| > Macintosh. Almost any user can be doing fairly interesting and useful tasks
| > with very limited training, but the cost of developing the programs for the
| > Macintosh is higher due to developing the user interface.
| 	And re-develop it for every system release.... :-)
+---------------

Hey, when Microsoft can't even conform to its *own* interface definition
(for DOS), you expect them to conform to an ID created by an upstart like
Apple?  Of *course* they didn't pay attention to any of the warnings in
INSIDE MACINTOSH about features that shouldn't be used.

And they've trained just about every programmer who's ever worked with DOS
to be similarly ignorant of warnings.  Is it any wonder that so many
programs broke when System 6.0 came out?  (N.B.  *None* of the programs I
use on my Mac broke when I upgraded to 6.0.0.  I never did understand why a
6.0.2 was even needed.  I guess it just goes to show that programs from
programmers one can trust are better.)

Sorry; flame off.

+---------------
| > The primary advantage of the Mac interface is it's uniformity across
| > applications, ease of use for non computer literate users and fast learning
| > curve.
| 
| so I have a bit to say about all this. My experience of the Mac is that
| simple tasks are indeed simple to do, without even looking at the manual.
| As soon as one strays from the sort of stuff covered in the tutorial, it kind
| of turns on you. I sometimes call this the "brick-wall" form of learning
+---------------

The gentle learning curve of e.g. Mac programs comes at the cost of an
extremely *steep* learning curve for the programmer(s) putting together the
interface.  I've noticed that menus and etc. are slowly getting better as
programmers become more used to the interface; and on-line help is also
improving (again, slowly).

Also remember that there is limited space for menu commands and the like.
Even on a Mac II, if you're doing enough things at once via multiple open
DAs.  And I, at least, find scrolling menus to be rather annoying.

+---------------
| 	Second comment. This system is pretty spiffy, as Mac's go. 16Mhz
| 68020 accelerator in an SE, with a Radius Full-Page Display. For the purpose
| of reading NetNews over a 1200 baud line, though, I'd rather have my old
| C. Itoh 101. A cheesy keyboard, 1-bit deep seriously ugly characters (yes
| a Mac can have scads of fonts, but 72 DPI make any of then small enough
| to get 80 columns seriously ugly), and the inability to keep up with
| _1200_ baud when re-painting seem a bit much to put up with when all I want
| to do is read the news.
+---------------

Nobody claimed that the Macintosh was the be-all and end-all of WIMP [ ;-) ]
systems.  (Or if they did, they're just plain wrong.)  It's probably the
cheapest one that works reasonably well (yes, I've used MS Windows)

+---------------
| 	Unfortunately, the end user will also have to "look at" a terminal
| which was (often) chosen for snazzy features and buzz-words, rather than
| clear, legible characters and a usable keyboard. Note, I am not anti-bitmap,
| anti 630 (never seen one live), anti- X-windows, whatevr. what I am is anti-
| Bells_and_whistles_bought_with_money_that_could_have_gone_toward_legibility.
+---------------

Which is probably why business users are buying Mac IIs, not SEs.  You can
get away with a larger font when you've got a larger screen to play with.
And, of course, terminals like the 630 have even bigger (and higher
resolution) screens which make for even better legibility.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc    allbery at ncoast.org (soon)
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery at hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser



More information about the Comp.lang.c mailing list