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



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



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