search

UniversalViewer / universalviewer

A community-developed open source project on a mission to help you share your 📚📜📰📽️📻🗿 with the 🌎
http://universalviewer.io
Other
500 stars 191 forks source link

Small screen (responsive) mode #352

Closed mialondon closed 2 years ago

mialondon commented 8 years ago

@edsilv I've typed up notes from a conversation with our UX manager, Donald Phillips, about the mobile/tablet experience (and narrow embedded view). I'll email to see if we can find time to meet together and work through the UX stuff this week.

This is an elaboration of issues touched on in https://github.com/UniversalViewer/universalviewer/issues/334 (but separate from the discussion there about how embedding UV items in an external site works e.g. specifying which page and what information is shown on load.

These suggestions will need reality checking, and are only designed as a minimum viable product for this phase of the product.

We thought designing three breakpoints would be tricky, so we've prioritised functions for a) screens up to 767 pixels, and b) those above. Those above 767 pixels get the default, desktop experience (for now). We've assumed screens below 320px are out of scope (as on other BL work).

Key functions to be available on small screens in this phase: On the screen permanently

Permanently available from the small screen view: i.e. might be available from a menu item, might be a modal overlay

Things available in desktop but not included in simple view:

mialondon commented 8 years ago

Donald can't get back onto github so I'm posting his notes.

Mobile principles Displaying content is prioritised over navigation and other page furniture

Support portrait and landscape views Support touch and gesture Support the most common mobile devices Tier 1, 90% of mobile traffic: iPhone 3+; Android 2.3+; Blackberry 10+ Tier 2, 10% of mobile traffic: Windows Phone 7+; Symbian/Nokia S60; Blackberry 6+; Android 1 to 2.2 Tier 3, <1% of mobile traffic: Blackberry 4 to 5; Nokia S40; WAP2/XHTML-MP phones

Mobile touch targets: Min. required Size: 7mm This is the diameter (for circular buttons) or the edge length (for squared buttons).

Min required distance: 2mm This is the distance preserved around the target.

mialondon commented 8 years ago 
UI feature          Small (320-767) Medium (768-1023)   Large (1024 +)
Title                   X               X               X
Description / metadata  -               X               X
Next & previous page    X               X               X
Current page and total number of pages  X   X           X
Thumbnail view          X               X               X
Single page view        X               X               X
Double page view        -               X               X
Index view              X               X               X
Zoom in /out            X               X               X
Rotate                  X               X               X
Navigator               -               X               X
Jump to beginning /end of doc-          X               X
Jump to a specific page / image -       X               X
Search                  X               X               X
Full screen             X               X               X
Settings:  Navigator on /off -          X               X
Settings: Two page view on / off -      X               X
Settings: Preserve zoom on / off -      X               X
Print                   -               X               X
Download                X               X               X
Share                   X               X               X
Embed                   -               X               X
mialondon commented 8 years ago

Removing the search result blobs and leaving the 'previous / next' navigation for search results would create a more usable experience on small screen devices. The screenshots are an extreme example (searching for a word in the title of a book is bound to produce too many results) but show the difficulty of using the blobs at small scale.

Mobile view (current Wellcome player): img_7459

Desktop view (current Wellcome player): search results wellcomelibrary_org_item_b24876732

mialondon commented 8 years ago

Two screenshots of responsive mode (mobile) for the current player used in Discovering Literature e.g. http://www.bl.uk/romantics-and-victorians (screenshots made with browser developer tools)

bl_dl_responsive_simpleview

bl_dl_responsive_moreinfo

mialondon commented 8 years ago

This thinking about the minimum viable functions in simplified viewing mode will also be useful for the 'side by side' view.

mialondon commented 8 years ago

Donald's mobile UX sketch mobile.pdf

mialondon commented 8 years ago

Sharing internal discussions on what should be included in in the first version of small screen (320-767px) mode for the sake of transparency...

Comparing the sketch above to https://github.com/UniversalViewer/universalviewer/issues/352#issuecomment-238549063 - it only has zoom in/out, rotate, next/previous page, More information and download/share.

  1. Should the title be on the main screen?
  2. I assume current page, total number of pages isn't in?
  3. I assume search within isn't in?
  4. I assume index view isn't in?
  5. Is full screen mode in?
sdellis commented 8 years ago

Thank you for sharing this with the community. I like the attempt to minimize the visual complexity on the mobile screen. Here are my suggestions:

Formalized Use Case It would be nice to formalize the use case for mobile interaction with these texts to be able to test and measure success. I presume 1) readability and 2) ease of navigation are priorities. With this in mind, I would actually default to 1-up (single page) view and use a gesture-based up/down scroll to thumb through the pages, similar to how Facebook works (along with countless other apps) .

Follow Convention Where do common mobile interfaces place similar functionality and menus? Putting any frequently used items like navigation or mode/view changes at the top is not easy to get to and is not common UI practice. I would say "more info" and "view mode switching (index, 2-up, 1-up)" should be at the bottom. There is no need for zoom or navigation icons/controls as they can all be gesture-based. I would also argue that Full screen mode should be the default and preferred case with mobile. Any interaction with an embedded/non-full-screen UV should open it in full screen, with the "x" to exit in the upper right to close back out.

Assuming reading is the main use case for mobile, I would argue to keep both title and current page/total pages on the screen for context, the way that the Kindle app does it. Share and Download can both be at the top as they are used less frequently (probably only once per object) and they have recognizable icons to save space.

mialondon commented 8 years ago

@sdellis thanks for your comments! I'm replying from a conference, so apologies in advance if my response is too hasty.

I'm wary of making design decisions on the fly, but we can definitely look at moving the icons to the bottom, making responsive mode more app-like.

We won't really know how people will use the mobile version until it's been live long enough to gather some data. Our main goal at this point, particularly given that we've only got a few days for this, is to ensure that people loading a page (for example, after following a link on Twitter or Facebook) have a reasonable experience and can assess whether they'd like to look at the item in more detail. I suppose I'd characterise the main use case as 'glancing' rather than 'reading' for now, but it will depend on where the UV is used - for collections items from the catalogue, or for 'highlight' images from articles in the content management system - and we'd expect it to change as we gather more data.

Introducing new gestures and methods of moving between pages is a bigger question that goes beyond responsive mode. We'll be considering it in in our next development phase, and I'd definitely like to discuss it with the wider UV community before we start that work.

Thanks for your comments!

edsilv commented 8 years ago

image

edsilv commented 8 years ago

Having a "MobileFooter" would be a nice approach in terms of config as well as UX. We'll have a single place to make config changes.

sdellis commented 8 years ago

@mialondon That makes sense, especially given your deadline. I love the example @edsilv provided above. Spot on. My only suggestion there would be to fill the entire space between the footer and header with the image/content, again to maximize readability.

jronallo commented 8 years ago

The main feedback I've gotten is that swiping would be a more natural way on mobile to change pages. I also understand that that could be a larger job and scoping the current to making the mobile experience usable is good.

One suggestion for @edsilv's mockup is to place the next arrow next to the previous arrow. If you're right handed curling the thumb back to reach the next arrow all the way on the right-hand side can be tiring.

edsilv commented 8 years ago

This is what I currently have:

image

Next/Prev next to each other could make sense... @mia?

Yep, swiping is probably ideal to navigate on a touch device - although this layout will appear below a width of 480 (mobile landscape), which could just mean the UV has just been embedded at a small size - not necessarily on mobile. So we have to accommodate mouse navigation (that's why the plus/minus buttons are back).

I've added a slight separation between those buttons and the info/download/share buttons as they represent different categories of interaction.

I can investigate gestures more in future. I think we're closing in on something workable for this sprint.

mialondon commented 8 years ago

A note re spacing of icons - apparently the BL doesn't have formal guidelines, it's 'usually dependent on the size of the target as the smaller the target the more space required - but 3-5mm for a 7-9mm button would be ok for an average finger size'.

jennpb commented 7 years ago

Hi @edsilv @mialondon I'm wondering if this is going to make it into a release anytime soon? Or if it has, and I've just missed it?

mialondon commented 7 years ago

@jennpb we have some work to do on our version as the page that hosts the UV isn't responsive, so you can only access it by going in and out of full-screen mode, but it is there.

jennpb commented 7 years ago

@edsilv As our /item/ page is responsive already, what would need to be done to deploy this new feature? Is there additional dev work to be done?

edsilv commented 7 years ago

@jennpb I'm currently working on getting a v2.0 release into shape. I recommend waiting until early in the new year when this should be ready before updating your deployment of the UV. It should be a drop-in replacement. But I think it's probably wise to allow a couple of day's work for testing things like Google Analytics etc. If your responsive page has a fluid design, the UV should automatically scale to fit and switch to mobile view below 640px.

jennpb commented 7 years ago

Thanks @edsilv and @mialondon.

BinaryRoads commented 7 years ago

It still jumps on mobile to the end of the page. Is there an estimated date for which the v2.0 version will be released?

edsilv commented 7 years ago

@BinaryRoads this is fixed on the dev branch. UV 2.0 is scheduled to be released Jan 2017.

mialondon commented 5 years ago

From Fluent's most recent usability tests:

NB we didn't get much data on mobile usage as responsive mode wasn't working properly on the test site when they did the testing

mialondon commented 2 years ago

@edsilv do you have a link for the current implementation so I can test on mobile and see if this is now redundant?

edsilv commented 2 years ago

https://universalviewer.dev