Raskin book on UI and radical data thoughts

[Chris Pressey]

On Tue, 01 Apr 2003 21:07:37 -0800
Jay Nelson <jay@REDACTED> wrote:

> Paulo mentioned Jef Raskin's book on UI.

I'm not sure what to make of Raskin's claims.
>From http://humane.sourceforge.net/the/not_an_editor.html :

"Commands never become invisibly hidden deep in a menu structure, and
can be invoked at any time, just as in command-line systems"

What I take from this is that commands do indeed stay invisibly hidden -
in a man page or help file.  Not exactly a great leap forward.

"but you never get locked into modes"

This seems to go against the idea of THE's "LEAP mode" as described in
http://www.businessweek.com/technology/content/jan2003/tc20030122_7027.htm

So I guess the operative word is "locked" rather than "mode".  Is his
position that modes, once entered, ought to be immediately canceled by
any user action that isn't addressed by the mode?  Hard to tell.

More from the BusinessWeek review:

"At its heart, THE is a command-line system, but it adds a key element:
visibility. The user should see information only when needed."

I don't see how this conflicts with drop-down menus, in fact this seems
to be the very idea behind why menus drop down or pop up.

"Raskin accomplishes this simply. The cursor is represented by a
flashing blue block. Within the blue block sits a single letter or text
command such as space (indicated by a black dot) or a tab (indicated by
an arrow).  Why is this useful? Think of all the times you've chased
phantom paragraph commands with the backspace key in an effort to
realign sentences and eliminate shortened lines. There's also the havoc
wrought by a forgotten tab. In THE, you see the tab by mousing over the
space without having to flip back and forth between viewing modes."

I'm tempted to say, "big deal" - even ol' CygnusEd on my Amiga 500
allowed you to make tabs visible (and IIRC spaces too.)  The only
innovation here is that it now happens on mouseover.  Whee.

I'm also tempted to go one step further - it's tabs themselves that are
flawed.  Tabs *as part of the text* are a huge mistake.  Tabs should be
part of the layout, which ideally should be seperate from the text. 
Personally I never use tabs except where I absolutely have to
(<<grimace>> Makefiles.)

So, while I'll give him due credit for the terms he's coined, and while
he seems to have the best of intentions, I think I'm a bit nonplussed by
Mr. Raskin's actual ideas.

Of course, my reaction isn't based on working with THE; I don't have a
Mac handy.  But even that's a little suspect - if *all* modern GUI's are
"fundamentally flawed" then certainly there's no good reason for him to
base his prototype on one particular system or another... ?

> I may have to try to find a copy of the book because some
> of the ideas seem familiar to what I have been thinking about
> lately.
> 
> "Perhaps we don't need applications at all. This revolutionary idea
>   is explored at length in the book. In Raskin's world, instead of
>   buying software applications, we buy application-independent command
>   sets that plug into our general user interface. The command sets
>   would work with transformers that change content from one data type
>   to another (allowing you to check spelling in a graphic using
>   optical character recognition, for example).
>   [...]

I'm still hedging on this, for two reasons.

One is, to me, application = command set.  This isn't a very radical
change.  It's not like applications will disappear, only that they might
be packaged more loosely.  Erlang's definition of an application (e.g.
stdlib is an application) is a very good example of this.

Two is that I see the problem as inherently being one of data
interchange (protocol).  If two command set vendors can't describe the
same kinds of data objects in the same way, they can't work together,
and any advantage gotten from discarding the application as container,
is lost.

There are basically two reasons for why data interchange is in such a
sorry state.

One (the bad reason) is that companies are often far too paranoid about
their stuff.  If other companies can build things which access their
data, that means that their customers are no longer solely dependent
upon them for their business.  My corner of the industry is extremely
bad for this, to the point where two software systems can be said to
"interface" if one captures the already-formatted and post-driver (i.e.
encoded for a particular printer) output of the other, parses it, and
imports it.  This sort of thing makes my teeth ache.

The other reason is the justifiable reason - that one vendor has
developed a product that actually encompasses something new, different,
non-gratuitous, and useful, as a means of acquiring market share by
giving their customers something superior.  When the data for that
product is exported to another product, it will lose that specialization
- and there's no simple way to recover it when it's imported back into
the original product.  There are lots of ways to work around the
problem, but there's no way to actually solve it - true interchange can
only take place when the capabilities of the two things doing the
interchanging actually match.

You could break down all data in day-to-day use, codify and standardize
it, but you run the risk of saying "This is the defining essence of a
spreadsheet and a spreadsheet shall never be anything more than this"
- and consequently penalizing innovation.

On the other topic:

> An interesting
> approach would be to make the disk single-assignment.  *Never*
> allow data to be modified, only allow new versions of the
> data to be created and retain all versions for their lifetime.

I think we already have these: journalling file systems?

-Chris