Design Tooling With Solid & Atom (or, making the IDE our BFF)
Now that the debate over whether designers should code is settled, we should all move on to solving more important problems.
We can finally begin to ask, “How should designers code?” BuzzFeed has some really great opinions on that topic, which is why we built Solid as our foundational CSS framework.
Empowering designers with the means to code requires them to adopt development tools. Obviously, most development tools are built for engineers, but when designers code, coding tools are necessarily design tools and become fundamental to designers’ process. That ultimately means that the text editor or IDE (Integrated Development Environment) becomes central to that workflow.
It’s about time we treat the IDE as a design tool and begin to use it in ways that fit our processes as designers.
The Problem With Solid
Solid is too perfect. As an OOCSS atomic framework, Solid is too good at doing what it is supposed to do. It has a plethora of prefixed classes that can get very messy to write and exceedingly difficult to remember. This is why the Solid team has invested so much time producing human-readable documentation for all the features included in the framework. Obviously, as the framework grows, so does the documentation and the reliance on that documentation. Designers that are less confident in their coding ability become overwhelmed at the sprawling complexity of implementing responsive-prefixed OOCSS classes. Developers used to a legacy HTML/CSS workflow find themselves buried under piles of documentation.
Getting Friendly With Your IDE
One way of getting at this problem from both ends of the designer/developer spectrum is to employ your IDE. This way we can try to help designers solve for systemic complexity while also helping developers establish mental models of how Solid should work.
Maybe you have strong feelings for your IDE
Or, maybe you just use whatever is popular in your circle of designers or developers (many of us at BuzzFeed use SublimeText). I’m going to do something radical and suggest you try out Atom.
“Atom is a text editor that’s modern, approachable, yet hackable to the core — a tool you can customize to do anything but also use productively without ever touching a config file.” -The people at GitHub who made Atom
My goal isn’t really to sell you on Atom, but using Atom as an IDE does open up a really big world of design tooling that was inaccessible to most people before now. I should also mention that It’s completely free, cross-platform, has a super simple plugin package manager, and is built on Node.js and Chromium. What you sacrifice for the marginal slowness of running your IDE on a quasi-JavaScript engine, you gain in the ability to script your coding interface in HTML, CSS, and JavaScript.
AutoComplete Joins Your Squad
Atom’s AutoComplete framework is lightyears beyond what other IDEs offer. By ever-so-gently smashing Solid’s CSS classes and variables into an autocomplete plugin, we are able to provide an instant way of recalling responsive classes and variables, while providing quick context and links to relevant documentation right in your IDE.
Check it out at https://atom.io/packages/solid-completions and install it directly into your Atom editor using the integrated package manager.
The solid-completions plugin will autocomplete any classname in HTML-ish documents (including Mustache, Handlebars, etc) and will provide you with easy access to Sass variables in Sass/SCSS files. Just begin typing any part of the classname you would like to use and autocomplete will tell you what kind of Solid class it is and link you directly to the relevant documentation should you need more context.
Getting Friendly With Your Framework
Maybe you don’t want to use Solid, or maybe you have a favorite framework that you think can benefit from tight integration with your IDE. So, let’s get a little technical and talk about our general approach for creating an AutoComplete provider in Atom. Unfortunately, getting Solid into an autocomplete “provider” isn’t necessarily trivial, so here’s a few things that I did to make it easier along the way. I’m not going to go into too much detail here, but feel free poke around and clone the repo at github.com/buzzfeed/solid-completions to help make your own autocomplete provider based on your frameworks and preferences. If you’re still scratching your head, don’t hesitate to get in touch.
First, I’d recommend getting a little more familiar with the Atom autocomplete provider API docs on GitHub. You’ll notice that Atom plugins are written in CoffeeScript. CoffeeScript compiles to JavaScript, so it’s totally acceptable to write plugins in JavaScript if it’s more your speed.
Then you’ll need to structure the data that you want your provider to serve. We did this by analyzing our SCSS and CSS files with PostCSS. PostCSS is a stylesheet post-processor that’s commonly used to manipulate CSS after it has already passed through preprocessors like Sass and has been rendered into CSS. It’s incredibly powerful, but we like it because it constructs a walkable AST (abstract syntax tree) in JSON that you can use to extract all the rules in your CSS or Sass that you would like to serve as autocomplete phrases.
You’ll then have to define the scope to determine when the autocomplete provider will be serving suggestions to the user. For classes in an HTML document, your scope would look something like:
.html .meta.tag.any .string.quotedHowever, be aware that this will trigger autocomplete on any attribute that has a value in quotes. To make sure you’re only triggering on class attributes, you’ll have to take a look at the current line your editor buffer and walk back to the nearest attribute.
Finally, when you build your array of suggestions, make use of the various properties in the suggestion object to include hints to the user about what the keyword does and how to use it. Our solution shows the Solid framework logo, along with a label indicating what the function of the class does. We also include a link to the relevant documentation for that class within the description field.
Get Friendly With Your Fellow Designers and Developers
Designing in code means one less level of abstraction for passing design artifacts between “designers” and “developers.” Having both sides of the spectrum work with the same tools creates many efficiencies, but there is also a big opportunity to build our own processes and workflows into extensible tools like Atom to allow for even greater learning, cooperation, and standardization.
