Roadmap to Version 2.0

[sherakama]

Version 1 has given us an opportunity to explore and learn about what this project should be. As a group we need to clearly define the goals of this project and be bound to our decisions. Please leave comments about the following topics.

1. Feedback / Lessons learned from version 1.0
2. High level goals for this project
3. Specific goals for this project
4. Other comments

From this thread we can then identify tasks and break them out in to tickets to put in to the project. If you don't have any comments specifically on any item just say as much and move along.

Thanks.

[sherakama]

Feedback From 1.0

• Too coupled between variables and every other file
• Load order still important
• This project should never ever output any css unless called through a mixin or function
• Do not include a base
• Maps don't work with load order. Nested variables do not get set.
• The grid system is the #1 most important feature of this
• This project needs an identity. Should it be a pattern library? Me thinks yes.
• This project is difficult to use. Vendors and new to the work had a steep learning curve. Documentation was not evident and sassdoc did not provide what was needed. Developers wanted to google the how-to do something.
• Needs a browsable library of patterns
• Needs markup to go along with scss

High Level Goals

• Lower the bar for entry for developers
• Be agnostic to any CMS / Project
• Browsable pattern library
• Less rapid development / more planned work
• Inclusion on decision making
• Be extensible
• Be highly accessible
• Be a fluid piece of the puzzle between design comps and code

Specific Goals

• Define a grid system
• Define a typography system
• Define which pattern library / styleguide software to use
• Possibly remove sassdoc and replace with readthedocs
• Reduce levels of abstraction
• Define naming conventions
• Include font-awesome and normalize as npm dependencies

Other comments

• Should still keep this project as an NPM package
• Should still keep the linters and code quality checks
• Should publish examples/browsable library on github pages
• Should have a bundled sass compiler (grunt-sass)
• Would like to use Twig as the template system

[sherakama]

@JBCSU

[sherakama]

@dltom

[kgcreative]

Lessons Learned: • Base/ was a good first attempt, but it suffered from too much obfuscation and an unclear structure. The map/override map system was good in theory, and works awesome to override things when needed, but it's not easy to figure out HOW. • The variables that serve base/ suffer from the same problem. I think they were intended to provide consistency, but ended up being one more thing for new developers to keep track of. • I found myself wishing more of those variables were moved to the _retrieve-decanter-setting() function, so there may be some opportunity to be deliberate and make it better. • On both homesite AND identity, I found building overrides for base/ anyway, especially for some responsive typography and other settings. • I can see spinning out base/ into a separate Stanford base style project that is dependent on decanter. • Speaking of, I think we can remove FontAwesome, Normalize out of Decanter and move them into the base styles project. • I'm thinking the base styles project could be namespaced, and importable as a .min.css (unchanged), OR imported as scss if people wanted to customize it. If the latter, the same issue that bootstrap et al becomes an issue here, namely, potential merge conflicts if the base project is updated.

[JBCSU]

Not having worked with decanter in depth (without Kevin by my side), my thoughts are more broad, but for what they're worth:

I think this codebase could be split into multiple repos:

• I very much like @kgcreative's description of Decanter providing the ability to override Bourbon and Neat's variables without changing them in place. I think a wrapper around Bourbon and Neat that serves this function, and this function only, would be a good discrete chunk. I think the name Decanter applies best to this chunk, and should be open source.
• I think the codification of Stanford-specific styling (which may be what base is for???) should be a separate discrete chunk, and should probably only be open to Stanford folks. I think this is where we should introduce the 7.1 file structure, and work out how variables and maps are managed. I agree with Kevin that FontAwesome and Normalize should live.

[kgcreative]

This is pie-in-the-sky wishlisting, but a way of integrating polymer based on web components into decanter for Stanford things would be amazing. I'm still wrapping my head around this.

[sherakama]

From goals and vision setting workshop:

• Decanter is 1:1 to a product or project and can be forked/cloned/copied
• Decanter will start it’s focus as a tool to support the Jumpstart product line but be built generically to be re-used elsewhere
• Internal/external teams will clone/fork the Decanter project as a accelerant for their site building when needing customizations
• Joe will be gatekeeper of our product patterns with guidance from Kerri.
• When forked or cloned the team that makes the copy is now responsible for its maintenance
• Decanter is a styleguide and a pattern library. Will need both documentation available and does not have to be the same tool.
• Decanter is a tool to be used by product owners, site builders, and developers alike.
• Decanter will contain SASS and Twig templates that power a styleguide system and can be integrated in to Drupal/Wordpress

[sherakama]

Version 2.0 Release goal is here: https://github.com/SU-SWS/decanter/milestone/1