Page MenuHomePhabricator

Add an image: Investigate building mobile onboarding pop-ups on top of GuidedTour
Open, HighPublic

Description

Investigate how easy/hard it would be to build the mobile onboarding pop-ups (task https://phabricator.wikimedia.org/T290780) shown in the Add image prototypes on top of the existing GuidedTour (which is currently desktop-only).

Event Timeline

Changes needed to GuidedTour

  • T264817: Improve GuidedTour performance
  • Update icons — the set of icons used in GuidedTour is different from the current OOUI icons so the UI will appear inconsistent if they aren't updated. This can probably be updated either upstream or overridden.
  • Support scaling the guider to be within the viewport and/or margins. This isn't unique to mobile per se (see screenshot for the issue on desktop) but this issue will likely to be more prominent on mobile where the viewport is much smaller. (See this issue on Guiders-JS upon which GuidedTour is built). Ideally we'd be able to specify a margin as well to exclude certain areas that should never be covered even though they are within the viewport (for example, the image inspector).

guidedtour.png (862×1 px, 137 KB)

  • Support responsive widths for guiders — currently the guider width is 400px, which will be too wide for many mobile devices (See this issue on Guiders-JS upon which GuidedTour is built)

Screen Shot 2021-09-21 at 1.57.26 PM.png (1×746 px, 102 KB)

  • Figure out a way to opt in to GuidedTour from mobile site. It does show up when the default skin is Minerva (loading desktop site), but not when the mobile site is loaded.
  • Support scrolling within the guider if the content overflows (?) The current behavior is the guider doesn't scroll so the guider can only be dismissed by clicking outside it. While highly unlikely to happen on desktop, this might be more of an issue on mobile (see below).

Screen Shot 2021-09-21 at 3.23.47 PM.png (632×1 px, 208 KB)

Usability concerns
In addition to the implementation challenges, I have some concerns about accessibility and usability.

Using dynamic type (to show larger text) is fairly common on mobile. We do support relative font sizes — if the user has larger font set, the UI text (both font size and line height) would scale accordingly. This can be problematic in our particular use case where we have a fixed bottom element (for example, the suggestion reason in the image inspector) which then limits the amount of space available for the guider and could lead to the guider covering up the entire screen (which seems to defeat the purpose of having in-context guidance since the user is losing the overall context). When the base font size increases, the available space for the guider decreases while the guider itself requires more real estate.

I did a quick comparison in the current prototype on an iPhone Mini (high-res images here). Even with just a difference between a factor of 1 and 1.1 of the base font size, the real estate of the tooltip increases rather dramatically (and even more so in Russian than in English).

tooltip_comparison.png (3×2 px, 1 MB)

Some non-ideal ways around this:

  • Don't scale the text—this goes against the user's preference as well as the a11y guidelines. The user can zoom on their device to make the text larger, but they would then lose the context of the guider.
  • Enable scrolling within the guider if the content overflows—this might not be that user-friendly since the user may not be aware that the area is scrollable and is not a very common pattern. On the other hand, users who have extra large text accessibility preference set might already be accustomed to having to scroll.
  • Wait and see—perhaps this isn't really that big of an issue for us right now since mobile devices are larger nowadays (although our users might be using older/smaller devices) and we're only starting w/Portuguese, Spanish, Arabic

Screen readers
When a tooltip is shown, its content is "announced" to the user (via live regions). This makes sense in the context of tooltips that are opened in response to an action initiated by the user, for example, focusing on an info icon. However, in this case, the tooltip appears automatically so a screen reader user would not have any context as to why the content is being annouced.

Guiders.js (the popup library used by GuidedTours) is abandoned (last change is five years old), neither the code quality nor the feature set is great, and guiders are a common use case which plenty of people have written code for, so we might want to look at current high-quality third-party guider libraries before investing much effort into modifying the current one.

Guiders.js (the popup library used by GuidedTours) is abandoned (last change is five years old), neither the code quality nor the feature set is great, and guiders are a common use case which plenty of people have written code for, so we might want to look at current high-quality third-party guider libraries before investing much effort into modifying the current one.

Do you have any particular third-party guider libraries in mind?

I briefly looked at https://github.com/usablica/intro.js (played around w/the demo on a mobile device, I haven't looked much into the code). The library does support element highlighting but the mobile experience (even in the demo) is still not ideal—for example, the guider gets cut off (it looks like the scroll offset calculation doesn't take into account the height of the element + that of the guider).

IMG_1811.PNG (2×1 px, 1 MB)

https://github.com/shipshapecode/shepherd looks promising, but from the official guide, they only support recent (last 2) versions of Chrome, Safari, Firefox and no IE (Edge only)

I haven't done any kind of serious evaluation but just from some googling "big names" are intro.js (mobile issues aside, AGPL so probably couldn't use it), Popper/Shepherd (has an aggressive browser compatibility policy), and Hopscotch (unmaintained). There's also Tourguide but that seems too opinionated on design. So nothing jumps out as a great option (although of course there are plenty other libraries).

Our policy is current and previous version of Chrome/Firefox/Opera/Edge, IE11+, Safari 9.1+, iOS 9+, Android 4.3+, with IE11 support being somewhat limited. Popper says "supports modern versions of Chrome, Firefox, Safari, Edge. IE11 works with some polyfills." and "On new releases, we may add more modern functions that require new polyfills, or positioning behavior may break in IE11 since it is completely untested. We don't plan to officially support IE11, but welcome PRs to fix issues. For the most part, IE11 seems to work without much trouble." and "IE10 and older - Browsers older than 2013 (including Android 4.4) will never be supported ...". Shepherd doesn't specify but it's built on Popper so I assume it's the same.

I imagine we could live with lack of IE 11 support, it's in the process of being droppped anyway. So use of Popper would probably be blocked on T290815: Bump basic and modern supported Android browsers to v5 and possibly Safari / iOS where the level of support is not clear.

(Please add project tags as project tags instead of subscribers. Thanks!)

@MMiller_WMF @RHo should we continue researching this, or move this out of the current sprint as it looks like we are just using the overlay (T292092: Add an image: overlay onboarding) for onboarding?

@MMiller_WMF @RHo should we continue researching this, or move this out of the current sprint as it looks like we are just using the overlay (T292092: Add an image: overlay onboarding) for onboarding?

@MMiller_WMF please confirm but yes, we will try to pick this up post-initial release.