What the heck?
* [ ] Atomic Design
* [ ] patternplate
* [x] Atomic Design
* ⚠ Responsive Design
* ⚠ Dynamic Views
* ⚠ Single Page Apps
⚠ Responsive Design - the hard parts
* [x] Plethora of devices
* [x] Virtually infinite number of distinct viewports
* [x] Old problems with user agent differences persist
Responsive Design - the goal
* [x] Optimal presentation of content
* [x] Accessible by default
* [x] Standardization of components
⚠ Single Page Applications
* [x] Break one thing, break the application
* [x] Potentially infinite number of mutations
Thinking and talking about pages will not cut it anymore - we'll have a hard time expressing all possible mutations of the things we create.
Let's shift our focus to systems of
small and comprehensible components.
Component systems
* [x] Definition of relative display rules
* [x] Identify basic common styling
* [x] Reusable components
* [x] Consistent design
⚠ Design systems - the hard part
* [x] Deconstruction of features is hard
* [x] Stake holders have a hard time giving up on "page"
* [x] Perceived low development velocity
* [x] Lots and lots of boilerplate for component setup
(to the rescue)
patternplate in a nutshell
* [x] Unapologetically web based
* [x] Environment for design systems
* [x] Application for documentation of design systems
* [x] Build tool for extraction of tech
Transparency in team
Build process
Deliver faster
Deliver better
github.com/sinnerschrader/patternplate
By Mario Nebl
Primer to Atomic Design applied to Frontend Engineering @S2. We explain tech-assisted creation and maintenance of component libraries with patternplate.
Technical Director - Web Engineer - Nerd @SinnerSchrader Hamburg