For the first two "Web Pals" discussion activities we have created a basic container object (...bridge.apps.conf.SimpleMOOComponentView) that includes adjustable panels for:
  • A whiteboard-based map
  • A user list showing which users are at the current location
  • A shared workspace (typically a shared text editor), available on a tab behind the map
  • A description, typically a shared text editor
  • A content panel, typically defined by a script to include a large chat area and a small message board for broadcasting instructions.

(More details on general object navigation work, including the classes used for the MOO UI, can be found here: Workspace and object navigation)

The shared workspace, description, and content are populated based on object names ("text", "description", and "content", respectively) within a directory. If a spot on the map points to something other than a directory then the content of the object is shown in the content panel and the others are left blank.

The current templating mechanism will support generalization of this tool, in that we could make a "MOO Site" template that would create a moo object and a map, as well as "MOO room" template for creating individual rooms in the moo. There are a number of issues, however, that are not addressed by this:
  1. Permissions setup. In general there will be two classes of users, admins and regular users. In some cases only parts of the content (e.g., the text and chat) should be writable by regular users. The existing templating scheme does not handle this kind of permissions manipulation.
  2. Archiving. At the end of an activity it will often be useful to capture the text and chat (and other objects?) and reset these objects.
  3. Admin room setup. It has proven very useful to have an admin room that is not accessible to regular users and includes a tabbed pane for "lurking" in the other rooms without appearing as present.
  4. Script sharing. Currently we have copied and modified scripts for content setup, though sharing scripts across all MOO objects in the system, at least as default, might make more sense.

In the long run, a pluggable set of scripts for performing these kinds of maintenance tasks might be a good idea. Security implications of scripting support are, however, still something of an unknown, so in the initial implementation support for handling these issues will probably go in the MOO ComponentView object.

1. Permissions setup

This will require configuring the following:
  1. Permissions specification for admin users (a list of ids, as would go in the permissions dialog)
  2. Permissions specification for regular users
  3. Definitions of room categories, e.g., normal rooms vs. admin rooms. There should probably also be a category for things like the "scripts" and "archives" directories that are handled differently.
  4. Default room category
  5. Category for each room folder

Items 1, 2, and 4 can simply be string properties of the MOO object, probably a new subclass of the current NavigableObject class. Item 5 can be a property stored in the EmbeddedObjectDescriptor for a given room.

Alternatively, items 1 and 2 could be based on an accounts object. This would allow the group creation functionality in the accounts object to be used to define more flexible permissions schemes.

For item 3 (room category definitions), it will be necessary to define:
  • Read and write permissions (world, all in accounts object, specific group, owner accounts only) for the room itself
  • An arbitrary number of read and write permission overrides for specific objects. For example, permissions on text and chat objects would often be relaxed.

This data could be represented as a list of items of the form:
  • "category" read=[xxx] w=[xxx]
  • "category/item name" read=[xxx] w=[xxx]

An alternative to specifying lists of users associated with roles (admins/normals) would be to provide an arbitrary set of (user-list, capability) pairs, where capabilities (assuming an AnnotationSpace-based system) would include:
  • For non-admin rooms:
    • View
    • Chat
    • Annotate
    • Edit background url
  • Admin capabilities:
    • Edit map
    • Add/remove spaces
    • Access admin space
These could be represented as an array of (String, long) pairs, with constants for different capabilities. When reset, permissions would need to be generated for:
  • AnnotationSpaceSet, based on view and add/remove space capabilities
  • The admin object, based on access admin space capability
  • The map object, based on edit map capability
  • Non-admin objects, based on edit background url capability
  • Chat and draw objects within each non-admin space, based on chat and annotate capabilities
Issues include:
  • Guest and "any user" access. Guest browsing could be supported as a separate setting, and "any user" could have its own capabilities config object
If we assume a more limited kind of MOO, essentially composed entirely of AnnotationSpaces (as described in "MOO-Workspace integration"), MOO creation/configuration might look like:
  1. Create a new MOO object, which would have (contain), by default:
    • A whiteboard object for the map. (Could be overridden by an "advanced" setting)
    • An "admin" AnnotationSpace, which would have a specialized view and be accessible (where permissions allowed) from a menu item
    • A text object for the broadcast message. Could alternatively be implemented as a property of the MOO object.
  2. Establish lists of admins and users. Permissions would be applied automatically. (Could also provide an override for this)
  3. Edit the map, via a menu item
  4. View list of existing AnnotationSpaces (and create new spaces) from the admin room. Other operations available would include renaming, deleting, and setting the default starting space. (Chat browsing would also be implemented in the admin space, but probably presented separately from other operations.)
  5. Modify the broadcast message (from the admin room)
As with the original WebPals MOO, this is a very admin-oriented approach. An admin sets up the basic structure and establishes permissions such that restricted users can only modify the contents in very specific ways. In the interest of avoiding chaos in a relatively structured activity like WebPals, this degree of control seems appropriate. On the other hand, it definitely suppresses the kind of creativity that more open authoring capabilities of "real" MOOs afford.

A critical limitation of both the original WebPals MOO configuration and the envisioned AnnotationSpace-based configuration is the use of a central map object, which presents roughly the same problems as did the MB map of yore. As with the MB map, a whiteboard-based map will not readily scale to hundreds of locations. Unlike the MB map, the whiteboard-based map introduces extra security issues: Any user who can edit the map can not only add their own spots, but can also disrupt other users spots. CORK's security mechanism can easily handle more complex permissions, but the permissions UI in BRIDGE currently cannot.

Traditional (text-based) MOOs get around these issues by simply linking content. Since such content lacks any kind of mapping to a coordinate system, overviews are generally not possible, and all navigation is via link-following. The ability to have a graphical overview of the entire space is a popular feature among the WebPals teachers, and an intermediate solution that allows an overview, is scalable, and permits more flexible end-user authoring is not obvious. We may, however, consider an alternative configuration for more open-ended tasks that would abadon the whiteboard-based map and provide the equivalent of hyperlinks and the original 'dig' functionality in MOOs. If based on the AnnotationSpace class, the map panel could be replaced by controls that would show outlinks (and in-links, perhaps dynamically tracked in a contained object, managed in a way similar to the webcounter object) and provide tools for making outlinks and digging new spaces. Overview maps that provided direct links to critical spaces could still be supported, and could maintain restricted write access to control clutter and scalability.

/public/projects/bridge/design/MOO Configuration Tools Login | Web Editor | Full Editor
Last modified 2/24/04 1:03 PM by isenhour (history)
Site contents