jupyterhub / mybinder.org-deploy

Deployment config files for mybinder.org
https://mybinder-sre.readthedocs.io/en/latest/index.html
BSD 3-Clause "New" or "Revised" License
76 stars 74 forks source link

A "Binder Menu" button for all UIs #1462

Open betatim opened 4 years ago

betatim commented 4 years ago

The technical question of this issue is: how can we add HTML like the following

<div id="button"></div>
<script src="https://static.mybinder.org/some-bundle.js"></script>

to every website served by mybinder.org? Keep reading for why I am interested in this

Currently we add a few buttons to the top right hand corner of the classic notebook UI for Binders. They help users share the right link, visit the original repo or join a video room.

For lab, RStudio, voila, streamlit, etc we don't have these buttons. Sometimes people ask if we could add the buttons there as well. For lab we could by making an extension for lab specifically. For the other "arbitrary" UIs it would be harder to do.

One idea I've had and worked on a bit is creating a "Binder Menu" that is a single JS file. This "Binder Menu" would contain all the buttons/links/what not that we want to display.

Right now it looks a bit like this (on some dummy page I made for testing):

Screenshot 2020-06-07 at 09 01 21 Screenshot 2020-06-07 at 09 01 32 Screenshot 2020-06-07 at 09 01 46

The only modification to to the original page's HTML are:

<div id="button"></div>
<script src="/build/bundle.js"></script>

the menu itself is a small svelte app, mostly because it takes care of CSS class name stuff to make them unique.

The questions I have are:

What do you think?

betatim commented 4 years ago

Also pinging @yuvipanda @sgibson91

choldgraf commented 4 years ago

Some quick takeaway thoughts:

  1. In general, I think it's a cool idea and I like the idea of standardizing this experience across user interfaces. Thanks Tim for cranking out a prototype!
  2. How do we ensure people actually know about this button? E.g., I think many people never realize that the readthedocs button is there. Maybe we make it "pulse" once or twice upon page load?
  3. We should make sure that the button collapses to a smaller size (maybe just the binder logo?) on narrower screens
  4. Should the binder logo be in the button?
  5. There should be some way to turn off the Binder button, I think (e.g. if a user thinks that it impedes their visualization or something like this)
  6. If we didn't want to use a javascript framework for this, I think we could accomplish the same thing with a <details> block for the button, and the sub-buttons would be the content. but I don't think it's such a big idea, just an FYI.

Also, I originally read this issue as "A binder menu button for all of us" haha

betatim commented 4 years ago

buttons'r'us :D

Thanks for the ideas and comments!

I thought about placement of the button for visibility, annoyingness, being in the way, etc. Top right would probably be super visible but also highest chances of being "in the way" (RStudio has UI elements there, jupyter as well, etc). For now I was thinking that putting it in the bottom right, where people are used to finding the "floating action button" (FAB) in UIs that follow material design rules, would be the thing to do. If there is content there you can often scroll to move it. Not as good as not hiding stuff but at least people can self-rescue themselves by scrolling.

I tried using the binder logo but switched to text-on-orange because it let me make the button "binder orange". With the logo you have to use a white background. So often you end up with logo on white (button bg) on white (from the original page). Seemed like orange would be more visible and have an "obvious" label ("looks like a button, behaves like a button and the name is "Binder" so this is the "binder button"). I've not seen FABs with logos on them, often they seem to have a "+".

Styling and content of the button are at the level of "something that works and isn't extremely ugly". So any and all ideas welcome. It is something I plan to iterate on once we figure out a way to make the button appear and if we want to make the button appear.

JS framework: I started with "hand made" HTML + JS, then tried StimulusJS and settled for svelte because it takes care of two things that turn out to be tricky:

  1. creating a small bundle.js while being able to use tools like tailwind for CSS.
  2. dealing with the fact that CSS is global to the whole page. We don't want the styling of the page to "leak into" the styling of the button and we don't want styling of the button to modify the "host" page either. Svelte does some automagic stuff with prefixing and scoping which will prevent the button from changing the host page and seems to be pretty good at stopping stuff from leaking in. So for now I'd stick with it, then later see if we can improve/reduce the size of the additional code/JS that needs to be injected by using some clever webpack config instead of piggy backing on a framework.
choldgraf commented 4 years ago

For now I was thinking that putting it in the bottom right, where people are used to finding the "floating action button" (FAB) in UIs that follow material design rules, would be the thing to do.

Makes sense to me 👍

With the logo you have to use a white background

good point 👍

often they seem to have a "+".

I wonder if we actually could use a "+" or an arrow to signal to the user that "this is a hoverable thing that will expand a menu"?

So for now I'd stick with it, then later see if we can improve/reduce the size of the additional code/JS that needs to be injected by using some clever webpack config instead of piggy backing on a framework.

Sounds good - how difficult do you think it would be for a random Binder team member to want to make a change to the button, figure out Svelte, and then build and demo their change locally? To me that's the main question from a tools standpoint - will this raise a significant barrier to others helping out?