The idea for integrating the SimpleMOO and Workspace objects has come up in a number of contexts. Such an integration would result in something like a navigable set of workspaces, where each workspace could contain arbitrary objects.
At present, workspaces can simply be added as content targets in a MOO. This approach has several drawbacks, particularly in the context of activities where more than two or three people are likely to be in a given place (e.g., WebPals):
- Considerable screen space is wasted, particularly since the user list is duplicated.
- Space used by the description and the navigation control is also often wasted, since these are not useful for the bulk of the activity.
- The embedded chat component is too small if chatting is the primary purpose of the activity. (It can, however, be opened in a separate window on the workspace.)
- WYSIWIS window management on the workspace becomes more annoying in proportion to the number of active users. This feature would probably also present signficant performance issues beyond three or so active sessions.
- The shared "message board" is lost
Alternatively, workspaces could be embedded in NavigableObjectSets, which are essentially simplified two-panel variants of the MOO object. This has most of the listed problems. In addition, the current side-by-side configuration (or a top-bottom configuration, for that matter), it not well-suited for the kind of simple navigation needed by WebPal-ish activities. These problems can be distilled to two basic needs:
- Elements that are only intermittantly needed should be managed in such a way that they do not permanently consume screen space.
- Characteristics of the Workspace that do not scale beyond two or three users (WYSIWIS window management, in particular) need to be addressed.
A specific activity that could use a moo-type object with workspace functionality is the proposed "WebPals II" activity at BMS:
- The basic structure of the activity would be the same, in that VT-BMS teams would wander through the space for a while and then settle into an assigned room for a discussion.
- Discussion would revolve around an instance of "everyday text" -- an artifact that might consist of text and/or images
- In addition to discussion of the artifact, students should produce a summary or other commentary text.
A possible design for a tool to support "WebPals II" would be:
- The artifact to be discussed could be shown on the background, and would be immutable within the moo object.
- This could be generalized to a background layer which could also have accessible controls.
- Room descriptions could be embedded in the background layer as well
- Whiteboard tools could be used for annotation
- This would reflect our marginally better experiences with whiteboards, rather than text areas, for group composition.
- It might be useful to (optionally) enforce a token-passing scheme to try to limit chaos and mischief (See Token management)
- Could also consider multiple (per-user) annotation layers. This capability would be useful for other kinds of annotation tasks.
- Avatars in a layer of the workspace could be used instead of the user list.
- Scalability issues
- Could reflect activity, e.g., moved to match location of added annotations, drift to bottom when idle
- Initial implementation of AnnotationSpace just puts the user list on a tab in a floating window, with user count shown in tab label.
- Chat could be done in a separate pane, or in a floating (non-WYSIWIS) window on top of the workspace
- A separate pane is problematic since it becomes "fixed" in at least one dimension.
- Might be able to make this semi-transparent to mitigate effect of covering part of the workspace
- An editable "wrapper" page would generate a web-accessible overview of the artifact, summary, and discussion.
- The shared "message board" used to provide instructions during an activity could be integrated with the annotation layer, possibly as a ticker.
- A ticker would have the advantage of being invisible when not in use, and would also limit the chances of the message board being covered by a floating chat window.
- Since navigation and chat are usually mutually exclusive, these could occupy the same space.
- To support navigation "browsing", the navigation panel could include a minimal view of the chat (e.g., just the last msg or two, and no input field), so that the user could keep track of the conversation while considering a change in location.
Implementation notes:
- JDesktopPane may or may not be a good idea
- Would simplify window management
- Would make it easier to expand beyond a single floating window (e.g., if we wanted to support arbitrary floating objects as in the current Workspace tool)
- Has cross-platform oddities
- May not support background images
- May not support whiteboard tools operating on background
- May not support transparency in floating windows
- A
JLayeredPane is probably a better alternative, though input event delivery will need to be tested.
- This appears to work fine, at least under OSX. JInternalPanes are even supported.
- Original set of bridge classes include
LayeredComponentViewPane, but this assumes that all layers are CVs. This may be useful to review for opaqueness, event propagation, and layout issues.
- Add "background source" to SharedDrawing
- Useful for other annotation tasks
- Should minimally support URLs, but could also handle drawings in a more real-time way
- Need to consider offset and sizing issues. (See
SharedDrawingView.getPreferredSize().) A reasonable approach might be:
- Allow offset and scale to be configured, defaulted to no offset/no scaling. To support margins on all four sides (useful for annotations), we probably want to use top/bottom/left/right insets rather than an (x, y) offset coordinate.
- Default component size to union of background size (with margins) and figure bounds
- See
SharedDrawingView.drawBackground(...) (SharedDrawing.draw(...) may also be relevant)
- An alternative to a background property would be a "locked", unselectable figure
- Would be somewhat more general and, in some cases, simpler (as both background and foreground could be constructed at the same time)
- Locking/unlocking interface could be complex, and (in the context of classroom activities) would either require extra security or have to be sufficiently hidden to avoid mischief.
- Automated construction (e.g., for integrating annotation support with the bridge object version browser) might be more complicated if it required adding and configuring a figure within a drawing, rather than simply setting a property on the drawing itself.
- We currently have no properties (in the JavaBeans sense) in
SharedDrawing
- Should consider abstracting this a little so that background could be implicitly determined, e.g., an annotation layer attached to another object.
- Abstraction might also let us separate margin configuration from content configuration. This may not actually be a good idea, since changing the margins would disrupt already-place figures.
- Containment hierarchy. We currently have two models for structing aggregate objects:
- Self-contained collection. Workspace objects are specialized folders (technically sublcasses of
Website) that minimally contain a chat object and are somewhat opaque from the perspective of the "explorer" view in the full editor. Objects can be added or removed only from within the Workspace UI itself.
- The primary advantage of the self-contained aproach is that we have greater control over contents. For example, logic in the Workspace can ensure that a chat object is always present, (re-) creating it if necessary.
- Configurable view of an arbitrary collection. The MOO and NavigableObjectSet objects are essentially views of sets of objects. They maintain state information, but do not contain any objects that are "in" the moo or NOSet. The contents are instead implicitly defined by linked objects in the navigation control, e.g., objects linked to figures on a whiteboard.
- MOO structure is fundamentally more complex than workspace structure, so it isn't clear that having two different models is inappropriate. MOO configuration is harder than workspace configuration, but that would be better addressed by templates (e.g., for a standard "room") and tool support for configuration. More notes on tool support at "MOO Configuration Tools".
- For the new "room" objects envisioned for the WebPals II activity, a self-contained model is probably appropriate. As with workspaces, these objects will have several standard "contained" components (chat, drawing for annotation layer) as well as state information (such as background image) that may reference objects logically "inside" or "outside" of the room containment hierachy.
- In the interest of generalizability to other annotation tasks, "room" is possibly not a good name for this object. Maybe "annotation space"?
- The self-contained model also better supports multiple (e.g., per-user) annotation layer
- A difference between workspaces and annotation spaces (?) is, at least as outlined in the WebPals II sketch above, that integration of the navigation tools within the UI of the annotation space will require the annotation space to know something about how it is being navigated. Further, the navigation component will need to replace essentially the entire UI when the user moves from place to place.
- A possible solution to this is to have the annotation space support being told what navigation component to display. We could then take the "configurable view" approach to structuring a set of annotation spaces, with the MOO object responsible for telling each annotation space about the current navigation context, and having the MOO object replace the UI, much as the current MOO implementation does for the content panel.
- Alternatively, the floating window could be provided by the container UI, in a structure that more closely resembles the old SimpleMOOComponentView. One advantage of this approach would be that it would not be necessary to save and restore window position on each transition. A downside is that this would preclude AnnotationSpace from presenting an alternate set of tabs in the window (or at least make such customizations somewhat more difficult). Per-room chat tabs in an admin space are a possible example.
|