Single objects (either individual tools or composite tools such as the Workspace objects used in the Awareness project activities) will be sufficient for some kinds of focused collaborative interaction. Other kinds of activities, such as "moo"-style discussions, could be more easily carried out if there was a mechanism for moving between workspaces or objects. This navigation could take several forms:
- A list or menu of available objects
- A GIS map of locations, each with a workspace or other object (e.g., a yet-to-be-designed MOOsburg-style desktop)
- A simpler image-based map drawn on a whiteboard object
- A dynmically generated graph of nodes showing a relation between objects (e.g., a timeline, usage representation, or social network visualization)
Creation of tools that allow such navigation will be facilitated by the design of classes and interfaces that support:
- Standard interfaces for navigation widgets and navigable widgets
- Standard UI layouts and behavior that support composition of an arbitrary navigation component and the bridge workspaces or other objects that they are being used to navigate
Preliminary work on this was driven by the ROLE "MOO" activity at BMS and the concept map tool used in the Awareness activity (see http://java.cs.vt.edu:8888/Awareness/24). Both of these tools are containers navigated (initially) by whiteboard-based maps. Supporting classes for these tools include:
-
edu.vt.chci.cove.nav.NavigableObject provides a minimal replicable object containing a pointer (path) to a navigation control such as a whiteboard or GIS map and a starting path. The assumption is that the UI will show the navigation control and the content object specified in the starting path.
-
NavigationControl is an interface for a map or other widget that lets the user pick a data item. ProxyNavigationControl provides an implementation to support defered construction of NavigationControls.
-
NavigationControlSource is an interface that can be implemented by bridge ComponentViews to return a NavigationControl. This is primarily intended to prevent CV's from having to implement the NavigationControl interface. It is possible that (yet) another level of indirection is needed, so that the container class could ask for a NavigationControlSource for an arbitrary replicated object.
-
NavigableLocation describes a selectable data item on a navigation control. It specifies a path to the data item and a label for that item, since the label within the control may differ from the name of the data item. (This might be the case, for example, with a concept map, where we would might want the object linked to a text node to be labelled with the node text instead of the name of the object.)
Specific classes for the MOO and concept map include:
-
NavigableObjectComponentView provides the basic UI implementation for the concept map. It supports two panes, with an adjustable splitter between them. The navigation control goes in one pane, and the navigable content component views go in the other pane. The menu for the CV is taken from the navigation control's CV.
-
edu.vt.cs.collab.bridge.apps.conf.SimpleMOO is a subclass of NavigableObject that current adds no additional state or functionality, but is used to map a different CV to MOO objects than (e.g.) concept map objects.
-
SimpleMOOComponentView provides a multi-pane UI for navigating to folders. Within each folder, objects named "description", "chat", "content", and "text" are shown in various places in the UI. If these are not present, the CV of the pointed-to object will be shown in the "content" part of the UI. At some point we will at least need to parameterize the names of these pieces. A further step would be to provide more general control over the number and layout of "slots" for objects. (This should be considered as part of design work on MOO Configuration Tools.)
-
bridge.apps.draw.DrawingComponentView implements the NavigationControlSource interface and includes a ProxyNavigationControl instance. When the CV has fully loaded, the ProxyNavigationControl is connected to an instance of NavigationTool (which implements NavigationControl) if one is available.
Web Interfaces
In the initial implementation (Fall 2002), NavigableObjectWebView simply delegated web rendering to the navigable object's navigation control. So, for example, a concept map object based on a SharedDrawing would just show the drawing when viewed on the web. This has presented a problem in the awareness activity, since concept maps are printed from the web. This means that there is no easy way to print a web and all the text (or other) objects assoicated with it.
Possible solutions include:
- Change the WebView implementation of SharedDrawing to include the content of any linked objects.
- would allow greater control over the html that is generated for objects linked to external content (i.e., remote URLs)
- but would not be appropriate as a default, since SharedDrawings are used for imagemaps on web pages:
- Could be made a configuration option associated with the drawing
- Could be controlled by an argument passed into the embedded object, like a url parameter. Arguments to embedded objects are not currently (030207) supported.
- Extend
NavigationControlSource to have it return a list of NavigableLocations.
- Would provide a mechanism that could work for navigation controls other than drawings
- but would require loading
ComponentViews in the web server.
- Introduce a new interface for objects that return a list of
NavigableLocations for a NavigableObject's NavigationControl.
Option (1) seems like the best candidate. A mechanism for passing args into embedded objects will need to be added. We might eventually also add a configurable option on SharedDrawing to show linked content.
|