-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Treat / and /explore as distinct URLs #860
Comments
As long as the origin point is populated, browser history does work between the 'home' view and the 'map' or 'explore' views. The case of the origin point not being populated is a separate issue, so created #861. The '/explore' URL works (goes to the map explore mode), by rewriting to a URL with appropriate parameters set. Losing the separate '/map' route in the URL bar was a consequence of the redesign loading the map on the home view and treating the home and map pages as restyled versions of the same page. The 'learn' page is a separate page, served statically by Django, that does not interact with the JavaScript router. Modifications to the URL scheme would have consequences for direct linking and handling of permalinks. |
I tested Back button behavior (Chrome 61/Mac) and made the following observations. TL;DRWithout an origin, back button behaves unexpectedly in two scenarios:
With an origin, back button behaves as expected, but the origin is lost when returning to the Home page from Explore (map), Directions (map), and More info (detail). ObservationsWithout originScenario: Explore
Scenario: Directions
Scenario: Details
Scenario: Explore then Details
With originScenario: Explore
Scenario: Directions
Scenario: Details
Scenario: Explore then Details
|
Blocked by #1024 |
@lederer do you happen to know if this is still an issue? It looks to me like the routing library has been switched out since this was opened, so I'm wondering whether the behavior has changed at all as part of that work. |
Still an issue. The behavior described in the original comment remains, as does that described in the TL;DR of the longer follow-up comment. |
Go to the GoPhlGo home page and hover on the "Learn" nav link. The browser status bar says
gophillygo.org/learn/
. Click and you land on the Learn page, with the browser address bar reflecting that same URL (gophillygo.org/learn/
). Click browser Back and you return to the home page.Contrast that to…
Start on the home page and hover on the "Explore" nav link. The browser status bar says
gophillygo.org/explore
. Click and you land in Explore mode, but the browser address bar still has the home page URL (gophillygo.org
). Click browser Back and instead of returning to the home page, you return to the page you were on prior to visiting GoPhlGo.I think we should normalize these behaviors.
Given the single-page nature of our home and map views, I reckon there are implications I'm overlooking, but here's a strawman:
gophillygo.org/map
./map
URL.gophillygo.org/explore
should redirect togophillygo.org/map
with the destination picker set to explore mode (ie, "within")./
and/map
as distinct entriesThanks @designmatty for bringing this up.
The text was updated successfully, but these errors were encountered: