Next steps on UI Guide

next_steps.md

Next Steps

Start with the basics.

• Typography
• Colors
• Basic Components
• Complex Components
• Page Layouts

For everything we do we need to make sure we either use something that exists or have a good reason why we roll our own. I do not think we should have any kind of strict requirements around what we use or do not use. Since a UI Guide is very specific to the consuming applications we should not feel boxed in by any existing component libraries. Ideally we integrate these libraries into our UI Guide as we build it out more.

Typography

Need to figure out our typography strategy. My thoughts thus far:

• Use a responsive approach (get bigger body text on mobile, and smaller headers)
• Start with a body copy size of 18px
• Scale our sizes based on body copy size using rem units
• Figure out if we want default margin/padding on anything

Colors

We need to figure out what colors we want to use. There is an audit of our existing colors. We should probably think of colors as parts of different ideas:

• State Colors -- active, info, warning disabled etc.
• Theme Colors -- brands and headings
• Element Colors -- <a>, <em>

In my ideal world we would have very few colors and for things like :hover and :active we would do a lighten or darken of a given color by a percentage.

Basic Components

These components are the most simple sorts of things you can dream up. Components like lists and buttons. These basic components will be the first set of items that start making assumptions on margin and padding. It may be the case that they would only make assumptions on padding and our more complex components will make assumptions on margin. We'll need to see how this plays out.

Here is what I'm thinking for our first round of basic components:

• dividers (e.g. a list divider)
• lists
  • in-line
  • indented
  • full-width
  • groups
  • highlighted (colored)
  • sizes
• buttons
  • groups
  • sizes
  • in-line
  • stacked
  • full-width
  • drop downs
  • split buttons
• paragraphs (e.g. defaults for <p>)
• Forms (e.g. in-line, stacked)
  • labels
    • sizes
  • inputs
    • groups
    • pre/post "add-ons"
    • sizes
  • help text
  • error messaging
• tables
  • striped
  • condensed
• mini layouts (e.g. what you see with market stats in TPF)
• font icons (e.g. font-awesome, material etc.)

Complex Components

• Panels (similar concept to bootstrap)
• Navigation
  • Site level navigation
  • The concepts in the division navigation
• Filters
• Bid Toggle
• Flags/Ribbons (e.g. the banner in TPF)
• Tabs

Page layouts

As we get further along we should have some basic page layouts we work with. This isn't to say that we only allow specific layouts but that we have common ones that we can use easily and will contain content in a way we expect.

After we do the basics

I think once we've done the basics we should be pretty good to start pulling the UI Guide into our actual sites, starting with the admin application first.

z_possible_jiras.txt

h1. Base Documentation for ui-guide

The following list needs to be added to the ui-guide in the first section.
The purpose of this list is to show the direction of the ui-guide.
This list will also give an idea of how the code should be used. By reading
this documentation in its final form a consumer of the ui-guide will know
exactly what to expect when they use a class/component from the ui-guide.

# Use BEM
# Coding style should follow cssguidelines -> http://cssguidelin.es/
# Selector specificity should be as low as possible
# Styles are separate from {{html}} tags
# Use {{rem}} units for most measurements
# Mention philosophy/ideals
#* Containers do not assume content
#* CSS for look is separate from CSS for layout
#* CSS should be semantic when used (e.g. color-primary instead of color-red)
#* JavaScript related classes must be separate from the style or layout classes
#* Classes for JS must start with {{js-classname}}
#* Utility classes are not to be used directly in HTML
# Margin and Padding
#* Should only be set on components
#* Based on base typography sizes
# Components
#* Support RTL and LTR by default
#* Used to build up larger components
#* Can make some assumptions on margin and padding
#* Only have 4 sizes: large, default, small, extra-small
#* Favor using {{extends}} over mixins directly to reduce CSS rules
# Document expectations of where code goes:
#* measurements.less - holds constants for size like margin/padding
#* rtl.less - holds code that is specific for achieving right to left and left to right styles
#* mixins directory - only for mixins that _must_ be mixed into the declared styles

**Success Criteria**

* Base documentation is added


Notes: Feel free to add more to this list. Need to document what overall
design philosophy we use, (e.g. material design?).








h1. Standardize Typography

With what exists we can move forward and call it good. However,
we need to work with the Design and Development teams to ensure
we build out the correct base typography. Typography is the
base that all other parts of the ui-guide will be built upon so
it is imperative we have a solid base starting out.

Parts to include in typography:

* Headings (already created)
* Information on base choice (e.g. font-size)
* Example text of how large blocks of text look
* Decide on if padding/margin should exist in {{<p>}} and how much

**Success Criteria**

* One page for typography doc added
* Headings are documented
* Headings exist
* Basic examples of text are shown
* Design has signed off on typography choices








h1. Standardize Colors

Design and Development need to get together and land on colors.
The colors can fall into different categories and or use case.
All colors should follow a semantic usage pattern.

Currently defined colors: 

* primary
* secondary
* success
* warning
* info
* critical
* inverse (opposite of "base")
* "base" (opposite of inverse)

More colors can be added or updated, need to figure out with
design.

Document the usage of colors:

* text-color--TYPE (these are used to set the color of text)
* background-color--TYPE (these are used to set the background color of elements/components)

**Success Criteria**

* Colors are chosen
* Examples of when to use colors is documented
* Usage expectations of text-color and background-color is documented







h1. Create Base Buttons

Need to create our basic buttons and types.
Figure out if these buttons should follow bootstrap styles
or if we need to adhere to material design.

These base buttons should already be created, the goal
here is to ensure the created buttons match what is desired
form a design and development point of view.

Remember to take into account our text and background colors
and how we want to size the buttons.

Color and size back up the base set of buttons. Full width
buttons should be included as well (e.g. {{button--full-width}})

**Success Criteria**

* Base buttons are documented
* Base buttons are created







h1. Button Group: inline and stacked (space)

Create inline and stackable buttons. These buttons
will likely be used later by different components such
as forms and paging. These buttons should have space between them.

**Success Criteria**

* inline buttons created (space)
* inline buttons documented (space)
* stacked buttons created (space)
* stacked buttons documented (space)








h1. Button Group: split buttons

Create groupings of buttons that support splitting the buttons into
two clickable parts. See bootstrap example: http://getbootstrap.com/components/#btn-dropdowns-split

**Success Criteria**

* Split buttons created
* Split buttons documented


Note: split buttons _are_ separate from the dropdown component. The dropdown component will
likely use split buttons, but split button should not be coupled with dropdowns. 








h1. Lists: basic

Create a simple bullet and numbered list.
This should have whatever our defaults will
be for lists (e.g. show the bullet or not).

Full width lists should be included here as
well. (e.g. {{list--full-width}})

**Success Criteria**

* Create base lists
* Document base lists







h1. Lists: inline

Create a simple inline list. This list should allow for
creating components like inline navigation. Mostly used
for horizontal based lists.

**Success Criteria**

* Create inline lists
* Document inline lists






h1. Lists: indented (padded)

This is a type of list that adds padding and indentation
to _only_ the top level. For example: 

{code}
<ul class="list--padded">
  <li></li>
  <li></li>
  <li>
    <ul class="list"> <!-- this is not indented -->
      <li></li>
      <li></li>
    </ul>
  </li>
</ul>
{code}

Suggested classes to achieve this:

* {{list--padded-large}}
* {{list--padded}}
* {{list--padded-small}}
* {{list--padded-extra-small}}

Initially we should really only start with {{list--padded}}

**Success Criteria**

* Created indented (padded) lists
* Document indented (padded) lists






h1. Lists: inline and stacked (grouped)

Grouped lists go together similarly to how grouped buttons
go together. The grouping should _only_ style the lists so they
look joined together.

Example:

{code}
<ul class="list list--grouped-inline">
  <li></li>
  <li></li>
  <li>
    <ul class="list"> <!-- this is not indented -->
      <li></li>
      <li></li>
    </ul>
  </li>
</ul>
{code}

Proposed classes: 

* {{list--grouped-inline}}
* {{list--grouped-stacked}}

**Success Criteria**

* inline list group created
* inline list group documented
* stacked list group created
* stacked list group documented







h1. Lists: Styles

This tickets includes adding styles and "types" of lists.
For example an "alert" list or a "warning" list. These should
be related to the text-color and background-color classes.

Also this ticket includes how to show a list item as "active".

These style should be able to be applied to _all_ other list
types that exist.

**Success Criteria**

* List styles are created
* List styles are documented






h1. Forms: initial creation

Create the base form styles and layout. Likely this will
mirror what is in bootstrap or material design.

Keep these pieces in mind:

* inputs
** select
** text
** number
* labels

Example: 

{code}
<form class="form">
    <input class="form__input form__input--number" />
    <select class="form__input form__input--select" />
</form>
{code}

**Success Criteria**

* Basic parts of forms created
* Basic parts of forms documented






h1. Forms: inline and stacked

Create the layout options for forms. Initially we'll allow for
inline and stacked forms. This ticket should control the flow
of elements that exist within a form.

Example:

{code}
<form class="form form--inline">
    <input class="form__input form__input--number" />
    <select class="form__input form__input--select" />
</form>
{code}

**Success Criteria**

* Create inline and stacked forms
* Document inline and stacked forms




h1. Forms: complex inputs

Create more complex input elements. This should cover things like
sizing, and "add-ons" (e.g. an icon affixed to an input box).

This should also cover grouped inputs, similar to how lists and buttons are grouped.

**Success Criteria**

* input sizing is created (may not need to exist) 
* input sizing is documented (may not need to exist) 
* add-ons are created
* add-ons are documented






h1. Forms: Error Messaging and Validation

Add validation and error messaging to form inputs. This ticket will include
basic validation as well as how messaging around that validation should be
shown on the page.

Messaging may be at the individual input level or at a group. It can also be
at the entire form level.

**Success Criteria**
* input validation is created
* input validation is documented
* error messaging is created
* error messaging is documented

I think this is a good start. I'll play around with type and colors initially in sketch and zeplin. I agree we should use tints of existing colors where possible to keep the maintenance of the css to a minimum.