Logo Storage

Continuing this conversation: Broken logo (opened path) - #25

Agreed, I think we can use Zoho Workdrive to host it. We will also want to update the docs page :slight_smile:

3 Likes

Maybe we should start a separate discussion about a file storage and its usage?

It would be nice to have a kinda transparent system, which explains how to keep and exchange different files, not only these specifically. Folders strucuture, roles and responsibilities etc.

Personnaly I prefer Google Drive, but I’m also ok with any systematic solution.

And, BTW, Github might be not that bad as it seems, if users can have direct download links form the website without digging into it’s structure. It has the version control, it allows to undo any inproper changes and provides a common way to contribute for everybody which is rather important.

It’s obvious that changes should be reviewed by the Team Lead somehow (or someone else who’s in charge) before going to production, but there also should be a normal workflow to let people upload their files for that. Otherwise it turns into mess kinda “logo_new22.svg”, “logo-white-fixed-some-points-02.eps” etc and nobody knows if a file is current or outdated, how it is used along the project and if its deletion would break linking for users or other resources.

To me It’s worth of thinking and discussing (and even careful planning :slight_smile: ).
Shouldn’t we split this into a topic?

4 Likes

Agreed. I think it is worth splitting the topic. I’m sure there are other files / docs (such as “How tos”) that would benefit from central storage and management. Github would work for me too for certain files.

@james also referred to the need for improved content and organization of documentation in this post.

3 Likes

I have split the thread :slight_smile:

I will wait for @BlueSkyPhoenix’s input here. It will depend on what is easiest for the marketing team to implement :slight_smile: I do agree that there should be some verification of any assets that are changed.

4 Likes

GitHub is a good solution for design assets that are official and infrequently changed. It is not really overkill for this purpose because we want to be able to have verification when something changes, and be able to look up historical versions if necessary. All of this is also free.

Zoho WorkDrive or something like it may be better for passing files around when people are collaborating on design projects, but it doesn’t seem like a very good solution for what we need here.

5 Likes

Thanks for the discussion, all – and thanks for your work on this!

The Box account was something that was created some time ago and I don’t think it’s necessarily the right solution; I’d much rather see us consolidate rather than splinter off into one more platform that everyone has to remember exists.

That said, I’d like to hear opinions on the unrestricted access to some of the original, modifiable vector art. I greatly appreciate all the work that went into improving the logo; I also agree that changes should be verified before they are accepted into our “library” (wherever that ends up living). However, I’ve seen a fair number of times that an .eps was mishandled by a well-meaning “brother’s-nephew’s-second cousin who took an online class” and in the process, mangled the logo entirely. If we don’t make those files publicly available, they can’t be mangled… especially now that the work has gone into fixing them.

I looked at several Open Source projects to see what they’re doing with regard to logo usage and brand guidelines, and here’ s what I’m seeing:

Most host the files directly on their website and allow people to download assets from there. That said, most also only offer .png and .svg versions of their logo. Most also offer brand guidelines to clarify acceptable usage.

Examples:

https://www.npmjs.com/policies/trademark - this one is the most restrictive of all
https://www.tensorflow.org/extras/tensorflow_brand_guidelines.pdf
Here’s one that hosts on Github: artwork/projects/kubernetes at master · cncf/artwork · GitHub

To be clear, I do not want to restrict our community from being able to share freely about ClassicPress and to have a transparent system as @norske pointed out:

Personally, I’d advocate for the ability to download .png and .svg files directly from the site here: ClassicPress Brand Guidelines | ClassicPress.

For original vector files, I think that all team leads should have access to those files, but that they shouldn’t necessarily be openly available to the general public.

For Community/General public logo requests:

  • Contact any team lead.
  • Team lead can share the file (or refer them to the Design Team lead at their discretion)
    ** Should advise the community member that any changes/modifications should be approved by the Design Team lead.
  • Changes can be submitted by the Community member to the Design Team lead for review and approval.

Upon approval, Design Team lead is responsible to:

  • Update all related publicly accessible files (on the brand guidelines page)
  • Contact other team leads to advise changes so they can make appropriate changes in their area of responsibility
    ** Marketing team
    ** Core team
    ** Community team
    **etc.

Thoughts? Feedback?

5 Likes

Re: Github – I know there has been some pushback about Github from those who are unfamiliar with it. If you are not a developer (and many creatives aren’t) Github can be confusing. I don’t want to discourage people from volunteering because of a perceived technology barrier.

3 Likes

I agree with this. Practically it means they will be stored somewhere in GitHub, whether along with the rest of the site’s code or in a separate repository.

More details here, this task is waiting for an owner: Improvements to Brand Guidelines page · Issue #3 · ClassicPress/site-www · GitHub

I am curious why not store the source files alongside the .svg and .png versions and make them available for download on the brand guidelines page also? It seems like it would be simpler to keep all formats there, and having access to a .ai is not that different from a SVG in terms of what someone can actually do with it (a SVG file is fully modifiable as well).

3 Likes

I’m fine with this too. ClassicPress Brand Guidelines | ClassicPress seems the right place for them to live publicly and Github works for me in terms of storage.

Agree. Perhaps a separate repo would be less daunting for those less experienced in Github (and I include myself in that last statement)?

I’d be happy to pick this one up if @james and @BlueSkyPhoenix are OK with this? Given that it’s mostly my comments that are being quoted (i.e. it’s me that started it :slightly_smiling_face: ), it seems only fair that I take responsibility for sorting it. Likewise, if you’ve other ideas, that’s fine too.

This make sense to me. As James says, the .svg is an editable file which can be opened by Illustrator (or even a text editor). So once the .svg is out in the wild, any control is lost.

My only question about this is: clearly the .ai file would remain the master copy and the file that needs to be updated and approved etc. Would the same process also apply to any files (.svg, .png, etc.) generated from the .ai?

3 Likes

Sure, but they will do even worst without the source file :sweat_smile:
So I’m for the unrestricted access to every file.

4 Likes

+1, it is the best solution from the UX perspective.

4 Likes

Github is great for managing SVG since the code is XMl based it keeps track of changes within that code not just the image as a whole.

I have a collection of logo icons on GitHub and script to convert all the SVG into PNG, black and white versions.

You can easily link to what ever you need for users to download.

4 Likes

Yes, please :slight_smile: I will drop some more information about how I envision the page working on that GitHub issue.


We (edit: more specifically the design team) should be reviewing each change to the logo files, and this should be something that happens very infrequently. I think this addresses most concerns with distributing the .ai files.

Let’s back up and take a second to better define the purpose(s) for this storage system. I think there are two:

  • Public users should be able to download our official assets from an official place with an official URL that we host ourselves. We’ve basically all agreed that this should be the brand guidelines page, which means the files need a clean way to get onto our web server for hosting.
  • ClassicPress team leads should be able to reference our official assets and work with the design team to update them when needed (infrequently), with the ability to track changes and access historical versions if needed. Bonus points for being free.

To me, this points pretty clearly towards storing the files in GitHub.

Related…

I think this is probably the best path. It will take a bit of configuration to get this into the right place on our web server but that is not too hard. This has the advantage that the file structure and history would be publicly viewable (currently our site files are private, I’d like for us to open-source it one day but there are some parts that would need to be audited first).

Another thing we will need is a list of places the logo is used in an official capacity. Changing our logo is always going to be a painful process but this will help a bit. The list can probably live in the same repository and I can help put together something for the core code.


@wadestriebel @BlueSkyPhoenix Please correct me if I am wrong here, but collaborating on design assets as they are developed is a separate problem, where some kind of cloud storage drive makes more sense than GitHub. However once an asset is finalized and agreed upon, and we agree that it’s something critical like our logos, it needs a more permanent and robust storage system.

5 Likes

I completely agree with what’s been presented here – what’s the next step?

5 Likes

I suppose the first step was creating the GitHub repository for these files, which I’ve just done: GitHub - ClassicPress/ClassicPress-Design: Repository for official versions of logos, logomarks, and other brand assets.

Unfortunately that is the easy part :wink: The next step would be to name the files according to the naming convention we agreed upon earlier this year and put them into the repository, then generate/replace .png and .svg versions. The SVG images should be web-ready, with a minimum of extraneous attributes added by Illustrator et al.

I can help with questions about how to get this organized, and unblock specific steps where needed, but some things will need to wait for Michelle’s input.

Again a lot more detail on Improvements to Brand Guidelines page · Issue #3 · ClassicPress/site-www · GitHub, fair warning, this issue starts to get into a lot more than just logo storage.

4 Likes

So, am I right in thinking that the new names would be as follows ?

Original New
feather-gradient.svg classicpress-logo-feather-gradient-on-transparent.svg
feather-white.svg classicpress-logo-feather-white-on-transparent.svg
icon-gradient-600.png classicpress-logo-coin-gradient-on-transparent-600x600.png
icon-gradient.svg classicpress-logo-coin-gradient-on-transparent.svg
icon-white.svg classicpress-logo-coin-white-on-transparent.svg
logo-gradient.svg classicpress-logo-wordmark-gradient-on-transparent.svg
logo-white.svg classicpress-logo-wordmark-white-on-transparent.svg

Regarding the repo, What do you think about creating a logo subfolder to help keep things organised for when other non-logo assets are added at some point in the future?

5 Likes

I like the idea of using a logo subfolder, would be nice to eventually add all marketing assets in one place :slight_smile:

5 Likes

I have gone ahead and started something,
https://github.com/mathewcallaghan/ClassicPress-Design
The SVG files are optimised a bit smaller than the currently available versions.
This is all I have time for at the moment.

4 Likes

I’ve tried classicpress-feather-gradient.svg from mathewcallaghan/ClassicPress-Design but the path is already opened.

I’m totally unfamiliar with autometed tests, but if anyone can write it, it’s easy to check for this kind of problem in SVG files. Every path must end with Z (or z), that means closepath.

Simone.

1 Like

Isn’t that for strokes?

1 Like