Date: Mon, 15 Jul 1996 13:23:33 +0200 (MET DST) From: grog@lemis.de (Greg Lehey) To: jfieber@indiana.edu Cc: chat@FreeBSD.ORG (FreeBSD Chat) Subject: icons (was: FreeBSD keyboard) Message-ID: <199607151123.NAA04607@allegro.lemis.de> In-Reply-To: <Pine.BSF.3.94.960714091516.1889A-100000@Fieber-John.campusview.indiana.edu> from "John Fieber" at Jul 14, 96 02:15:56 pm
index | next in thread | previous in thread | raw e-mail
John Fieber writes: > > On Sun, 14 Jul 1996, J Wunsch wrote: > >> The problem arises, however, that even for frequent users of such a >> recognition-based system, the efficiency cannot grow beyond a certain >> point. > > I think that is a minor problem. In fact, studies show that > although people percieve keyboard shortcuts (recall) as being > faster than pulling down a menu (recognition), when actually > measured, people perform about the same with both. Granted, this > cannot be fully generalized to cover all tasks, nor is it fully > representative of a unix style command line interface. Also, > percieved difference are critical in marketing whether they are > real or not. This may the case when the number of choices is small. When you consider the number of key combinations which Emacs recognizes, menus become very inefficient. I introduced my wife to Emacs just a few weeks ago, showing her the menus at the top of the screen, but she prefers to use the key combinations because it's easier than navigating all the menus. > The real problem that drives unix power-users ape is that current > recognition based interfaces typically have hard-coded > non-extensible functionality. Nobody has devised an *efficient* > visual method for assembling and saving new functionality from > existing components as in the unix pipeline model with shell > scripts. The research on this front falls under the category of > "programming by example" and is for the most part just that: > research (I can provide some reference for anyone interested). > Macro recording has been around for quite a while, but beyond > fairly trivial tasks, a regression into old fashioned textual > programming is required. Granted. As I said in another message, menus aren't flexible enough. > I'd love to find a visual regular expresnion builder; I'm always > having to re-read the manual page whenever I want to construct > something non-trivial. Now *that* would be nice. Maybe it's even doable. >> When looking at the icon and toolbar etc. forest of the typical >> application of these days, i still believe it's rather done for optics >> than to improve recognition. > > I think toolbars should default to being hidden. They are most > useful *after* someone has used a piece of software for a while > and discovered which are the most frequently used features, some > of which may be burried in a deep menu or dialog box. I suspect > toolbars are mostly confusing to a new user, and the icons are > usually a joke. I'll bet the icon artists couldn't even pass a > "what does this icon mean" test. Hmmm. I'm not sure that I agree with you on this one, but it's not that important anyway. If the functionality were easier to understand, the icons would be too. Greghome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607151123.NAA04607>