sammeltassen
commented
2 years ago Maybe this issue can be widened to include web accessibility standards. Thinking e.g. about adding support for keyboard navigation.
Closed tomcrane closed 1 year ago
sammeltassen
commented
2 years ago Maybe this issue can be widened to include web accessibility standards. Thinking e.g. about adding support for keyboard navigation.
tomcrane
commented
2 years ago As someone without access to a large monitor, I should still be able to use the manifest editor. As someone using a keyboard only, I should still be able to use the manifest editor.
The manifest editor might be better on a bigger monitor - more room to see IIIF content, thumbnails, browse other collections (#5) But its UI should not require a very high resolution.
What's our minimum resolution?
jpadfield
commented
2 years ago The ability to do this on a phone or at least a small tablet could be good to allow users to create content groups or manifests on the fly as they walked through a collection - useful for exhibition planning, creation of educational tours, etc.
I do not think this is a key or high priority use case at this stage, but it would be good to consider it as a possible future use case?
It might be that this functionality could fit in a separate piece of software that could then generate a list of resources for the editor work with ....
jpadfield
commented
2 years ago Minimal UI could work on a small resolution screen - two spaces: Left display selected thumbnails : Right display potential thumbnails Left display selected thumbnails : Right edit metadata for selected images or the manifest So this would seem possible on quite a small screen and these sections would not need to be equal in size. as resolution increases more options would become possible. the use of modals might also allow rich functionality on a smaller screen??
stephenwf
commented
1 year ago The current iteration of the Shell does have basic responsive support.
The left-panel is moved to a button on the bottom, which will open as an overlay.
And the right panel is in the button in the middle.
The "preview" button at the bottom does not currently work, but the responsive layout does give us a starting point to iterate.
The Manifest Editor is a content creation tool and does not need to be designed for very small displays like phones.
But it does need to work well on smallish displays, tablets and the like.
The old version got very cramped.
There needs to be a clear relationship between the (form-like) capture UI and the currently selected resource. There is no need to try to make everything editable all the time. What's editable is highly contextual.
We need to figure out what that means. How do you navigate around? The PowerPoint analogy works well for Canvases within a manifest, but the IIIF Presentation model is more complicated than that. How best to make editable things selectable and show just the contextual UI (driven by that resource's capture model)?
What navigable representation of structure is available beyond the list of canvases? E.g., ranges...