[Design-devel] Looking for colors to identify Debian releases

[Jonas Smedegaard]

Quoting Christoph Biedl (2016-10-23 13:41:45)
> Jonas Smedegaard wrote...
> 
> > Hi Christoph (cc design list - please subscribe if not already),
> 
> Now done.

Excellent. Welcome aboard!


> Basically, I need this for two purposes:
>
> Colored shell prompts in chroots that hold the respective 
> distribution. Terminals however, at least the older ones, do have a 
> tight constraint on the number of available colors, 16 or even eight.
> 
> Graphs created by the mentioned tools. They can utilize the full 24 
> bit color set but still should be usable for people with (slight) 
> visual impairment. These colors should resemble the respective low-res 
> color where possible. And they should work well when drawing a line on 
> a white background as gnuplot and rrdtool do.
> 
> 
> In the end there might be nothing but a small table in the Debian wiki 
> like (all numbers but for jessie are made up):
> 
> | The following colors are recommended to describe individual releases:
> |
> | Distribution  ANSI color code   hi-res color
> |
> | (...)
> | squeeze       1;34              #223344
> | wheezy        1;35              #334455
> | jessie        1;36              #489191
> | stretch       0;31              #556677(*)
> | buster        0;32              #667788(*)
> | bullseye      0;33              #778899(*)
> |
> | sid           1;30 or 0;37      #101010 or #f0f0f0
> |
> | (*) Tentative, to be determined in the artwork contest before the release
> 
> Note sid is always some black or white to mark its constant state, and
> there are two colors so it's visible on both light and dark
> backgrounds. Although on a second thought I'm not sure whether we
> should rather provide separate sets of colors for both background
> settings.
> 
> Other tasks are determining the colors as a part of the artwork
> contest, and spreading the data through technical means, the obvious
> place was distro-info-data.
> 
> For low-res colors reusage is inevitable so choose at least six to have
> one as a spacer.
> 
> 
> All that's left to do from my point of view was to define these 
> colors, for the past, back to buzz.

If your idea is only listing the colors, then I guess you are done.

But if your idea is to make the colors "the official colors of Debian", 
then I believe what is needed is for our users to embrace them.  And for 
our users to most efficiently embrace some color scheme, it should be 
possible to apt-get it, so that it will appear in our popcon :-)


> As I'm not very confident in my design abilities, I wouldn't want to 
> do this on my own, or with some amiable feedback only.

Sounds like you have experience with drawing graphs (I don't), and a 
concrete idea.

I guess a next step is to communicate your idea.  You could create a 
page at wiki.debian.org about it, that e.g. covers this:

 * What is fixed (RGB hex values?, must work on 16-color terminals? Must 
work for XX and YY forms of color-blindness?)

 * What is variable per release (can one release be duotone-style, and 
another be tritone? Must the Debian swirl red be included always?)

 * Example use cases (you mention shell prompt and graphing here)


> > Perhaps an easy start was to implement as base16 themes?
> (...)
> > I am considering a) packaging base16 for Debian, and b) try make a 
> > GTK+ theming engine tied to it.  Having release-oriented color 
> > schemes would be a fun option for that :-)
> 
> Quite frankly, I don't see how base16 fits into this. It still might 
> be something to look into when it's about to find palettes or ways to 
> describe them in a technical way.

One way to communicate your idea to others is to put together a concrete 
implementation of it.

Base16 is not a tool to browse and pick color schemes, but a format to 
express a low-res color scheme, for easy and flexible deployment: A 
definition of how to label 16 colors - either as a single color theme or 
a dual "light" and "dark" combo.  Use of that specific format reuses 
years of testing integration into a range of environments, drawing from 
experience with integrating Solarized and other monolithic schemes.

I suspect it is only slightly more work to express your idea in the 
base16 format than colorizing one specific environment - and is far less 
work than colorizing, say, 5 environments (which terminal do you use? 
Will you require every user of your concept to use same as you?).

I suspect it is easier to convince package maintainers to implement 
support for a generic color scheming framework, than to convince them to 
integrate a single hardcoded color scheme.


> PS: Next thing was to do the same for architectures. Although you'll
>     never get easy-to-read graphs if you put some 28 lines of data 
>     into one, like it is done in the popcon statistics.

Dismissing 28-color scheme as "never easy-to-read" is not fun. ;-)

Maybe relevant to locate and reference research in the area of easy 
distinguishable colors.  I seem to recall that NASA and BOEING did 
research on this for coloring instruments aboard spacecrafts (Hollywood 
have promoted to the public that the eject button should be red and 
sealed behind an added glass, but all other colors of all other buttons 
and knobs have also been carefully decided).

IBM has released a design manual, including color scheme, at Github, if 
I recall correctly.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/design-devel/attachments/20161023/f7cc22f4/attachment.sig>