Brian Beckham - Atomic Design - Modularity Matters: Bringing Atomic Design to Sitecore Development - SUGCON

Editor's Notes

1. Templated Design = Organize by page type – create a data template for each and rendering and poof – you can create your website Why is this bad? Doesn’t require page editor support Tends to be very inflexible – only captures the initial state of the website – only serves present use cases Doesn’t encourage reuse for the developer Creates dependencies between dev and content management teams Marketing will try to “repurpose” page types to increase velocity
2. More experienced teams will take these pages types and break them down further Look for patterns in the design, and strive for reuse “cherry pick patterns” after the design is complete Really only a “developer tool” at this point, doesn’t really benefit the content administrator
3. Once we deliver this glorious design…we get some constructive feedback from the client …. And they want to use personalization and MVTs in random places …. At some point in the future And there are some places where the content fails the design - Let’s take this carousel panel as an example Only serves present use cases And the design gets challenges later on in the build - Content doesn’t fit!!!
4. *Animation* Multi-tenancy – they didn’t just buy Sitecore for 1 website did they? the customer want to build another 10 websites, and they don’t want to start from scratch every time But they also don’t want the websites to look like they came from a boilerplate design – more than just using a CSS framework like Zurb or Bootstrap There’s only so much CSS can do The list of supported devices and browsers is constantly changing – responsive is important
5. Instead of creating a design, create a design system Focus is on the content structure, not the content itself
6. Highlight Navigation (menu) Teaser
7. Header Footer Sidebar Carousel
8. ATOMIC DESIGN DOESN’T GO THAT FAR Twitter Bootstrap Isn't atomic design – I can use it to build an atomic design component set however Atomic design is a theory or methodology, but not an implementation…Pattern Lab is a website that allows visitors to create their own atomic design system Atomic design is a design methodology … so in the implementation of that design, you can do whatever you want – javascript, added attributes, whatever BrainJocks SCORE includes a components module that uses atomic design principals – some of the solutions we will demonstrate are included in SCORE, but there are many ways to achieve this, and other products such as Zen Garden and Keystone When translating this to a component architecture, we have a new list of constraints to deal with
9. Show carousel building Show page building and how same principals extend to that as well
10. Taking an atomic approach to Sitecore development represents an even bigger shift than just flipping interface design on its head. Building an entire website (both the back end and front end) “atomically” means building a complete component architecture. And, because we’re working in the context of the Sitecore CMS, the building blocks that make up the architecture are portable, reusable Sitecore components.   What does this look like on a real development project? Does it really work? (yes) Let’s say the project team has already done an inventory of the content and functionality that need to be included on the site. (For possible use in your talking points/notes: ‘Content-first’ is a change for many developers and designers, but it’s a good change. Instead of building page structures and then having to figure out how to get the actual content to fit in them (or building more templates because it won’t fit), we start with the content and then figure out what the pages should look like. That makes a lot of sense to me, since content delivery is the point of having a site in the first place. Here, I’m talking about ‘content’ in the broadest sense of everything you want a visitor to experience and interact with on the site.) We’ve also done the IA work to know how the site should be structured to engage each target audience. And, we’ve finished site scaffolding and [whatever else has to happen to create a “shell” for a new build!]. Now we need to build the site framework; that’s our modular, component architecture.
11. Demonstration should include the following items: Editing standard values and branch templates in page editor Rendering component datasource location rules Snippets
12. From a business perspective, what does this allow us to do? Build first/design later: Most designers are used to starting with the page as the central design unit, and creating something that’s unique in layout, elements and styling. Atomic Design tears up the page and flips everything with a ‘build first/design later’ approach. You’re looking at the project holistically and figuring out what building blocks you’ll need in a way that maximizes commonalities and opportunities for reuse.   This flip introduces major efficiencies into the design process. Sites are easier to build, update, expand and maintain (which means they’re done faster and end up costing less). For big and growing companies, scalability is king. An atomic approach makes it much simpler to add pages and content to a single site and, even more significant, to create entirely new tenants within the enterprise’s web ecosystem. It’s a matter of reusing portable building blocks wherever it makes sense instead of building everything from scratch. The work for a new site is then reduced to building only the elements that are entirely unique. Approaching the site as a design system ensures consistency across the site (enabling a better user experience, more impact from branding). (This answers the question, “why bother”; we could set it up by talking about how change is hard and takes time and effort, but atomic design is worth it for a few reasons…)