Intent-to-Deprecate: History Manipulation of Modal Components #25080
Comments
cathyxz
added
INTENT TO DEPRECATE
|
This'll make Bento muuuccchhh easier. |
|
Hmm, I'm not convinced we should do this.
What is the problem with swipe-to-go-back (Also launched in the latest
Android)? I'd expect it to e.g. close the lightbox.
…On Wed, Oct 16, 2019 at 9:12 PM Justin Ridgewell ***@***.***> wrote:
This'll make Bento muuuccchhh easier.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#25080?email_source=notifications&email_token=AAAV4T2QOO6WSMBDH67NKSLQO5RQDA5CNFSM4JBPZRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBNTUCQ#issuecomment-542849546>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAV4T2QPWRRCAQMWF62NR3QO5RQDANCNFSM4JBPZRRA>
.
|
|
|
|
Do you have a sample URL? I personally really like using these gestures
instead of looking for custom close buttons.
…On Wed, Oct 16, 2019 at 9:17 PM Cathy Zhu ***@***.***> wrote:
amp-lightbox and it's modal usage, was specifically one component where
this feature might still make sense (which is why I didn't list
amp-lightbox in the deprecation list). amp-sidebar, since we animate it's
open and close, was one situation in which swipe-to-go-back could make the
sidebar open from the wrong side of the page, and that would result in an
awkward UX. amp-lightbox-gallery, also has some pretty fancy transition
animations by default. I can see how swipe-to-go-back triggering these
animations would result in a strange UX.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#25080?email_source=notifications&email_token=AAAV4TYD3TDNXP65C3JFG2LQO5SFXA5CNFSM4JBPZRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBNUFOI#issuecomment-542851769>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAV4T6ZZGCIWTHKFDLB7TTQO5SFXANCNFSM4JBPZRRA>
.
|
|
Yup, one is https://amp.dev/documentation/examples/components/amp-sidebar/preview/?format=websites on iOS Safari. Opening the sidebar and then swipe-to-go-back results in going back to the same page, and then the sidebar animates close. |
|
Just tried it on Android 11 with swipe gestures turned on and it feels and
works great. I don't have an iPhone right now. What happens there?
Or just clarifying: When I swipe-to-back I expect the sidebar to close?
right? Or do you have a different expectation?
…On Wed, Oct 16, 2019 at 10:07 PM Cathy Zhu ***@***.***> wrote:
Yup, one is
https://amp.dev/documentation/examples/components/amp-sidebar/preview/?format=websites
on iOS Safari. Opening the sidebar and then swipe-to-go-back results in
going back to the same page, and then the sidebar animates close.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#25080?email_source=notifications&email_token=AAAV4T4H24QVYTSYKHTFKGDQO5YBDA5CNFSM4JBPZRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBNYUOY#issuecomment-542870075>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAV4T2HFZ736OQEG6AYSVDQO5YBDANCNFSM4JBPZRRA>
.
|
|
|
|
I see. There is no horizontal overscroll on Chrome for Android for the
gesture which is why this doesn't look weird.
So, basically in iOS it looks broken when an overlay has history attached
and doesn't cover the entire screen?
…On Wed, Oct 16, 2019 at 10:30 PM Justin Ridgewell ***@***.***> wrote:
[image: back swipe on iOS]
<https://user-images.githubusercontent.com/112982/66956338-3cc3b280-f032-11e9-94b0-47d12803ea90.gif>
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#25080?email_source=notifications&email_token=AAAV4T6SU6ZWKNZVJIZ4XVDQO52XBA5CNFSM4JBPZRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBN2XGY#issuecomment-542878619>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAV4T3MYCOXORLLAYHULPLQO52XBANCNFSM4JBPZRRA>
.
|
|
Yup. In iOS, the interaction of history with animated transitions looks super broken because the swipe gesture opens an overlay of the previous page (in the history API). It results in swiping to the same page, and then triggering an animated transition. It looks extra broken when the direction you swipe is the opposite of the direction that the sidebar closes to (sidebars can be configured to open from left or right). @kristoferbaxter and @sparhami voiced concerns that maintaining history state in modals for desktop wasn't a very common pattern either, but as a minimum this interaction doesn't feel right on Safari. |
|
Following the native land, however, the back navigation is used very aggressively in sidebars, popups, and lightboxes. Is this just a technical problem on iOS? Can it be resolved by delayed history pop slightly? |
The problem is in native, you don't have this persistent swipe from the edge behavior for dismissing things. For example, a lightbox has a swipe to dismiss, but that is a downwards or upwards swipe. For example, in the lightbox view for the iOS photos / Google Photos apps, a swipe from the left, even on the edge, navigates the carousel. On iOS this gets a bit confusing. If you swipe away from the edge, it navigates the carousel. However, if you swipe near the edge, it will navigate back (the UI will look incorrect, the preview of what is being swiped back to looks like the lightbox open state), but then the lightbox closes. The preview image that iOS captured for the previous history state is not correct. I think the sidebar is an interesting example. In in some native apps (e.g. Gmail on Android and iOS), swiping from the side of the screen will cause the sidebar to open as well as close. Also, swiping from right to left (in LTR languages) is what closes the sidebar, not a swipe from left to right (back navigation gesture in iOS). I think the expectation on the web in iOS is that swiping from the edge will take you back to the previous page rather than closing a modal. I'm not sure native apps are the right model, and they often don't really have a consistent concept of different pages (with back/forwards) other than what an app itself implements. Some apps have left/right swipes navigate to different sections in some views. In other views, swiping left to right will close (aka go back) but then swiping right to left will not reopen (aka go forwards). |
|
Scientific poll https://twitter.com/cramforce/status/1184615159026683904
…On Thu, Oct 17, 2019 at 1:28 AM Sepand Parhami ***@***.***> wrote:
Following the native land, however, the back navigation is used very
aggressively in sidebars, popups, and lightboxes. Is this just a technical
problem on iOS? Can it be resolved by delayed history pop slightly?
The problem is in native, you don't have this persistent swipe from the
edge behavior for dismissing things. For example, a lightbox has a swipe to
dismiss, but that is a downwards or upwards swipe. For example, in the
lightbox view for the iOS photos / Google Photos apps, a swipe from the
left, even on the edge, navigates the carousel.
On iOS this gets a bit confusing. If you swipe away from the edge, it
navigates the carousel. However, if you swipe near the edge, it will
navigate back (the UI will look incorrect, the preview of what is being
swiped back to looks like the lightbox open state), but then the lightbox
closes. The preview image that iOS captured for the previous history state
is not correct.
I think the sidebar is an interesting example. In in some native apps
(e.g. Gmail on Android and iOS), swiping from the side of the screen will
cause the sidebar to open as well as close. Also, swiping from right to
left (in LTR languages) is what closes the sidebar, not a swipe from left
to right (back navigation gesture in iOS).
I think the expectation on the web in iOS is that swiping from the edge
will take you back to the previous page rather than closing a modal. I'm
not sure native apps are the right model, and they often don't really have
a consistent concept of different pages (with back/forwards) other than
what an app itself implements. Some apps have left/right swipes navigate to
different sections in some views. In other views, swiping left to right
will close (aka go back) but then swiping right to left will not reopen
(aka go forwards).
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#25080?email_source=notifications&email_token=AAAV4T6QG4ZH4ZUQCEB6LRLQO6PQBA5CNFSM4JBPZRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOH2NA#issuecomment-542932276>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAV4T47LP52ALKGKSIJYILQO6PQBANCNFSM4JBPZRRA>
.
|
|
Worth mentioning that we also recently implemented swipe-to-dismiss for sidebar itself (we have swipe to dismiss for lightbox-gallery already). So if you swipe on the sidebar (not from the edge), you can actually close the sidebar already. |
|
I thought about this some more, and the "broken" part of this experience really comes from the interaction with |
|
I think we should approach this carefully... iOS is always tricky. But one way to look at this: how do native components with overlays work. E.g. Lightbox, however, is slightly different UX, imho - it often appears as a drill-down navigation and thus the back button makes sense from the navigation point of view. |
|
For reference, here is Android |
|
Summarizing feedback so far:
Given that, here are few potential action items that we can vote on:
I'd like to propose:
How do folks feel about launching an experiment (or a separate experiment per component) for that? |
What's the use case here? |
|
Maybe I'm misinterpreting @dvoytenko 's comment here, but my understanding is that we should allow people to navigate back to a previous field via back button in popup forms. For example, if we're in a lightbox containing a form, we should allow the back button to re-open a closed lightbox in case folks filled it out and accidentally tapped cancel--in this case, we should preserve the form content. I think this is a legit use case. Though I wonder if mobile operating systems are going to be providing more and more native components for this kind of use case (context: Apple's view section under Human Interface Guidelines ). I also think sidebar might not be applicable to this use case (I don't think sidebar is meant to be used for containing long forms). |
|
Yeah, I think I didn't explain myself very well. My use case was the popup-based controls such as a fancy date/date-range/etc input. The overlaying popups, imho, should be cancelable via back button. Thus I think we have 3 use cases:
I know we did some polling around, but nothing that answers a specific question: The back button exists and clearly visible in iOS and Android most of the time -> in each of these use cases what's a user's expectation when clicking back button? I think on Android things are a bit clearer since back button is shared with the platform in general and hence the native expectations are more naturally applied to the Web case. I understand that on iOS we have some technical issues as well. But that's not uncommon. I think one of the first bugs filed on amp-carousel was a request to cancel iOS's back navigation when a user swipes on the carousel. And this was even more compounded given that Search on iOS swipes between documents. But somehow we navigated between all these cases. |
|
Maybe we can do this. I'd like to For the remainder of the use cases, it may be worthwhile to compile a list of use cases to answer @dvoytenko 's question of what do users expect when clicking the back button, but also evaluate how broken these experiences are when "back" is done via something like a swipe gesture. I can do that and paste a spreadsheet back here. In short, I agree that in popup overlays for menus or inputs, we should maintain history so that a back button can take us back to our previously entered input. I think lightboxes and dialogs are a gray area, and maybe the problems and solutions are |
|
For reference, here's what they look like respectively: Sidebar with animation disabled (iOS)
Sidebar experiment with history disabled (iOS)(I think the gif was sped up) |
|
@cathyxz I'd really rather see us first trying to work around the animation part. I'm still very skeptical about disabling back button for sidebars or most of things that "pop up". I know first-hand how frustrating the History API be at times, but I still view back button support as a net win for the user. |
|
@dvoytenko The problems with history go beyond just the UI bug. They don't behave in a way that is consistent. For example, the following flow does not behave in a way that is consistent with history states:
-> There is now a history entry to go forward, but hitting forward does not re-open the sidebar Since we added to the history stack, there is a next history entry for the sidebar state. The browser UI now shows the forward button (on iOS in the bottom bar, Chrome/Android has it in the 3 dot menu) as being available, and I can swipe forward (right edge to left) on iOS, which shows the sidebar as open in the preview state. When I go to the forward state, nothing happens. Since the back/forwards cache does not work due to many analytics implementations using
-> Does nothing as far as the user can tell Other flows are weird/broken too (e.g. on https://output.jsbin.com/sigupoy):
-> Bind changes the state, then closing the sidebar quickly reverts it back after a flash
-> Bind changes the state, then closing the sidebar quickly reverts it back after a flash Your can |
|
@sparhami These points still tell me that History API is pretty difficult to work with in its current state. But we are doing what we can do support the most obvious user flows. I definitely want to be realistic about it, but I'd also like to make sure we do all we can to support this. As for the specifics: it looks like we have two issues: forward button and push/pop races. Forward button: I don't think this is much of an issue, tbh. In Android it's buried pretty deep. On iOS it's visible, but I'm not sure people give it a lot of attention. Unfortunately, I've been trained on the Web to almost never trust the forward button except for simplest cases. And part of the issue is with the push/pop race. Push/pop race: ideally any out-of-sidebar action would wait for the sidebar to be closed and history popped. IIRC we've run into numerous issues with this given inconsistencies in how History API was implemented:
But how do you see this should work? Per API reading this is a bit confusing sequence.
The sidebar comes back quickly? Or does the bind state reverts? |
|
I think the conclusion of the design review was that we can solve the sidebar issue by disabling animation, and that we should do some UX research more broadly on the subject of history state in modal components across various platforms, since there is currently no clear consensus on that front. Looping in Design will also be helpful here. Let's table this discussion for now and revisit in the future. |
Summary
We currently have features in components like
amp-sidebarandamp-lightbox-gallerythat add operations of open / close modal to history state. We intend to deprecate them by introducing an experiment and gradually ramping this up.Motivation
Due to implementation of features like "swipe-to-go-back" on Safari, our current manipulation of history via components like
amp-sidebarresult in unintuitive end user experience. History manipulation has also been known to cause issues such as #6585, where link navigation is broken when history pop is happening at the same time. Example of weird UX: link, try opening sidebar and then swipe-to-go-back on iOS Safari (see gif below for actual behavior).Impact on existing users
Users will no longer be able to open / close modals (e.g. sidebar, lightbox-gallery, lightbox) using the back button.
Alternative implementation suggestion for developers using AMP
This is open to discussion, we can consider preserving this functionality under an attribute, where the default is to have this behavior turned off instead of on.
Additional context
We intend to deprecate this feature by first introducing an experiment that turns off history manipulation for
amp-sidebarandamp-lightbox-gallery. The intention is to gradually ramp up this experiment over time. Based on community feedback, either completely remove this feature, or to convert this behavior to either a default-on or default-off attribute./cc @ampproject/wg-approvers @ampproject/wg-ui-and-a11y
Current Behavior on Safari Mobile
Edits:
The text was updated successfully, but these errors were encountered: