Dialogs should not be part of url or page history #4566

Closed
cyrret opened this Issue Jun 20, 2012 · 9 comments

Comments

Projects
None yet
5 participants
@cyrret

cyrret commented Jun 20, 2012

This is per the documentation (http://jquerymobile.com/demos/1.1.0/docs/pages/page-dialogs.html)...as well as just good UX practice in general.

Currently if multiple dialogs are open, multiple &ui-state=dialog are appended to the url, and all the dialogs are part of the nav stack. As a result, the user will need to close each dialog, one at a time, to get back the page the dialogs are contextual to.

If the user has to tap through to close a bunch of dialogs (a la Windows or pre-iOS 5), a dialog is probably the wrong widget for the use case.

I have an "almost ready fix" for this on my fork: https://github.com/cyrret/jquery-mobile. If you guys want to keep the existing behavior where dialogs are part of the page history, there should at least be configuration that can disable this. If need be, I can create said configuration and modify my fix accordingly.

@ghost ghost assigned gabrielschulhof Jun 20, 2012

@johnbender

This comment has been minimized.

Show comment Hide comment
@johnbender

johnbender Jun 20, 2012

Contributor

@cyrret

We have to alter the browser history in some fashion to enable the back button for dialogs. That is, we could use pushState (though I'm not 100% on whether that works with the same url) but it was previously broken in older versions of iOS which is why we use replaceState which requires an already altered url.

You said yourself that if they have to tap back through a bunch of dialogs they're probably using the wrong widget :D

Given the requirement that the back button work with dialogs I'm going to close this issue. If you can propose an alternate solution that takes that into account feel free to post back.

Contributor

johnbender commented Jun 20, 2012

@cyrret

We have to alter the browser history in some fashion to enable the back button for dialogs. That is, we could use pushState (though I'm not 100% on whether that works with the same url) but it was previously broken in older versions of iOS which is why we use replaceState which requires an already altered url.

You said yourself that if they have to tap back through a bunch of dialogs they're probably using the wrong widget :D

Given the requirement that the back button work with dialogs I'm going to close this issue. If you can propose an alternate solution that takes that into account feel free to post back.

@johnbender johnbender closed this Jun 20, 2012

@cyrret

This comment has been minimized.

Show comment Hide comment
@cyrret

cyrret Jun 20, 2012

Can you better explain the requirement that the back button work with dialogs? I may be able to propose an alternate solution once I better understand this requirement.

My solution supports the back button, what is does not support is keep a history of all open dialogs. It only remembers the last one opened.

What I mean by "using the wrong widget" is in the case where the UX depended on having a history of all open dialogs. Given the current release of jQuery, it would be very easy for the user to get in a state where they have a bunch of dialogs open, especially when the dialogs are triggered by user behavior. In my mind the most elegant behavior for this situation is to only have "record" in the history of the most recently opened dialog.

Thanks!

cyrret commented Jun 20, 2012

Can you better explain the requirement that the back button work with dialogs? I may be able to propose an alternate solution once I better understand this requirement.

My solution supports the back button, what is does not support is keep a history of all open dialogs. It only remembers the last one opened.

What I mean by "using the wrong widget" is in the case where the UX depended on having a history of all open dialogs. Given the current release of jQuery, it would be very easy for the user to get in a state where they have a bunch of dialogs open, especially when the dialogs are triggered by user behavior. In my mind the most elegant behavior for this situation is to only have "record" in the history of the most recently opened dialog.

Thanks!

@johnbender

This comment has been minimized.

Show comment Hide comment
@johnbender

johnbender Jun 20, 2012

Contributor

@cyrret

"Dialogs should not be part of url or page history"

I think my confusion arises from the title because they have to be a part of the browser history in some fashion or another to support the back button. Because we have to alter the url somehow to create a new history entry, is the win here not tacking on extra dialog states to the hash? ie confining it to #&ui-state=dialog instead of #&ui-state=dialog?

Either way we'd likely wait until 2.0 because of the way this breaks backward compat so drastically in terms of behavior.

Contributor

johnbender commented Jun 20, 2012

@cyrret

"Dialogs should not be part of url or page history"

I think my confusion arises from the title because they have to be a part of the browser history in some fashion or another to support the back button. Because we have to alter the url somehow to create a new history entry, is the win here not tacking on extra dialog states to the hash? ie confining it to #&ui-state=dialog instead of #&ui-state=dialog?

Either way we'd likely wait until 2.0 because of the way this breaks backward compat so drastically in terms of behavior.

@cyrret

This comment has been minimized.

Show comment Hide comment
@cyrret

cyrret Jun 21, 2012

The win here is primarily in usability for the end-user. The url history was just something I additionally noticed that seemed a bit funky. Perhaps a specific example will clarify things...

Current state:

  1. Let's say the end-user opens 3 dialogs successively, Dialog A, Dialog B, and Dialog C.
  2. The url looks like this at the end of these 3 dialog opens: http://somepage.com/#&ui-state-dialog&ui-state-dialog&ui-state-dialog
  3. At this point, if the user clicks the dialog's close button or browser back, Dialog B will be shown. And the url looks like this: http://somepage.com/#&ui-state-dialog&ui-state-dialog.
  4. Closing dialog B or hitting browser back again shows Dialog A and this url: http://somepage.com/#&ui-state-dialog.
  5. Closing dialog A or hitting browser back again will finally yield the original page with the original url.

With my patch:

  1. The url looks the same after 1, 2, or 3 successive dialog opens: http://somepage.com/#&ui-state-dialog.
  2. Hitting browser back or closing the dialog after any number of dialog opens always just goes back to the original page.

Does that make sense?

RE: backwards compatibility. I understand and agree this is a valid concern. At the same time, I don't want to leave my patch hanging for that long, and believe it could help many developers pre-2.0. What if my "no-history" patch behavior were off by default, and I added an html attribute to called "data-omit-from-history" that could enable this on a per-dialog-basis?

Alternatively, I could also add a javascript attribute to $.mobile to enable this for all dialogs (disabled by default again).

Would you consider that safe to pull in?

Thanks again.

cyrret commented Jun 21, 2012

The win here is primarily in usability for the end-user. The url history was just something I additionally noticed that seemed a bit funky. Perhaps a specific example will clarify things...

Current state:

  1. Let's say the end-user opens 3 dialogs successively, Dialog A, Dialog B, and Dialog C.
  2. The url looks like this at the end of these 3 dialog opens: http://somepage.com/#&ui-state-dialog&ui-state-dialog&ui-state-dialog
  3. At this point, if the user clicks the dialog's close button or browser back, Dialog B will be shown. And the url looks like this: http://somepage.com/#&ui-state-dialog&ui-state-dialog.
  4. Closing dialog B or hitting browser back again shows Dialog A and this url: http://somepage.com/#&ui-state-dialog.
  5. Closing dialog A or hitting browser back again will finally yield the original page with the original url.

With my patch:

  1. The url looks the same after 1, 2, or 3 successive dialog opens: http://somepage.com/#&ui-state-dialog.
  2. Hitting browser back or closing the dialog after any number of dialog opens always just goes back to the original page.

Does that make sense?

RE: backwards compatibility. I understand and agree this is a valid concern. At the same time, I don't want to leave my patch hanging for that long, and believe it could help many developers pre-2.0. What if my "no-history" patch behavior were off by default, and I added an html attribute to called "data-omit-from-history" that could enable this on a per-dialog-basis?

Alternatively, I could also add a javascript attribute to $.mobile to enable this for all dialogs (disabled by default again).

Would you consider that safe to pull in?

Thanks again.

@cyrret

This comment has been minimized.

Show comment Hide comment
@cyrret

cyrret Jun 22, 2012

Hey, I just wanted to follow up on this. Do any of my suggested alternatives seem appropriate to pull in? Thanks.

cyrret commented Jun 22, 2012

Hey, I just wanted to follow up on this. Do any of my suggested alternatives seem appropriate to pull in? Thanks.

@johnbender johnbender reopened this Jun 22, 2012

@johnbender

This comment has been minimized.

Show comment Hide comment
@johnbender

johnbender Jun 22, 2012

Contributor

@cyrret

Points well taken. I'll ask the rest of the team.

Contributor

johnbender commented Jun 22, 2012

@cyrret

Points well taken. I'll ask the rest of the team.

@cyrret

This comment has been minimized.

Show comment Hide comment
@cyrret

cyrret Jun 23, 2012

Thanks John, let me know.

cyrret commented Jun 23, 2012

Thanks John, let me know.

@jaspermdegroot

This comment has been minimized.

Show comment Hide comment
@jaspermdegroot

jaspermdegroot Dec 16, 2012

Member

@johnbender @gabrielschulhof - Did we already make a decision about this?

Member

jaspermdegroot commented Dec 16, 2012

@johnbender @gabrielschulhof - Did we already make a decision about this?

@arschmitz

This comment has been minimized.

Show comment Hide comment
@arschmitz

arschmitz Aug 7, 2013

Member

the dialog widget is being deprecated in favor of just a specially styled page so im closing this

Member

arschmitz commented Aug 7, 2013

the dialog widget is being deprecated in favor of just a specially styled page so im closing this

@arschmitz arschmitz closed this Aug 7, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment