Skip to content
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

Open
dittaeva opened this issue Aug 29, 2012 · 8 comments
Open

Always permalink / updating map link #46

dittaeva opened this issue Aug 29, 2012 · 8 comments
Assignees

Comments

@dittaeva
Copy link
Member

See, refer to, discuss on, but do not be deterred by waymarkedtrails#90.

@ghost ghost assigned esisa Oct 15, 2012
@esisa
Copy link

esisa commented Nov 14, 2012

There is two parts to this one.

  1. Update URL to reflect view
  2. Update browser history so when a user clicks back in the map you move "one move" back.

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.

@dittaeva
Copy link
Member Author

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)?

@esisa
Copy link

esisa commented Nov 15, 2012

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.

@esisa
Copy link

esisa commented Dec 5, 2012

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:
http://facilmap.org/ (their code can be found on Gitorious)

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.

@dittaeva
Copy link
Member Author

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

@esisa
Copy link

esisa commented Dec 12, 2012

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.

@dittaeva
Copy link
Member Author

dittaeva commented Jan 7, 2013

Please commit against Waymarked Trails master.

@lonvia
Copy link

lonvia commented Jan 7, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants