| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
[Draft: 6/14/2001]
The computer, as a tool, is primarily used for communication. For my purposes, there are three main types of computer-mediated communication: interactive, in which at least at least two people communicate in near real-time, like IRC, instant messaging, netphones, and videoconferencing; reactive, when exchanges take place asychronously, like email, usenet, and weblogs; and finally, inactive, where there is not an exchange -- data flows in one way, usually in the form of a document, often hardcopy. I will address these in reverse order.
Ignoring the technical aspect, inactive, unidirectional communication concerns itself primarily with presentation. This implies, to me, that the interface should concern itself primarily with documents, or data, rather than tasks, or applications. Presentation usually requires the prior selection and analysis of data. I suggest, that for purposes of analysis, it is more intuitive to select the data before the tool(s) used to analyze it. Consider this assertion in the context of object-oriented programming, a popularp rogramming paradigm which asserts that programmers work better when data-oriented, too. An example more specifically in context is the XML/XSLd ivide, which formalizes the recommended separation of content and form on the web.
So -- how do users get the data they wish to analyze? Typically, it seems, through a search engine. While this may reflect more a chronic difficulty with operating systems than user preference, it is worth considering its consequences. One study -- "Towards zero-effort personal document management: a new paradigm for users", by Hull and Hart, published in IEEE's Computer Magazine, vol 34 #3 (Mar 2001) -- indicates that there may be a better way to handle document management. You can read what looks to be an early draft of the Computer article at http://www.ricoh.co.jp/rdc/techreport/No26/Ronbun/A07.pdf -- in short, you save every document communicated (printed, e-mailed, faxed, copied, etc). That's a large part of the zero; saving is no longer something you have to remember to do. Three interfaces were available, implemented as web pages. By hits, the most popular was the list of the last ten most recently saved documents, at approximately two-thirds; about a quarter of the time, the users used a calendar-based interface developed for the paper; and the remainder were full-text searches. The calendar interface presented time-sorted thumbnails of saved documents per-day, along with context extracted from conventional group calendaring. Approximately 40% of documents retrieved were over a week old, and 10% more than six months. While the results of this paper de-emphasize search, it emphasizes something equally important: users hate creating meta-data: hence, the 'zero-effort' in the title. This makes it harder to search effectively -- I'll discuss a few ideas for automagically gathering meta-data shortly -- and points out the importance of making it easier for the user to remember `where things are'.
Now, why did I quote such a perfectly ordinary way to talk about things? Look at the construction more carefully: we 'find' files, we 'search' for things on the internet, and we wonder 'where' something is. All spatial metaphors. The MacOS exploits this, particularly in the Finder; it's not just that a folder is a new name for a directory, but that it has a certain position (on screen), color, and look. I'm not sure about the over-arching principle of spatial orientation in an operating system; I suspect it's the small things, many of which also operate on the principle of consistency. (If the last time I closed a folder, it was at (x,y), it should be there when I next open it, unless there's some very good reason for it not to be. Real folders don't get up and walk away. (As an aside, that gives me an funny idea: allow for a `secretary' or `janitor' mode, where the system opens folders in different locations from where you left (closed) them.)) One idea I particularly like for spatial orientation -- and a tree view/interface in general -- is the hyperbolic tree, as exemplified by inxight's (inxight.com) StarTree. (http://inxight.com/productseu/stviewer/stvieweroverview.html) (Hey, look, I found a WikiBug! :)) Spatial orientation becomes even more powerful when combined with multi-axial (dimensional) presentation and branching (please take advantage of the z-axis for trees whose nodes have more than two characteristics), like Excel spintables, or different 'sort by' options in conventional file managers. Changes in any view should be persistent, as discusses above.
The tree would not be restricted to the local machine. The standard suite of remote protocols should be supported, as well as a protocol to allow selective exporting of local subtrees to certain groups, which would then be spliced into the local tree display as a sibling at the appropriate level.
The users' disinclination for meta-data creation only increases the need for a operating system -wide meta-data format (for instance, XML). I have two conceptually simple ideas for automagically generating metadata. The first is to allow arbitrarily long `file names' when saving (sending) a document -- the more description, the better -- and to save the (full-text, etc) search terms which caused a document to be opened as meta-data on the document, with the next search on that same (or similar) query prioritized accordingly. Recording the tree context in which the search was performed could also be beneficial. These searches should affect the display of the tree by squelching non-matching modes and sorting or marking the remainder by relevancy. A tree interface should make it intuitive to nest -- succesively refine -- searches.
However, the operating system can only do so much to generate meta-data, limited as it is to dealing in generalities. It is therefore important that the tools extract and store as much meta-data as is practicable. A current example includes acoustic fingerprinting for the lookup of music meta-data; another might be searching only a document's headers.
In short, since most people don't seem to make effective use of the filesystem, don't bother to present it to them when they look for information to analyze. Much in the same way modern file managers preview data, the tree should extend its presentation into the heirarchy, if any, of the data contained within the files it displays. The user selects the data they're interested -- right clicking on subtree roots? -- some operation by which all tree selection/marking is orthogonal -- and performs some action to begin the analysis; alternatively, one window could be kept open with the default, non-tree, view of the currently-marked data (a 'group preview'), and switching to it would begin the analysis phase. Certainly, once the analysis phase begins, the analysis view should reflect and be reflected in the tree. The primary indication to the user, however the analysis phase begins, should be the provision of toolboxes. The tools in the boxes should work equally well in noun-verb[-object] or verb-noun mode. As with the tree itself, the user should be able to take `snapshots' of any particular screenlayout and return to it later.
If no analysis is immediately necessary, the user should be able to select a node in the tree and request that a new child be attatched to it, and begin work from that node, with some default set of tools. Those who prefer a WYSIWYG mode would generate the view window with default tools of say, page-layout; whereas those who prefer markup languages would get a default toolbox like LyX's; this would be selected either as the default default, or named specifically by the user with a dialog or context menu.
Or, notify & present. With the groundwork laid out above, reactive communications should be fairly straightforward. The 'check mail' daemon (or mail filter that looks for weblog/wiki notifies, the netnews thread tracker, etc) notices a new message, it notifies the user -- go to workspace #5 for new mail. When the user goes to workspace #5, the desktop data tree should be centered on the new message(s), and the user's preferred message view should be open, along with the preferred toolbox. Hitting `reply' sets the user up to send a new email message, and the user can work on the e-mail like any other document. There should be one 'send' (propogate) button; for shared/colloborative documents, it will send notifications to those interested; it will send e-mail; it will upload files; etc, as subject to user approval. With a relational local store, saving and sorting incoming e-mail should be straightforward, and no dedicated mail reader would be necessary; the tree additions could just be flagged. (The `summary of recent changes' dialog would be sortable by type, of course.)
I'm hoping someone can find a way to avoid making this task-oriented, because all I can think of is the addressbook idea. :)
In short, much as programming introduced a data-centric paradigm, shouldn't the interface, conventionally application-centric, do the same, go from `multiple document interfaces' to `multiple tool interfaces'?
-- ToddMiller (thanks to GilMolina for his feedback)
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|