Re: [Usability] totally abstract task/document-oriented desktop questions

["David Adam Bordoley" <bordoley msu edu>]

Luis Villa <louie ximian com>
>

Hi Luis glad to see that you are thinking about some of the issues that need 
to be worked out. 

> Hey, dudes- 
>
> late night brainstorming led me to a question- in a hypothetical
> document-centric/app-hiding desktop, how does one initiate actions that
> are not document-centric? i.e., if evolution-as-app goes away, how do I
> initiate the action of sending a mail? [For that matter, how does one
> create a new document?]

Well there are a couple possible solutions here (well these are the ones 
that I've considered so far at least or seen proposed). These include: 

1. A global "New" Menu.
----------------------------
In an early mockup seth showed me as he was in the brainstorming stage for 
developing storage, he included this as a panel menu. From what I remember, 
this menu would contain a list of possible document type that you could 
create (Document, Spreadsheet, Email etc.) If I was to design this, I would 
limit the number of document types to 10-15 common ones and a "More.." menu 
item that popsups a complete of the available documents that a user can 
create. 

2. Document Template "Folder"
------------------------------
First please note that I use the term folder in the generic sense, not in 
reference to unix directories. I somewhat alluded to this in the previous 
paragraph, but the basic idea here is that each program (I'm intentionally 
not using the term application here, programs are used to create the 
implementation but are not first class user interaction objects) provides a 
set of document templates for the document types it can create. A  user 
would open this folder, double click on the document type they want to 
create (a text file, a music playlist etc.) and the new document that the 
user created would automatically be saved and stored on the disk by Storage. 
A user should also be able to create new template from documents they have 
created. I think approaches 1 and 2 nicely compliment each other. 

3. Local Access to Document Templates (shitty term but yeah)
------------------------------------------------------------
Basically what I'm alluding to here is that some special folders would 
provide the ability to create document types that have a distint connection 
to the users current task&#8206; from their file menus. For instance the 
mail folder would provide the ability to create a new email from the "File" 
menu. 


Another idea to consider specifically in reference to email, is that an 
email is really just a text file (or html in some cases). So another way for 
a user to send a new email is to create a new text document using either 
method 1 or 2 and then select File->send to. In fact, this is already 
recommended in the HIG. We should also support direct manipulation 
interfaces too. It would be nice to be able to show the desktop and then dnd 
a file from tasklist to the desktop mailbox or be able to drag an icon in 
the titlebar of a text document to an open mail folder view to send mail 
etc. There are alot of possibilities here. 

> Alternate/secondary question- what about things where the file/document
> manager is a spectacularly crappy metaphor, like managing a playlist or
> playing music in general? i.e., in a strictly document-centered world,

I don't think that file/document metaphor is spectactularly crappy for 
managing playlists at all. In fact I think it works pretty well. A playlist 
is nothing more than a special type of document. This document has certain 
rules of manipulation. To add songs to the list you open you're music 
library folder (again this could be a folder more in terms of a Storage 
query for "All my music") and dnd the songs you want to add to the playlist. 
A playlist should exist independent of the music library. Translating this 
in terms of the current rhythmbox interface, playlist would be individual 
files in the file system that can be opened, viewed and manipulated, but are 
not part of the music library (so there would be no sources in the music lib 
view as in RB). 


> the 'basic unit of manipulation' seems limited (offhand) to having the
> granularity of a single document- opening a word doc seems easy/is
> intuitive in this world-view, but how do I 'open my music collection' or

Music folder on the desktop. In the short term, this is a traditional unix 
directory with a special music library view. In the long term this is a 
Storage query folder that resides on the desktop (allowing all kinds of cool 
things like network transparency see seth's manifesto). 

> 'open my mail' when those things do not really exist as an object I can
> manipulate via the file manager?

Same as above, the mail folder is a desktop folder. Even cooler its icon 
should provide some special info. For instance if new mail has arrived the 
icon should change states to indicate this. If you have unread email it 
should try to clue you to this as well. The icon is a live object in this 
example. Clicking on the icon opens the mail folder (something akin to the 
evolution mail view). 

Also note with storage we can do lots of cool things like search for "Mail 
from bob" and get a nice list of query results. 

> Finally... I suppose that a possible answer to the above is 'you can't
> do that because your file-system is an archaic abstraction that should
> not be the center of a document-based desktop'. 

I think I've sorted alluded to this above as well. I don't think the desktop 
metaphor is broken so much as the hierarichal file system is broken. Even in 
the world of storage, i still think a desktop with icons for some folders 
(mostly the special kinds i've mentioned above like music, pictures, mail, 
address book etc.) will be useful. Access to data like documents, and 
spreadsheets is better provided by the storage search interface (seth's 
research paper has some interesting comments on why this is so). 

> Certainly that's where
> seth is leaning, and it seems MS is following his lead. 

At the university of washington job fair this week a 15yr old kid was 
interviewing people for microsoft. His current job task, developing natural 
language search querying of the file system. Storage is cutting edge indeed. 

> If that's the
> case, where is the user entry point for these meta-document tasks? Does
> the app create a meta-entry somewhere, or is the user expected to do
> 'find all music files' followed by a 'play the selected files'?

As I mentioned above the view for "find all music files" should be a music 
player. The traditional icon view isn't very useful for music. 

> Anyway, I suppose this is maybe all covered in the Storage writeups;
> apologies if that is the case... I'm literally sleepless tonight and
> writing this without an ethernet connection so I'm sort of winging it.

Glad to see you are interested. 

dave