Follow up on scalable, maintainable CSS

I wrote down some ramblings about this subject a while back after first reading about it through @mrmrs on Twitter. The idea of single function CSS classes was weird and seemed unnatural at first, but I was very intrigued. I considered this idea around the same time I was realizing that, at work, I basically keep creating variations of the same designs over and over. Thus bloating our CSS file and wasting time developing components that were pretty much previously completed. Then a lightbulb went off. 💡

We were in the middle of a project at work and I decided to try something. I’d create a bunch of “helper” classes that would perform single functions on an HTML element. For instance, .text-center would align the text in the center of the element. .container-800 would create a container that was 800px wide. I created about 20 or 30 of these classes and tried to come up with rules that I routinely use when creating BEM or SMACSS style components.

The result? Incredibly fast iteration! I could piece together these classes in HTML to make interfaces in our CMS so quickly that I couldn’t deny there is some real value in this.

Another result: people who work on my team can no go forth and build awesome interfaces without necessarily needing to know about SCSS, preprocessors, etc. It lowers the barrier for entry and helps groups work together faster.

It makes designer and developers speak the same language. “I think there should be a little more padding on this container” can now be remedied by the designer or the developer by modifying the padding class on the element. If the designer doesn’t know CSS or any of the tooling the developer uses, it is still possible for the designer to change the interface to their liking. This is so powerful.

If you’d like to check out a library that has created tons of these “helper” classes already, look into Tachyons. It’s a wonderful concept and library.

Successful web projects begin with content

If I had a nickel for every time someone jumps to design and layout in a web project meeting, I’d have about $5 (that’s a lot of nickels).

As Mike Monteiro puts it in his (excellent) book You’re My Favorite Client:

No one comes to a site because of the design. They come for the content or the service, like booking air travel. The design should encourage them to stay, offering a wonderfully easy-to-understand and even delightful way to interact with that content or service. Bad design can certainly bury good content, but you can’t design a “premium experience” and pour crap content into it with any expectation of success.

I think this is a little scary for people who design and make websites, because it demotes the importance of how a site looks.

Consider this post from SimpleBits:

This is my favorite website. I visit it almost every day. It’s not responsive. It’s not optimized for iPhone. It looks blurry on a Retina display. It doesn’t use the latest HTML5/CSS3 framework. It doesn’t have a thoughtful vertical rhythm. The fonts are nothing special. It is neither skeumorphic nor flat. It doesn’t have its own favicon. It doesn’t have a native app or Twitter or Instagram. It doesn’t use AJAX or SCRUM or node.js or Sinatra. It doesn’t have an API or an RSS feed or VC funding. It hasn’t been featured on a prominent tech blog or won an award.

It tells me the soups of the day.

Freely distributed information that’s relevant to the person reading it. That’s web design.

I’ve gotten incredibly invested in projects before and become so enamored with how I implemented a certain design pattern or how clever a design element was, only to see it met with a tepid response from users. This is typically what happen when you put the cart before the horse. The design could be incredible but if it’s not useful to the user, who cares? The user doesn’t look at your website the same way the person who made it does.

The user is looking for helpful content or a helpful service. They’re not there to look at how it was implemented or how it looks. The only people who do that are other designers and developers.

Most successful web projects start with great content. Design serves to highlight the content. So if all this is true, why do so many meetings quickly move into design?

This is something Monteiro also touches on repeatedly in his books, but we — people who design and create websites — all share some guilt for allowing this to happen. The people who move the conversation towards design before a) purpose of the site is settled and b) engaging content is developed simply don’t know that they’re trying to derail the process.

It’s our job to remind them what is important. It’s our job to prioritize content over design. Ideally, a great content strategist can work with the client and help tease out what is most important to be shown and developers can focus on building a great technical foundation.

So everyone who is reading this, go forth into your next meeting and remind people of the solid foundation that web projects should be built on: a purpose, something useful to the user, and great content to support it. Once those things are decided, the design will follow.

Thoughts on scalable, maintainable CSS

This post is heavily inspired by the article referenced in the above tweet. If you haven’t already read it, stop what you’re doing and go read it. Every once in a while you come across a post that challenges your assumptions and makes you take a step back and evaluate your process.

I know a little bit about maintaining large CSS code bases. At my current job, we have a 140 site network of Drupal 7 sites for the college. We also have a few WordPress installs and some other sites and static pages in the mix.

Maintainability is something I strive for. There are also some issues with maintaining CSS for large sites that haven’t been addressed until now.

With all the different naming conventions out there, you’d think we’d have nailed it by now. The truth is, CSS is still a mess.

Preprocessors and build tools have brought us a long way, but what if that is the wrong place to focus?

What if you could open up your text editor and build the interface you want without writing a single line of new CSS?

could open up Sublime Text and write some fancy mixins and Sass functions that really are clever and then make some new classes for my components, but why? Chances are I’ve written CSS that does all of those things already.

I’m not very interested in what I can do with css. I’m interested at this point in what I can help groups of people do with css. –mrmrs

This brings me to why I’m so interested in the concept of one class, one function.

When working with a giant network of sites with distributed authorship, you learn real quick that you can almost never come up with a solution that everyone will like. Certain groups want slight variations to components that you built. Things come up.

What if we threw a bunch of lego bricks at them and said “Here’s all the tools you need”?

Consider the following HTML:

<div class="card card--red">
<h2 class="card--headline">Headline</h2>
<p class="intro">Here is some test text</p>
</div>

Without looking at the CSS for this, can you imagine what it would look like? I’m guessing you would know it looks something like a card and maybe it has a red background? Other than that, it would be difficult to tell what is happening here. Are there any clues about fonts, padding, borders, or text styling?

Now, consider this HTML:

<div class="bg-red padding-2rem border-1px">
<h2 class="sentinel italic font-large">Headline</h2>
<p class="whitney drop-cap">Here is some test text</p>;
</div>

You’ll notice a couple differences right off the bat. There are more CSS classes, yes. But you can also get a much better idea of what the HTML will do. It is semantically clear.

Benefits of this approach include rapid interface development without having to write a line of CSS. Once you come up with all your “utility” classes, you’re free to construct your interface using classnames in HTML.

Also, it allows a broader group of people to benefit from your CSS. People who may not be comfortable with CSS can now in plain English, add classes to their markup which does one thing without having to worry about side effects.

Let me be clear: I don’t think this is a substitute for writing some abstract classes. I think there is still a need to write classnames that don’t map directly to a function (ex: .header-top, .footer, etc) but the point is that a majority of the CSS functionality will be easily exposed in the form of plain English utility classes.

I think this has the potential to help large sites with lots of CSS and lots of people who use the CSS. I’m interested in giving this a try at my organization. When I do, I will most certainly report back here with my findings.

Check out the followup to this piece.

2015 year end review

It seems like just yesterday I was writing my thoughts on 2014 and 2013. This year marked a couple accomplishments. It was a busy year full of graduate coursework, freelance projects, and full-time work.

In 2015 my title changed from “Associate Web Developer” to “Front-end Developer” which was more apt at the time because a majority of my day was spent working with HTML/CSS/JavaScript.

Our office undertook a giant project of migrating CMSes. We went from using a vendor’s product to building our own CMS using Drupal and the Panopoly distribution. It’s been quite the undertaking but offered lots of opportunity for growth.

Being a front-end guy, adjusting to Drupal was a little challenging. I was used to WordPress where templating seemed to make a little more sense. I found that in order to do proper front-end work with Drupal, you need to understand PHP well enough to manipulate data using Drupal’s hooks and preprocess functions. In 2016, looking into decoupling Drupal is extremely appealing because of the front-end freedom it provides. No longer will the front end be entangled with a giant monolithic system. I look forward to seeing what is possible.

I did a technical review for Packt Publishing on a book about Bootstrap.

I completed 9 credits of my master’s degree in Human-Computer Interaction.

SUNY Oswego won a national CASE award and CASE DII Gold award on projects that I lead development efforts on.

Began working with a network of 140+ Drupal multisites. I deploy theme, module, and configuration (via Features module) to these sites. I also run updates on them and customize functionality when necessary.

Went to Cornell University for DrupalCamp in April.

Went to Acquia Engage in Boston in October.

Dusted off my Java skills and prototyped a yoga routine app to help with my yoga practice.

Next year I would like to focus more on creating a real pattern library for the site at work. Identifying and designing some more reusable components will be key to have a robust pattern library that faculty and staff will want to use.

Also, 2016 will be the year that I really sink my teeth into some front-end libraries. I’ve begun Wes Bos’ React for beginners course that has proven to be a solid introduction to React. I’d like to

  • build a simple React app of my own
  • implement a REST architecture
    • consume/write data to Drupal
  • build an Angular2 app
  • finish YogaRoutine

I’ve spent some of 2015 reading about these frameworks, now it’s time to actually do it. I’ve been slowly dipping my toes into the waters of front end frameworks and I think it is finally time to take the leap into it and try to build something with them on my own.

 

Thing one thing I don’t understand about Google Photos

Let me be clear: Google Photos is awesome and I love using it, but as a loyal Google user, I feel a little slighted. Here’s why.

When photos were managed by Google+, they counted against your storage. I accumulated a lot of photos during this time.

Now that Google Photos is out, they are offering FREE storage (that does NOT count against your storage quota) if the photo is under 16MP.

But wait a minute, all those previously uploaded photos are still counting against my storage, even though they were imported into Google Photos and are less than 16MP.

Not a huge deal, but a little disappointing. Anyone else have this experience?

 

Sharing content between Drupal multi-sites with RESTful and Feeds modules

At Oswego, when we decided to go with Drupal multi-site, one of the biggest drawbacks was the ability “out of the box” to share content between sites. But when you think of it, how much of Drupal works just as you’d like right out of the box? We looked at a few options but what we ended up settling on was a combination of modules that is doing the trick nicely.

Problem

We have a branch campus that needs to pull in program information from another site (graduate studies). The branch campus editors should not be able to edit the content being brought in since they are not the content experts on the subject. Graduate studies maintains the “master” content, then needs to be periodically pulled into the branch campus site. Then, using views we can display a list of content that we pulled in.

Solution

Being a semi-Drupal-newbie, this took quite a bit of trial and error before I figured out something that will work. If you know of another solution to this, by all means leave a comment! I’d love to hear it.

First thing I did was set up the RESTful module on the graduate studies site. This module makes it very easy to be able to expose our graduate program data as a read-only REST endpoint. I experimented with exporting it as RSS, or trying to build something to export the graduate programs as CSV or some other form of structured data but ended up going with JSON via the REST module. JSON is so widely supported, readable, and consumable by so many other applications that it seemed like it was the best route to go.

I’m currently working on a post about setting up the RESTful module! Sign up for email updates to get notified.

The feeds module alone doesn’t consume JSON, but luckily there is a really nice module called Feeds Extensible Parsers.

I’m also working on a post about setting up the Feeds Extensible Parsers module to read JSON!

I currently have it set up to update the branch campus’ program content every 3 hours. Using Drupal’s role and permissions, I can configure it so the branch campus editors can only read the program content, keeping it in sync with the “master” copy.