projectmirador / mirador-design Goto Github PK

Explore issues around introducing window minimization behavior.

Window minimization wasn't really relevant to Mirador 2's window slot-based system, but could be more desirable or even expected in a freeform workspace. The question was raised during the Mirador 3 kickoff meetings. On the other hand, it wasn't ever brought up as a user requirement in our user interviews or discovery process.

An implementation would likely include:

• Showing just the toolbar of a minimized window. This could be just at the bottom of the workspace viewport (the minimized window toolbar is automatically placed at the bottom of the workspace), or minimizing the window to its toolbar and letting the user be responsible for moving it in the workspace. Or, just removing a minimized window from the workspace completely.
• Including the minimized window's title in the workspace window list, with an indication that distinguishes it as a minimized window versus an open window (this is how the user would find a minimized window if it wasn't represented in the workspace at all)
• Search function (in the window list) that would help the user find minimized (or open) windows

Potential benefits

• Easier workspace management in a scenario where the user has many open windows and some of those windows are not immediately relevant to the user's task (e.g., it might be easier to minimize a window to make room for other activities in the workspace versus having to drag the non-relevant windows out of the workspace viewport)
• If minimized windows are represented by their toolbars in the workspace in place (i.e., a window is not moved when minimized), arranging a complex workspace could be made easier, in that the user could minimize a bunch of windows, rearrange them within a more compact workspace, and then return the windows to previous size when the rearrangement is complete

Potential drawbacks

• Window minimization becomes another requirement our windowing system would need to support
• Adds some complexity to the workspace management (from the user perspective), especially if minimized windows are not represented in the workspace (the user would have to recognize/learn that they can find minimized windows in the workspace window list)

Our initial thinking is that providing a window minimization option doesn't seem to be an especially critical feature, in that 1) it wasn't brought up in our user interviews, and 2) the user could always close windows not immediately relevant to their task and, if we provide a history of recently opened windows/manifests in the catalog, reopen them relatively quickly.

It would be helpful to see the logo represented (or did I miss it?). Also, in addition to the requireStatement there is discussion of changing the logo to provider in order to allow a label. This would provide a label with identity of the agent/institution providing the manifest, as well as the logo. See IIIF/api#1639

Next-prev navigation currently appears in 2 places:

• overlaid on the canvas
  
• in panels that show canvas-level content (metadata, annotations, layers)

In the panels, there are 2 patterns:

• prev : canvas label : next
  
• prev : # of n : next
  

Canvas label length varies dramatically - some examples:

• The Emperor Napoleon in His Study at the Tuileries
• page 84 (seq. 90)
• Beinecke MS 10, 23r
• 21
• cropped to image, recto, unframed
• Letter from Lewis Pelly, Belgrave Mansions, Grosvenor Gardens to Lord Elcho [9r]

Questions:

1. Confirm whether we need both nav locations (canvas and panel)? What is the effect if multiple panels are open?
2. Decide on canvas label location & treatment. Could it be added between the canvas buttons so it's visible even if the panels are closed (although those buttons are intentionally collocated to make back & forth a small mouse movement)?
3. ...?

The production releases of Mirador 2.X have provided an annotation tool with limited functionality and flexibility. Use cases have bene identified that call for expanded general functionality on the one hand, and very specific context- or project-specific functionality on the other. To list a few examples:

• authenticated annos
• annos created for public, private or group consumption/interaction
• tagging or classification requirements calling upon specific controlled vocabularies
• annotation of dynamic media objects such as audio or video

And so on.
Should not annotation therefore be based fundamentally on a plugin framework? Possibly with a generic annotation tool, but capabilities for selecting more specialised tools that might serve educational purposes, specific projects, etc.?
In the current design sketches an Annotation tool is presented as a core component rather than a plugin. hence raising the issue as a general question.

Regarding Layers:

• Some consideration should be given to how to set the initial state of an annotation via the manifest (behavior hidden, CSS, ?)
• Assuming the user can adjust opacity and perhaps even change the Z-order of the images on a Canavs, an option to 'reset' to initial state could be helpful.

Multi-Volume Works fall somewhere between Collections and Manifests. We didn't see any wireframes that specifically show MVWs. Is the "Catalog" view the way that MVWs will be supported?

I just clicked through the new mockup for viewing annotations and really like the design and functionality!

What I am missing is the possibility to search & filter all annotations across all canvases of the manifest.
At the moment I don't see how I could search for anything without already knowing the exact page on which I have to look, while a frequent use-case would be to open a book in the viewer and then look for annotations inside it - not on a specific page.

Apart from the search & filter across canvases option, it would be great to mark annotated pages in the page overview, as well as in the content structure. This would also help to find an annotation in a book without knowing on which page it might be.

Maybe I just didn't click on the right buttons and it's already there?

Would the ability to download an object as a TIFF or PDF be a separate plugin? We didn't see this functionality in the wireframes, but it's a feature we are interested in having.

While I understand that 'Manifest' is perhaps unclear to users, it might be worth a broader discussion in the community about how best to address this. We've seen some terms cause issues (e.g., attribution in the museum domain IIIF/api#1287 ).

It'd nice to be able to enter/edit SVG markups directly on annotations when existing shape editing tools are not enough (e.g. https://life-of-the-buddha-rails.herokuapp.com/mirador?manifest=1&room_id=1&canvas=http://manifests.ydc2.yale.edu/LOTB/canvas/panel_01&annotation=http://mirador-annotations-lotb.herokuapp.com/annotations/Panel_1_Chapter_1_Scene_1_5_English_Inscription )

@snydman mentioned wanting to implement gallery view this sprint. Revisiting the interactive designs, it seems like there are some questions that shake out:

• Should we display single canvases by default?
  • Or is there something about inferring v3 behavior from the manifest?
• How does view type affect sidebar panel behavior?
  • Should canvas metadata NOT be available while in gallery mode?
  • Can you select canvases in this mode? Does clicking on a canvas switch the viewer mode type? Does the notion of a canvasIndex exist in this mode?
  • Should the Canvas Navigation panel be accessible in this viewing mode?

I'm unclear on the difference between the three dots vs. the hamburger menu in particular and same icon appears to decorate the same window but obviously has different functionality. The tabular display icon is also a little bit close in appearance to the hamburger menu icon.

I might have missed it in the videos and mock-ups, but will keyboard shortcuts be supported? The designs don't really address zooming and panning yet, but I assume there will be keyboard and mouse support in those modes as well?

It'd be good to be able to override default labels (and their translations).

For example, while "next canvas" would be appropriate in some cases, "next panel" could be in others -- and more nuanced variations in other languages.

Not clear how workspaces or annotations can be done without authentication. I do not think that it is practical to allow anonymous persistence of state or annotations. Provisioning sign in and a profile should be considered in the base design of the UI, even if authentication might be part of a Mirador ++ full featured package as an optional component.

@glenrobson brought up in Mirador session about filtering by language

The image/window manipulation icons are all very clear except for the "lock zoom" icon, which looks to me like an "add new folder" icon of some kind. A padlock-and-plus-sign combination of some kind would make more sense.

Assuming features such as adding images to a canvas and modifying images on a canvas are not going to be part of initial Mirador 3.0 scope, it would be good to understand how a plugin designed to perform these functions would be seamlessly added into the application and how the design supports such extension points (without having to create a completely different layers dialog).

Originally posted by @beaudet in #6 (comment)

AnnotationCollections are subdivided into AnnotationPages, which may be necessary for large annotation sets. Will this be handled behind the scenes (e.g., continuous scroll/lazy loading) or in some other way?

Brought up in Mirador session, can you promote an annotation as a first class window.

Will it be possible to drag windows/albums to different positions within the workspace, or will they be stuck in the order they were loaded in? I can imagine wanting to drag two windows together for side-by-side comparison, and I think that should be made as easy as possible. I can also imagine users wanting to resize windows relative to each other, rather than simply zooming in on one at a time.

In the Catalog mockups (19), there are tags for the album. Where are those coming from?

It would be interesting to see annotations with highlighting and tagging motivations represented.

In the first video/mocks, the menu drop-down from the hamburger appears to be semi transparent. I'd be cautious about this due to legibility/accessibility.

copying ProjectMirador/mirador#1580 here as advised on slack:

In the new system we're developing (on library.bdrc.io), we'd like to represent the outlines of a work as a collection of collections (or in the most simple cases, collections of manifest). We would have no real limit to the depth of our collection tree. Is there a plan to support that data structure?

This is a minor detail, and likely out of convenience or lack of appropriate icon. However, just mentioning it because it could be slightly confusing.

Regarding the filtering functions for annotations--much welcomed. Ideally the list of categories would represent only those motivations that are potentially available. This could be determined, for example, through some local configuration parameter, or possibly from parsing the known annotations for 'motivation' or 'purpose.'

Annotations for an object might exist in more than one location, i.e., more than one annostore; individual locations might support different sets of motivations; and they might also provide their own associated IIIF content search endpoints (and such an endpoint might be different from that identified in the manifest currently being viewed).

Should functionality for annotations include a notifications mechanism for querying a notifications service (or services) for third-party annotations? If a third party's annotations are identified this way, and are searchable via a IIIF content search endpoint, should the location of that endpoint be returned by the notifications service? How, then would M3 negotiate searches when more than one search endpoint is pertinent?

Right-to-left and/or top-to-bottom directions, are those being considered for the menu system and display of annotations?

Going through the designs, I don't have a solid feeling for how navigation within albums is meant to behave. Especially for a "book" view, there is a significant departure from the current designs that places more emphasis on the interface for viewing single canvases/images. For example, there is no "thumbnail" view that I can see, and I'm not sure where "manifest" navigation ends and "collection" navigation begins. It makes sense that they would be integrated, and this distinction would be hidden from the user to a certain extent, but that's not the impression I got from this video. Would the user's current position in the album be represented in the window or in the global sidebar?

There are quite a few remote resources coming in all the time with different UI representations. Right now some have placeholders and some don't, and soon we'll need some design guidance to start thinking through the technical implementation. I will try to list all those I can think of here, with some context. As a general approach to these interactions, I'll propose the following requirements for asynchronous resources (feel free to say otherwise though):

1. Any user action should produce an immediate result in the UI.
2. The resulting UI change should communicate the eventual result of having initiated this request for remote data, for example, by placing a stand-in shape for the UI element that will eventually present the data.
3. As far as possible, placeholders should exhibit object constancy, approximating the shape, layout, and size of the objects they represent, avoiding flickering, teleportation, disappearing, or other disorienting effects.
4. Placeholders should have all states of the request represented. (initial, pending, received, rendered, failed)
5. Elements should provide pleasant and unobtrusive transitions between the request states, to avoid the jarring visual effect of text, icons, or shapes suddenly jumping in and out of existence.

Objects with Asynchronous States

Windows

When the user opens a window, the manifest might still have to load. So the title, index information, and thumbnail outline (number of canvases, their size and order) will not be available. But the containing box and some interface elements can still be rendered. #1748 comment

Image Canvas

Initially, it will be blank when advancing the page or opening a window until the initial tiles have loaded.

Thumbnail Strip Thumbnails

Annotation Pages

Search Results (and result pages)

Manifests in the Catalogue

There is some added complication of having the url and no other data on initial load, possibly with location information(?) #1834 comments.

Canvas Thumbnails in the Catalogue

Proxy Representations

Some UI elements serve as proxies for "real" elements, and may have their own request state in addition to representing the request state of a different resource.

Image Layer Thumbnails

Image layers have a thumbnail to represent the canvas sub-resource they control, but they also need to show the loading state of the layer they represent. See the Mirador 2 advanced features demo for an example of this. Layers Demo

Annotation List Segments

This depends on the implementation, but thumbnails of annotation regions might have a different request cycle than the annotations themselves, so this should

Global States with Asynchronous Aspects

There are some other, less object-specific asynchronous states of a more abstract or global nature, such as potential auth states (depending on how those eventually get designed). Here are some that might be relevant.

• The openseadragon canvas is not fully rendered on zoom (still waiting for some tiles to render). Do we want some type of understated spinner or status indicator the user can usually ignore, but check if they're not sure whether the image is just low-res or still loading?
• Collection pages need to be retrieved before the list can be rendered in the catalogue area, or TOC area of windows (for multi-volume works(?)).
• The initial load of the workspace is still retrieving resources it needs to begin building (depends on implementation details). For example, if we decide to load manifests before populating a crowded workspace with blank windows, or if there is a remote config that needs to be retrieved.

I was reminded by looking at some of the placeholder tickets and comparing with existing behaviour that there was a lot of demand for deterministic manifest ordering in the catalogue list. Was this captured anywhere? If so, I think manifest ordering has some implications for the placeholder behaviour as well.

Most of the mobile apps or sites I enjoy using tend to have the most frequently used button in the lower right vicinity of the screen, sometimes even physically removed from a main menu (as in Google Mail/Drive/Maps, Twitter, Telegram, Outlook, Lyft, etc.). Also, it seems not uncommon to omit the product or company logo from the main menu to save space on small screens.

Doing both of those would make room in the main menu for other things, and while I understand the goal is "minimal visible controls", a main menu with only the "menu expand ellipsis" and "full screen" seems sparse. To be honest, even the desktop main menu seems a bit sparse to me. Would it be appropriate to have "settings" or possibly "share/save" or "download/export" in the main menu?

Also, can the main menu bar always be displayed on mobile, even when the user moves through the catalog or workspace? I notice that the menu disappears sometimes.

Extracted from ProjectMirador/mirador#1794 so we don't lose it

We definitely want to preserve aspect ratio. The question (to me, anyway) is whether we limit horizontal width in some way to prevent horizontally-oriented logos from consuming too much topbar space (and whether we omit display of logos at some viewport or window width to gain as much topbar space as possible where topbar space is limited).

Here are a couple of examples of horizontally-oriented logos from our existing fixture list:

http://beta.biblissima.fr/iiif/manifest/ark:/43093/desc57cb76cd3739a24a9277b6669d95b5f3a590e771

https://gallica.bnf.fr/iiif/ark:/12148/btv1b10022508f/manifest.json

Not currently in our fixture list, but another example:

https://iiif.harvardartmuseums.org/manifests/object/299843

This requires a database or an application that understands the request. Probably not part of the default experience, but a plugin that a developer can hook into?

The design could show the Manifest as a member of more than one Collection.

I wonder if the requiredStatement should be represented here in the information side panel.

See: https://iiif.io/api/presentation/3.0/#requiredstatement

In Mirador 2.0, we made a conscious decision to call the search box a "filter" because the code is not searching every string in the manifest. It is only doing a filter on some elements in the HTML. In this case, just the title and the source. I don't want users to think they are getting a discovery environment within the catalog find and filter area.

Currently we load asynchronously and don't sort unless configured to load in the order they are provided to Mirador. Also, the last opened sort could be problematic because where is this information stored? This feels like a specific use case if Mirador is part of a larger application with a database that powers it and not part of the core Mirador

Here is a checklist from the specifications for client requirements. I've tried to fill it out from the mocks, but not every feature is clear as to the relationship with the specifications

• Clients must render label on a Collection.
• Clients must render label on a Manifest.
• Clients must render label on a Canvas
• ... and should generate a label for Canvases that do not have them.
• Clients must render label on a Range.
• Clients should render label on an Annotation Collection.
• Clients must render metadata on a Collection.
• Clients must render metadata on a Manifest.
• Clients should render metadata on a Canvas.
• Clients should render summary on a Collection.
• Clients should render summary on a Manifest.
• Clients should render summary on a Canvas.
• Clients must render requiredStatement on every resource type.
• Clients must render provider on a Collection.
• Clients must render provider on a Manifest.
• Clients should render provider on other resource types.
• Clients should render thumbnail on a Collection.
• Clients should render thumbnail on a Manifest.
• Clients should render thumbnail on a Canvas.
• Clients should render thumbnail on a content resource.
• Clients should process viewingDirection on a Collection.
• Clients should process viewingDirection on a Manifest.
• Clients should render homepage on a Collection, Manifest or Canvas
• Clients should render rendering on a Collection, Manifest or Canvas
• Clients must process items on a Collection.
• Clients must process items on a Manifest.
• Clients must process items on a Canvas.
• Clients must process items on an Annotation Page.
• Clients should process items on a Range.
• Clients should process structures on a Manifest.
• Clients should process annotations on a Collection
• ... Manifest
• ... Canvas
• ... Range
• ... or content resource.

Annotation creation/management/discovery modelling for M3 thus far focuses on images. Given support for additional media types in the Presentation API, should annotation support extended to other media types, particularly audio and video?

For a rather large corpus of Asian manuscripts and a few modern editions, it would be a very noticeable improvement (over Mirador2 and UV) to have a mode where all the images are displayed vertically. Diva and the Internet Archive viewer have this feature and it makes reading very smooth, while our (BDRC's) users report a rather poor experience with Mirador and UV.

An example with the Internet Archive viewer:

https://archive.org/details/bdrc-W4CZ57131/page/n7

For an example with Diva go to

http://library.bdrc.io/show/bdr:V22084_I0886

and click on "View images in Diva". That kind of display would be a tremendous help to many Asian users!