One of the beautiful things about certain obsolete technologies is the tight relationship between their shortcuts and scripting language. I consider ExBase and Lotus-123 examples that fall into this category. Newer mouse-based tools don't have a natural progression between mousing and scripting such that you have to both mentally switch gears to script the tool; and cannot as easily use a "record mode" to produce rough drafts of the scripts. Mousing and scripting are very distinct and very different animals in the newer tools. (Mouse-to-script features do exist in some tools, but the produced code is usually verbose and cryptic.)

Lotus-123 turned regular accountants into programmers by allowing one to use the menu commands as scripts. It was an incremental process to go from the menu shortcuts to automating processes by typing the very same shortcut letters into macro commands. MS-Excel ended this trend. (See Lotus case study under ComputerProgrammingForEverybody.)

ExBase was designed by people who didn't like unnecessary typing and it showed. Most commands could be abbreviated to the first four letters. A reduced need for punctuation, shift, and control keys also made it quick to use. But if you wanted more formal scripts, you just use the full words. Or, since most script readers knew the abbreviations already, you just pasted the command history into a text file, add parameters where needed, and it becomes a script. (Some dialects had options to expand the abbreviations I believe.) MS-Access is a dud in this regard. Your mouse-strokes have no reuse value.

In short, '''finger shortcuts can more easily be turned into scripts than mouse shortcuts'''. For this reason, I don't think the mouse has made me any more productive. The mouse does make new software easier to learn, but is not a productivity enhancer beyond the learning curve improvements. But since everybody works and thinks different, I'd like to hear other opinions on this.

--top

Well, one can certainly say that use of a mouse makes for much more difficult testing facilities and edit-test cycle.  And use of a mouse is heavily context reliant... e.g. the context of what is visible under the mouse at the time of click/drag/drop/etc.  Providing or ensuring this context is quite difficult in any sort of automation (be it testing or scripting).  But there are some things that are difficult to do without context... e.g. selecting a particular object represented upon a map - these things would be equally difficult to handle with keyboard commands, since you'd somehow need to create 'keyboard scripts' to find the target object anyway.  As far as scripting goes where the relevance of context is reduced: that comes down to how the scripting framework is designed.  I've written some configurable GUI stuff at work for primary menus, dialogs, and popup menus, but I tend to attach menus and buttons to scripts rather than vice versa, and it works quite well.

''I'd have to see a specific scenario for "selecting an object". If all objects have unique ID's, then "selecting" would be a matter of "querying". I'm tempted to call GreencoddsTenthRuleOfProgramming. -t''

---------
CategoryUserInterface, CategoryTool