Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define community guidelines for extending Jupyter design assets #65

Open
choldgraf opened this issue Jan 23, 2021 · 3 comments
Open

Define community guidelines for extending Jupyter design assets #65

choldgraf opened this issue Jan 23, 2021 · 3 comments

Comments

@choldgraf
Copy link
Contributor

The issue from @jasongrout here: https://github.com/jupyter/trademark/issues/7 got me thinking that this is quite a common pattern that I've seen. It goes something like:

  • Jupyter is inherently modular and extendible
  • So people extend it to new kernels/use-cases/etc
  • They want a logo for their project
  • So they slightly modify the Jupyter logo to adapt it to their project-specific setup

In this case it was combining the Rust logo w/ the Jupyter logo, but I've seen it with domain-specific things, color changes, etc.

Since Jupyter is itself designed to be extensible, I think it would be valuable to the community if there were guidelines for how people could gracefully (and without violating Jupyter's trademarks) build on top of Jupyter design assets for their own logos and such. For example - what if somebody designs a new language-specific kernel and they'd like to make a logo for it. It would be nice if there a repeatable pattern they could follow to generate this logo (e.g. the Jupyter logo + a designated space where a new logo would go).

This is beyond my personal design skills, but I wanted to flag it as a thing to think about. How could Jupyter take its philosophy towards infrastructure, and also apply it to design?

@ellisonbg
Copy link
Contributor

This is also showing up again in the RTC logo discussion here: https://github.com/jupyterlab/rtc/issues/51

A few years ago, we had talked with some of the Jupyter UX design interns about creating a visual design system that consists of a set of visual building blocks that could be used to create new logos for different purposes. The idea was to have this visual language be related to, but distinct from the actual Jupyter logo, so we can balance the need to maintain the overall Jupyter brand that is represented by our main (trademarked) logo with the need for modularity and extensibility around the community. We do have another group of UX design interns starting at Cal Poly this summer, I can add this to the list of potential projects.

@echarles
Copy link
Member

echarles commented Apr 21, 2021

https://github.com/jupyter/trademark/issues/7 returns a 404 (prolly private repo)

I came to the jupyter ecosystem roughy 2 years ago and the first difficult this I had to deal with was building my own compass across all the github org, repos, readthedocs, third-party projects... One thing that helped me was the umbrella of specific derived logos like the jupyterhub, or jupyterlab. I am fan of those derivatives and a official extensibility and modular toolkit would help (if possible to build and define that, which I see also like constrained innovation and imagination).

Even that that UX toolkit is provide, we still remain with the fundamental question of "which project deserves a specific logo?'. e.g. does jupyter server (https://github.com/jupyter-server), jupyter rtc, jupyter format... deserves their own logo?

@jtpio
Copy link
Member

jtpio commented May 7, 2021

this is quite a common pattern that I've seen. It goes something like:

I think this is indeed a very common pattern. For now the guideline is pretty much "don't modify the logos".

The "Logo Misuses" section is useful, but it's not clear whether "parts" of the logo could be reused or borrowed (for example the semicircles only):

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants