Revisions to IPFS brand book

[akrych]

As a first step to make or UI Style Guide - I made (first sketch of) IPFS Brand Book Guidlines. Feel free to comment, if you want to change something or add something :)

PS. I made also set of icons for IPFS, free to use for our community.

IPFS_brandbook.pdf

[hacdias]

BTW, it would be very coooooool to have an Icon Font to use the icons on the web 😅

[akrych]

@hacdias We can do this :) 👍

[hacdias]

Uuuuu. Really nice 😄

[lidel]

@akrych I came up with two areas to think about in spare time: up to you to decide if they belong to PDF version of Brand Book, or is it something for an appendix to a final Style Guide. Just wanted to write them down somewhere :)

[1] Indicating Progress

A common theme in IPFS ecosystem will be uploading/downloading something, be it data or metadata, stats. We could provide some guidelines/ideas about on how to communicate things like:

• "upload/download in progress" (0-100%) – visual feedback when sending a big file. Some ideas: it could be a clean progress bar, it could be IPFS cube being slowly filled with colour and progress % overlaid over it etc
  • "wait a sec" – a spinner for things that do not take more than 1-3 seconds

(Having some prototypes, we could extract them into reusable components)

[2] Icons for popular actions

IPFS exists in a specific problem domain, which makes it possible to anticipate need for specific icons. We could add a few more to avoid situation where apps are using different icons for the same action. I suspect the most popular actions would be:

• "Upload" / "Download"
• "Pin" / "Unpin"
• "Share" / "Copy"

ps. found potential typos in PDF: Guidlines → Guidelines, Table of contest → Table of Content :)

[nothingismagick]

The link logo doesn't seem like its style matches the other icons.

I propose thinning out the body of the links like this (but SVG and clean):

---

And here is a suggestion for a way to use the classical idea of the pin and combine it with the IPFS logo.

{edited to be more to the point and less inflationary}

[nothingismagick]

Consistent use of typography within the brandbook:

Page 22 (screenshot):

Page 17 (screenshot):

Note: If the user of the brandbook styleguide writes IPFS with Verdana, the "I" will have serif-esque styling. In Montserrat this is not the case. To this end I would not consider Verdana to be an appropriate drop-in replacement for Monserrat.

[nothingismagick]

It would also be a good idea to have the English proofread before publishing this document again:

"Typerface?" "secoundary?" "is safe web font" "Everywhere when"

"How to write paragraph"

"pallete" "maincolors" "the Navy blue" "this include also they"

[editted to remove unflattering and needless commentary]

[nothingismagick]

Starting on page 15, the subheader at the bottom right is "Visual identity" - it should be "Logo" until page 19.

[nothingismagick]

"The color palette" There should be clear guidance about when to use primary and secondary colors with text. Is Carmine the right color to use for error feedback? What about success - turquoise? When are the tints (they are not shadows, btw) to be used?

On page 23 you have shown the gradient with hexcode (#3E9097 > #6DC5CD). This gradient is supplementary to the color swatches provided, this deserves some explanation. Furthermore, you describe the swatches on p.23 with RGB, CMYK and PANTONE - but I have to scroll back / zoom out of the PDF to find their #RRGGBB values. It would be smart to have this on one easy to reference page...

[flyingzumwalt]

@nothingismagick please make an effort to be more gentle in your feedback. We want everyone to have a friendly and safe work environment.

The technical parts of your feedback are very useful -- asking for additional guidance about how to use colors with text, pointing out inconsistencies in icon style, suggesting new icons, pointing out typeface inconsistencies, and calling out the need for copy editing. All of those things help us make this guide more useful. When giving feedback like that, please avoid comments like "They look like stock icons that took an extra shot of bland in their lukewarm tapwater..." and "really? I speak EU English too, but this is just mind-numbingly bad, but wait. It gets worse." -- these needlessly attack the work that @akrych and others have put into the guide.

As an open source project that values transparency we try to do all of our work in the open, which means we're always making ourselves vulnerable. It's on all of us, as a community, to make this a space where it's safe to take creative risks and to show your work-in-progress. People should be able to to be confident that they will not only be safe from attacks but also be encouraged and supported when they post their work.

[whyrusleeping]

Tldr; @nothingismagick, chill.

[nothingismagick]

Hey everybody - especially @akrych, @flyingzumwalt and @whyrusleeping first of all I wanted to apologise for my absolutely inappropriate tone on several of the comments in this thread. Mea culpa.

Second, I actually deleted one of them and edited the others (and noted what was changed) where there was actual "content". I clearly overstepping some boundaries of not only good taste but also compromised the environment of collaborative working with some harsh words. I am REALLY sorry for dropping the ball and I hope you give me another chance.

[nothingismagick]

So, I have been doing a LOT of thinking about what happened to me internally here - where my stack overflowed so to speak, and I wanted to share what I think is the root of my reaction. It has to do a bit with the scope and the approach of this issue / repository at the time when I ranted. This is not meant to be an excuse for my behaviour - and is not about shifting blame. I just want you all to know that I have completed my due diligence regarding understanding my personal behaviour and think I have come up with something that might actually HELP this specific aspect of the project that is focussed on maintaining a consistent visual brand identity.

Some framing

1. The context is Github, a place where people can contribute to open-source software projects.
2. Authors are always credited for their work and licenses are appropriately displayed.
3. A common working pattern is to report an issue, discuss it with stake-holders, fork the repo, fix the "issue" and make a pull request that can then be further discussed, enhanced, approved and finally integrated / merged / published.
4. Binaries, packages, or other artefacts, if they are supplied, are clearly referenced with build steps and commit records, enabling the interested to find and understand the code used in the generation of said objects.

I think we can all agree that this is how community development works (or should work) here. I had a very specific feeling, at some point, that the way that this issue was presented was in a form (rendered pdf) where it was technically impossible to follow the common working pattern I mentioned above - and that is where my personal psychological "safety-net" broke. I was participating in a conversation where all I could do was give feedback and couldn't REALLY contribute - which had the opposite effect of what was intended. @akrych was working on being transparent, which is really cool and rare in the design world - but I just couldn't grep it.

So my proposal? Well, it is not a complete "do this and everything will be better", but more of a suggestion about looking into ways of leveraging the strengths of git and CI in order to render a pdf from e.g. HTML, CSS and text. There are many approaches to doing this, too many in fact to begin discussing. I see some major benefits of this approach:

• recyclable code blocks
• translations become easy
• a build pipeline keeps the version up-to-date on every change
• zero reliance on proprietary software like InDesign
• the ability to publish the "code behind the book" instead of just the book
• participation via classical git patterns is enabled

Anyway, thanks for reading. See you around.

[lidel]

@akrych some requests to address in spare time :sweat_smile:

• replace Montserrat with Inter UI for text blocks in web contexts (for reasons noted in https://github.com/ipfs/docs/pull/68#issuecomment-396147766)
• add a recommendation of fixed-width (monospace) font to use along with Inter UI and Montserrat (for code snippets, configuration files in Advanced view of webui, IPLD Explorer etc)

[lidel]

If anyone is looking for more up-to-date resource, follow:

• Figma: IPFS-Brand-sheet-public
  • PDF version

[lidel]

Closing, as we now have IPFS brand sheet

(PDF version)