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
next in thread | previous in thread | raw e-mail | index | archive | help
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. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607151123.NAA04607>