From owner-freebsd-chat Sun Jul 14 12:16:30 1996 Return-Path: owner-chat Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01123 for chat-outgoing; Sun, 14 Jul 1996 12:16:30 -0700 (PDT) Received: from Fieber-John.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA01116 for ; Sun, 14 Jul 1996 12:16:27 -0700 (PDT) Received: from localhost (jfieber@localhost) by Fieber-John.campusview.indiana.edu (8.7.5/8.7.3) with SMTP id OAA02352; Sun, 14 Jul 1996 14:15:57 -0500 (EST) X-Authentication-Warning: Fieber-John.campusview.indiana.edu: jfieber owned process doing -bs Date: Sun, 14 Jul 1996 14:15:56 -0500 (EST) From: John Fieber X-Sender: jfieber@Fieber-John.campusview.indiana.edu Reply-To: John Fieber To: Joerg Wunsch cc: freebsd-chat@freebsd.org Subject: Re: FreeBSD keyboard In-Reply-To: <199607140713.JAA15291@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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. 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. 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. > 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. -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================