Add enhanced gesture support

[sdellis]

No description provided.

[cmmills]

I think instead of deciding on a gesture library to implement maybe we should start defining what gestures and the corresponding action we want to support. Here is a list I have so far, distributed by page modes.

Single Page Mode

Pan - Pan around image, redraw
Swipe left/right - ?
Transform/Pinch - zoom on page
Rotate - rotate image
Press/Tap and hold - ?
Tap - ?

Two Page Mode

Pan - change page based on direction, unless zoomed then pan image and redraw
Swipe left/right - change page
Transform/Pinch - zoom on page, switch to single page mode as well?
Rotate - ?
Press/tap and hold - ?
Tap - ?

Thumbnail Mode

Pan - Scroll around thumbnail viewing
Swipe left/right - ?
Transform/Pinch - zoom in or out, resizing thumbnails
Rotate - ?
Press/tap and hold - Open image
Tap - Open image

[sdellis]

This is a good start. I suggest we stick closely to popular e-Reader (Kindle App... what else?) conventions, particularly for Single Page mode. There are a few other gestures that may be useful, depending on what functionality we want to support now and in the future.

For example, if we want to support the reading or creation of annotations at some point then we should think about what gestures to reserve for that - typically Tap might be used in Single or Two Page mode for following links or reading annotations. Likewise, "Press and Hold" or "Press and Drag" might be used to select/highlight text or a region to create. Another feature might be an Edit/Author mode for authorized users, which may have its own set of gestures. We may also have gestures work differently depending on the region (tap at top may bookmark, while tap at bottom may toggle controls)

Have you seen the latest demo of Mirador2? It's an interesting use of OpenSeadragon "collection" feature. It also has "reader" vs. "comparison" modes.
http://sul-reader-test.stanford.edu/m2/

[cmmills]

It could be difficult to offer expansive gesture options if we are trying to achieve expansive; iOS, Android, and Win8, support in browser.

Those examples are legit for sure, and as you said expectations will be mode and/or regionally specific.

Maybe we need to figure out what modes we want to support, then the regions of those modes and then start mapping gesture functionality? Just a thought.

Mirador is interesting, are you suggesting the addition of a "compare" mode? I am interested where this might be heading.

[sdellis]

Actually, I wasn't suggesting the addition of a "compare" mode. I think Mirador's use case is more of a "scholarly workstation" - BookReader on steroids type thing. I think there are a number of different, more basic use cases, that it doesn't address. I don't want to redo what Mirador already does well, but where it falls short right now (albeit it is still being developed) is on mobile devices and accessibility (to some degree). And, yes, I could see the three modes you suggested, with three other possible modes that would fill in a few more gaps (probably as a phase 2):

1. Reading Mode
   If I'm looking at image-based facsimiles of analog bound-objects/manuscripts, then Mirador does a pretty good job. However, if I want a better "reading" experience that is similar to eBook Readers for reading transcriptions, translations, digital-born texts, and such on a variety of devices, then I'm out of luck. A "page" on an tablet may translate to several pages on a phone if you want to optimize font-size and layout for legibility. In fact, I wonder how one is supposed to handle such cases if adhering to the Presentation API, which assumes a single canvas per page?

2. Presentation Mode
   I could see this as a Reveal.js style Presentation viewer. It could even have some "websocket" or "near field communication" feature which would be useful for controlling conference or classroom presentations (computers hooked up to projectors, or student/audience devices) from a mobile device.

3. Authoring Mode
   Basically a way to create basic settings like start page, directionality, add/arrange/remove pages (with or without images), create a TOC, and save the manifest object to some persistent storage.

For me (and Princeton), I think Authoring Mode would be the highest priority after basic functionality, although I understand Oxford is developing a Presentation Authoring tool. I am also interested in checking out the Code4Lib 2015 presentation on the existing open source PageTurner options and usability studies in February. Lots going on in this area!

Come to think of it, the above functionality sounds like BookReader on steroids. :) Perhaps we should consider an architecture that would allow for custom builds so the user can decide which "modes" and other modules to bundle.

[cmmills]

Good to have the convo now, I am thinking along the same lines as this is a reader first.

Maybe the what you described above are more appropriately "modes" while what I described are "views". Meaning "Reading Mode" could be used in either single page or two page view.

I wonder also are we heading towards support for epub right away or sticking with image-based multi page documents.

I am thinking too this is heading into the pluggable architecture, modules and such.