-
Notifications
You must be signed in to change notification settings - Fork 2
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
Always permalink / updating map link #46
Comments
There is two parts to this one.
I think you only expect 1) to work? If so it will work when navigating to a different page, but not when just using the map. |
I think I wanted both 1 and 2 to work. It is a problem when you do searches, and zoom in on routes (with the zoom to route button) that "back" will only bring you back to the last "permalink" and not the last view. For me that has been very frustrating at times, and I expect it could be for other users as well. Doesn't both 1 nad 2 work in geolocation.ws and modest maps (as linked to in waymarkedtrails#90)? |
Ok, 1) should be pretty easy. 2) is probably a bit more work, although I need to test this out first before I know how much work it is. From what I could see neither geolocate.ws or modest maps actually uses the browser history. But it might be some kind of issue in my browser only. I will check it out. |
Ok, I have taken a look at this issue. Neither geolocation.ws or modest maps actually implement browser history(at least not working in Chrome, Firefox or Safari). This site is implementing browser history: Is this the kind of functionality you would want @dittaeva? There is also a question about what should happend to the route list etc. Should all state be saved when a user hits the back button? That will probably add complexity when adding new GUI features later, as you would always have to make make sure that state is saved. One might be able to automate this, but bugs will pretty sure pop up. |
Ok, the way I understand you 1) is easy and unproblematic, 2) might need more thinking through. So maybe start with 1) and postpone 2)? Permalink functionality has also been discussed in waymarkedtrails#72 |
Ok I can start on 1). That will basically put the permalink into the URL automatically instead of the user pressing the permalink buttom manually. So a small step forward :-) Further work should probably be thought thoughrougly through before implemetion. This stuff can get pretty tricky. |
Please commit against Waymarked Trails master. |
Just a few random thoughts to this: The sidebar views are now implemented with anchors and they are respected on page load, i.e .../#routes automatically opens the route list. This syntax is contrary to what was proposed in waymarkedtrails#72 but should be helpful to return to the correct state of the sidebar when the back button is used. There is still the cookie function to bring you back to the last view. It should solve 2) for most cases with exception of the one mentioned by @dittaeva where a zoom-to-relation link is involved because these URLs take precedence over the cookies. This was intentional and is logic up to a certain point because it is meant as a direct link. Maybe it would be a good idea to separate the whole thing and offer two functionalities: a) direct link to relation, b) zoom in on relation. a) should do what 'zoom to relation' does now and b) could be implemented like the other sidebar functions as an anchor. When you navigate away a) would indeed bring you back to a view on the relation and b) to whereever you were last with the route view open on the last viewed relation. I don't think 1) can replace the cookie completely, so a unification of the two update functions would be good. Using a bbox as location in the cookie was not the brightest of ideas. If you have to touch that code and want to change the cookie to contain the usual x/y/zoom permalink, be my guest. |
See, refer to, discuss on, but do not be deterred by waymarkedtrails#90.
The text was updated successfully, but these errors were encountered: