Static style guide

[danbeere]

A WIP, that will continue to evolve, this is the initial commit of our static style guide for inner. Inspired by Managing Style Guides at Shyp we're going to try using GitHub as a way to commit to, review and update our style guide(s). @KunalJain @plainspace @jimdotrose @ndintenfass @rishimkumar

[KunalJain]

Looks great! @danbeere

Few things to consider:

• Picker pattern than a branch picker
• List pattern than a branch list. We should be able to use that list for deploy etc in future.
• Same as above for commit list.
• Patterns for graphs than Insights
• CTA's on graphs
• Patterns for pages - Example Add project, build list, project settings etc.

[Peeja]

This looks fantastic. I only have one concern: I'd strongly prefer if we divorce the notion of our heading sizes from the HTML tag names h1–h6. I think it's much better not to imply that those headings need to be implemented with those HTML elements. Currently, we have a lot of style attached to those tag names, and we end up overriding it all over the place.

I think it's also semantically valuable to find an actual name for them. For instance, these:

aren't "H2s", they're "Module Headings" (or "Primary Module Headings" or "Module Titles" or something else appropriate). Finding that name for them is valuable. Case in point:

I'm not actually sure what this heading is. It's called an "H3", but that doesn't tell me what it means or when we use one.

Speaking of headings:

I'm a stickler for names, but I think it's important: these are headings, not headers. (A header is a block of content at the beginning of some larger unit of content; a heading is a line of text that serves as a title in the content outline.) I'd also prefer we called them something like:

• Heading Biggest
• Heading Big
• Heading Medium
• Heading Small
• Heading Smallest

again, so we don't conflate their names with the HTML names h1 though h5, which won't necessarily be how they're always implemented. (Incidentally, I'd say it's appropriate to call one of these "Heading Big" here rather than "Module Heading", just as it's appropriate to call one of our colors @blueDark: this is our typography palette, just as we have a color palette. We'd say, therefore, that the Module Heading is a Heading Big, just as we'd say that External Links are @blueDark.)

[Peeja]

Oh, two other things:

• @blueDarkest is missing a hex value.
• Modules (I'm glad to have that word, by that way), Build List Items, and each project in Insights are all instances of what we've been calling a Card; it might be useful to see the Card style demonstrated abstractly as well.

[danbeere]

Static style guide iteration addressing some feedback of the previous commit. Some screenshots below.

[danbeere]

Update required to add some space between elements for readability. Some screenshots ⬇️

@KunalJain, I'll continue to add more usage examples and if you've any recommendations that'd be great too. Cheers 🍻

[Peeja]

Because these text styles are more than just sizes (the smallest two are all-caps), we should find names for the entire styles. Using font-size: @fontSizeSmall won't get you an all-caps heading; instead, @fontSizeSmall is just one attribute of a text style for a particular kind of heading, which also includes font-weight and, in this case, text-transform. We'll end up using these text style names as mixins or extends in the code.

I'm concerned that this doesn't demonstrate a "List B" (let's find a more meaningful name for that, too) so much as a Commit List. Reading this, I wouldn't know how to reuse this element for anything else. The other place where we have a "list with items that can be expanded or collapsed" that I can think of is the Test Failures, which have only the "More" toggle in common with this design:

If that's really all that a "List B" dictates, that's not clear to me from the way it's laid out here: it reads to me as if the header and the individual rows are significant.

(Also, there's still an "H5" in the List B header.)

[danbeere]

Updated lists section to include our tests failure pattern.
Screenshot below:

Thanks a million for the feedback, @Peeja! Didn't update the font styles section as part of this, but below is an example that specifies font styles including all-caps. Is that what you have in mind or something else?

Cc @KunalJain

[danbeere]

Style guide updates based on PM feedback to include tables, combo buttons, pagination, messaging templates and tooltips, as well as usage descriptions for some patterns. Cc @KunalJain

[Peeja]

Yeah, that's exactly what I'm going for. (I assume "Recipient", "Address", and "Label" are the names for the styles in this example?)

Also, the List Expandable reads much clearer to me now. Based on the name and the two examples, I can infer that we're really just talking about the expandability toggle. 👍

[danbeere]

Add expandable list item from the stages/steps of our build page ⬇️

Also on Zeplin 👍 https://zpl.io/ZiOq4V

[Peeja]

I'm glad to see the step component on the style guide, but I don't think it counts as a List Expandable. A List Expandable shows the first three items of a list and then a disclosure to reveal more. The step component just hides or shows everything. It's not a list at all.

[danbeere]

@Peeja Good point. Any thoughts on how best to categorize it?

[Peeja]

I don't think we use that component for anything else, so I think it's just a Build Step.

[danbeere]

Update selector UI element with icon top right (optional)

[danbeere]

@KunalJain @Peeja Reordered and renamed - d1066c8 - some UI elements to agree on. Any thoughts?

[Peeja]

Looking good! Under List Expandable's Usage, though, I'd say, "For lists which can be expanded or collapsed." It's the list that expands, not the items.

[danbeere]

Update - dc231e8 - list expandable usage copy following @Peeja's feedback

[KunalJain]

🚢