Page MenuHomePhabricator

Ctrl/Shift+click on <maplink> should open full screen in a separate tab/window
Closed, ResolvedPublic

Description

Similar to T133787, for advanced users, clicking a <maplink> link should open the full screen map in a separate tab or window (actual key should depend on the browser's defaults)

Details

Related Gerrit Patches:

Event Timeline

Yurik created this task.Jun 15 2016, 6:28 PM
Restricted Application added a project: Discovery. · View Herald TranscriptJun 15 2016, 6:28 PM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald Transcript
Yurik moved this task from Unsorted to UI tasks on the Maps (Kartographer) board.Jun 16 2016, 11:07 PM
JGirault claimed this task.Jun 17 2016, 5:35 PM
JGirault moved this task from Backlog to In progress on the Maps-Sprint board.

Change 294940 had a related patch set uploaded (by JGirault):
Make <maplink> a real link so users can open it in a new tab/window.

https://gerrit.wikimedia.org/r/294940

Change 294940 merged by jenkins-bot:
Make <maplink> a real link so users can open it in a new tab/window.

https://gerrit.wikimedia.org/r/294940

JGirault closed this task as Resolved.Jun 21 2016, 11:12 PM

@Yurik said

One thing - do we really want to have two different routes /map/ and /maplink/ for this?

I answered on IRC:

14:15 J<•jgirault> yurik: does it make sense to mix both though?
14:15 J<•jgirault> right now it is /mapsomething/<id of that mapsomething in the page>
14:16 J<•jgirault> if we change it to /map/<id of any mapsomething in the page>
14:17 J<•jgirault> we might have: /map/0 (=mapframe); /map/1 (=maplink); /map/2 (=maplink); /map/3 (=mapframe); /map/4 (=maplink)
14:17 J<•jgirault> and I don’t think it gives any benefit
14:19 J<•jgirault> it makes the route less human-readable (one poweruser could easily reverse engineer what these routes mean - /maplink/0; /maplink/1 - and find a faster way to visit map links, or maps, via the updating the url directly)
14:23 J<•jgirault> it makes shared links more human readable too. if someone asks me to look at https://en.wikivoyage.org/wiki/Salzburg#/maplink/3; I might understand I am looking at the 3rd maplink in the article. Once I close that popup, it’s a bit easier to find my way in the article. If we mix mapframes and maplinks all together, I don’t have this opp
14:30 J<•jgirault> I think we can also gain from maintaining them separately… If later one wants to disable mapframes, #/maplink/<id> routes will still work. If we want to change #/map/ route to include more metadata, like #/map/<index>/<lat>/<long>/<id of POI popup that should be open>; we will be able to without having to make sure it is compatible with maplinks

14:32 J<•jgirault> To me, the one thing I am not so sure about is whether <id of the element in the page> is a good pattern
14:34 J<•jgirault> For instance, to point to a heading users (expect to) share https://en.wikivoyage.org/wiki/Salzburg#See
14:35 J<•jgirault> From a user standpoint I think this works much better than sharing https://en.wikivoyage.org/wiki/Salzburg#/heading/3
14:35 J<•jgirault> And if later one decides to move the "See" paragraph further down the article, the shareable link still works
14:38 J<•jgirault> With heading IDs, people would soon be looking at the wrong paragraph. Sure “#See" doesn’t make it future proof either, but IMO it’s more reliable than “#/heading/3"
14:40 J<•jgirault> I am afraid that in the future people will complain about the unstability and unpredictability of this pattern