When a major resource is viewed, its URL should be in the browser URL bar

[jar398]

It would be nice to be able to hyperlink to collections, just as you can to studies, trees, and taxa. https://www.w3.org/TR/webarch/#uri-benefits

[kcranston]

Duplicate of #881 . The 'Share' button provides a URL for the collection. But perhaps this is not obvious enough?

[jar398]

Not obvious to me. There is a well established way to get the URL, via the browser address bar, so that's the only place I know to look. I have not learned that 'share' means 'give me a URL' - in many applications e.g. iPhoto it has something to do with email or social media, so there are competing forces trying to train me that it means something else. Although now you mention it, I may have seen it elsewhere used in this way. Am I just not hip enough?

[jar398]

Also I remembered that there was a previous issue, but could not find it... because I was only searching open issues. Sorry about that.

[jimallman]

I was actually hoping this was the obvious link (opens with the direct URL):

[jimallman]

Also I remembered that there was a previous issue, but could not find it...

Perhaps this one, mentioned by @kcranston above? There's some discussion there, including the nuances of different useful URLs (to the collection in app UI, raw data on GitHub, history on GitHub): https://github.com/OpenTreeOfLife/opentree/issues/881

[jar398]

Correct, @jimallman, I was referring to #881, the issue that @kcranston mentioned. That is the one I remembered, and that I failed to find through search because I forgot to deselect open-only.

I'm changing the issue title to be closer to what I really want to say, and to distinguish this request from #881.

Besides removing the need to train users, using the URL (instead of an ad hoc control) also makes the usual drag-and-drop from the URL bar work, and bookmarking, and history, etc. etc.

[jimallman]

Ah, I misread your message (sorry). The trick with updating the curation URL in this case, is that we're often already using this to indicate lots of other context: a study, a tab, perhaps a tree and its reference tree for conflict.

Currently I build the "canonical" URL for a collection to point to it in the main collections list, like so: https://devtree.opentreeoflife.org/curator/collections/jimallman/my-test-collection-100

I can teach that view (main collections list) to update its URL, but the same behavior on the study-editor page could be extremely brittle (and probably surprising to the user).

[jar398]

I've never written one of these javascript webapps, but this sounds like a case of implementation concerns exposing themselves to the user, and breaking user expectations about how to use browsers that they've had to learn and are probably heavily invested in. URL bar, bookmarks, forward, back, are pretty fundamental to the web.

Seems like these issues don't come up for server-based webapps. Are there standard user operations a javascript webapp can't do, that a server-based webapp can? I guess that would lead to inescapable differences that users would have to learn.

Doesn't the browser history provide context? Or, isn't there some other communication channel by which context can be transmitted from one part of the app to the other? E.g. for many sites (e.g. Amazon, Wiley), if lots of context is put in the URL along with the information needed to get to the resource being viewed, then if the URL is used where that context info doesn't make sense, it is just ignored. This way the URL acts as both a hyperlink (to what's seen) and a context provider. It works pretty well.

Curious about what you mean by 'extremely brittle'.

(I came across another example today of a page I wanted to link to that didn't have its own URL; I copied the URL by habit and found it went to some random search page. Maybe this is why I'm grouchy.)

[jimallman]

Doesn't the browser history provide context? Or, isn't there some other communication channel by which context can be transmitted from one part of the app to the other?

Sure, the webapp (esp. with JS browser-history management) generally knows what's up. I'm manipulating the URL explicitly to support sharing, in the sense of "By sending you this URL, I expect you to see pretty much what I'm seeing right now." This is no mean trick, since we have lots of tabs, popups, and (potentially) multiple target resources in view.

Tree collections in particular can appear while we're mainly focused elsewhere, ie editing a study or browsing a curator's profile page. If you like, we can keep building up the query string to add a visible collection's ID.

Curious about what you mean by 'extremely brittle'.

OK, that was overstatement. We've correctly wrangled lots of challenges in the URL- and history-management so far, so this is probably feasible. It will just require more special case JS to handle an incoming URL that says, "We're looking at study FOO, the Trees tab, specifically tree BAR, but right now we want to see collection BAZ instead."

[jar398]

"By sending you this URL, I expect you to see pretty much what I'm seeing right now." - that sounds right, if that's interpreted to NOT include what happens if you go back or forward, or when you click a little 'x' to close (maybe when you use the URL out of context, there is no 'x').

"We're looking at study FOO, the Trees tab, specifically tree BAR, but right now we want to see collection BAZ instead." -- I don't understand how that's consistent with the previous quote, i.e. why all that junk needs to be in the URL. If you're looking at the collection, the bookmark should be for the collection, not the total context. Am I missing something? If the view were of some combination of collection BAZ and that particular tree, and this fact will be important to a user of the bookmark, then maybe

• but I don't think that's the case. I only see the collection with a big black plain surrounding it, with an 'x' that (from the user's POV) is just another kind of 'back' button. It's the same view I get when I go through the collections list.

If there's some other reason to put the study/tree junk in the URL, that's another story - then we have something more like Amazon URLs, and following the URL out of context could do something with the tree and study parts of the URL, or not. But apparently there is no such reason, since collection URLs do not currently include the junk.

This looks to me like a general pattern, so I'm not sure why "special case JS" is needed - it will be JS that looks like all the other similar situations and the pattern could be abstracted if the implementation were nontrivial.

Note my request is only for "major resources". I don't see very much reason to want to bookmark a popup, although occasionally it is nice. Maybe you see the collection view as a popup, but personally I don't experience it that way - it's an important thing that I want to talk about (bookmark).

Sorry to go on and on like this but I don't want you to do something you're not persuaded by.