tweaks to social images

[choldgraf]

Per #908 I think these are some improvements to the social images.

In this PR:

• Adds margins to the Binder logo
• Adds logic to choose the link title based on if we're an index template vs. a loading template (and adds spec information to the loading title)

Todo

Discuss whether the way I've chosen to add spec information to the loading title makes sense. A few thoughts to consider:

• Do we want a different structure than just gh/org/repo/ref?
  • We could always add a little dictionary of spec: human readable spec pairs, so gh resolves to GitHub etc.
  • Do we wanna get clever about parsing the spec itself or leave it as item/item/item?
• Should the spec be in the description instead of the title, etc. This might give us more space to work with, and then we could keep "The Binder Project" as the title.

Open to ideas here! I just realized that it might be straightforward to do so wanted to open the proof of concept here.

[betatim]

I think on all pages that are related to a repo we should make the description about what it is the user will get if they click on the page, not a description of the binder project. I'd aim for ...GitHub repository <org>/<repo>... as the blurb to identify the spec instead of putting the raw spec. Would need a dictionary to map provider shortcode to a "human readable" thing (or maybe we make a template sentence that can be different for all providers?).

For the pages that aren't tied to a specific repo we should put a snappy sentence about Binder. On the landing page we use "Turn a Git repo into a collection of interactive notebooks" as the snappy tag line. Should we make that snappier and then use it on the card as well?

[choldgraf]

OK, the latest push adds a quick "provider: human readable text" mapping and then uses that for the social media description. That should work well enough (though perhaps we want to cap the total number of characters? maybe something to keep an eye on)

[betatim]

Not a huge fan of the "open" here. Do we need it? The previous version had a better "feel" or rhythm to it when reading. Because the rhythm isn't so nice it makes me as a reader think we are just stuffing adjectives in for SEO purposes or so we can tick of buzzwords.

Another point is that I think outside of the bubble of open science not soo many people know what to do with "open" as a description. What is an open computing environment? Anyone can see what I am doing? I think a word that is better is "public" (as in only public repos) but that is confusing too because the env you get isn't public, it is sourced from a public repo.

IMHO the goal should be to let the user know what will happen to them if they click the link (where will I get taken?) and entice them to click it. We don't need to explain what Binder is, people will look that up if they care to know.

This is why I'd go with the three adjectives version.

[choldgraf]

I think three adjectives sounds better too. The reason I'm trying to add "open" is because I see it as one of the main distinguishing factors compared w/ other cloud services. E.g., it'd be somewhat trivial for Colab to add some kind of "share an environment" feature. Where does that leave Binder? I was trying to highlight things that are uniquely Binder Project.

That said, I think it's awkward enough and we don't have consensus enough that it shouldn't be in this PR

[willingc]

While "open" is a convenient term, it can have multiple interpretations: open, pseudo-open, open requirements, etc. Some of the distinguishing factors are transparency and inspection/introspection of builds and dependencies. It would be great to at some point break down a reproducible build into the key blocks where inspection is important (requirements, container build, versions).

[willingc]

Which is my long winded way of saying that we need to capture and publicize the distinguishing factors. Perhaps not in the title but yes keeping focus on it for those who will care.

[choldgraf]

@willingc I think that's a good point - it actually reminds me of a recent blog post from tal yarkoni that you might like if you haven't seen it yet. I agree that we can and should try to dig down to the specifics and why they're useful in BinderHub! Happy to iterate on that in another PR

[betatim]

Good points. Investing effort into explaining why Binder is the way it is, why we think that this is a good trade off, etc is a good idea. I keep thinking back to "Binder, so advanced it might contain magic" (advance tech being indistinguishable from magic) and the fact that most magic tricks are actually very simple to understand once they are explained to you. So I am pondering how we can explain Binder like that :) "Binder performs a magic trick" (building your env from nothing), let me show you how it does it. See, there is no magic here, you could do it yourself! ramblingrambling

[choldgraf]

@betatim see latest commit, I think I've addressed your two comments

[willingc]

Thanks @choldgraf

[choldgraf]

@betatim if you give this a merge I'll be around the rest of the afternoon to spot-check any errors that might come up once it's deployed (since this one is hard to test w/o a public binderhub)