BlogmyQuery – BMQ

As designers, we pride ourselves on being great communicators. We go to extreme lengths to communicate with users in a language they understand, enabling them to engage with our messages and feel like they’re part of a story we built just for them. Yet, we do a poor job of communicating with those whom our work requires us to talk to every day—and we need to, and can, get better at it.

In fact, as much as we consider ourselves designers, significant parts of our working hours are actually spent communicating with one another. At least, mine are. Here’s a list of tasks I perform on a typical workday:

• Log onto IRC (the way people at Canonical—the company behind the Linux operating system Ubuntu—communicate with anyone who’s on the clock) and greet my colleagues.
• Check my e-mail; reply to some, save some to deal with later.
• Log onto Basecamp; check my to-dos, update some notes, and comment on a hot thread.
• Make a quick phone call to my manager to get the daily update and clarify priorities.
• Log onto Onotate, a tool we use to provide feedback on designs and wireframes; read feedback I received on my designs and provide feedback on others’.
• Do a bit of designing based on feedback and planned tasks; upload them again for quick reviewing.
• Meet with my team via Google Hangout to discuss a particular ongoing project.
• Reply to the e-mails I left for later.
• Do some more designing.

Sound familiar? Whatever your specific situation, I’d bet much of your days are spent communicating with other people, too: talking, writing, being silent, smiling, frowning, asking, answering, listening, and, at worst, yelling.

Good communication skills are what allow us to sell our work, justify our decisions, and stand behind our positions. This (along with doing good work) is how we gain the trust and respect of colleagues, bosses, and clients—something every design professional aspires to. And it’s why all these little pieces of communication we constantly deliver are so important.

So what’s so hard about communication, and how can we get better at it?

Digital communication

We hate our inbox, but don’t know what we’d do without it. We have chats on Skype. We have back-and-forth conversations on Basecamp. But most of these communication channels don’t really satisfy us, make us feel better, or dissipate our concerns. On the contrary, they often seem to make us even more anxious about work. Why is that?

People need human contact and interaction to flourish.

Psychiatrist Edward Hallowell calls the interactions that makes us happier “human moments�—being in the physical presence of someone and having her emotional and intellectual attention—and argues that not having enough of them can lead to oversensitivity, self doubt, rudeness, and worry.

Why? Because digital communication makes us miss all the benefits that come from communicating to while being in someone’s physical presence:

The human moment, then, is a regulator: when you take it away, people’s primitive instincts can get the better of them. Just as in the anonymity of an automobile, where stable people can behave like crazed maniacs, so too on a keyboard: courteous people can become rude and abrupt.¹

This sounds incredibly familiar. All you need to do is think of Twitter.

Hallowell explains how the human moment increases the release of hormones that promote trust and bonding, which are at lower levels when you’re not in the presence of another person. These hormones make us less prone to worrying or overreacting.

Digital communication removes all the cues that mitigate worry. As more and more people work like I do, alone from home offices, without much face-to-face interaction, it’s important that we’re aware of this both in ourselves and others.

So what can we do about it?

One answer comes from 37signals, which hires great talent regardless of geography and encourages others to do the same. In their book Rework, founders Jason Fried and David Heinemeier Hansson report that meeting in person is important for remote teams.²

I work remotely from my home in Belfast, but I meet with the rest of my team in our main offices in London at least once a month. Then, not only do we have lots of meetings and face-to-face discussions, but we also make time to grab a cup of coffee, have lunch, and basically just interact casually—something that simply doesn’t happen when you have to type out everything you want to say.

Other teams within Canonical are fully distributed, and they tend to meet every few months for about a week at a time. This is usually when a project is getting started or nearing launch, because close interaction and immediate answers are so critical during these times.

The phone used to scare me, but since becoming a remote worker, I actually hope people will pick it up to ask me something instead of writing an e-mail. And even better than that are tools like Skype and Google Hangout. My team tries to have at least one “hangout� every week, sometimes every day of the week. Regardless of what you’re discussing, relating expressions, gestures, and a space to faceless e-mails or IRC messages will make a difference.

While many good things come with working from home, such as no commute and being able to truly focus on a task, moments of loneliness inevitably assault me every now and then. This makes it critical that both parties—the remote worker and the main office—try to make those at a distance feel like they’re part of something.

Even if you’re not working remotely, it’s very likely that someone you or your company works with is, or will be soon—which makes it crucial for healthy communication that you consider how to create bonds and develop trust without interacting every day.

Emotional creatures

When dealing with people, remember you are not dealing with creatures of logic, but with creatures bristling with prejudice and motivated by pride and vanity.

—Dale Carnegie, How to Win Friends and Influence People

Human beings desperately seek approval, dread condemnation, and thrive on appreciation and encouragement. Not you or I, of course—all the others.

One key point Carnegie makes is that people are prodigies at rationalizing their decisions and actions. From the most merciless criminals to devoted grandmothers, we all tell ourselves—and others—that it’s not our fault.

The problem, of course, is that as professionals we must be accountable for our own shortcomings—as Andy Rutledge makes clear in his book Design Professionalism:

Perhaps most importantly, professionalism means, in every situation, wilfully gathering responsibility rather than avoiding it.

But our irrationality isn’t all bad. Dan Ariely, a professor at Duke University who writes about behavioral economics, has noted several experiments that prove that humans will work harder when their efforts are acknowledged and their work is appreciated and meaningful than they will for financial gain alone.³

It’s normal for irrationality, emotions, and cravings to influence our behavior in the workplace. Understanding this is the first step to communicating with colleagues. When you see that someone feels discouraged, you can quickly offer a few positive words. When you need to make a point in a meeting, you can avoid remarks that would blame others—remarks that only make people uncomfortable and create animosity. If you do need to point out a mistake, you can choose to do so in private, and also communicate that you trust your colleague to do a better job next time.

Considering others’ feelings might not sound like your top priority, but it’s important to understand that the faintest insight into how we actually think, what motivates us, and what makes us disagreeable will only improve communications and, in turn, influence the responses and value we receive back.

A shared vocabulary

As designers, one trap we typically know how to avoid is assuming that a user understands our jargon. Yet we do this to everyone else around us: other team members, clients, and people in our company who aren’t designers. When these people don’t seem to care about what we’re doing, we write them off and say, “they don’t get it.�

It’s a lot easier to blame other people than to admit the obvious: We don’t really know how to get our point across in a language those different from us will understand.

Sometimes, we can even have a laugh about it.

A few months ago, my team was working on a project in conjunction with another, more developer-focused team within the company. Even though we had prepared several documents illustrating the project plan, which involved various research and discovery steps, we felt this other team didn’t completely grasp our role, as they’d occasionally send us things like “finished wireframes.�

My reaction was the same as most designers’ would be: I brushed it off as failing to understand the discipline of design.

I was wrong. A member of the other team eventually explained that when we showed them research plans filled with words like “IA card sort,” that meant nothing to them. If we wanted everyone’s buy-in, we had to do a better job at explaining our jargon, as Mike Monteiro explains in Design is a Job:

It’s your job as a designer, and a communication professional, to find the right language to communicate with your client. When you say a client doesn’t “get it� you might as well be saying, “I couldn’t figure out how to get my point across. I am a lazy designer. Please take all my clients from me.�

It’s funny because it’s true.

We want people to care about design as much as we do, but how can they if we speak to them in a foreign language? It’s important that, as we do with any user, we find a shared vocabulary and empower everyone else to become evangelists for our cause.

Once we took the time to actually define all of those funny words in our research and discovery phase, we turned the other team into advocates for design—people who, armed with a shared vocabulary, can and will spread the word of design within their own networks. In this case, that network was extremely important to us: other developers within the Ubuntu community whom we desperately wanted to engage with in our design process.

All this takes work, yes. But aren’t showing and communicating what design is all about?

Building a narrative

We like to create stories for our users—narratives that are engaging and compelling, that delight them and make them feel like they’re part of something. We want them to feel invested in us, our products, our sites. We want to bring them along on a journey we carefully curate.

We think, “If I were this person, what would I want to feel once I land on this site? What would I be thinking? What would make me stay?� We consider their point of view.

Then we step into a meeting and expect everyone to consider ours.

Instead of showing your work to your colleagues with a few mumbled words and a shrug and expecting them to get its sheer brilliance, it’s important to involve them from the start, making everyone feel invested and part of the solution. Map out the future you see in front of you, and make them walk the same journey.

My team is responsible for the design, build, and maintenance of Canonical’s main websites, but we also have some involvement with several other peripheral sites—for example, consulting on design or providing front-end development. Because we’re called the “Web Team,� we’re generally the first to hear about problems with any of these other websites, too—even though we don’t manage them.

Instead of quickly dismissing those complaints, I find it a lot more interesting to try to understand where they are coming from. Why do they think something is wrong? What would a better solution look like for them? Clarifying what our responsibilities are and explaining the obstacles my team is facing at that particular time (such as too few resources, impending release deadlines, or technical constraints) also improves the conversation.

Sharing a vision for where we want to be in a few months’ time and how they will benefit from it brings other teams along. And when everyone participates or at least understands the process, they’ll also better understand how and why you got there.

Final words

We know we need other people to do our jobs well. But we often say this—to ourselves and to everyone else—without taking the time to truly listen to, be inspired by, and understand the reasons behind others’ words or actions. We desperately want everyone to understand our motivations, to see that we’re upset and tell us something positive, to listen to us and marvel at our wisdom—yet we rarely bother to reciprocate.

People fail to get along because they fear each other, they fear each other because they don’t know each other; they don’t know each other because they have not communicated with each other.

—Martin Luther King, Jr.

We already have the right tools to communicate with one another effectively. We just need to put the same effort into communicating with colleagues as we put into communicating with users. When we truly understand our colleagues and respect their needs, we will build stronger, more trusting relationships within our teams and organizations—and better design because of it.

Footnotes

[1] From “The Human Moment at Work� by Edward M. Hallowell (Harvard Business Review, January 1999). The article is behind a paywall, but you can preview or purchase it.

[2] See more in Rework's (Crown Business, March 2010) chapter “Hiring� in the section “The best are everywhere.�

[3] In The Upside of Irrationality (Harper, June 2010), Ariely describes an experiment where three groups of participants were asked to solve as many sheets of word puzzles as they wanted, with decreasing compensation for each subsequent sheet. In the first group, participants wrote their name on each completed sheet before turning them in. Facilitators would give them an approving nod, and then place each sheet on a pile of others’ sheets. In the second group, the facilitator would place the sheet on the pile, minus the name and the nod. In the third group, facilitators would take and immediately shred each sheet—no nod, no name. Those in the first group completed many more sheets than the others for the same compensation; the only difference was that their work was acknowledged.

Translations:
Italian

RSS readers: Don't forget to join the discussion!

Designers hold CSS close to their hearts. It’s just code, but it is also what makes our carefully crafted designs come to life. Thoughtful CSS is CSS that respects our designs, that is handcrafted with precision. The common conception among Web designers is that a good style sheet is created by hand, each curly bracket meticulously placed, each vendor prefix typed in manually.

But how does this tradition fit in a world where the websites and applications that we want to create are becoming increasingly complex?

Looking Back

If we look back in history, deep into the Industrial Revolution, we will see a parallel with what will happen with our handcrafted style sheets once the complexity of the products that we want to build becomes too great.

The Industrial Revolution (which took place approximately between the middles of the 18th and 19th centuries, starting in the UK) was a period of upheaval in society; several aspects of life were changing. Much of this was due to the way people produced goods: during this period, manual labor started to become mechanized. The textile industry, for example, moved from primarily human- to machine-based production, and its artisans started looking at ways to be more efficient.

One of the many products of the Industrial Revolution. (Image: McCord Museum)

These machines that were created with efficiency in mind were initially quite primitive, and the public didn’t know what to think of them. It took us some time to adapt the way we worked with them and the way we thought of them.

Jobs that previously required human labor now didn’t require anyone; a machine could do the job cheaper and faster; employees became redundant. But the jobs in which people were being replaced by machines were mainly repetitive ones, jobs for which manual labor didn’t necessarily make for better products — at least not in any significant way.

Some argued that the output suffered in quality, that machine-made objects lacked personality, that craftsmanship was being lost, and yet production improved and evolved. We were also getting to the point that some products were getting too complex to be made by hand anymore.

This revolution shaped the world we live in today and gave us access to things that were until then too expensive or even non-existent.

Getting back to our topic, we’re seeing increasing complexity in the world of Web design and CSS. We want to create increasingly complex websites and apps — systems so complicated that they cannot be made entirely by hand.

MobileMe, with its extensive functionality and comprehensive interface, is an example of a complex Web application.

The World Of Developers

Developers and programmers are already inclined towards automation. Developers instinctively avoid reinventing the wheel. They understand the need to automate production (at least some stages of it); they understand that hand-crafted code is not needed at every step of the process.

Even if you are a great front-end developer who knows JavaScript like the back of your hand, you still defer a lot of your work to jQuery or some other library. Even if you’re able to write the code yourself, the time you’d save by not doing that frees you to deal with more significant problems. The gains in writing a script from scratch are no match for the gains in being able to focus attention on problems that no machine or automated process can solve.

jQuery, a well-known developer’s tool.

The skills and knowledge you’ve gathered through the years are not in vain, though. This knowledge is what makes you the best person to decide whether to choose jQuery; it’s what makes you able to adjust a plugin that doesn’t quite do what you need; and it’s what makes you capable of determining the best tool for the job.

The Wrong Attitude

Web designers don’t approve of these kinds of shortcuts. This way of thinking doesn’t translate to CSS; in the world of CSS, taking these “shortcuts� is not well regarded.

We CSS authors have a list of dirty words that we avoid saying when we’re speaking with fellow Web designer friends. For example, when someone says they’ve used a CSS framework, the apology immediately follows: “It wasn’t our fault.�

Principles such as DRY (don’t repeat yourself) are not present in CSS.

DRY states that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.� This applies not only to code but to every aspect of a product, such as design itself. When DRY principles are followed, we’re supposed to end up with products that are of higher quality and easier to maintain.

We CSS authors don’t think of the cost of maintenance or the increased complexity that duplication and cancelling out of styles add to our CSS sheets.

We usually follow something closer to WET: we enjoy typing. Why someone would want to hand-code vendor prefixes for CSS gradients is beyond my understanding, but the truth is that some people do, and they take pride in it.

CSS authors — i.e. Web designers who write CSS — don’t like the machine. We don’t think any CSS that the machine can produce will ever be as good as the one we make ourselves by hand. But what if this is not true? What if the result is as good as our own manual labor from scratch?

Other groups have had the same fears. The Luddites were workers who fiercely opposed the Industrial Revolution and progress. They said that machines were taking their jobs — which was true. But they fought, protested, became violent and eventually lost. Things would evolve whether they liked it or not.

The Luddites, smashing the machine. (Image: Wikipedia)

Context Matters

It’s true that we don’t all code for the Facebooks and Yahoos of this world; your CSS’ performance might not be the most important thing to focus on in your projects. But this is why considering context matters, and this is why it’s important not to dismiss techniques and solutions because someone once told us they were wrong or dirty.

We can embrace the flexibility that some measure of automation gives us and focus our worries and energies on deeper problems. We could focus on so many things: accessibility, usability, design theory, psychology, business, economics, experimentation and even programming are all suitable candidates and are areas in which having some knowledge, even at a basic level, can greatly improve our work.

An interesting reading list. (Image: Mike Kuniavsky)

Expanding our skill set can give us a better understanding of the products we create, the people we create them for (and their context), and how they are supposed to work behind the curtains.

Rethinking our processes might lead to better quality work. It might lead to perfecting a machine still in its infancy. If we don’t deny mechanization from coming into our work, we get the chance to shape it so that it does exactly what we want it to do.

Try This At Home

If we look around, we’ll see that several people are already trying to change the way we write our CSS, whether by introducing some kind of automation or by looking at ways of creating style sheets that don’t bypass issues such as maintainability. We can take inspiration from the work they produce in a number of interesting ways. Below are some of the most prominent examples, but feel free to add your own list in the comments section.

Frameworks: Don’t Reinvent the Wheel

As mentioned, “frameworksâ€� are probably the dirtiest word in a CSS author’s vocabulary — or second dirtiest, after “Dreamweaver.â€� (Note: this article was written before the advent of Adobe’s Muse.)

Often when discussing the subject of this article, people walk away assuming that the message I am trying to get across is to use CSS frameworks. That’s not correct. But it isn’t entirely incorrect either. Let me explain.

Frameworks are an important tool in a CSS author’s repertoire. By that, I don’t mean that you should blindly use popular frameworks such as Blueprint or 960 Grid System. Sure, these frameworks have nailed some things, and we can certainly learn a lot from their flexibility and modularity, but it’s more important that you — especially if you’re on a team — adapt a framework to the needs of you, your company and your team.

Blueprint, a popular CSS framework.

Perhaps you or your company works with such disparate clients and projects that a framework wouldn’t really be helpful, though. Perhaps a library in which you can collect snippets of frequently used code would be more useful. Or perhaps a starter template is what you need.

Whatever you need, more often than not you can find a way without having to reinvent the wheel from project to project. And if indeed you work with a number of other designers and developers and share CSS, then these tools will make collaboration easier, and you won’t have to adapt to the style of the person who created a particular file.

Frameworks can also be useful tools for wireframing and prototyping, especially when there are time constraints and you need to put something in front of users or stakeholders quickly.

There are differences between a framework and a patterns library, components or even a simple collection of code snippets. A framework is a system that is flexible and can be adjusted to a myriad types of layouts, creating various page templates, whereas a library constitutes smaller individual modules that don’t have to be tied to any particular overarching framework or page construction.

A pattern demonstrates how, for example, tabbed navigation should function or how to mark it up; a design component could be the exact visual representation of an instance of tabbed navigation, with its colors, shapes and fonts. This explanation of these two distinct and important concepts is very simplistic. The “Further Reading“ section at the end of this article lists some useful resources on both.

The Yahoo Design Pattern Library.

A framework doesn’t have to spit out numerous unsemantic class names to every container in your markup. If you are creating your own, you are free to name those classes whatever you feel is right.

Let’s imagine you are starting to write a framework that can be shared across various development teams in your news organization. You might start with the following skeleton:

/* Resets */

/* Structure */

/* Global elements */

/* Visual media */

/* Article structure */

/* Forms */

/* Tables */

/* Reusable */

This structure is probably similar to many of your own style sheets. Let’s look at the “Article structureâ€� section as an example of something that would probably benefit from some framework inspiration. In the project, you will probably have to accommodate several variations of templates from various departments, sub-departments, content creators, editors, etc. Rather than using classes like span-6 and pull-3, you can define a naming system that better ties into the website’s content. For example:

/* Article structure */

article {
	width: 80%;
}
article.charticle { /* Charticle pages have no sidebar */
	width: 100%;
}
article.listicle {
	width: 70%;
}

article > .headline {
	font-size: 2em;
}
article.feature > .headline {
	color: #000;
}
article.breaking > .headline {
	text-decoration: underline;
}

article > section {
	border-bottom: 1px solid #efefef;
} 

article > aside {
	background: #efefef;
	padding: .5em;
}

article > footer {
	font-size: .9em;
}

Several things about the above CSS could be debated (I’m sure many of you have strong feelings about descendent selectors and named elements and even whether some of these classes could have been simple element selectors — to name but a few points), but none of this matters in this example. What does matter is how you can be influenced by what popular do-it-all frameworks are doing, and how you can apply that to your clean, semantic and perfectly named markup and CSS.

If you can plan for and analyze the needs of the people who create the content, then you can ensure that they have the flexibility they need to do their jobs and that you can be proud of your code. Sometimes an extra class is necessary, but if that makes everyone’s life easier, then why not, right?

Think of Others

Following what we discussed in the previous section, the fact that your CSS doesn’t live in a vacuum can be extremely useful.

Other people — and the future you — might need to come back later on to edit the style sheet that you’re creating today. Wouldn’t you want your future self to be free to go home to your spouse and kids earlier on a Friday afternoon rather than have to stay up late refactoring a CSS file that is hard to comprehend and impossible to extend?

Do yourself and others a favor by considering what you’re doing. Add comments to your CSS files for such things as the following:

Calculations
Font sizes (especially when dealing with ems) and layout measurements are great candidates for these types of comments.

h2 {
font-size: 18px;
line-height: 1.167; /* 21 (original line-height) / 18 (h2 font-size) */
}

Hacks
On the rare occasion that you use a hack, explain what you’re doing, refer to the hack by its common name, and link to an online reference that explains what you’ve just done.

aside section {
float: left;
width: 50%;
display: inline; /* fixes the double float margin bug on IE5/6. More on this bug/solution: http://www.positioniseverything.net/explorer/doubled-margin.html */
}

To-dos
Even CSS documents have “nice to haves,� so listing what you’ve been planning to do but haven’t gotten around to yet might be a good idea.

/* To-do
Change all colors to RGB format.
Sanitize reusable classes section.
*/

File structure
Summarizing what is contained in a particular file can save time when someone is looking for a certain selector.

/*  Table of contents
Resets
Structure
Links
Typography
Small screens
*/

Dependencies
Is this file being imported by some other file? Does it override something else? Explain what and how.

/* Christmas style sheet 2011

Overriding: main.css
Importing reset file: reset.css */

The fact that CSS comments are not standardized could cause a problem with all of this preparedness: everyone does them differently. In my quest for the ideal CSS formatting style, I discovered the dusty CSSDOC standard, which tries (or tried) to introduce some kind of sanity to the situation.

The old dusty CSSDOC website.

CSSDOC is an adaptation of Javadoc (a documentation generator that extracts comments from Java source code into HTML). It is also similar to PHPDoc, Javadoc’s adaptation for PHP. A comment that follows the CSSDOC format (a “DocBlock�) looks like the following:

/**
 * Short description
 *
 * Long description (optional)
 *
 * @tags (optional)
 */

Every block starts with /** and ends with a space followed by */. Every line must start with a space followed by an asterisk. The tags may contain information such as @author, @copyright, @todo and so on.

The CSSDOC standard suggests that a CSS file should include a comment about the file itself at the top, containing meta data that is relevant to the whole file. This comment should include information such as the title of the document, a description and tags such as @project, @version, @author, @copyright and even @colordef, indicating which colors are used in the file. The file comment may be followed by any number of section comments that divide the style sheet into relevant blocks. Section comments include the tag @section:

/**
 * Typography
 *
 * @section typography
 */

The CSSDOC documentation is not lengthy. Also, it hasn’t been maintained for a while, but I did find it interesting and have started applying it to my projects because it takes some of the guesswork and subjectivity out of comments.

Another way to make sharing documents on a team easier is to standardize the style. We all have our preferences on how to format CSS, how to name classes and IDs, address bugs, etc. Creating a style guide that recommends a way to do these things in your company will make it easier for anyone who edits the CSS to dive straight into what they need to do, rather than having to decipher someone else’s style.

This may be overkill for a team of one or two, but it can improve efficiency and save time when the team grows. In this case, consistency should have final say; personal preference is not important. If you’re the only one on a team of 12 who prefers single-line CSS, you will have to take one for the team. (Pardon me if I sound bitter; perhaps I still recall what happened on my own team…)

Here are some examples of style guidelines:

• “Class and ID names must be lowercase.â€�
• “Do not specify units for values of 0 (zero). They are unnecessary.â€�

When creating a style guide, include a succinct explanation for its inclusion, otherwise it will be easy for people to challenge it. The BBC has some great examples of guidelines that are relevant to CSS authors.

An example of CSS guidelines, part of BBC’s “Future Media Standards & Guidelines� documents.

Learn About Object-Oriented CSS

Object-oriented CSS was started by front-end performance consultant Nicole Sullivan. The methodology brings modularity and flexibility to CSS by forcing you to create small flexible style sheets.

It follows two main principles. First, it states that an element should behave predictably, no matter where you place it on a page. So, a child element should behave the same independent of the parent, and parent elements shouldn’t need child elements to render correctly.

The second principle is that the rules that control the structure of elements should be separate from the rules that control their skin.

So, if you look at the pages that you need to build in a modular way and think of individual objects first and the pages second, then after creating the initial CSS you should be able to build any page layout using just the existing modules.

All of this sounds great, but object-oriented CSS does have some drawbacks.

For instance, in order for an element to be adaptable enough to be placed anywhere on the page, the name of its class should also be flexible. If you style a box and give it a class name of footer, and later on you decide to apply that style to a box in the sidebar, then the initial class name you gave it will be wrong — it’s not flexible enough. Thus, class names in style sheets that follow object-oriented CSS can sometimes be less content-driven or less semantic than we’d like.

Despite its drawbacks, object-oriented CSS has its value in certain situations. If we are working on a big website for which a small style sheet (small file size) and flexibility and maintainability are important, then following the principles of object-oriented CSS can bring huge improvements to our processes and huge savings to our company.

Once again, you don’t have to follow this methodology blindly in order to gain from its benefits.

Going back to the news company, let’s imagine you want to make a box that sits in the sidebar more prominent than other elements contained there. You might write the following CSS:

#sidebar .highlight {
	background: #efefef;
	border: 1px solid #000;
	box-shadow: 0 0 .5em #000;
}

#sidebar .highlight > h1 {
	font-weight: bold;
}

What’s so wrong with the CSS above? If you are following object-oriented CSS, then you shouldn’t restrict a style that you will probably reuse in the main content area by confining it to the #sidebar container. In our example, though, we’ll happily keep the descendent element selector in the second rule (object-oriented CSS advises against child elements being dependent on parent elements, but you can draw the line on how closely to adhere to a particular technique as you see fit, and that’s the beauty of it!).

So much more could be said about this technique. It is indeed well worth looking into, all bias aside. You will read things that you probably don’t consider good practice, but remember: context is important, and your expertise equips you to adopt the principles that will help you in your situation.

Step Into Programming

The command line is a boundary between designers and developers that we designers usually don’t want to cross. Instructions on opening the terminal can be quite intimidating for designers if they’re not familiar with it. I confess I’m guilty of steering clear of it most of the time.

But consider this: we keep talking about how we should learn and draw inspiration from the past — from print design, for example. We claim with pride to have deep knowledge of typography, color theory, layout, grids and scales. We see it as a requirement for anyone who calls themselves a professional designer.

This knowledge should be extended to encompass programming, at least at a basic level. After all, it is what powers our most precious creations.

Instead of being inspired by architecture — by its teachings, its processes and its vocabulary — why don’t we get inspired by the architect’s example, by what they have to learn? Why not be inspired by the multitude of disciplines that an architect has to know intimately in order to be a great professional?

How many disciplines can you spot in this model? (Image: n fiore)

Why not start now? Open Terminal. (Go on, don’t be scared. It’s only there to help.) Now type the following:

$ gem install sass

(You don’t have to write the $; it’s just there to indicate this is a Terminal command.) There, you’ve just installed Sass (which we’ll cover shortly). That didn’t hurt, did it?

If you’re working on a Sass file, you could type the following simple command to make the original Sass-formatted file automatically update the corresponding normal CSS file whenever changes are made:

$ sass --watch style.scss:style.css

The List Goes On

There are several more tools you can keep in your arsenal that can move CSS another step into the future.

Quite a few Web designers and CSS authors are becoming enamoured with CSS preprocessors such as Sass, which make it possible to extend CSS’ syntax to include, for example, variables, complex calculations and nested selectors. Not only do they enable you to use functionality not yet available in normal CSS, but you can increase efficiency by automating tasks such as updating a frequently used color on a file-wide basis, rather than having to change each instance by hand.

The increasingly popular Sass.

And with all the improvements brought by CSS3, even pure and simple CSS is becoming more powerful, enabling us to create very complex layouts and animations more easily and with fewer lines of code.

The list presented here is a short one, and I’d be happy to know what techniques you apply in your own projects to make the process of writing CSS more fluid and to make your style sheets smaller and more easily maintainable and sharable.

This Is Just The Beginning

Eric Meyer says, “You can’t identify a code craftsman by whether or not they use this framework or that language. You can identify them by how they decide which framework or language to use, or not use, in a given situation.� This statement couldn’t be closer to the truth. Discussing tools without context is pointless.

Saying that something is good or bad should be done in context. By deciding that a certain technique is fundamentally flawed because someone once said so, and holding to that opinion throughout your career without ever challenging it, is not what being creative is about.

In his Critique of Pure Reason, Kant says, “Have the courage to use your own intelligence.� I would ask you to set your biases aside when when speaking about tools, techniques and processes with other designers and developers who write CSS. Don’t view different opinions as a sign of ignorance or poor craftsmanship.

Certainly, we may question certain aspects of our jobs as Web designers, and whether to be more liberal in letting automation into our processes is just one of them — but one I’m particularly interested in.

I know and work alongside very intelligent and creative programmers. These are people who understand systems so complex that my brain shrinks every time it tries to even begin to understand them. These are also people who are proud of their work, true craftsmen of their times. I find it quite interesting how these two groups (CSS authors and programmers) work on the same products but in such different ways, how they both work with code but with such contrasting values.

There is a place for carefully handwritten, handmade, perfect CSS — I take great pleasure in this myself. But there is also a place for the study and perfection of a more mechanized approach to style sheets. Both can certainly run side by side.

What are your views on this subject? Have you been trying to automate any part of your CSS writing? Do you think style sheets should always be handcrafted?

Further Resources

Hopefully, I have linked to all of the resources used to write this article in the article itself. Here are a few more interesting reads that touch on this subject, if not in its entirety at least partially.

Front page image credits go to Creativity103.