Classically there’s a tradeoff between the ease of typing something and the amount of think time you have to put into remembering what to type.

One thing I am annoyed by on too many blogs is the inability to tab from the comment field to the “submit” button, which forces a mouse event and a scroll event.

The war is long lost but I recall with fond pleasure how I blew a Word user away by using WP5.2 … ^F6-P boom And when I rolled out the functions I’d cobbled together with WP’s lovely macro language? Sonic boom. The key in that situation was that I had a large number of unique tasks and a small very number of tasks carrying a huge workload (MILSPEC change management). So it was ideal for hot-keyed macros: like shooting fish in a barrel.

For one thing, unless I’m reading passively or doing some flavour of CAD my hands are nowhere near the mouse. Or, to invert that, when I’m keyboarding I have to routinely suppress my resentment with reach, swivel, click, drag, select, click, select … interminable menus and options bla-bla-blah, and nowhere muscle memory comes into play. But even with that aside, to have to right click and then select Delete from a menu /after/ having dragged to select a block … I can outshoot that action stream using keystrokes anyday, if the app allowed me to.

I don’t disagree with the fundamental insight … far from it. But we’ve just barely begun to implement the foundational cognitive ergonomics. (I was gratified to see in one thread that Brad explicated his having moved Help to the upper right … cuz that’s where it is most often. When it works it works cuz it works. Tradition is sometimes/often arbitrary; life’s like that and we should sometimes just suck it up.)

Harold’s point about expert users is, I think, key. It’s merely foolish to impose a system that makes good use of habituation onto a newly arrived visitor. I’m quite sure that attentive study shows a clustering or quantum of user intention and expertise … until and unless we contrive some seamless continuum (a terrible distraction inspired by naive perfectionism) we should focus on differentiating expters from n00bs (no diss) and serve both well. “Intermediate level” sounds quite appropriate … so long as this isn’t just a maelstrum of fish/foul goat/sheep confounds.

Alternatively we can always fall back on the old TRW concept of making people think more like machines. There might be funding for that.
;-P

That way, you can have a learners/beginners UI to get people up to speed, then they graduate to the intermediate UI that assumes knowledge of things like C-s, C-o, C-q etc. And of course, if an application follows strong UI design guidelines, experienced computer users might be able to start a new program in the intermediate UI. Gosh! C-o opens a file in Excel too!

Then, I think there should be a choice of expert-level UIs. For example, VIM and Emacs have both grown together (VIM started small, light and fast, and Emacs stared with everything AND the kitchen sink), so that they both represent reasonable choices for a power-user’s text editor.

This is also one of the problems that web developers are working on (or working around). Google and others have started introducing intermediate level UI features in web apps (like shortcut keys), but try building a site that looks and feels like WoW…

And Bill’s comments too. They remind me of the LEO editor for Python which was always touted as having great productivity benefits if only your team would undergo the three month training required to use it properly. Not sure if it ever took off or could. But there’s something nice about the idea that LEO empowered programmers could outperform the norm.

I’m convinced that there are certainly productivity improvements available to power-users, beyond anything currently dreamed of, once we step away from the assumption that “ease of use” equals “1-to-1 correspondance between functionality and UI objects”.

As every nerd knows, real (interesting) productivity, comes from higher levels of abstraction. And maybe what’s really important about the outliner tradition (from HyperScope to MORE / UserLand / OPML to LEO) is that it remains loyal to this notion. When you collapse a block of text and ideas down to a single-line, you are essentially abstracting away from that detail and working with the higher-level description.

OTOH, the Xerox Parc tradition of the GUI and direct manipulation, lost this core ideal. (At least as it was spread via Apple and Microsoft, although obviously you can probably do all sorts of powerful abstractions via a Smalltalk interface)

I’m pretty sure that this insight is general. The really interesting innovations beyond HyperScope are going to be new ways of giving the power-users yet more abstract ways of manipulating their information. Either by folding more of it together as complex aggrogates, or allowing large-scale cross-cutting processing. (Maybe style-sheets in Word are the only other surviving popular example.)

But then maybe the Engelbart work isn’t focused enough on a particular context and associated method-of-use?

To relate this to a similar software offering, how important are the specific Compendium features compared to the process of IBIS?

And a big factor in the ChangeFunction is how critical the problem/pain is being solved by the new offering. Can you convince people that there will be a pay-back for learning to use HyperScope that compensates for the investment, compared to other uses of your time?

Let’s put it this way: if you were picking between 2 start-ups to invest in, how much weight would you associate with 1 of the teams using HyperScope? How does this compare to betting on a dogfight where 1 party has an F-15 and the other a Cessna?