Require glyphsApp users to use color tracking with GF-defined semantics?

[davelab6]

@ gorjious mentioned in a private project that

there are Glyphs plugins by Hugo Jordan called Color Flow and Font Dashboard that make use of Layer Colors to mark progress. Hugo also has a prototype of producing an HTML progress report based on those colors.

I wonder if in our project requirements we should say, glyphsApp users are expected to use color tracking of progress, with a GF-defined semantics/schema?

Then @simoncozens could integrate a reporter into the batteries-included template repo, and all such projects would get more insight into their progress

[tphinney]

Vassil and I have been using color flags (~ same thing) in FontLab just like this, for several years now, in a collaborative way on both Google Symbols and Science Gothic before it. We semi-regularly change, or introduce extra flags, for specific stages of work. I’m… unconvinced that one size will fit all, based on our experience to date.

I will note that we also use tags, because any given glyph can only have one color flag (at least, per layer, and we only use one per glyph because anything else was way too confusing).

For example, what if there are two kinds of fixes that you need to make; you would want to distinguish those. What if one was 5x as much work per glyph as the other?

What if there are two or three different things that need to be done, and the affected glyphs are overlapping sets?

Perhaps something like this better than nothing. But I would view any simple %-done that is just based on glyph count with some skepticism.

That said, I can imagine ways of giving it enough flexibility that individual custom schema still work within a broader framework. For example, have a narrow set of colors for “done,” and anything else is some version of “needing work.”

[eliheuer]

Please keep in mind that some projects use different shades of one color to differentiate between base drawings and composite glyphs. For example: dark green and light green should read as the same level of completeness (done, good) in the Google Fonts Template Repo if this is implemented.

I like the basic traffic light color scheme approach:

🔴 major work needed 🟡 minor work needed 🟢 good, done

This is subjective, but to my eyes green for done/good is nicer to look at than any other system I have seen.

IMO this makes more sense than a gray color for composite, both dark green and light green mean good and/or done while maintaining the distinction between base and composite glyphs. Sometimes composite glyphs are just auto-generated and need tweaking to look right, so they also need a good/done indicator.

[tphinney]

I imagine a lot of people have their own schemas already for this sort of thing. And GF are usually pre-existing projects.

But certainly GF could propose some reasonable practices or a model for this... which might eventually become a requirement some years down the line.

[arrowtype]

Yeah, this seems like it could be a handy thing to offer guidance or suggestions (and maybe even tooling) for, but it also strikes me as something that would be onerous to impose on designers, as everyone will be coming from their own systems.

But yes, establishing some reasonable, optional conventions could be great!

To that end, here are my main experiences with marks:

• I like to mark composed glyphs in gray, to quickly show that I don't need to click into them to draw
• I sometimes use marks like yellow or red to mark glyphs as needing checking or fixing ... But I find that for me it's more productive to make external checklists to track this kind of thing. It's very hard to remember why a glyph is marked red or yellow, if you come back later.
• A useful way I used marks recently was for the Shantell Sans project, where we marked all Cyrillic glyphs in a color (purple, I think?) to mark them as glyphs for my collaborator to work on. It helped make things easy to sort and visually distinguish from the Latin characters and symbol set that we had before extending into Cyrillic.

[gorjious]

I've found ColorFlow to be a really helpful productivity tool. It extends the basic function of setting Layer colors in Glyphs by 1) allowing users to associate a task with a given color and 2) making it easy to quickly apply color/mark tasks as complete via a checkbox in the sidebar. Furthermore, its focus is on the workflow for a user and allowing customization for that.

For example, this is my current setup of breaking things down into smaller tasks:

There are 12 layers colors which give a lot of options for assigning a task to a color. In ColorFlow, there is a separate .txt file that allows for customizing the names and order in that colors are presented. I imagine it could be possible to have that file be localized to a particular glyphs file (something to ask Hugo Jordan about) which could work with a template.

Everyone has their own workflow, of course, and use/association of color but with so many color options, it seems reasonable to have a select set of colors that are reserved for general tasks (green=done, red=error, orange=in progress, etc) and others open to customization.

[HugoJourdan]

I wrote a script to generate a Color Label report in HTML. I haven't publish it yet, but It will be soon available on GitHub.

Here is a screenshot :

This report don't only show how many layer/glyph are set per color for each master, but also the difference between two script execution. (That's what you can see in "Advanced Report" panel)

I preferred to use HTML instead of a Markdown, because I wanted to use custom CSS, but it's possible to convert it to a Markdown file.