meetuparchive/meetup-swatches

Cross-platform color configuration by design@Meetup

Swatches for Meetup

Hues at my Meetup?

Here they are - standardized and design-approved Meetup colors. For web, mobile web, iOS, and Android.

Documentation

http://meetup.github.io/meetup-swatches/

---

Development setup

1. make sure you have ruby 2.0.0 installed (if you use rbenv this will be easy, .ruby-version sets the correct version for the project)
2. make sure you have the bundler gem installed
3. use bundler to install dependencies
4. After editing colors.yaml use this command to rebuild the consumable files

	$ bundle install
	$ edit src/colors.yaml
	...
	$ rake

Updating live documentation

This is currently a manual process.

1. build docs in your branch by running rake
2. git checkout gh-pages
3. git checkout master -- doc/index.html
4. git add . && git commit -am "update gh-pages" && git push

fun fact: to make a branch-specific or release-specific build of docs live, just copy doc/index.html to gh-pages as [someOtherFile.html]

meetup-swatches's Issues

make the rebuild.rb a propper gem

Idea:

an abstracted "swatch cutter" gem that you feed a color yaml, and it generates ios, andriod, sass, and less files

we can update our meetup-swatches gemfile to require this gem

Why:

because this would make a cool open source thing

2.1.0

Small fixes/additions to foundation-based palette

add "attention" yellow

for when we want to display something potentially negative (ie. "unpaid" status icon) without associating meetup red with bad things

change or append to output files to use lists and/or maps of colors

for example, with a Sass list we could do something like:

/* swatches sass distribution */
$accent_swatches: $red, $blue, $green;

/* consumer */
@each $color in $accent_swatches {
     .backround--#{$color} {
          background-color: $color;
     }
}

I see some advantages to using maps or lists over a bunch of orphan vars for the distribution files...

Update $C_backgroundCollection to be blue shifted

Can we just rename this repo "swatches"?

"Meetup-swatches" seems redundant.

Semantic versioning

We should start using semantic versioning for this project instead of counting by tens.

version = <realease>.<bugfix>.<hotfix>

Add `inverted` link color

in inverted color schemes, the link text becomes very low-contrast (especially with the light font-weights in SQ2). We can improve readability by tinting the $C_link to, e.g. 5EB4FF.

current:

proposed:

add orange accent color from create sales page to swatches?

it's a pleasant orange, and fits well with C_red: https://secure.meetup.com/create/learn-more/

Create alias for error color

Right now we're just using $C_red.
In the rebrand, we're using our new yellow color almost exclusively for errors. Might be nice to alias this as something like $C_error

Switch overlayPressed to 0,0,0,.2

As part of normalizing pressed colors on Android, we had a chat about overlayPressed and if it's really going to get used on all elements, it needs to just be a shade. Transparent blue isn't going to play well with a red button.

As part of this, I'll look into where overlayPressed is already getting used and possibly split this color if it's getting used for things that aren't presses.

Should backgroundFooter be the same as backgroundInverted?

Coming out of the nav specs, the BG footer color is a 25% gray, and the inverted color is a 20% gray.

We will probably want these to match, in case inverted sections get stacked on top of the footer components.

make a github page branch

Create swift app distribution

see app UIColor+Palette.swift

Can this be renamed Swatchsquatch?

consider generating an ase file for photoshop/illustrator/adobething

https://github.com/layervault/ase.rb

Add "accentDark" red color

Add inactive navigation icon color

Fully-opaque rgba() in scss should be rgb()

using rgba color declarations in css when alpha channel = 1 is a little brutish. Let's be more refined.

make sure cocoapods can deal with non-tagged 'latest' code

We would like to treat the master branch as "ready for production", meaning that we can eliminate the tag-versioning step whenever we make updates.

For sassqautch, this will be simple to set up with bower, but cocoapods might need some tweaking.

Modify swatches export script to include version information.

It would be useful for the exported android/colors.xml file to have two changes in particular:

• Include a comment containing version information, so that when an Android maintainer updates the colors, we can tell the last time they were updated.
• Change the name of the file from colors.xml to swatches.xml (or something similar.) Our Android project currently has a colors.xml file with older versions, so perhaps having a different file naming convention will help. [1]

---

[1] Also, feel free to open an issue on the Meetup Android repo if you think we'd be better served by making the modification on the Android side of things.

---

See also: #35, meetup/meetup-android#142

Deprecate $C_backgroundFooter

Assuming we standardize the footer background to be an inverted context (which was advised by AdamD on 2013-12-30), we should deprecate this parameter.

repeated color values in SCSS should just use color names

Ideally the SCSS output should be explicit when it's applying color names (not just reusing color names in colors.yaml).

e.g.

// bad
$C_secondaryGray: rgba(0,0,0,0.65);
$C_textSecondary: rgba(0,0,0,0.65);

// good
$C_secondaryGray: rgba(0,0,0,0.65);
$C_textSecondary: $C_secondaryGray;

I realize colors.yaml is supposed to be the primary pre-processed color reference, but this update would make the SCSS cleaner.

Add color for outlook.com

Needed for bug https://bugz.meetup.com/show_bug.cgi?id=50319. The color is #0072c6.

Note: in branch outlook_contacts_50319, this color was temporarily hardcoded in _social-buttons.scss.

make documentation beautiful

It would be nice to make the swatches prettier; maybe an inline-block list of cards that mimic pantone swatches.

We should also look at calculating and printing hex codes with JS

Colors need opaque alternates/fallbacks

Part of our set of primary colors (mostly just the shades of gray/black) are alpha-channel colors, which can work nicely on the site and give us rich semi-translucent shading and layering fun.

However, to be able to tap the same shades of gray for email designs or UI that cannot rely on RGBA colors, we need some opaque hex values for these, facsimiles of the tinted color over white (over black for the inverted colors).

change C_money to a different green; add wepay blue

@extend instead of @mixin for colors with opaque fallbacks?

all of the opaque-color fallback mixins (e.g. color_textPrimary) are argument-free mixins, which means they would probably be more efficiently implemented as @extend %placeholders.

Filesize savings are probably pretty tiny, though, so this is a really low-priority issue - I think the only advantage to keeping the setup as-is is that the styles in the element inspector in browser dev tools will be a little easier to read.