Update UI so interface options are more discoverable

[sgibson91]

Hey all!

I'm leaving this as a draft PR for the time being as it still needs some tinkering before it'll actually work in production.

With a lot of hand-holding and pair-programming from @yochannah, I've made a stab at #799 which intends to make the different user interfaces more discoverable. This PR removes the drop-down menu option from the filepath box and adds radio buttons underneath for Classic Notebook, JupyterLab and RStudio, with Classic Notebook being our default selected option. I've got everything to parse correctly to the "Share this link" box and the badges 🙌

If we like how this is, here are remaining to-dos:

• [ ] Clean up path and pathType variables and parse filepath and urlpath variables instead (or some other solution if this is too convoluted)
• [ ] I've made an incorrect assumption on how the links are generated for both a filepath and urlpath argument. I can work from a JupyterLab example here, but if anyone has an RStudio example, that would be great!
• [ ] Parse stuff through to image.js correctly

Screenshot:

[minrk]

That looks great! Question: if someone had a custom destination that required setting urlpath directly (e.g. a dashboard view), how would they create that with the new form?

[sgibson91]

Good question! We could have a fourth option that is a free form box?

[betatim]

One thing I've been pondering (one extreme of it being #1102, maybe this is too extreme) is how to simplify the launch menu/UI. My hunch is that most people don't use or understand when to use most options. Maybe something to explore is to have a "default" view that hides a lot of options and a way to reveal the "expanded" options. In this case we could keep the frequently used options (classic, lab, rstudio) in the default view and reveal the field for "I need something custom because i've got a dashboard" in the expanded view.

I think adding this idea to this PR would make the scope too big, which means this is meant as an idea for where to go next which might inform what we do here.

[sgibson91]

I think that's an interesting idea! And I'd like to establish that I don't want to merge anything that removes a functionality the user currently has, e.g. a custom URL for a dashboard. Because that would be annoying for our users and who knows when we'll have time to complete the work. So I'm happy to work this over a few, smaller PRs.

[betatim]

If we like the idea of having an "expanded" view then I think having a radio button that selects a text field into which you can type stuff gets more of my 👍 than if we plan to have that for the long term.

One thing the current UI solves is that "URL to open" and "Path to a notebook file" are mutually exclusive options. I don't have a good suggestion on how to express that with the radio button proposal.

Crayon sketch of an alternative idea. How about adding the UI options to the dropdown menu (and selecting one as the default) which then either fills in the text field with the right value or (even cooler and probably months of UI work) takes over the whole text field so it isn't fillable any more but just shows "Classic notebook" or "RStudio"

[sgibson91]

One thing the current UI solves is that "URL to open" and "Path to a notebook file" are mutually exclusive options. I don't have a good suggestion on how to express that with the radio button proposal.

They are mutually exclusive options in the form, but it is possible to have a UI that opens a specific file (at least in JupyterLab, c.f. #1163). This PR would combine the two. Albeit incorrectly, but that was my faulty assumption more than anything else. I guess the question is which behaviour we want to support? (Should they be mutually exclusive? Why?)