Objects (such as the workspace) may need to communicate with a third, higher-level object that affects objects horizontally in the hierarchy. How can we namespace events to allow this level of control?

Remove unused CSS from 1.0

Widgets are currently stored in an array on the viewer, but they now pertain to workspaces only. Provide a way to add, switch, and activate workspaces on the viewer object and delegate such concerns for widgets to the workspaces of which they are a part.

Perhaps some element of "history" or "all previously opened objects" with a non-widget-specific representation will be useful for the load menu.

HTML/CSS

The manifest panel list items should adapt the number of visible thumbnails with a media query or javascript to prevent images from popping under the thumbnails.

The logic to handle image loading is currently trapped in the template data function of the manifestsListitem module, but should be broken out into its own object so that it can be used in the other 3 places we will need to lazy-load images and manage their loading state with a placeholder.

At least allow the user to add it without repository info while still displaying the info for the default manuscripts.

Write basic initialisation to keep a window "blank", and then populate it at its current position in the workspace.

Implement a basic version of the workset selection modal that populates the with a window. List manifests, allow user to click one, close the modal and populate the workspace slot with a window.

From list of workspaces loaded into Mirador

The "viewer" now has a child called "workspace", which will store window layouts and work-space level settings, such as lock modes, previously active objects, the widget population of the "free form" or "scratch" space, and so on. All super-widget state is managed by the workspace.js file.

The workspaces directory contains instantiation objects for particular workspaces, including the "single image focus", "book reader", "details view", and "compare view". Workspace.js should provide only the structure and methods needed by all of these variations.

This includes:

• A model providing an array of open widgets (currently kept under the viewer object)
• A model of a workspace "slot", with its methods for loading, switching, and splitting.
• A model for defining the positions and possible transformations of these slots.
• Methods for registering events with the viewer object (notifying it of changes to open items, layout, which workspace is focused, etc.)
• Storing undo states?
• Registering workspace-specific event types (such as the synchronised zoom function for multiple-window layouts).

A crude version of this pattern is implemented in AnnotationLayer.js in Mirador. This is essentially what backbone provides, but we don't need the rest of backbone and backbone presents other complications. The basics of this pattern would be simply removing direct DOM-manipulation code and making sure all our objects have their data abstracted into a model whose fields are exposed only by getter and setter functions that broadcast events to the necessary subscribers. Children or views of controller objects only have their render functions called by the events sent from parents (except in particular appropriate cases).

Annotorious, annotator, etc

Also be able to query a db for annotations on a canvas based on the config.

From William Straub/HMML:

For example, according to WCAG standards, users should be able to utilize the keyboard (usually Tab key and arrow keys) to get to any of the menu items – mouse only web buttons and gadgets can be difficult or impossible for some users with disabilities to access

Useful in zen or other simplified modes

Provide feedback to user

Pair coding/experimentation. Up to two days.

Abstract module as a mixin as name.js in utils. Have a Getter and Setter Method, event publication method, model hash whose changes are observed, a way to add events as a hash.

Events as a Hash

 { "eventName" : [functionName], ... }

When the user initialises a new item, it is done from a workspace slot. Which slot is going to be populated needs to be stored or represented in a way that the manifest panel events can access it.

Initialisation and basic object with template.

Allow for finer grained updates to provide visual feedback to user

Rather than having all files flatly housed in a single directory, use directories to express the object hierarchy.