sparkdesignsystem/spark-design-system

Spark Design System

spark-design-system's Issues

Datepicker: Code / A11y / Design / Documentation Review

Does this belong in core?

see onenote, also: https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Highlight Board: Code / A11y / Design / Documentation Review

see one note, also: https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Design review

We need to do a design review of everything in the system to make sure that what we built is what design expected.

Spacing: Implementation / Code / A11y / Design / Documentation Review

We need to define this so that it can be used the the other patterns.

Should we remove all direct element styling that isnt some kind of reset?

Looking at anchor tags

Should we reorganize drizzle into core and extras?

Document font usage

Add documentation to the typography section for fonts and font stacks.

Notably, if Typekit able to be used, we use Quatro Slab for headings and Myriad Pro for body copy. If Google Fonts is used, we use Open Sans for all text.

Develop a roadmap for spark design system

Need to create a more formal roadmap for the near future of Spark.

Documentation review

We need to review each page and make sure we have documented everything correctly and fully.

The submenus in the wide version of the main nav dont line up right with the list item content

Need to figure out browser support

a11y review

Review all code for accessibility and add ARIA where needed.

Tools / Utilities: Code / A11y / Design / Documentation Review

includes:

• animations
• mixins
• utilities

see one note, also
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

https

Set up https for sparkdesignsystem.com

Modals: Code / A11y / Design / Documentation Review

1. If modal content is tall on landscape mobile view then allow scroll bar
2. Expose click event for modals, a basic thing that they can use if they want. They have to add the data-attribute we suppy.
3. For no click event, they import our JS and use the exported functions we created
4. Add modal HTML in the DOM above the closing body tag
5. Three types of modals; Choice, Wait, and Info (no buttons, and a little close X?)
6. One file for modal functions utilities, and then one that is for binding UI which imports the modal utilities
7. Have data-attribute for modal cancel button. Close modal if clicked otherwise they don’t use our data attribute

see one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

bring flex grid into spark

reference:
https://github.com/sparkdesignsystem/spark-design-system/blob/master/src/assets/toolkit/styles/objects/_flex-grid.scss

The sneak peek pattern doesn't work without this.

Spinners: Code / A11y / Design / Documentation Review

see one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Add search input

There is a search input in the Masthead component that needs to be added to Inputs. It should have no label, but "Search" as a placeholder and the appropriate aria role to replace the label and role="search"

Razor Implementation

Let's figure out how to supply razor templates for use with spark.

Masthead: Code / A11y / Design / Documentation Review

see one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

React implementation

Lets figure out how to supply components for use with spark.

Twig Implementation

Let's figure out how to supply twig templates for use with spark.

$purple-dark not defined

Set up sass linting

Fix up the spark logo svg

Colors: Code / A11y / Design / Documentation Review

see one note,
also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Navigation: Code / A11y / Design / Documentation Review

This should include:

• hamburger
• navigation

see onenote, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Need an icons section in spark

Update drizzle with spark logo

Tabs: Code / A11y / Design / Documentation Review

see one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Write the code style section of the contribution guide

Needs to go on README and on index

Buttons: Code / A11y / Design / Documentation Review

see the one note,
also: https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

This should include buttons, button-secondary-action

Set up monorepo and publish packages

Packages

• spark-core
• spark-extras
• spark-extras/description-table
• spark-extras/highlight-board

icons: Code / A11y / Design / Documentation Review

We need an icon set

see one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Inputs: Code / A11y / Design / Documentation Review

Includes:

• forms
• input
• validation-criteria

See the one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Links: Code / A11y / Design / Documentation Review

See the one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Dictionary: Code / A11y / Design / Documentation Review

see one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Create testing plan

What types of testing do we need to do?

add code of conduct (CODE_OF_CONDUCT.md)

`

Adopt a code of conduct to define community standards, signal a welcoming and inclusive project, and outline procedures for handling abuse.

`
https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/

Define success metrics and how to track them

problems we're trying to solve with the design system:

1. Client-facing apps don't look like they belong to the same company / ecosystem.
2. Tons of UI code duplication across apps.
3. Wildly varying patterns across applications causes a lot of duplicate work, by Designers and UI Engineers.

possible KPIs:

1. application adoption (how many apps are directly using Spark)
2. system completeness (how many patterns are implemented and ready for use)
3. ease of use (how long does it take an engineer level UI person to set their app up with spark-core)
4. documentation completeness (how many patterns have complete docs)
5. drizzle / spark guide pageviews ? (im not sure if > pageviews means its successful)

possible ways to measure them:

1. survey, manual research
2. automated pattern count (possibly vs a target?)
3. surveys to UI Engineers
4. automated pattern count vs automated documentation section count
5. google analytics

Thoughts?

Typography: Code / A11y / Design / Documentation Review

See the onenote also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Tables: Code / A11y / Design / Documentation Review

significant work done in servicing on these, fyi

see one note, also:

https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Review all code

Need to do a full code review.

Decide on dependency updating schedule

Come up with a regular schedule for making sure our dependencies are up to date.

Reach out to initial consumer apps, get browser analytics.

We need to know if there's anybody supporting browsers outside our defined list:

https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing#supported-web-browsers-current-version--one-prior

Notifications: Code / A11y / Design / Documentation Review

see the one note, also:
https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Create contribution workflow

This should be focused on how designers and developers who are external to the Spark team contribute to Spark.

Pagination: Code / A11y / Design / Documentation Review

does this belong in core?

see one note, also:

https://github.com/sparkdesignsystem/spark-design-system/wiki/Pattern-Testing

Write the change workflow section of the contribution guide

How do we make changes to Spark?

Should we reorganize the drizzle docs into spark core and spark extras?

instead of fundamentals/components, I mean.
I think it might be easier to parse it for devs if it matches what they get when they install it.

For non-devs it'd be helpful to know what's considered necessary (core) and whats a nice to have (extra).

thoughts?