projectmirador/mirador

An open-source, web-based 'multi-up' viewer that supports zoom-pan-rotate functionality, ability to display/compare simple images, and images with annotations.

mirador's Issues

Spend at most a day researching higher-level publication pattern for Event system

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?

Re-render the corresponding template element with the result of ajax requests.

Fix CSS for scrolling

Bind events so that clicking the workspace slot invokes the workset selection modal

Open image view from window UI and manifest panel UI

Scaffold new folder structure for m2, making the object hierarchy more accessible.

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

Break out image loading code into the imagePromise module for re-use.

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.

Port over image view code from mirador rc.

Represent dummy workspace slot origination for window to be opened.

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.

Work out a consistent "init-bind-update" cycle for the way application components share data and manage their own event-binding and lifecycle.

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).

Event mixin

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], ... }

Implement logic to handle the whimsical "service" attribute, which may be in either the "resource" hash or the resource.default hash.

Add facility to viewer initialisation to add workspaces, delegate widgets.

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.

Template for workset selection modal

Initialisation and basic object with template.

Keyboard accessibility

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

Store whole manifest at top-most level, store (after querying) what's needed for each widget on a per-widget basis.

Handle duplicate manifests gracefully

Provide feedback to user

Refactor templates

Allow for finer grained updates to provide visual feedback to user

write complete configuration object for each coordinate system use-case example, with annotation.

Set up automatic demo instance.

Change manifest IDs in top-most level to use the URI as id.

Render new manifest list items from "add from URL" bar.

Display first few images of an object in manifest panel

Clean up configuration options to reflect new mocks/plan

Write the basic workspace.js controller/constructor for workspaces.

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).

Detect changes to null values in template data structures.

Tool panels should shrink the OSD canvas.

Bind events and implement destroy process for workset select modal that populates workspace from clicking the manifest list item.

Change manifest list item template to represent "blank" state.

HTML/CSS

Bind events on the manifest label to open a thumbnail view.

Clean up CSS

Remove unused CSS from 1.0

Refactor main menu toggling

Overflow issue in Manifest Panel

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.

Store and delegate state of tool panels (TOC, thumbnails, metadata)

Finish markup structure and initialisation of manifests panel.

Research queuing asynchronous events and setting listeners on their states.

Pair coding/experimentation. Up to two days.

Live updating of manifest panel UI according to asynchronous process status.

Polish css for manifest listing.

Fix overflow scrolling in thumbnail view

Choose workspace type

From list of workspaces loaded into Mirador

Workset Selection Modal Populating 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.

Initialise window object inside a workspace slot

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

Import mirador 1.0 window code in minimal form, to initialise a thumbnail view.

Check for repository info on addFromURL function.

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

Allow for different annotation engines

Annotorious, annotator, etc

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

Search/filter manifests

Disable workspace select window if only one workspace available

Useful in zen or other simplified modes

Display repository logo in manifest panel

Fetch the template data with correct structure but null values.

Revise workspace code to integrate event system research.