ACL Nerd Candy
Styleguides, conventions and front-end processes…
Really John, YASAAWINTLHTC???
(yet another stupid article about why I need to learn how to code)
I know that you have probably already read 1,257 blog articles on why designers should learn how to code, or why creating a styleguide will bring world peace, or how awesome you’ll become if you just install the latest Nodeactscriptacular module using the Terminal (of course). But I bring great tidings of joy… I am NOT going to talk much about any of that. Rather, I am going to assume you have already made up your mind on the matter and are instead simply interested in how others have chosen to tackle the beast and make it work for them.
One thing I do know is that nerds love to see how other nerds do their nerd things.
What we do feel strongly about at ACL is this — becoming the most efficient versions of ourselves possible and optimizing repetitive tasks allows us to focus on the pursuit of our passion, which is delivering a BEAUTIFUL customer experience through the planet’s ONLY cloud based, data-driven GRC solution. Our team, and I personally, subscribe to the power of standardized processes as mechanisms of freedom. They free us, from the mundane, and allow us to focus on creating the rad stuff.
Why do we have these processes and tools in the first place?
Styleguides, UI components, naming conventions, and code-writing guidelines form the basis of our collaborative approach to design and front-end development at ACL. Rather than view them as limiting factors, these processes alleviate the need for us to reinvent the wheel on each project and speed up the arrival time for prototypes and MVP’s. Having a product and codebase that appears to be created by a single person, regardless the number of contributors, is the new unicorn.
From the 50,000-foot-view, standards, conventions, and processes give us the peace-of-mind that we don’t need to remember all of the nitty-gritty details each time we begin a new layout, code an HTML template, or prepare assets for deployment.
Pro-tip: guidelines and conventions are never chiseled in stone, nor should they be viewed as completely prescriptive. They should evolve as your team learns better methods and should have flexibility for “bending the rules” now and then.
The ACL Front-end Stack
So enough of the philosophical and theoretical, let’s dive into the details of our approach and tooling.
Regardless of the project type or tech stack, we tend to always begin with one or more of these foundational items.
- ACL UI Components
Our component library is a collection of reusable UI designs and their accompanying code snippets. This collection of standardized components in a centralized location greatly reduces repetitive tasks and time wasted by having to constantly create them from scratch.
- ACL Styleguide
The styleguide governs the usage of the UI components, as well as possible use cases for reference. I constantly refer to the styleguide to ensure my designs are consistent with the work of my fellow designers.
- ACL Icon Font
We have chosen the icon font approach for a few reasons:
1. Icon fonts provide a prepackaged container for sharing and distribution of our icons. We don’t have to hunt down individual PNG images, everything we need is contained in one file.
2. Very deep browser support — all the way back to IE 6.
3. The existing ecosystem is time-tested and proven for creation and maintenance of icon fonts.
4. Our own build system takes away even more of the headache. Loc’s latest work on our icon build system is stellar. Utilizing the unique exporting features from the Sketchtool CLI allows us to stay within our comfort zone (Sketch) when working with our icons.
Most of the team has made a full transition to Sketch for layout and mockups. I know we all have our preferences, but Sketch has always allowed me to be exponentially more productive than Photoshop or even Illustrator. It just feels like a tool that was created for interface design.
Maintaining a flexible and scalable HTML and CSS architecture might be one of our most challenging day-to-day tasks. There are countless ways to organize, structure and name your files and classes. And although a highly subjective topic, we’ve chosen to adopt the BEM (block, element, modifier) methodology as our solution. The last thing anyone wants is having to spend countless hours creating a naming scheme or trying to figure out why a teammate named something `.xcd-101-blueButton`. Conventions such as BEM, SMACSS, or Suit all strive for similar goals — to bring sanity to the world of CSS, helping to scope component CSS and make working in a team much more enjoyable. (BTW, there are MANY more benefits to using these systems…)
- Zurb Foundation Framework
Say what you will about front-end HTML/CSS/JS frameworks, but a truth remains — they help get things prototyped and built much faster and efficiently. We have used the Foundation framework as a heavily customized “departure point”, rather than subscribing holistically to Zurb’s opinions on UI design.
- Haml (HTML)
Haml is described as “Beautiful, DRY, well-indented, clear markup: templating haiku.” I personally enjoy the terse form and reduced punctuation (brackets, colons, semicolons, etc) that templating languages bring to the game. The addition of logic, variables, and conditionals also adds value to the process of rendering data into an HTML template. Historically ACL has primarily utilized a Rails-focused stack which made using Haml a no-brainer, but with our recent shift towards Angular and React, HTML templating languages are fading to the background as we return to straight HTML, on-the-rocks.
- SCSS (CSS)
Everyone loves CSS preprocessors and the SCSS flavor more specifically (or so I’m told. I’m partial to Stylus myself ;). I think we have all come to our senses regarding preprocessing and the pitfalls that can come along with it. Our team sticks to the basics: variables, some mixins, nested media queries. Utilizing preprocessors can easily get out of hand with multiple layers of nesting, complicated functions, and unnecessary math. Stay classy people… vanilla CSS really isn’t all that bad.
- Node/NPM & Bower
Package managers for the win! NPM and Bower make it super easy to locate and include many popular third-party libraries and their dependencies. It also makes the process of getting new team members onboarded much smoother. After cloning a project repo, you can grab everything needed with two simple commands: `npm install` & `bower install`.
The items here aren’t implemented on every project or task, but rather depend on project-specific variables such as timeframe, need for a prototype, how quickly we need to arrive at MVP, etc.
I love Balsamiq for wireframing due to its opinionated style and limited “design” features. It allows me to quickly get ideas committed to screen without increasing the fidelity too early.
We love the rapid prototyping and collaboration features. InVision allows us to quickly share designs and gather feedback from the team without huge investments of time.
Modern product design involves so much more than simple static graphics and views. Animations and motion help to reinforce decisions and provide positive feedback that give our users a sense of accomplishment and delight. They don’t just simply decorate our designs, they anchor them and are key to the overall experience for our people. These days, when we need to prototype an interaction or animation, we have been reaching for Framer. Framer is a prototyping tool that uses code to produce your animations, so not only are you able to produce some slick results but you are gaining some coding experience at the same time.
From the Angular site — “HTML is great for declaring static documents, but it falters when we try to use it for declaring dynamic views in web-applications. AngularJS lets you extend HTML vocabulary for your application. The resulting environment is extraordinarily expressive, readable, and quick to develop.” We couldn’t have said it better ourselves. Angular’s ability to extend HTML through inline attributes makes it easier for “designers who code” to quickly become comfortable and productive.
Once the new kid on the block, React has quickly gained traction and serious cred from the front and back-end communities. Being backed by Facebook surely doesn’t hurt, but it’s approach to componentizing UIs and data-binding captured our attention and we aren’t looking back. And yes, “componentizing” is a technical term.
Harp is a static web server with built-in preprocessing. We use it for generating our icon font reference site, as well as quickly spinning up HTML templates for prototyping and local testing. It is built on Node and uses NPM for installation and distribution.
My personal tools & apps
This is a list of my personal bits and bytes. Although others on the UX Design team employ some of these as well, they are by no means required.
- Sketch Plugins
Content Generator, Copy Fill Color, Sketch Palettes, Relabel Button, State Machine… just a few of my personal goto plugins. Sketch.land and Bohemian’s own plugin page are great resources for more. Sketch Toolbox is also great for finding, managing and installing your plugins.
- Atom Editor
I sent out a quick poll to my teammates in prepping for this article and, apparently, I am the only one who uses Atom instead of Sublime Text 2/3. Pffft… Their loss. Atom is updating constantly and is always improving. The theme and package ecosystem is aces as well.
You can pry Emmet from my cold, dead, repetitive stress-injured fingers. I refuse to write a single line of HTML or CSS without it. I can’t even do it justice with an explanation, so go check it out for yourself!
Roots is another static site generator, similar to Harp, that I use for getting a quick static HTML site going for testing or prototyping.
Surge is “static web publishing for front-end developers”. Again, it’s so magical that you must experience it for yourself. If you need to get your static HTML site on a server lickity split, then there is no better option than Surge. Oh, and did I mention that it’s free?! You’re welcome.
As you can see, we employ a diverse stack to create the radness at ACL, and I have only scratched the surface behind our logic and use for each part. Stay tuned, and subscribe to our publication, for additional posts that will take a deeper dive into some of the more complex aspects of our front-end process and tools.
How we’re improving and evolving
Per my earlier pro-tip, our thinking and process is never chiseled in stone. We are consistently monitoring our daily workflow and habits, looking for ways to improve, reduce repetitive tasks, and become more effective overall. We are currently creating an inventory of “design debt” — decisions within our products and processes that tend to optimize for the present rather than for the future — and creating a plan of attack for dealing with, and paying down, this debt. We are creating a new MVP approach (more to come on that subject) and investigating ways to incorporate SVG into our icon system.
Did I mention we are hiring?!
If you think that you would like to become a part of the teams that are making awesomeness on a daily basis, please don’t be shy! We would love to chat with you and our taco-loving leader, Matt Crest, has already written about it wonderfully in this post. Even if you’re not on the lookout for yourself, perhaps you can share with others you know who desire a change in their professional landscape.
We have created a site that acts as the window into Product Design and Engineering at ACL. We call it Build ACL. We want to showcase our culture and the lessons we’ve learned while building bleeding edge software used by 90% of the Fortune 500 and organizations in 140+ countries.