Author Archive

Uncompromising Design: Avoiding The Pitfalls Of Free


  

Misaligned interests create tension in the design process that can lead to bad, and potentially unethical, design decisions, that result in inferior products. In this article I will examine how the desire to build a large audience by giving away your products and services free of charge can cause conflicts of interest, which in turn can lead to dubious compromises in the design process that limit the full potential of your work.

The recently launched Twitter competitor, App.net, which has raised over $800,000 in the first month of fund-raising/pre-sales, has started its life as a simple premise: Twitter doesn’t work because the interests of the company and its users, along with the developers creating apps for its platform, are not aligned. They’re not aligned because as a free product Twitter doesn’t make money from its everyday users and developers, and thus does not hold any obligation towards them. Like most other free Web services, Twitter is building its business model on advertising, the advertiser becoming the customer, and its users, bluntly put, the product.

While it is possible that the interests of the multiple parties you are trying to satisfy with your product or service overlap, it is likely that there are also differences in what they want. In those cases where the interests vary, the product designer will have to pick the party whose interests will take precedence in their design decisions.

For example, if you build an audience of users through a free product and then go on to sell advertising, there may arise a conflict of interests on the issue of privacy. The advertiser benefits from knowing more about the users, while some users may wish to keep their information to themselves. The two conflicting interests force the designer to pick a side, either to push for more information sharing in order to make the most out of advertising, or to take a stand on the privacy of their users while losing the potential for more advertising revenue. If they decide to give away user information without their permission they will also be giving away their users’ trust, along with their own integrity.

Nothing Is Free

All work requires compensation, whether monetary or otherwise. Sometimes we choose to work for free, in regards to money, but that choice is always based on some other form of compensation. When we give someone a gift, we receive emotional compensation in return because the action of giving a gift satisfies our desire to please someone we care about. We may give a gift to somebody we do not know, but this also works the same way, providing us with emotional nourishment that satisfies a compassionate soul. Sometimes we create work for ourselves, that is, we work on something because we enjoy the creative process itself, the work being its own goal. In those cases, the process, together with the end product, are our compensation.

An artist may work on a painting for its own sake, the work being its own reward, but they will not work for free when commissioned to produce a piece for somebody else, unless of course they have the desire to present the work as a gift, in which case they must know the person they are working for well enough and care about them enough to feel that the emotional reward outweighs the toil. When this is not the case, when they do not wish to give away their work as a gift, they will seek monetary compensation, for even though they may enjoy the process of creation itself, the act of giving away their finished work and their time — and thus, a little of their life — requires fair compensation.

Money Or Love
The designer’s dilemma lies often in the difficult choice between monetary payment and satisfaction of a job well done. Image by Opensourceway.

Developers of today’s free Web apps and sites do not know their users well enough in order to give away their work as a gift. The bond between them and the recipient is not so strong as to generate enough desire in their hearts to wish to give away their work for free. One exception to this is the open source movement, in which case the work is given away as a gift, though the compensation has less to do with the recipient than with the intended function of the work.

Open source software is first and foremost created to satisfy a certain goal that the developer has, and the fulfillment of this goal is reward enough for them. They then release their work into the world and may derive further benefit, like patches to the software and prestige for themselves, but this further benefit is only an extra, only the icing for the cake which has already been eaten. In a few cases the software takes off and grows at a rapid pace, but the initial compensation has already been paid in giving the developer what they wanted when they first set off to create it.

Contrast this with free products and services that are not open source. Those products are given away free of charge, but they are not given away free from the maker’s desire for compensation. Since compensation does not come from the users it is sought elsewhere.

Advertising: A Gateway To Conflict Of Interests

Typically, this path leads to advertising. If the users aren’t going to pay for their product, the advertiser will pay for the users. The product developer begins to introduce ads and other forms of sponsorship deals. This creates a conflict of interests. On one hand, the product serves a specific purpose for the user, on the other, an ulterior motive is introduced in the form of advertising, which in turn uses the product as a means to sell something else, the product itself being relegated to the status of a promotional vehicle. The focus of the product is split in two:

  1. it must work to perform a certain function for the user, and
  2. it must get the user to click on an ad.

While it is possible to keep these two goals separate, in many situations they are not mutually exclusive, which forces the designer to pick sides and make compromises.

Some product designers and developers proceed to mask this conflict of interests by pretending that the two goals don’t actually point in different directions, and that their primary focus is always on making the best product possible, which in turn brings them more users, and thus more advertising money, the latter being the outcome of the former.

This stance is taken for two reasons. First, telling users that they are the product is not going to go well with them, and neither will admitting that you are compromising design decisions that improve the product to the advantage of the user for design decisions that only benefit the advertisers.

Second, this viewpoint may even be a subconscious reaction to the inner dilemma that the product designer has to face when they are forced to pick between two or more conflicting interests. A good designer does not want to compromise their integrity. They want to make the best product they can, which means a product that best serves its primary purpose, that is, its function for its users, so they try to resolve the conflict with a different explanation.

Twitter Changes
Since Twitter relies on advertising, it had to make quite unpopular decisions recently. The company limited access, enforcing display requirements, and forming guidelines for what sort of apps they want (and don’t want) to see on the platform.

But this doesn’t work. You can pretend the conflict of interests isn’t there but that will not make it disappear. For example, Twitter recently began to push back on developers who make apps for their platform by limiting access, enforcing display requirements, and forming guidelines for what sort of apps they want to see on the platform, and what sort of apps they don’t. Apps that are seen to compete with Twitter’s main offering, i.e. consumer micro-blogging, are discouraged.

Twitter’s initial goal was the creation of a simple micro-blogging service, which they’ve allowed to evolve into different forms to suit its many uses. But now, having to face the reality of needing to make the service pay, they turn to advertising, and in turn are forced to enact much greater control over how the user interacts with their product in order to reshape the service into a viable advertising channel. Now, there is nothing wrong with Twitter taking the advertising route to make money. That’s not the issue. What’s wrong is the situation in which they find themselves, having to strike a compromise between the needs of the advertiser and the needs of the many developers of Twitter apps who have helped get the service to where it is today.

Twitter does not technically owe anything to those developers, but to push them aside when you’ve reaped the rewards of their labor is not a decent thing to do. The roots of the problem are unclear commitments, which have been there from the very beginning. If the developers paid for the service, Twitter could work without hesitation on delivering them the best platform and API for their apps. Without this commitment, the various parties work together on a foggy perception of aligned interests, only to later find themselves in trouble when they discover that their interests aren’t so aligned after all.

Then we have the problems with privacy breaches that pop up all the time with services like Facebook and Google (Wikipedia has whole pages dedicated to listing criticisms of the two companies, here’s one for Facebook, and one for Google). Once again, these companies don’t make money selling a service to the end user, they make money from selling advertising. This creates a conflict where the product developer has to decide whether to focus on satisfying the needs of the user, or making the service more lucrative to advertisers by sometimes breaching the privacy of their users. The issue would not exist if people paid for their search service or for their social network, which would remove the advertiser from the equation and let the company focus solely on delivering the best product for the user, but as this isn’t the case, we are left in a situation where the interests of one party are compromised for the interests of another.

There are also the really obvious dishonest design decisions used in social games like that of Zynga, whose interests lie in promoting the product in order to pull in more users rather than actually making a good product. For example, they have a dialog prompt with only one button that says “Okay�. The dialog asks the user whether they will give the app greater access to their Facebook timeline, i.e. let it make posts on the user’s behalf, but there is no option to close the dialog, only to agree with it.

Upon clicking the button, the actual Facebook permission box pops up which lets the user decide whether or not they wish to give these permissions to the app, but because the previous box has already conditioned them to agree, they are more likely to simply click “Okay� again in order to proceed, rather than stop to make a conscious decision.

Manipulative Zynga Prompt
A manipulative Zynga prompt. The two buttons, “Accept” and “Cancel”, are about sharing a message with your friends, but the wording makes it seem as if they are to do with accepting the reward itself.

On the one hand, the designer is tasked with creating an informative dialog box meant to help the user make a rational decision, on the other, they are tasked with creating a dialog box which will manipulate the user into acceptance, and because they are not committed to delivering the best service they can for the user, they pick the latter. The interesting thing with Zynga is that they actually do make money from their users, but they do so only from the small percentage who pay, not from the whole user base. This means that to make money they have to capture masses of users, like dropping large fishing nets into the ocean to catch the few “whales� (the term used in the industry for large spenders) along with a pile of bycatch.

Lastly, consider all the online blogs and magazines that cram their pages with ads leaving no room for the content, and also the content itself, which takes the ever more sensationalist nature by the day, its only purpose being to bring in more page views, not to enlighten readers. For example, The Huffington Post split tests headlines to arrive at the one that brings in the most hits, thereby trading the experience and judgement of the author for the impulses of the masses. Because the reader is not the one paying, these sites hold little loyalty towards them, leading to design decisions that optimize for page views and ad clicks rather than for the creation of the best possible reading experience. Such sites also like to introduce design tricks like pagination, the goal of which is to once again boost page views, while they try unsuccessfully to convince us that clicking multiple times on a set of small page links somehow leads to a better user experience.

The conflict of interests that arises naturally in free products derails the designer’s core goal of making a great product, that is, a product that aims to fulfill its primary purpose of satisfying the user as best as possible. Loyalty to multiple parties with disparate goals is impossible, which leads to friction in design decisions and in the soul of the designer, forcing them to make dubious compromises in their work. Each small compromise doesn’t seem like a big deal, a little manipulative form box here, a tiny breach of privacy there, but remember that the final product is the sum of its parts, and so in the end, the multitude of small compromises add up into a substantial whole.

If Compromise Isn’t An Option, Free Is Not A Solution

A compromise is a concession on the part of all the parties involved, not just some, and you cannot compromise on principles without destroying them altogether. For example, there can be no compromise between truth and falsehood for you cannot make something just a little less true. In the same way, surrendering your users’ privacy or manipulating them into taking an action for your own gain is to surrender your honesty, and in turn, a part of the moral foundation upon which your work is built.

Whenever you feel a tension in making a design decision that you think is caused by a conflict of interest, ask yourself exactly what compromise you’re asked to make. Are you asked to make a fair concession between one party and another from which both will derive benefit, or are you asked to take something from your users without their permission, or make them do something they have not agreed to do? Are you asked to make a decision that will compromise the integrity of your work?

Faced with this dilemma, what do you do? The answer is simple, and is the very thing you should have been doing all along: charge money for your products. By selling your work instead of giving it away for free your interests and those of your customers — who are no longer just users — are aligned: they provide you with the compensation for your work, not some outside party, leaving you free to focus on delivering the best product, for them. This is not only moral in that you no longer have to compromise the interests of one party for those of another, it is also a much simpler solution. You make a product and sell it directly to the customer, no need for other parties, nor conflicting interests, nor dubious design decisions.

App.net
App.net proclaims ad-free social networking in their banner. Because the membership fees are placed right next to it, the user never wonders where the catch is.

It works, too. A great example is the App.net project which I’ve mentioned at the start of the article. Its creator, Dalton Caldwell, wasn’t satisfied with the way Twitter was treating its developers, so he set off to create his own micro-messaging service, with the difference being that this service would be paid for at the outset by its users and developers. Caldwell set a minimum of $500,000 for his fundraising month during which people could sign up for a year of service to a product that didn’t yet exist.

In just a month he raised over $800,000 and has launched an alpha version of the service. His critics have been saying that nobody would ever pay for a Twitter-like service, but clearly there is enough value there for some to sign up for a paid alternative. It is far too early to judge the future of the venture, but the initial fundraising success shows that people are prepared to pay for services they care about, even with the presence of free, established alternatives.

Charging For Online Content Works

On December 10th 2011, the stand-up comedian Louis C.K. decided to release his full-length special Live at the Beacon Theater on his website as a DRM-free download for $5. Two weeks later, sales from this self-published special exceeded $1 million. The download was DRM-free, meaning that people could easily pirate it, but given the fairness of the price and the package that route just wasn’t worth it. Yes, not everyone can re-create the success of Louis C.K., but that’s not the point. Of course to drive product sales you need to generate enough excitement and interest — that’s the job of marketing. The point is that selling digital goods on the Web is possible, and, when you have something people genuinely want, can be very lucrative. The success of Louis C.K. has since inspired other comedians, namely Aziz Anasari and Jim Gaffigan, to adopt a similar distribution model.

Last year, The New York Times put up a paywall around its online articles. The paywall allowed visitors to read 10 articles a month free of charge, but required a paid subscription for subsequent access. The implementation of the wall was very porous, meaning that it was very easy to get past it with a variety of simple steps, and so many critics believed that people wouldn’t be fooled into a paid subscription. Just four months after the implementation of the paywall, 224,000 readers have already signed up to the paid subscription, not far short of the company’s goal of reaching 300,000 subscribers within a year. Combined with sign-ups through other channels, such as Kindle and Nook subscriptions, the total of digital subscribers rose to around 400,000. Although this number still makes up a small portion of the newspaper’s revenues, it highlights healthy growth and proves that charging for online content can work, even in the face of everyone else giving theirs away for free.

The New York Times Paywall
The New York Times paywall prompt. Even though there are simple tricks to get past it, many people still prefer to pay for their content.

Other newspapers like The Wall Street Journal and The Economist successfully use the same model by keeping most of their content accessible only to paid subscribers. When you charge your readers for content, you no longer need to run after page views by creating sensationalist work, nor does your website need to try and squeeze ever more page loads out of each visitor through design tricks like pagination. Once your readers have subscribed and paid, they’re going to read what you have to say no matter how attention grabbing or plain your headlines are, freeing your authors and journalists to focus on creating work that enlightens your readers, not shallow content designed to spread.

For an example of design related publishing consider the success of Nathan Barry and Sacha Grief, whose two eBooks combined have made them $39,000 worth of revenue — and are still selling. Bloggers like to give away their experience for free, and while this is great for the readers, it doesn’t help pay the author’s bills. Some put up a few ads on their site, but unless they consistently generate a lot of traffic, the revenue generated by the ads won’t amount to much. Instead of chasing after advertising pennies, why not package your experience into a book? If your audience is tech savvy, you won’t even need to print the book — just offer a DRM-free eBook package that your readers will be able to consume on any device of their choice. The success of Barry and Grief shows that people are ready and willing to pay for good content, you just have to give them the opportunity to do so.

As for an example of well implemented advertising, consider The DECK ad network, which includes some of the top tech sites around the Web like the Signal vs. Noise blog from 37signals, Dribbble, Instapaper, A List Apart and many more. The ad network uses a very unobtrusive 120×90 pixel banner, with a sentence or two of text underneath. Its small size shows respect for the end user by keeping advertising within strict limits. It’s a subtle way to advertise which has inspired other networks to offer the same format, such as AdPacks from BuySellAds. This small format won’t work for everyone — most of the sites that use The DECK rely on other sources of revenue — but it is a good way to deliver a cleaner experience for the user while still providing an advertising channel.

Summing Up

Free products themselves are not the problem. We give gifts all the time and the giving of them to the people we care about is reward enough for us. The problem is the giving away of free products and services while still expecting compensation. If the compensation does not come directly from the user, the developer proceeds to extract it by other means, which usually involves bringing in other parties to the table, leading to a conflict of interests. When the interests of the user and the product maker are not aligned, not only do you get a neglect in the feature set, but a product of a wholly different nature. The conflict is not just external, it exists inside the mind of the designer, and a battle is fought every time they are put into a situation where they have to limit their full creative potential by compromising the interests of the user.

It doesn’t have to be this way. People will pay for design and content created to serve them, not to exploit them. People have paid for centuries, and they will continue paying for goods and services that give them value. Instead of picking the path of free design, take the road of moral design — design firmly based on the moral values that guide your life and your work. By turning your users into your customers you eliminate the conflict of interests and thus free your mind to work fully on the problem at hand, and any compromises that you make will be real and fair compromises, that is, design judgements that improve your product by taking it in the direction you want it to go, not dubious choices that surrender your values, limit your creativity and cripple your work.

(vf)


© Dmitry Fadeyev for Smashing Magazine, 2012.


Using the LESS CSS Preprocessor for Smarter Style Sheets

Advertisement in Using the LESS CSS Preprocessor for Smarter Style Sheets
 in Using the LESS CSS Preprocessor for Smarter Style Sheets  in Using the LESS CSS Preprocessor for Smarter Style Sheets  in Using the LESS CSS Preprocessor for Smarter Style Sheets

As a Web designer you’re undoubtedly familiar with CSS, the style sheet language used to format markup on Web pages. CSS itself is extremely simple, consisting of rule sets and declaration blocks—what to style, how to style it—and it does pretty much everything you want, right? Well, not quite.

You see, while the simple design of CSS makes it very accessible to beginners, it also poses limitations on what you can do with it. These limitations, like the inability to set variables or to perform operations, mean that we inevitably end up repeating the same pieces of styling in different places. Not good for following best practices—in this case, sticking to DRY (don’t repeat yourself) for less code and easier maintenance.

Enter the CSS preprocessor. In simple terms, CSS preprocessing is a method of extending the feature set of CSS by first writing the style sheets in a new extended language, then compiling the code to vanilla CSS so that it can be read by Web browsers. Several CSS preprocessors are available today, most notably Sass and LESS.

Less-css in Using the LESS CSS Preprocessor for Smarter Style Sheets

What’s the difference? Sass was designed to both simplify and extend CSS, so things like curly braces were removed from the syntax. LESS was designed to be as close to CSS as possible, so the syntax is identical to your current CSS code. This means you can use it right away with your existing code. Recently, Sass also introduced a CSS-like syntax called SCSS (Sassy CSS) to make migrating easier.

If It Ain’t Broke…?

By now you might be thinking, “So what? Why should I care about these things, and how exactly will they make my life as a Web designer easier?â€� I’ll get to that in a moment, and I promise it will be worth your time. First, let me clarify the focus of this article.

In this tutorial, I’ll be using LESS to demonstrate how CSS preprocessing can help you code CSS faster. But that doesn’t mean you must use LESS. It’s my tool of choice, but you may find that Sass fits your workflow better, so I suggest giving them both a shot. I’ll talk a bit more about their differences at the end of the article.

I’ll start off by explaining how LESS works and how to install it. After, I’ll list a set of problems that large CSS files pose, one by one, and exactly how you can use LESS to solve them.

Let’s go!

Installing It

There are two parts to any CSS preprocessor: the language and the compiler. The language itself is what you’ll be writing. LESS looks just like CSS, except for a bunch of extra features. The compiler is what turns that LESS code into standard CSS that a Web browser can read and process.

Many different compilers are actually available for LESS, each programmed in a different language. There’s a Ruby Gem, a PHP version, a .NET version, an OS X app and one written in JavaScript. Some of these are platform-specific, like the OS X app. For this tutorial, I recommend the JavaScript version (less.js) because it’s the easiest to get started with.

Using the JavaScript compiler is extremely easy. Simply include the script in your HTML code, and then it will process LESS live as the page loads. We can then include our LESS file just as we would a standard style sheet. Here’s the code to put between the <head> tags of your mark-up:

<link rel="stylesheet/less" href="/stylesheets/main.less" type="text/css" />
<script src="http://lesscss.googlecode.com/files/less-1.0.30.min.js"></script>

Note that I’m referencing the less.js script directly from the Google Code server. With this method, you don’t even have to download the script to use it. The style sheet link goes above the script to ensure it gets loaded and is ready for the preprocessor. Also, make sure that the href value points to the location of your .less file.

That’s it. We can now begin writing LESS code in our .less file. Let’s go ahead and see how LESS makes working with CSS easier.

1. Cleaner Structure With Nesting

In CSS, we write out every rule set separately, which often leads to long selectors that repeat the same stuff over and over. Here’s a typical example:

#header {}
#header #nav {}
#header #nav ul {}
#header #nav ul li {}
#header #nav ul li a {}

LESS allows us to nest rule sets inside other rule sets, as a way to show hierarchy. Let’s rewrite the above example with nesting:

# header {
  #nav {
    ul {
      li {
        a {}
      }
    }
  }
}

I’ve omitted the content from the selectors for simplicity, but you can see how the structure of the code quickly changes. Now you don’t have to repeat selectors over and over again; simply nest the relevant rule set inside another to indicate the hierarchy. It’s also a great way to keep code organized because it groups related items together visually.

Also, if you want to give pseudo-classes this nesting structure, you can do so with the & symbol. Pseudo-classes are things such as :hover, :active and :visited. Your code would look as follows:

a {
  &:hover {}
  &:active {}
  &:visited {}
}

2. Variables For Faster Maintenance

We usually apply a palette of colors across an entire website. Any given color could be used for multiple items and so would be repeated throughout the CSS code. To change the color, you’d have to do a “Find and replace.”

But that’s not quite it. You could also isolate those values into separate rule sets; but with this method, the rule sets would keep growing as you add more colors across the website, leading to bloated selectors. Here’s what I’m talking about:

#header, #sidebar .heading, #sidebar h2, #footer h3, .aside h3 { color: red; }

To make a simple color change, we’re faced with long selectors, all dedicated to that one color. It’s not pretty. LESS allows us to specify variables in one place—such as for brand colors, border lengths, side margins and so on—and then reuse the variables elsewhere in the style sheet. The value of the variable remains stored in one place, though, so making a change is as simple as changing that one line. Variables start with an @ and are written like this:

@brand-color: #4455EE;

#header { background-color: @brand-color; }
#footer { color: @brand-color; }
h3 { color: @brand-color; }

In LESS, variables also have scope, so you could use variables with the same name in various places; when they’re called, the compiler would check for the variable locally first (i.e. is there anything with that name where the declaration is currently nested?), and then move up the hierarchy until it finds it. For example, the following code:

@great-color: #4455EE;

#header {
  @great-color: #EE3322;
  color: @great-color;
}

…compiles to:

#header { color: #EE3322; }

3. Reusing Whole Classes

Variables are great, but we often reuse more than single values. A good example is code that’s different for every browser, like the CSS3 property border-radius. We have to write at least three declarations just to specify it:

-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;

If you use a lot of CSS3, then this sort of repeating code adds up quickly. LESS solves this by allowing us to reuse whole classes simply by referencing them in our rule sets. For example, let’s create a new class for the above border-radius and reuse it in another rule set:

.rounded-corners {
  -webkit-border-radius: 5px;
  -moz-border-radius: 5px;
  border-radius: 5px;
}
#login-box {
  .rounded-corners;
}

Now #login-box will inherit the properties of the rounded-corners class. But what if we want more control over the size of the corners? No problem. We can pass along variables to the “mixin” (these reusable classes are called mixins) to get a more specific outcome. First, we rewrite the original mixin to add the variable we want to manipulate:

.rounded-corners(@radius: 5px) {
  -webkit-border-radius: @radius;
  -moz-border-radius: @radius;
  border-radius: @radius;
}

Now we’ve replaced the values for a variable, and we’ve specified the default value inside the parentheses. To give mixins multiple values, you’ll just need to separate them with a comma. Now, if we want our #login-box to have a border radius of three pixels instead of five, we do this:

#login-box {
  .rounded-corners(3px);
}

4. Operations

Variables let us specify things such as common palettes of colors, but what about relative design elements, like text that’s just a bit lighter than the background, or an inner border that’s one pixel thicker than the outer border?

Rather than add more variables, we can perform operations on existing values with LESS. For example, we can make colors lighter or darker or add values to borders and margins. And when we change the value that these operations depend on, they update accordingly. Take the following:

@base-margin: 25px;
#header { margin-top: @base-margin + 10px; }

This gives the #header element a top margin of 35 pixels. You can, of course, also multiply, divide and subtract, and perform operations on colors like #888 / 4 and #EEE + #111.

5. Namespaces and Accessors

What if you want to group variables or mixins into separate bundles? You can do this by nesting them inside a rule set with an id, like #defaults. Mixins can also be grouped in this way:

#defaults {
  @heading-color: #EE3322;
  .bordered { border: solid 1px #EEE; }
}

Then, to call a variable and a mixin from that particular group, we do this:

h1 {
  color: #defaults[@heading-color];
  #defaults > .bordered;
}

We can even access values of other properties in a given rule set directly, even if they’re not variables. So, to give the sidebar heading the same color as your main h1 heading, you’d write:

h1 { color: red; }

.sidebar_heading { color: h1['color']; }

There’s not much difference between variables and accessors, so use whichever you prefer. Accessors probably make more sense if you will be using the value only once. Variable names can add semantic meaning to the style sheet, so they make more sense when you look at them at a later date.
A couple more things to mention: You can use two slashes, //, for single-line comments. And you can import other LESS files, just as in CSS, with @import:

@import 'typography';
@import 'layout';

To Conclude

I hope by now you’ve got a pretty good idea why CSS preprocessors exist, and how they can make your work easier. The JavaScript version of the LESS compiler, less.js, is of course just one way to use LESS. It’s probably the easiest to get started with, but it also has some downsides, the biggest one being that the compiling takes place live. This isn’t a problem on modern browsers with fast JavaScript engines, but it might work slower on older browsers. Note that less.js actually caches the CSS once it’s processed, so the CSS isn’t regenerated for each user.

To use the generated CSS instead of LESS in your markup, you can compile your files using the various other compilers. If you’re on OS X, I suggest trying out the LESS App, a desktop app that watches your LESS files for changes as you work and automatically compiles them into CSS files when you update them. The Ruby Gem has the same watcher functionality but is trickier to install if you’re not familiar with Ruby (see the official website for details on that). There are also PHP and .NET versions.

Finally, LESS isn’t your only option for a CSS preprocessor. The other popular choice is Sass, but there are still more options to check out, such as xCSS. The advantage of LESS is that it uses existing CSS syntax, so getting started is just a matter of renaming your .css file to .less. This might be a disadvantage if you dislike the CSS syntax and curly braces, in which case Sass would probably be a better choice. There is also the Compass framework available for Sass, which is worth checking out if you go with Sass.

(al) (sp)


© Dmitry Fadeyev for Smashing Magazine, 2010. | Permalink | Post a comment | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: ,


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress