More on the Exploded Viewer
The long argument set out in Progressive Enhancement, Digital Objects and the Exploded Viewer can be boiled down to a shorter statement of the techniques for reconciling the different needs of page-per-thing and page-per-view:
- Publish a real web page for every view of a complex object (such as every page of a manuscript or book). This is the page that shows all the content of that particular view — transcription, translation, commentary, editorial — to the rest of the web, including to search engines, whose users don’t know where a digital version of a thing might live, or might not know the name of the thing they are searching for.
- It must be a real HTML page, not a JavaScript illusion. The text of that page must really live at that address. You’re making a server-side viewer.
- Use JavaScript on top of this base to create user experiences that feel more viewer-like, using the HTML 5 History API to reconcile a client-side generated view with the public URL for that view. The enhanced view is capable of bootstrapping itself from any web entry point into the object. When, and if, this mode takes over, it may cease making requests for the HTML pages and get the data to drive its views from other sources.
Further thoughts and conversations lead to more questions.
The article didn’t have much to say about design and specific user experience. What constraints on design does this technique impose?
I didn’t really go into design considerations because I don’t think it imposes any constraints at all, over the challenges we already have in presenting complex digital objects. It forces you to think more about the most accessible views, because you have to provide them for the technique to work.
The HTML version could look completely different from the JavaScript version. There could be multiple JavaScript versions suited to different types of content, or different audiences.
At what point would a transition to the JavaScript enhanced version happen?
I gave one example: detecting History API support as the trigger. But it doesn’t have to happen automatically at all, it could be offered to the user. You’re proud of the simplicity of your HTML view of an object, especially on its home page entry point. The JavaScript enhanced view might be an optional extra offered for users who want something more bookreader-like; it’s consciously invoked to provide a very different interaction. On the other hand, you may be just as proud of the fact that the HTML version and the enhanced version are indistinguishable in their static visual design; it’s only in the wider range of interactions, and the live feel of those interactions, that you sense the difference. Both design approaches work.
The technique sounds all-or-nothing, rather than progressive.
There doesn’t have to be a single transition point, from completely static to the state of the art JavaScript app. If you’re looking at a painting or a manuscript where fine detail is significant, you might want to introduce deep zoom capability into the static view if the browser can support it, without jumping straight to the most-enhanced mode. There’s no right answer here. It could be your default behaviour for certain classes of objects that the bulk of the view is provided by a server side rendering, with lots of per-view progressive enhancement but still a real web page transition from view to view; for other classes of object you could jump to a viewer type experience much earlier, because the material is better suited to rapid visual summary of many views, fast page riffling, and so on.
There is still the problem of focus mentioned in the original article and further explored in this blog post from 2017. The Exploded Viewer offers more ways of dealing with that problem.
When would this technique be inappropriate?
I think it may be problematic for objects with many views, with no content for each view other than a single image, and no likelihood of providing any new content in the future. An example would be a digitised book with no transcription. In this scenario, you’re still doing non-JavaScript users a favour by providing HTML-only access to the work, but the great benefit of exposing the textual content of the object to the web at the page level starts to work against you — you’re spreading potential hits for your object across hundreds of seemingly identical published web pages. This could be mitigated by providing more hints to search engines about what links to follow, of directing humans and machines alike to the object’s home page.
What next?
Examine existing partial or complete implementations of this technique, and try to poke holes in it! Science in the Making is a partial implementation:
