An Agile Design Manifesto
(for Ember.js)
I recently did a talk on this topic at EmberNYC, and Emmett Shine (@emmettshine), my old boss at Gin Lane Media in NYC encouraged me to distill it into a Medium post.
So! I just finished a shiny new web app with NYC’s Gin Lane Media for sweetgreen, a culinary lifestyle brand dedicated to smartly-sourced, seasonal food — it’s easily the best work of my career. Not because it’s stable and pretty (it is!), but because of how we approached the build — and in particular, how we ran design in parallel to development.
Before I get into the nuts and bolts of our process, it’s important to chat about why Ember is better for design iteration (at least in an agency setting) than most other javascript frameworks & libraries.
This is not about data immutability or render speeds. This is about running a better business through a deeper understanding of technology.
Things like React, Flux, Backbone and jQuery (amongst many others) fall into the category of “progressive enhancement”. They’re libraries that bolt on to a server rendered template, and allow it to do things it couldn’t do before. On the surface, this seems great — you add bit and bobs to the good old browser environment, and only use what you need.
However, as an ambitious project matures, so does the UI, and it’s requirements. So you reach out and grab another library that does another thing, and then write some ~simple~ code to make library X work nicely with library Y.
Progressive Enhancement sucks when there’s churn in the project’s maintainers.
Leaving a team with a Fat Slab of Custom Code™ that bolts libraries together, and then bolts those libraries to the browser and API means a brittle, unmaintainable codebase.
Custom code in an agency setting is a huge liability (unless you’ve got some amazing employee retention, or infinite time, that is…)
Enter technologies like Ember, Meteor, Angular and others. Instead of enhancing the browser with a slice of functionality, they act more as a full application stack that runs in the browser environment, and provide developers with a shared solution for common tasks (routing, presentation logic, data fetching + modeling, and so on).
“At some point recently, the browser transformed from being an awesome interactive document viewer into being the world’s most advanced, widely-distributed application runtime.” — Tom Dale
In exchange for this enormous productivity boost, you’ll lose some low level control over the browser’s fabric. Experienced developers are usually uncomfortable with this, but that’s happened before…
*cough, Rails*
Something that isn’t immediately obvious, however, is how quickly an opinionated framework can help you identify patterns and core themes throughout your work.
Rails helped us do this with service layer programming — and now Ember is helping us uncover hidden workflow efficiencies for the user interface.
Whether you agree with it’s opinions or not, an opinionated framework surfaces non-obvious efficiencies for both the codebase and business.
Sam Selikoff’s (@samselikoff) Ember Conf 2015 is illuminating:
How to wield Ember’s View Hierarchy
Ok! Back to Agile Design.
Something that is generally glossed over in blog posts, meetups, screencasts and everywhere people talk about Javascript is Ember’s predictable view hierarchy. It something only a full application environment can provide — and it’s enormously powerful.
For the sweetgreen project, we ran design and development in parallel. We’d never done that before, but because we knew Ember’s internal presentation rules, we were able to develop a standardized approach to describing UI elements with CSS, so that all interface code was uniform across the project.
CSS Is Hard.
In the past, we would organize our CSS semantically.
It would make sense for a few weeks at the start of the project, but as it evolved and the designs changed, we would have to do big refactors just to move a piece of markup to a different part of the page, zig zagging between multiple markup & CSS files. It was chaos, but it felt unavoidable.
“It’s a, erm, toggle thingy outer wrapper, right? Call it that!” — Me, circa 2012
Erik Bryn (@ebryn) did an exciting lightning talk (more on that talk below) at EmberConf2015 about managing CSS in Ember.
His main point, however, is that CSS is hard — because it is global.
Like anything that is global, if you’re making changes without a complete understand of the entire codebase, you can never be entirely sure that your changes won’t have unintended side effects… unless you have a solid set of conventions in place for managing that “global-ness”, of course.
Organize SCSS by Route & Component
We organize SCSS by Route & Component. Ember guarantees that certain templates will only be on the page once, and certain templates will only ever be nested in others.
We can use this to our advantage!
For the sake of this example, let’s say you needed a primary flash queue for the entire application, and a secondary flash queue specific to the Posts Show route, with a different background color.
Here’s the templates:
- templates/application.hbs
{{flash-messages queue="system-wide"}}
{{outlet}}- templates/posts.hbs
<div id="posts">
{{outlet}}
</div>- templates/posts/show.hbs
<div id="posts-show">
{{flash-messages queue="individual-posts"}}
</div>Here’s the Flash Messages Component
- components/flash-messages.js
import Ember from "ember";export default Ember.Component({
classNames: ['flash-messages']
});
Here’s the CSS:
- stylesheets/app.scss
@import "components/*";
@import "routes/*";- stylesheets/components/_flash_messages.scss
/*
Base Styling for the Flash Messages component - how it will appear globally.
*/.flash-messages {
background-color: $default-flash-color;
}
- stylesheets/routes/_posts.scss
/*
Global Styling for the "Posts" resource. It's an ID because it's guaranteed to only ever appear on the page once.Thanks Ember!
*/#posts {
@import "show";
@import "new";
@import "edit";
}
- stylesheets/routes/posts/_show.scss
/*
Styling here is specifically for this on the "Show" route of the "Posts" resource. Most likely, it's empty, but it's a good place to override the global appearance of components, and ensure those changes are contained to this route only.
*/#posts-show {
.flash-messages {
background-color: $posts-show-flash-color;
}
}
Style Tiles
Because we knew we were going to iterate quickly on the visual design of the app — we needed a sane way for parts of the app to be a) designed and b) implemented.
We approached the designs by exploding the wireframes down into their atomic components, and designing “Style Tiles” for each one. This meant that we had mini style guides for each little component, and the developer could simply piece together these parts to create more complex components and layouts with ease.
Interactive Styleguide
Joseph Bergdoll (@josephbergdoll) , one of the two designers on the project is a CSS grand maester, and we wanted to leverage his skill without having to onboard him to the entire Ember ecosystem.
We built a live sandbox route in the Ember App that he could work from. Whenever a new Ember component was built, we’d add it to the “styleguide” route, so that Joseph could build out the nitty gritty visual detail and interaction style, without having to delve too deep into real application code.
It’s still live in production here:
order.sweetgreen.com/styleguide
LayerVault
First of all, R.I.P LayerVault. In case you haven’t used it, it essentially works like Github for images, PSDs, AIs, Sketch Files, and more.
It became an extremely sophisticated tool (that also used Ember CLI in places of their interface). It really took the pain out of asking designers to bounce out the latest versions of their work, and made design iteration feel breathless for all involved.
We’re upset that the service is shutting down — it was a god send for our process. I’m excited to see what Kelly (@KellySutton) and the team do next (and what they can open source from their learnings!).
Looking toward Ember 2.0
We’re definitely not the first people to pick up on Ember’s “design friendliness”. Ember is being used all around the web to create brilliant User Experiences. Here’s a collection of people who are realizing it’s power in the UX world:
EmberConf2015
More than half of the EmberConf2015 talks were focused directly on Design and User Experience. That is no mistake. The folks behind Ember (emphasis on folks - not companies) are aware that the “perfect javascript framework” is not wholly based on metrics like performance, etc.
More than half of the EmberConf2015 talks focused directly on Design or User Experience.
Instead, they understand that javascript “best practices” are a moving target, and while Ember strives to be a snapshot of those, the best way to provide value at a conference is to focus on something the JS community at large can agree on.
Lauren Tan (@sugarpirate_) compiled EmberConf2015 resources here:
She also spoke at EmberConf2015 — and her talk is fantastic.
ember-component-css
Erik Bryn, AKA the “Human HTMLBars Hype Machine” (his words @EmberNYC 2014) did a fantastic little talk about CSS at EmberConf2015.
Changes in Ember 2.0 and innovations downstream from Ember CLI are going to mean that it will make a ton of sense to store your CSS right next to your logic file, and template file for a given component.
- components
|
- flash-messages
|
- template.hbs
- component.js
- styles.cssErik has created an Ember CLI Addon that encapsulates that workflow. I’d encourage you to try it out as soon as possible! This is the type of thinking we need to bring CSS into 2015.
Thoughtbot: Ember is for Designers
This article from Thoughtbot (@thoughtbot) is fantastic.
Ember is Kool Aid
Ember is extraordinarily powerful — for those that drink the Kool Aid.
Like how it acts in the browser, it’s a “whole hog” type of thing — if you decide to use it, for best results, that should be the only paradigm you use.
If you adopt Ember for your business horizontally, for now, keep in mind that it’s a long play. Slowly but surely you’ll start to notice that the same feature that took your devs 3 weeks to build a year ago for a different project is taking a few days now. You’ll notice that the visual changes your designer wants aren’t accidentally breaking things on different pages. You’ll notice that fixes from one client will directly benefit another.
And with all of that, your build times will decrease, and margins will stay strong. I’m sure Dockyard (@DockYard) can attest to that.
For now however, please just order a sweetgreen salad, and know that that salad was 7 months worth of Ember.JS in the making.
