Raskin book on UI and radical data thoughts

[Jay Nelson]

Paulo mentioned Jef Raskin's book on UI.  I tripped on a
review that was posted on the website:

http://humane.sourceforge.net/humane_interface/hollands_review.html

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). Commands and transformers can be purchased
  as needed, perhaps even on an individual basis. The result is that we use a
  small set of elementary keystrokes or special keys for everything we do on
  the computer--word processing, email, tables and graphs, computation,
  drawing pictures, writing code. Because commands are consistently mapped
  to specific actions or gestures, software will be easy to learn, and 
there will
  be no negative transfer from one situation to the next."

Bjorn's posting on adding destructive operations to erlang to make it
less scary to programmers had me going for a while since my timezone
is around 9 hours behind!  I had been thinking more along the lines of
no option to modify data at all on a computer.

Last posting I was talking about data streams and how to apply them.
It didn't quite solve the problem I was pondering.  What I was really
thinking about is that data is not statically sitting in a file waiting to
be modified as is the current approach (and pretty much the current
OO approach as well).  In both cases, the structure and location of
data may be specified but not the lifecycle.  The lifespan is what is more
important -- how long is it needed and in what form.  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.

When I receive email, it should either get deleted immediately or
within a day or two, otherwise I keep it filed away in a folder for future
reference.  What if email automatically knew that it was ephemeral?
If I look at it but don't do anything with it, it should expire after 5 days
(or however I configure the lifetime of email).  If I decide to keep it
I don't put it in a folder, but instead assign a lifetime for it.  I can then
access it as a source for quoting, as part of larger document, for
reference material when calling someone, or as a source of an email
address, etc.  The purpose I kept it for may not be the only purpose I use
it for.  The data should not be "stored in the word processor" as my
Mom says, but stored on my computer and accessible by any means
at any time -- during its lifetime.  Applications force a conceptual
constraint on the way the user thinks about the data.

If I write an email and decide not to send it, it is kept as raw text.
I can modify it tomorrow and send it, but I retain the original as
well as the newer version (Bill Gates and other CEOs would probably
shudder at the thought of permanent, non-modifiable email).  I can
apply an HTML markup to it which will be guaranteed to always
correspond as I originally intended and merge the two elements (raw
text stream and markup stream) when sending them to my tcp_proxy
web server.  I can add a PDF markup as a third element and display it
on Joe's UI.  The raw text remains searchable and associated with the
various markups.  If I create a new version, the markup locations can
be modified as I edit and the text, HTML and PDF can all be generated
as a new version and remain in sync.

"Commands and transformers" are UI requests that modify data by
pushing it through a process and streaming it out the other side.  The
data on both sides of the transformation have relevance and life
expectancy that are independent of one another, but the UI request
creates one from the other at a given point in time.  The lifespan and
dynamics of the data are what are important.  Don't consider just a
single object or class, don't consider a single file or database table,
consider the entire life of the data and the ways that it can be transformed
in the same way you consider an entire set of possibilities when you
write a recursive function with pattern alternations or when you write
all the message types that a server may respond to.

jay