Open ggeisler opened 6 years ago
ggeisler
commented
6 years ago Based on discussion 3/20/2018, it might be more straightforward implementation if we dispense with steps 1 through 3 in favor of a way for the user to just invoke the Mirador viewer and use the load window approach to select items, and then configure the desired viewer state and save it.
Potential drawback is the current complexity of finding and loading items but that could improve with Mirador 3.
mejackreed
commented
6 years ago The load window could also present problems here as it may trigger a large number of requests which could be problematic.
Whatever solution is taken, I think we will have to implement completely wrapped within an iframe as Mirador will cause styling issues without doing so. This may also prove difficult for translation purposes if that is needed here.
ggeisler
commented
6 years ago Below is an updated design. The biggest change from the original design above is to use a modal window for customizing the viewer options. This change enables us to simply other aspects of the configuration.
Although configuring the Mirador widget will be more involved than other widgets, selecting it follows the same pattern:
We'll add a new widget button icon to the widget selection panel. Since the design assumes both exhibit items and IIIF items from outside the exhibit can be used, I'm not sure which section of the panel the icon should be added to, but I'd lean towards the "Exhibit item widgets" section.
When the user selects the Mirador widget, the initial configuration panel looks like this:
The numbered sections below correspond to the orange note indicators in the mockups.
This widget displays items in a Mirador viewer, which enables exhibit visitors to view and compare images in a zoomable, interactive environment. Optionally, you can add a heading and/or text to be displayed above the Mirador viewer and a caption to be displayed below the viewer.
The proposed design for item selection differs a bit from how we offer item selection in other widgets, because we want to enable the use of IIIF items from outside the exhibit, in addition to exhibit items.
The radio button group above the item input enables the curator to indicate the type of item she wants to add; the input shown should change based on the selected radio button. The "This exhibit" choice example shown in the mockup above is the same autocomplete input we use for other widgets that feature exhibit items.
If the curator instead selects the "IIIF manifest" radio button, the input changes to this one (we'll use a different example URL than in the mockup):
When the curator selects the "Load IIIF item" button, we follow the provided IIIF manifest URL and show the item specified in the manifest in an item panel the same way as with an exhibit item, with a thumbnail, item title, and the manifest URL:
If there is a problem with the provided manifest URL, show an error message similar to this:
(This is pretty generic, but I'm not sure what kind of responses we get when parsing a manifest URL. If we can distinguish between a URL not found versus a malformed manifest, etc. we could be more specific with the error message.)
Finally, unlike the other widgets where we allow unlimited items to be added to the widget, here I think we should limit the number of items to four. So after the curator adds a valid fourth item, a new item input should not be presented beneath the fourth item. If one of the four items is removed, then the new item input should be shown.
As soon as one item has been retrieved and shown in the item panel, show the "Preview and configure viewer" button in the panel sidebar area, at the top of the sidebar area, next to the first item panel:
Here's how things look when two items have been added:
Selecting the preview button launches a modal window with the item or items that have been added in a Mirador viewer with the default saved state for this configuration. That is, the selected items shown with our default viewer customizations (no close window icon, no load slot icon). The intro text is:
The Mirador viewer will be displayed to exhibit visitors as shown below. Optionally, you can customize how the viewer will be displayed by adjusting one or more viewer options and saving the changes.
Available Options
- Change page (multi-page items)
- Adjust zoom-level
- Change view type
- Show/hide contents sidebar
- Show/hide thumbnail strip
There are also a couple of checkboxes at the top of the list of available options. The first checkbox has the label "Enable public annotations" and controls whether we show the annotations icon in the viewer windows. The second checkbox, "Display by default," controls whether we show the annotations open in the viewer (versus requiring the user to click the annotations icon to display them). The second checkbox is nested under the first.
The first checkbox is checked by default. When unchecked, we hide the annotations icon in the viewer and the nested checkbox should be disabled, otherwise it is enabled.
The nested checkbox is not checked by default. If checked, we configure the viewer to show the annotations open in the viewer windows, otherwise the user has to explicitly use the annotations icon to open them.
The curator can adjust the options above and when she selects the Save changes button we save the current state of viewer, so that that state of the viewer can be used when loading it for exhibit visitors on the rendered page.
(What happens if, after configuring and saving the changes to the viewer, the curator chooses the "Preview and configure viewer" button again? Ideally, we could first check and see if the selected items in the configuration are the same ones, in the same order, as in the saved viewer state. If so, then we display the modal with the saved state of the viewer. If that isn't feasible, I think it is acceptable to load a fresh, default state of the viewer each time the curator selects the "Preview and configure viewer" button.)
The "Close" button should close the modal (not the widget configuration panel) without saving the state of the viewer (beyond the default saved state).
These are optional fields similar to other widgets, except 1) the Text field is displayed above the viewer, rather than to the right or left of it, and 2) the Viewer caption field is centered text shown below the viewer.
The mockup below shows the rendered feature page based on the configuration shown in the previous mockup (plus some adjustments the curator made in the Mirador viewer configuration):
For a realistic example, the Mirador widget here (Note A) is shown after an existing widget. The optional heading (Note B), description (Note C), and caption fields (Note E) were used.
The viewer is always shown full-width (we can limit the width of the description field to a more readable width via CSS). In this example, the sidebar for the feature page is turned off. If the feature page does not have the sidebar turned off, the same layout is used, it just has to fit in the 9 Bootstrap columns rather than 12. We'll probably have to experiment a bit to figure out the ideal proportions for the viewer (i.e., how tall it is with a one-row layout, how tall if the layout uses 3 or 4 items).
Note D shows how the curator has used the viewer configuration step to show the side panel for one slot, and zoomed in on the document in both slots. At this point the user can manipulate those options, but their initial state is determined by the widget configuration done by the curator. Unlike the Mirador viewer on the item show page, the user should not see the close window or slot manipulation icons.
jkeck
commented
6 years ago @ggeisler two questions that came up when looking over the design.
ggeisler
commented
6 years ago @jkeck Good questions.
What should the window/pane layout for Mirador be when the user has selected 3 or 4 items (e.g. are they always supposed to be side-by-side or does some number indicate a grid should appear).
The 3 items case is where we're imposing a possibly controversial constraint, in that we're saying if you have three items, you can't show them as 3-up (all in same row) and the one that takes the full width of the row is always in the bottom row. But this seems like a reasonable constraint for a first iteration of the widget and we can see if we get feedback from curators that suggests we need to add some form of layout configurability (assuming this makes sense to you).
Should we have the display/show checkbox in the case of the mirador widget?
I think you're right that this is potentially more problematic here than in other widgets. Let's just take the checkbox out. I don't think we're inconveniencing the user too much by removing it.
The re-order I'd like to keep if possible, just because of, say, the 3 item case, where the curator realizes that the first item is the one they want in the bottom row (after seeing the layout). It would be nice if they could just move the first item to the end rather than having to delete and re-add it.
I think this will work okay, user workflow-wise, if we reset the viewer configuration to the default state if they reorder items. It will be inconvenient if the user has done a bunch of viewer configuration and now has to redo it, but at least they don't have to delete and re-add the item.
caaster
commented
1 month ago A thorough review of this ticket is warranted to make sure this is still the correct approach and specification, to satisfy the 2024 Business Value Priority of: Create (Mirador?) widget that allows for comparison of at least 2 but up to 4 different images
This is essentially a replacement ticket for #415, because the proposed design is now substantially different and there is a lot of previous discussion in that ticket that might make discussion of this newer design harder to navigate. #415 does have a good definition of user requirements from @blalbrit so while I'm going to close it in favor of this ticket, see #415 for more context and previous discussion of requirements.
Widget selection
Although configuring the Mirador widget will be more involved than other widgets, selecting it follows the same pattern:
We'll add a new widget button icon to the widget selection panel. (If we support any item with a IIIF manifest URL, as the design below suggests, I'm unsure if the icon should go in the "Exhibit item widgets" section or the "Standard widgets" section; probably in the "Standard widgets" section, unless that can only be done in the Spotlight, rather than Exhibits, codebase.)
Configuration - Initial configuration panel display
When the user selects the Mirador widget, the initial configuration panel looks like this:
It's a more involved configuration than the existing widgets so the configuration is broken up into four steps. The numbered notes below correspond to the orange note indicators in the mockup.
The proposed design for item selection differs a bit from how we offer item selection in other widgets. If we could dynamically show exactly the number of inputs that match the layout selection in Step 1, that would be ideal. We could also follow the existing approach of showing only one input, and when it is successfully used to make a selection, show an additional input. If we do that, we'd ideally limit it such that a new input is not displayed after four are already selected.
The goal for the item inputs is to provide autocomplete for exhibit items (as with other existing item widgets), but also accept a IIIF manifest URL to find an item (so that the curator can, for example, compare side-by-side an exhibit item to an item outside the exhibit). (We want to support both methods with the same input, ideally, but we can discuss more if this isn't possible.) When an item is found, we show the draggable card for the item as we do now for other widgets (as shown in the mockup in the next section).
If the user selects more items than the layout selected in Step 1 needs, we just ignore the additional items.
If the user doesn't select enough items to fill out the selected layout, I think we just leave the unspecified slots empty. Presumably the curator will see the problem when the page is rendered and re-edit to fix.
At this point, we have enough information to save a Mirador viewer configuration (if and when the user saves the feature page) with the selected layout, selected items, and the default configuration options. So this step is optional.
This is optional text similar to other widgets, except 1) the Text field is displayed above the viewer, rather than to the right or left of it, and 2) the Viewer caption field is a free text field that is centered below the viewer.
Configuration - In-progress configuration
The mockup below shows how things would look for a curator who has chosen a 2-item layout (note 1), selected two items (note 2), added some optional text (note 5), and has selected the "Configure viewer" button to begin configuring the Mirador viewer (note 3):
When the curator selects the "Configure viewer" button it opens the Mirador viewer in the default configuration (first page of document shown, side panel closed, etc.) and selected layout. The curator can then interact with the viewer to change, for each slot, the displayed page of the document, its zoom level, the view type, and whether the thumbnail strip or side panel are opened. The curator should not have access to the close window or slot manipulation icons.
When the curator selects the "Save viewer configuration" button (note 4), the current state of the viewer is saved. This state of the viewer is then used when showing the viewer on the rendered page.
Selecting the Note 4 Cancel should close the viewer (not the widget config panel).
Rendered page
The mockup below shows the rendered feature page based on the configuration shown in the previous mockup (plus some adjustments the curator made in the Mirador viewer configuration):
For a realistic example, the Mirador widget here (Note 1) is shown after an existing widget. The text (Note 3) and viewer are always shown full-width (acknowledging that full-width text is not ideal UX...). In this example, the sidebar for the feature page is turned off. If the feature page does not have the sidebar turned off, the same layout is used, it just has to fit in the 9 Bootstrap columns rather than 12. We'll probably have to experiment a bit to figure out the ideal proportions for the viewer (i.e., how tall it is with a one-row layout, how tall if the layout uses 3 or 4 items).
Note 4 shows how the curator has used the viewer configuration step to show the side panel for one slot, and zoomed in on the document in both slots. At this point the user can manipulate those options, but their initial state is determined by the widget configuration done by the curator. Unlike the Mirador viewer on the item show page, the user should not see the close window or slot manipulation icons.