The mechanisms implemented by the client for allowing users to see, organize, and manipulate data objects should attempt to address the following goals:
- Mimic familiar desktop or web entities where appropriate
- Map onto URL structure, so that web navigation skills can be recruited to navigate data in the interactive client, and namespaces defined in the interactive client correspond to URLs.
- Support the idea of sites as compound documents (i.e., a site is a coherent collection of different data objects)
- Support the idea of sites as modular, re-usable entities
- Support exploration of other people's work (though we might expect most of this sort of exploration to take place on the web, not in the interactive client)
Significant issues include:
- Clutter (overwhelming the user with large representations of site structures)
- The need to embedded objects across sites (e.g., the global "search" and "user list" objects)
- Management and preservation of links (e.g. when files get moved/copied). Linking across other directories using simple file names (currently only support within directory? I'm not sure this is an issue). Management of linked tools/docs/files for web pages that get copied and moved (e.g. when a page is copied, tools currently need to be moved into the target directory manually). (dd)
In the April '02 prototype of the client, each window has a tree view that shows entire document hierarchy (starting at the root). Single-clicking on an object in the tree selects the object and shows its UI in the window. Objects may be dragged between folders in the same window, or between windows. Observations:
- The tree view:
- mimics similar views in Windows and MacOS (pre-OSX, anyway)
- potentially encourages exploration of other people's objects
- but inherently shows alot of objects. This is not only potentially overwhelming, but also limits visibility of objects deep in the tree.
- Using single-click to open an object
- speeds access to component UIs
- simplifies attachment of structure widget (the tree view) to editor widget, giving the user access to information about other objects that are part of the same site. (This is useful, for example, when composing a web page, though other mechanisms could be devised to facilitate that task.)
- but differs from desktop conventions, where double-click is typically used to open documents (note that this argument is weakened somewhat by the single-click interaction style of the Web)
- but complicates and slows drag-and-drop (and eventually cut/copy/paste) operations by unnecessarily opening the source object
- but introduces ambiguities in menu operations (e.g., does a particular action apply to the selection in the tree or to a piece of selected text in the editor?)
Alternatives include:
- By default, only show the user's home directory. This approach:
- reduces clutter (though perhaps only slightly, for users with lots of objects and directories)
- mimics, to some extent, similar "when I log in I just see my stuff" notions in other systems
- but may discourage exploration of others' work, and almost certainly complicates re-use of others' work
- but may be confusing if users launch the client from somewhere other than one of their pages (assuming client launch behavior stays the same)
- Switch to a more list-oriented view, where only the contents of the current site are shown. A popup menu (or "up" button) could provide access to higher levels of the directory structure, and (double-?)clicking on a subdirectory replaces the listing of the current directory with that of the subdirectory. This approach:
- should result in significantly less clutter
- maintains the notion of a site as a coherent collection of documents (in a way that is probably actually preferable to the tree view, where expanded subdirectories can obscure the contents of a site)
- but makes drag/drop or copy/paste between sites more tedious, though better mechanisms for opening multiple windows might help
- Separate directory structure from editing components. One kind of window would show an object-and-site (file-and-directory) view, and another kind of window is used to interact with individual objects. This approach:
- solves the single-click issues, since single-click can just be used to select and double-click can be used to open
- mimics traditional windows-explorer/mac-finder functionality (for better or worse)
- but obscures site structure when editing an object (unless we also represented the contents of the site on the object editor windows)
- but complicates window management, introducing both more windows and more kinds of windows
- but complicates modification of containers (folders), since double-clicking could mean either "expand" or "edit"
The single-click drag issues could also be addressed in other ways, including:
- Leaving selection intact if the user begins a drag with a modifier key (e.g., the control key) pressed.
- Changing selection on click (mouse-down/mouse-up on the same pixel) rather than on mouse-down. This would allow a drag operation to be initiated without changing selection and without using modifier keys.
As of 060223 I've switched the default view to a component based roughly on the "Windows Explorer" and similar MacOS finder views:
- Right panel has tree view of directories only
- Left panel has list view of contents of selected directory
- Double-clicking an item (or choosing "Open in Editor") opens the object in a new window
- Unless the item is a directory, in which case the directory is opened. This is potentially problematic
- Dragging from the list to the tree is supported
- Dragging within the list is supported
- Only for rearranging: cannot drag into a folder within the list
This approach:
- Reduces clutter
- Makes moving object easier
- Removes menu ambiguity
- Should simplify design of "undo" support
- Should simplify design of cut/copy/paste operations on objects in the directory view
- Simplifies editing of multiple documents at the same time
But:
- May introduce window management issues
- Has inconsistencies in drag/drop behavior
- Editing folders (default page and template) is somewhat more obscure
- Browsing permissions is more tedious, though this could be fixed by augmenting the list with permissions info
|