[Nautilus-list] The Evolution of Nautilus, or thoughts on the future UI of GNOME [LONG]



Firstly let me apologise for cross-posting such a long message to two
mailing lists. If this is unacceptable, please accept my apologies in
advance, let me know, and I won't do it again.

Secondly, this is REALLY long. It's just that I'm trying to make a case
for something that sounds initially daft.

1. Introduction - Mail Everywhere

When I first heard that Microsoft intended with Windows 98 (or was it
95?) to make the web the overarching UI metaphor, I thought it was the
most preposterous idea I had ever heard. Everything was to be interacted
with within a browser - help files, documents, web pages, local and
remote file systems, etc. Why would anyone want bowsing their file
system to be like browsing the web? These are totally different sorts of
things, I thought. But actually the idea turned out to be a surprisingly
good one. So good, in fact, that it has been adopted both by Nautilus
and Konqueror, both of which I think are amazingly good.

So I was thinking about what more could be done. What could the next
step in UI be? And that thought got me to thinking about NeXTstep. I
remember having a NeXTstation (one of the nicest machines I've ever
used) and the NeXT advertising campaign - the NeXT wasn't a personal
computer, it was an interpersonal computer. And the crowning glory was
its mail client. There were endless demos of a rich text mail message
containing images and all sorts of things, which the demonstrator
dragged and dropped from the mail app into framemaker frames.
Group-working was the key thing, and its mail app the key player.

"Alright, get on with it", you are almost certainly saying to
yourselves. "We've already got Nautilus and we've got Evolution. What's
your point?" Well that's true, but would it be possible to combine them
into one? "Don't be ridiculous, mail is totally different to everything
else" you say. Well, yes and no. Remember, that's what I thought about
the "everything is the web" UI concept. And I was wrong.

What is the viability of this as the next UI innovation? - "Everything
is a mail message"; "Mail everywhere". (In fact I think Apple really
missed the boat here - OS X is the offspring of NeXTstep and has its
mail client too. They could have really gotten one over on Microsoft.
"The web's okay, but Mail is the killer internet app, and in *our* OS
its not 'Web Everywhere' but 'Mail Everywhere'.")

2. Mail is too distinct to the rest of the filesystem

The idea that one might want to interact with one's mail in the same way
that you interact with files is not an uncommon one. Good MUAs often use
the same techniques for moving, copying and filing away your mail
messages as are used in most file managers. And file managers are not
entirely independent of concepts used in mail, after all we use MIME to
classify our filetypes. In Windows you can (depending on what MUAs are
installed) right-click on a file in Explorer and mail it to someone. But
for all that I still think that mail and the rest of the filesystem are
too distinct.

Let me give two examples, although I believe more could be found. The
first is intended to reflect the file manager not behaving in an
MUA-like way and the second is meant to illustrate an MUA not behaving
in a file-manager-like way.

2.1  The actual files in a mail directory often bear little resemblance
to what you see in your MUA

A really extreme example of this, but which illustrates the general
idea, is from about six years ago when I had a one year temporary post
at the University of Leeds. I had to work in Windows 3.1 and use Pegasus
Mail. At the end of the year it was time to leave, and I opened up my
mail directory to copy the mail folders I wanted to keep onto a floppy.
But what was in there bore absolutely no resemblance to my carefully
organised hierarchy of folders with meaningful names. (I'd never looked
in it before with the file manager, but I had assumed it would bear at
least a passing resemblance to what I saw from within Pegasus Mail.)
Instead there was a single directory of files called things like
fold1234.pmf. What was what? How could I tell? I tried opening them in
notepad but they were full of control characters. (Before going to Leeds
I was used to using SunOS or NeXTstep).

Now I don't mean to suggest that the situation is anything like that in
Linux, let alone GNOME. But it seems to me that when I browse my
~/evolution folder in Nautilus, what I see should look pretty much like
what I see in the Folder Bar in Evolution. And if I click on a folder,
then Nautilus should offer me the option to View as Mail, in which case
the view switches to Evolution's mail view, with a message list pane at
the top and a message pane at the bottom. I should be able to move my
mail around from within Nautilus just like I do in Evolution, delete
messages, all sorts of things.

2.2 Attachments

Attachments drive me crazy. I get hundreds of them. When I save them to
disk so I can work with them all record is lost of which message the
file was originally attached to. I have to think of increasingly baroque
names to save the attachments as so I have some reminder. Some times I
get the same file with minor modifications mailed to me many times, with
the mail message containing complex instructions about what changes were
made and why, and what should be done with them. MUAs of course keep a
wonderful record of all these attachments, they just store them together
with the message where they can't be worked on. Once the attachment is
saved to disk it is cut free of its message and instructions. Often the
hierarchy of mail folders where the message is stored bears no
resemblance to the directory where the attachment ends up being saved.

This just seems to me to be a really unintuitive way of working. But
what is the solution? I honestly don't have one, although I think I can
see some of the ways in which this could be overcome. In BeOS the file
system is a great big database, and if I understand correctly, files can
be associated with other files in all kinds of ways. Well GNOME should
be file system independent, but we could have an independent database
that kept track of these things. Virtual Folders could be used to
present different views of our data, files could be associated with mail
messages from which they originated. In part this would seem to require
Nautilus adopting Evolution's use of Virtual Folders, but it would also
require Evolution and Nautilus to cooperate in maintaining this
database.

3. "Mail" is too narrow, "Message" is a better concept

Really it isn't just mail messages that's at issue. I get plenty of
information off of newsgroups. I don't use an instant messaging client,
but I see no reason why they should be treated any differently. An
example: someone posts an interesting post to a newsgroup, which
contains an attachment. I save the message in one of my Pan folders and
the attachment in some meaningful place in my home directory. I reply,
and an interesting thread develops. But some people prefer to take up
some points privately by mail with me. Suddenly the whole correspndence
is broken across two different applications. Someone mails me that he's
in a hotel working on a laptop, and he really needs a hard copy of
something mentioned in the thread. Could I fax it to him at his hotel?

As far as I understand it, part of the long-term plans are for Evolution
to integrate other components: news, fax (instant messaging?). Great.
Preferably Evolution will use existing applications and componentise
them (how I wish Pan could just be embedded in Evolution, and that my
Pan folders simply were my Evolution folders). I simply wanted to point
out that I'm not simply talking about mail messages here, but messages
in general.

4. Integrating Evolution and Nautilus into one

So what I've suggested is that as Nautilus is made up of components, one
of those components should be a mail view, for browsing my ~/evolution
directory. But, why have a ~/evolution folder at all? Any directory
which had an mbox file, and folder-metadata.xml, mbox-ev-summary,
mbox.ibex, and mbox.ev-summary would be treated like a mail folder. Also
I should be able to mail files to people directly from within Nautilus.
Furthermore Nautilus should have some kind of way of keeping track of
saved attachments and the messages they originated from.

Evolution is made up of components, and should include all kinds of
messaging componets. Furthermore, evolution should be able to keep track
of where attachments get saved. In fact why not be able to browse
through my file system in evolution: my folder bar could just be the
directory tree of my home directory.

But wait a minute: now we've got two applications which are made up of
components, which allow one to browse messages, associate them with
files, send files as messages, keep track of what got sent from who and
to who ... uhm you see where I'm going? If Evolution is going to be a
framework for embedding mail, calendars, addressbooks, newsreading,
faxing, and uses virtual folders, and Nautilus is going to be a
framework for embedding file browsing, web browsing, the control panel,
and will hopefully use virtual folders; and if it would be good if mail
messages and their attachments were not stored and dealt with in a way
which is distinct to how files are dealt with in the file manager, then
wouldn't it be cool if somehow they were merged into one? And wouldn't
this be one of the coolest UI innovations ever?

Thanks for reading this far. I hopes this sparks an interesting
discussion. If this is the most ridiculous idea ever, then I'd be just
as interested to know that, and if it isn't I'd be really interested in
knowing how this very rough idea could be finnessed.

Best wishes,

Darren

-- 
==============================================================================
D. D. Brierton               Department of Philosophy, University of Edinburgh
ddb cogsci ed ac uk                            http://www.cogsci.ed.ac.uk/~ddb
==============================================================================




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]