Notes on Navigation in BRIDGE
Design Issues
Currently, BRIDGE supports two kinds of navigation interface: Concept Map and Simple MOO. As we have two types of maps: drawing object and GIS maps, how to effectively and smoothly switch between these types of maps with current interface is our concern. Possible solutions include:
- In each interface, the container records the location of the map that currently has the navigation control, and has no knowledge of the type of the map. For each type of map, however, they have the knowledge of whether the shape or the spot points to a navigable concept map/GIS map or not. Depending on the navigation feature of the represented object, a spot on a GIS map or a shape on a drawing object may give the navigation control to the represented object or only load the represented object. There are different ways of providing the information?change of navigation control on interface: One, directly transfer the navigation control from current map to the represented object; Two, notify the user that the object he/she wants to view has navigation feature and ask for the user?s choice
- Slightly different from above idea, the second solution does not let the map object have the knowledge of the navigation feature of the spot or the shape it contains. Instead, the spot or the shape itself may test whether the object it represents is navigable and return this feedback to the map.
- When the object is loaded in the container after the user chooses, a navigation icon is provided in the toolbar of each kind of navigation interface. The maps then initially do not have navigation features when loaded. Instead, it functions as the usually GIS map (create a spot, delete a spot, change the description of the spot, etc) or drawing object (add/delete shapes, edit texts, etc). Only when the user chooses the navigation feature by clicking the navigation icon, will maps have navigable features. If we consider this solution, another icon which is to issue the path for the spot or the shape is probably better be included in the toolbar. Then, when maps are loaded in the container, we can eliminate the navigation icon from their interface (currently, there is a navigation menu item in a GIS map interface and a URL link menu item in a drawing object interface).
- This solution is directly aimed at realizing the navigation from GIS map and drawing object and discards the idea of having SimpleMOO and Concept Map interface separately from maps. The solution works as follows: in both GIS and drawing object interface, there is a navigation icon which a user can open a new window (close current map window? Need discussion here) that is either a concept map interface or a SimpleMOO interface look, depending on the user?s choice. Therefore, a user does not create a SimpleMOO or Concept map from the menu, instead, they are just interfaces that provide navigation features to existent maps.
Software Details
There is another issue we discuss here: navigation control. How should we give navigation control to maps? At this stage, GIS map and drawing object follow different ways of getting the navigation control:
- GIS map with navigation control is only implemented in SimpleMOO interface. MapComponentView implements NavigationControl (in edu.vt.chci.cove.nav) and NavigationListener (in edu.vt.chci.cove.nav) interfaces. In NavigationListener interface, a spotClicked(Spot s) method is included. The NavigationTool (in edu.vt.chci.cove.nav) of GIS map contains a NavigationListener. The reason we let MapComponentView to deal with spot clicked situation is that the dealing requires knowledge of the SimpleMOO to reset navigation control. The validity checking of the path stored in the spot is done also in spotClicked method. Reset navigation control is in SimpleMOO, the container, since it involves transferring the navigation control from a GIS map to another GIS map or a drawing object.
- Drawing object with navigation control is implemented in both SimpleMOO and Concept Map interfaces. The drawing object has a NavigationTool class that creates a NavigationTool for it. This navigation tool handles the navigation of the drawing object but does not handle resetting navigation control.
There are some other features included in GIS map, and ideally, will be included in drawing object map as well in the future: backward and forward, history list. Before we attempt the coding, we want to discuss these issues here as well:
Backward and forward
A path list (double-linked list), two stacks (backward and forward) are maintained in the container SimpleMOO to realize the backward and forward features. A back listener and a forward listener listen to the actions from menu Goback and Goforward. backForwardNavigationControl(EmbeddedObjectPath p) is a instance method of the SimpleMOO that address the issue of transferring the navigation control from current GIS map to the next one (either backward or forward). This method is different from the resetNavigationControl method in SimpleMOO in that in the resetNavigationControl method a path needs to be added to the location history which includes checking whether the path is already in the list or not, while in the backForwardNavigationControl method this is unnecessary as the path is already in the list. Should we include these in the container? Or should we use a separate object that handles the backward and forward situation?
History list
A vector that stores the histories of the navigated maps is maintained in the container SimpleMOO that stores all locations (EmbeddedObjectPath) of navigated maps. Should we store NavigableLocations instead of EmbeddedObjectPaths in the list in the future?
|