The future of the GUI
Sam Thorne
I'm currently writing a dissertation looking into the general concept of
the current desktop metaphor, it's problems and what can be done about
it.
Having read up on my Don Norman, Alan Cooper, and some Jef Raskin et al,
the basic premise for my dissertation is that the computer interface
needs to fundamentally change for it to be the Universal Machine that
Alan Turing was talking about and yet be usable by the average, non-
technical user.
For example, why should users have to deal with a file system at all?
Isn't the whole premise of the computer, that it processes and manages
information for the user to manipulate, undermined by the fact that
users then have to run their own filing system, organise their own data.
Should the computer be doing this, and allowing the user to concentrate
on their actual goal for usage?
What I'm interested in is where this fundamental change might head; does
the desktop metaphor even need changing?
Is it possible to design an truly usable interface for a device that has
no specific use?
Would it ever really be possible to change the now firmly entrenched
desktop metaphor?
I'd be really interested in hearing all opinions.
Thanks for your time!
Sam
Bradley K. Sherman
Sam Thorne <s...@s-j-t.co.uk> wrote:
>Hi all,
>
>I'm currently writing a dissertation looking into the general concept of
>the current desktop metaphor, it's problems and what can be done about
>it.
>
>Having read up on my Don Norman, Alan Cooper, and some Jef Raskin et al,
>the basic premise for my dissertation is that the computer interface
>needs to fundamentally change for it to be the Universal Machine that
>Alan Turing was talking about and yet be usable by the average, non-
>technical user.
Can you expand on what you think Alan Turing was talking about?
--bks
Rolf Marvin Bře Lindgren
| Is it possible to design an truly usable interface for a device that has
| no specific use?
Alan Cooper would say no. ;)
--
Rolf Lindgren http://www.roffe.com/
ro...@tag.uio.no
Robert Metzger
>Isn't the whole premise of the computer, that it processes and manages
>information for the user to manipulate, undermined by the fact that
>users then have to run their own filing system, organise their own data.
>Should the computer be doing this, and allowing the user to concentrate
>on their actual goal for usage?
>
>What I'm interested in is where this fundamental change might head; does
>the desktop metaphor even need changing?
>Is it possible to design an truly usable interface for a device that has
>no specific use?
>Would it ever really be possible to change the now firmly entrenched
>desktop metaphor?
Have you read David Gelernter (Mirror Worlds, Machine Beauty, etc.)
and have you looked at www.scopeware.com (the commercialization
of some of his ideas) ? They have certainly made a serious attack
on the desktop and file system metaphor.
--
Robert Metzger
Hewlett-Packard Company
High Performance Technical Computing Division
met...@rsn.hp.com
Vis Mike
them to the desktop. Quick access to the things you need, no window
cluttering, everything persistent, data stored in well known formats, etc.
To deal with information overload, one idea is to have 'filters' associated
with 'virtual workspaces'. Each workspace would show only data such as
documents, contacts, events, messages, tasks for the filter criteria.
Also, I don't like floating windows, so I think a 'shelf and tablets (tabbed
applet)' type window manager would be ideal. Windows are aligned in shelves
which can be resized.
Sample mockup:
http://www.mike-austin.com/home/papers/my-windows.jpg
Preliminary paper:
http://www.mike-austin.com/home/papers/context-ui.html
~ Mike ~
"Sam Thorne" <s...@s-j-t.co.uk> wrote in message
news:20030827170...@news.dsl.pipex.com...
Sam Thorne
themselves are merely information.
If this is the case, then a second set of instructions could read, write
and erase the information that forms the first set of instructions and
follow them. This is Turing?s concept of ?machines? that perform
specific tasks, and then a ?universal machine? that can operate each and
any of these machines.
The Universal Machine theory is the whole idea of not just having one
machine to do each specific task, but then having another 'universal'
machine that can run each and every machine designed for the specific
tasks (and so perform any task).
Basically the computer we have today is the universal machine; it can
perform any task you set it as long as you write the instructions for it
to do so.
The reason I'm putting all this into the dissertation is to get across
the point that computers are far more capable than many think; for a
start I'm at a design college, so it's necessary to make the point
really...
Sam Thorne
> [Sam Thorn]
>
>| Is it possible to design an truly usable interface for a device that
>| has no specific use?
>
> Alan Cooper would say no. ;)
>
How do you do goal-orientated design when you can't ever know what the
goal will be?
That's the whole issue i'm working on though really; can we ever develop
something not based on shoddy metaphors from the real world that don't
match up to how computers work? Possibly not...
Some of what Alan Cooper has to say is very interesting, and I certianly
think he's written a good book ("the inmates are running the asylum")
for people that need to be addressed on the need for design for
software (the people who commission it).
But I'm not sure I really agree with his take on usability and other
software design fields. It seemed to be a lot of "they don't know what
they're doing, but I do!" without any real evidence to back him up...:D
Sam Thorne
> Have you read David Gelernter (Mirror Worlds, Machine Beauty, etc.)
> and have you looked at www.scopeware.com (the commercialization
> of some of his ideas) ? They have certainly made a serious attack
> on the desktop and file system metaphor.
It's interesting that a lot of people seem to be moving away from the
desktop metaphor is the same sort of direction.
There's an interview (http://www.theregister.co.uk/content/4/24648.html)
from a while back on theregister.co.uk with a couple of ex-engineers
from BeOS and the work they were doing on a database driven file system,
it's technical (I'm way out of my depth :)) but interesting none the
less.
I'd been thinking about the same thing really (though in pretty basic
terms); why should users have to organise their file system?
Spring is another approach to creating a new way for people to control
their data, interesting approach too (http://www.usercreations.com/
spring/ Mac OS X only, but there's lots of info and screenshots).
The idea of just being able to drag between items to perform actions
that use those items together etc.
I think we are slowly but surely developing ideas that make more sense
than the 'folders and windows' metaphor, but I can also see that the
desktop system is so mixed in with computing now that it may never be
changed.
Thanks again.
Sam Thorne
Michael Valentiner-Branth
> For example, why should users have to deal with a file system at all?
> [...]
> What I'm interested in is where this fundamental change might head; does
> the desktop metaphor even need changing?
>
The desktop metapher is IMHO limited in that way, that it is based on a
world bound to material, but the organization of information in a computer
is not (if we forget about the harddisk for a moment).
In the material world, a library for example, a hierarchical structure is
necessary (floor, room, row of shelfs, shelf ...), but it isn't in a
virtual system, that only consists of information.
See http://www.bookkey.com for my suggestion for an alternative to
hierarchical tree structures.
In contrary to most approaches, some of them already mentioned in this
thread, mine is still text-orientated (and therefore doesn't look
futuristic :-).
On first step I limited the application on managing bookmarks, but this
concept may be expanded to managing documents as well.
A lot of links related to the topic can be found at
http://www.iis.ee.ic.ac.uk/~rick/pim.htm
("Who's working on Personal Information Management?")
Michael
--
bookkey, Bookmarks by Keywords.
With a new way to handle a large number of keywords.
http://www.bookkey.com
Jorn Barger
> the basic premise for my dissertation is that the computer interface
> needs to fundamentally change for it to be the Universal Machine that
> Alan Turing was talking about and yet be usable by the average, non-
> technical user.
I'm skeptical whether one can say much about the interface
until we have a better idea of the 'guts' of the next
generation of software. Clearly, everything needs to be
more tightly integrated, and presumably more modular as
well, with a scripting language that makes it easy to
quickly construct simple special-purpose apps.
Everyone knows that orthogonality is the design ideal
for computers-- finding a set of primitives that can be
re-combined in near-infinite ways to generate complex
behaviors-- but not a lot has been done to take that
principle beyond 1984's MacPaint and 1987's HyperCard.
I don't see why the whole user-interface can't be
scriptable, so that people can associate a script/
behavior with any arbitrary interface event (mouse click,
keystroke, etc).
My background is in 'story AI', and I foresee operating
systems built around a huge database of stories about how
and why people use computers (cf 'use cases' in project-
management theory). This will allow intelligent error-
correction and streamlining of stereotyped tasks.
Sandia is trying to do this via a statistical approach
instead of stories:
http://www.sciencedaily.com/releases/2003/08/030815074654.htm
> For example, why should users have to deal with a file system at all?
One inevitable giant change in the filesystem is that
people are going to start _archiving_ every webpage they
visit, and they'll need a local google-equivalent to
access these. This will need a really efficient 'diff'
system to track changes in frequently-visited pages,
and once diff becomes part of the basic toolkit, it
might prove more-orthogonally useful, eg for sync-ing
lists of files.
I suspect the word-processor metaphor may replace the
desktop gui because it's deeper-- Emacs and Raskin's
approach being two models.
Sam Thorne
> I'm skeptical whether one can say much about the interface
> until we have a better idea of the 'guts' of the next
> generation of software.
them as almost irrelevant for the design of the new interface we're
talking about.
What really matters here is what users want to do; their goal in using
the computer. The implementation of any interface should really be
developed around this principle IMHO; how the guts of the software work
should then be reliant on how the interface works, not the other way
round.
> Clearly, everything needs to be
> more tightly integrated, and presumably more modular as
> well, with a scripting language that makes it easy to
> quickly construct simple special-purpose apps.
> I don't see why the whole user-interface can't be
> scriptable, so that people can associate a script/
> behavior with any arbitrary interface event (mouse click,
> keystroke, etc).
Have you seen Apple latest implementation of AppleScript? Scriptable GUI
is now a reality...http://www.apple.com/applescript/GUI/
> My background is in 'story AI', and I foresee operating
> systems built around a huge database of stories about how
> and why people use computers (cf 'use cases' in project-
> management theory). This will allow intelligent error-
> correction and streamlining of stereotyped tasks.
> Sandia is trying to do this via a statistical approach
> instead of stories:
> http://www.sciencedaily.com/releases/2003/08/030815074654.htm
>
That's a great link, thanks. I certainly see AI one of major parts of
the next generation interface. It's only logical that computers should
remember and adapt to use patterns.
> One inevitable giant change in the filesystem is that
> people are going to start _archiving_ every webpage they
> visit, and they'll need a local google-equivalent to
> access these. This will need a really efficient 'diff'
> system to track changes in frequently-visited pages,
> and once diff becomes part of the basic toolkit, it
> might prove more-orthogonally useful, eg for sync-ing
> lists of files.
In a way I think it might be the other way round; ultimately broadband
access is going to change the way information is stored radically. How,
I'm not quite sure :)
>
> I suspect the word-processor metaphor may replace the
> desktop gui because it's deeper-- Emacs and Raskin's
> approach being two models.
>
Could you expand on this a bit? I'm familiar with Emacs and THE (
Raskin's editor), but I don't see how the word processor metaphor fits
in with the ever increasing audio/visual use of computers amongst
everyday users as well as professionals in those fields (e.g. iMovie,
mp3 etc.)
Interesting stuff!
Sam
Jorn Barger
> > I'm skeptical whether one can say much about the interface
> > until we have a better idea of the 'guts' of the next
> > generation of software.
> I might be misunderstanding your meaning in 'guts', but generally I see
> them as almost irrelevant for the design of the new interface we're
> talking about.
> What really matters here is what users want to do; their goal in using
> the computer. The implementation of any interface should really be
> developed around this principle IMHO; how the guts of the software work
> should then be reliant on how the interface works, not the other way
> round.
Are you thinking of the principle that it's good to write the
documentation first, before writing the program? Because I
agree with that, but it only goes so far-- you have to know
what's possible, and that's changed radically as storage and
memory get cheaper, as processor speeds increase, and as the
Web (and Google) offers infinite information.
> Have you seen Apple latest implementation of AppleScript? Scriptable GUI
> is now a reality...http://www.apple.com/applescript/GUI/
Actually that doesn't go near as far as I want-- I want to
be able to change the placement and behavior of menus, for
example.
> > I suspect the word-processor metaphor may replace the
> > desktop gui because it's deeper-- Emacs and Raskin's
> > approach being two models.
> >
> Could you expand on this a bit? I'm familiar with Emacs and THE (
> Raskin's editor), but I don't see how the word processor metaphor fits
> in with the ever increasing audio/visual use of computers amongst
> everyday users as well as professionals in those fields (e.g. iMovie,
> mp3 etc.)
The dirty-little-secret of GUIs is that they're really
slow for wordprocessing-- switching from keyboard to mouse
and back over and over is a drag. If you start with the
assumption that you want to optimise keyboard-only word-
processing, and that your users will all be expert with
it, then you can start rethinking many OS functions as
word-processing-like, eg file search.
Once you've committed to this,I don't think it should be
too hard to look at an image file as a series of rows of
pixel 'characters' (approximately like a text file). I
already expect my word-processor to support geometric
operations for ascii-art, and it's wrongheaded to think
this is old-fashioned and doomed to obsolescence. Simple
ascii-art diagrams will always be useful in email and
netnews.
Since the word-processor will support text-to-speech,
perhaps the same sort of analogy can apply to editing
music files-- I've never explored that.
But I'm pretty sure that bitmapped windows have become
a real _cognitive_ obstacle to creative thinking about
software design.
Jorn Barger
Sam Thorne <s...@s-j-t.co.uk> wrote in message news:<20030829022...@news.dsl.pipex.com>...
> > I'm skeptical whether one can say much about the interface
> > until we have a better idea of the 'guts' of the next
> > generation of software.
> I might be misunderstanding your meaning in 'guts', but generally I see
> them as almost irrelevant for the design of the new interface we're
> talking about.
> What really matters here is what users want to do; their goal in using
> the computer. The implementation of any interface should really be
> developed around this principle IMHO; how the guts of the software work
> should then be reliant on how the interface works, not the other way
> round.
I think that one of the biggest problems for interface
designers these days is breaking out of the bitmapped-windows
paradigm-- it subtly poisons the imagination by encouraging
a sort of dualistic thinking, where computer processes are
broken into clumps viewed thru windows.
One antidote is to recognise that a bitmapped window is
itself an editable image, and could be handled using the
same toolkit as any other image-- Apple's ResEdit used to
allow this to some extent. The titlebar of a window
includes a text-field that you might want to spellcheck,
and the text it displays is a filename that you might want
to view in other contexts (my Mac lets me command-click on
the title of a Finder directory to see the path, and jump
to containing directories, for example).
Power-users always have lots of favorite utilities
installed that let them access shortcuts of various
kinds-- these should be integrated into the interface at
the deepest level, so that all apps can access them via
the same interface command-patterns. But before you can
redesign the interface-metaphor to optimise for these,
you have to know what basic set of orthogonal functions
will be most useful.
Another example: saving and/or closing a file needs to
be generalised to some kind of 'dispose' bar that allows
a range of options from 'delete and wipe disk' to 'save
and back up for security'. This range of choices needs
to understand what sorts of storage are available, and
how secure they are-- whatever interface metaphor you
use needs to be optimised to reflect these differences.
Sam Thorne
> Are you thinking of the principle that it's good to write the
> documentation first, before writing the program? Because I
> agree with that, but it only goes so far-- you have to know
> what's possible, and that's changed radically as storage and
> memory get cheaper, as processor speeds increase, and as the
> Web (and Google) offers infinite information.
>
code to implement that interface be written for the interface.
This is the classic Don Norman approach to design; the most important
thing is how the software is used, not how it is built.
>> Have you seen Apple latest implementation of AppleScript? Scriptable
>> GUI is now a reality...http://www.apple.com/applescript/GUI/
>
> Actually that doesn't go near as far as I want-- I want to
> be able to change the placement and behavior of menus, for
> example.
>
you use already type thing?
>
> The dirty-little-secret of GUIs is that they're really
> slow for wordprocessing-- switching from keyboard to mouse
> and back over and over is a drag. If you start with the
> assumption that you want to optimise keyboard-only word-
> processing, and that your users will all be expert with
> it, then you can start rethinking many OS functions as
> word-processing-like, eg file search.
>
The only problem with this is that it relies on the user becoming expert
at keyboard control before the interface becomes truly usable.
And the problem I see with that is that the keyboard doesn't really map
to the screen directly. For example, I can point to a file and
manipulate it with the mouse; direct manipulation. But there is no
direct link between keyboard control and the representation of the file;
in other words the same keys perform a myriad of different functions
without there being anything different in the interface.
This makes it difficult to learn.
> Once you've committed to this,I don't think it should be
> too hard to look at an image file as a series of rows of
> pixel 'characters' (approximately like a text file). I
> already expect my word-processor to support geometric
> operations for ascii-art, and it's wrongheaded to think
> this is old-fashioned and doomed to obsolescence. Simple
> ascii-art diagrams will always be useful in email and
> netnews.
> But I'm pretty sure that bitmapped windows have become
> a real _cognitive_ obstacle to creative thinking about
> software design.
>
I can appreciate the the word processor we have to day is pretty poor
for the task its meant, but by the same token wouldn't forcing users of
different mediums from text into a text-orientated interface be forcing
other people in the situation text editors are in now?
In my opinion the interface needs to be tailored to the task, that's
what I was talking about earlier. What is it the user wants to do? Once
their goal of using the computer is nailed down we can then build an
interface that suits that goal; and I think to dismiss GUIs means to
dismiss a large toolbox of interface possibilities that might very well
suit that goal perfectly, or they might not...:)
Viswanath Gondi
why not look at the web metaphor in the same way? On the web, pages
are arranged by topic and are connected through contextual navigation.
Applications on the web are also designed to perform complex
operations just by clicking on different links.
Sam asked, "How do you do goal-orientated design when you can't ever
know what the goal will be?" The designer dosn't know the goal of the
user, but can help the user by giving the user a set of task based
pages that are contextually linked. Others can connect these tasks to
form efficient processes. Like the web metaphor, the user is focussed
on a single task based page with no window clutter. As Jorn says, AI
along with the behavior of users and other metadata pertaining to the
pages can be used to connect these tasks contextually to form better
processes. But, standards are needed to exchange data between
different pages. The current developments in XML and webservices are
modularizing the data and using standards to store data. Linking
different pages with data should be as easy as current linking of
pages on the web. The taskpane in windows XP is a good example of
giving contextual navigation links to the task based pages.
Viswanath Gondi
http://blogs.law.harvard.edu/vgondi/about/
Gabriel Radic
> Another example: saving and/or closing a file needs to be generalised to some kind of 'dispose' bar that allows a range of options from 'delete and wipe disk' to 'save and back up for security'.
Since you said you are using a Mac, you may want to try dragging the
icon from the title bar of an opened document. CLick, hold, drag to
where you want to store that document.
The idea is there.