On Jun 23, 10:36 am, Martin Gregorie <[EMAIL PROTECTED]> wrote: > However, there's a case he missed, probably through never using a CAD > system. All the good ones can be driven either by mouse, or by > non-chorded key sequences or any combo the user likes. The essence of > CAD is very accurate pointing but all too many mice move slightly when > clicked. Fortunately a decent CAD system offers the possibility of > purely pointing with the mouse and doing everything else with the other > hand on the keyboard. The result is both fast and extremely accurate.
Actually, what I prefer in (2D and 3D) visual design apps is the ability to snap to some kind of grid/existing vertices, and to zoom in close. Then small imprecisions in mouse movement can be rendered unimportant. > An interface design point that nobody has yet mentioned here is that > there are four different types of user that map onto a grid: > > casual dedicated > untrained 1 2 > expert 3 4 > > I first ran across grid this in "Design of Man-Computer Dialogs" by > James Martin and its been very useful in systems interface design. > > The problem with almost all current GUIs is that they are aimed at types > 1 and 3 users - this certainly applies to Windows, OS X and Gnome > desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed > at type 3 and 4 users. The problem of course being the complete exclusion of type 1 users. Everyone starts out as type 1, and I don't think type 2 occurs in practise. You'd have to be some kind of religious nut to be "dedicated" while still "untrained", rather than only as a result of experience. Apps that provide no traction for a type 1 user will not see much adoption except in an environment of immersion, mentoring, or desperation. I wonder which of the three explains the majority of emacs users, and of vi users, and whether those prove to be the same one. :) (Actually, there'll be a single or a small number of class-2 users: the original developers, who presumably became dedicated before having much experience *using* the tool. Their experiences are atypical however, and their knowledge of the internals probably means they're type 4 by the time they actually use it to do more than debug it. Unsurprisingly, never experiencing it as a type 1 themselves they tend to be inconsiderate of future type 1 users...this is normal, and requires effort to avoid, in much the way blinkered views of stuff and seeing what you want to see can be normal, and efforts like using double-blind studies may be needed to avoid bias in evaluating, say, a new drug. That such efforts are needed should not be seen as disparaging the programmer or the drug-studier, but as merely reflecting human nature, and as a simple pragmatic requirement if one is to maximize utility.) > Its very difficult indeed to design an interface that suits both > untrained and expert users. One with a bog-standard UI but also a "console" or command prompt, scripting language, and customizable bindings? Funnily enough I can count the software I've seen with that range of capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand. Here's the list, in fact: ROM BASICs and QBasic (on any really ancient microcomputer, and old pre-Windows PCs, respectively; the former came with printed manuals and you could just run prepackaged software from disks very easily; QBasic had mouse and menu support, but an immediate mode command line. You might not count ROM BASICS as as friendly, due to the lack of menus and such, but then at that time in history NOTHING had menus and such! And comprehensive introductory use manuals came with those, and with pre-Windows PCs (DOS also had a decent and easy to navigate help system). Most other BASICs and programming environments more generally lack an integrated environment with an immediate mode prompt. Eclipse actually sort of does, but the evaluate line can't be used really arbitrarily and I've found it touchy, and rarely use it. Hypercard (found commonly on old Macs; had a command prompt you could access to directly communicate to an interpreter). Fractint (fractal graphics making software for old pre-Windows PCs; had a similar prompt, accessed by typing 'g', but also had extensive help and menus readily controlled by stock keyboard commands such as the arrow keys, and later a Windows port with menus and mouse support). Quake and descendants (yes, the games. Easy to just use the menus and play the game. Advanced users could hit ~ to drop down a console and do a few things. Really advanced ones made config files to rebind weapons and make chat macros to fire off a taunting sentence with a single keystroke -- no more embarrassment getting fragged while typing it in longhand in mid-game. Super-advanced ones got at the QuakeC and made bots, flag-capture mode mods, and other enhancements and utilities. And sometimes cheats.) There's probably some more out there, but I've yet to see such desirable things as: * The paint program with the usual interface, except you can also do stuff like hit ~ and type "resample files:c:\foo\*.jpg width:640 height:480 preserveAspectRatio:true doNotEnlarge:false" * The word processor with the usual interface, except you can also do stuff like hit ~ and type "format leftIndent 2 where paragraph begins 'Quotation: '" * The word processor with the usual interface where I can define logical styles, then change them in only one place and affect every pre-existing occurrence retroactively. * The word processor with the usual interface where I can also view an underlying markup representation and hand-hack that, and which likely has the capabilities of the first two as a direct consequence of the implied architecture. Only please, proper functional markup, not macros like LaTeX or (shudder) winword. I don't want it to be possible for documents of dubious origin to make it start sneezing, or any of the general ugliness that follows TeX around like its shadow. Documents that look as nice when displayed and printed, sure, but just as nice under the hood if you please. * Something as powerful as Mathematica, but with a more straightforward basic-use interface as well as access to a fancy interpreter. * The operating system where you can do powerful stuff with a command line and a script or two, but can also get by without either. (Windows fails the former. Linux fails the latter.) * For that matter, the operating system whose GUI takes the concept behind OLE to its logical conclusion, and lets the user separately choose and configure their text editing, this-editing, that-editing, whosit-viewing, and the like components, and those components are used in building more complex applications. All the alternatives would of course adhere to a common interface for a particular sort of component, of course. (An OO language like Java lends itself to this, what with interfaces and inheritance and dynamic class loading!) When I run my browser and go to GG to make a post I'd get a text entry field that was actually my choice in a box, with the usual capabilities such as spellchecking available, and its own little menu bar at the top and suchlike. I'd be able to save the contents to disk without futzing around with the clipboard and launching Notepad, and later reload, in case the web site was prone to eating the odd submission. My Jave IDE would display code in the same editor (the interface should therefore support the using application externally driving coloring/highlighting, as well as jump-to-line and similar capabilities). Of course the editor wouldn't itself be Java-aware, which might not be useful, for example composing a usenet post. Instead it would provide a variety of abilities to the embedding application, which may or may not use them. What it would provide being its particular internal search, spell check, key bindings, etc. > About the closest I've seen have been > keyboard driven menu structures which have been designed so the user can > build their own "command sequences" that traverse menu levels without > showing the menus, as long as items are selected correctly from each > level. Many CAD systems approximate to this but I've yet to see a > graphical desktop, IDE, or editor menu structure that came close. The bog-standard alt, this, that sequences on Windows "come close"; they do make the menus display, but otherwise they do exactly what you want, and you can ignore the menus blinking around in your peripheral vision. When I go to save a file with unsaved changes my first inclination is ctrl+S; if the app doesn't support that the very next thing I try is alt, f, s, before resorting to the mouse. -- http://mail.python.org/mailman/listinfo/python-list
