Designing The Well-Tempered Web

• By Rob Flaherty
• January 17th, 2012
• Design, User Experience
• 26 Comments

As technology evolves, so does the art and craft of Web design. New technology creates new challenges, which require new solutions. Often we’re working in uncharted territory, where the solutions demanded really are new. Other times, we’re faced with problems of a more universal nature, problems that have a history.

Given the limited history of Web design, we have to look beyond our immediate domain for answers to the more challenging questions. We do this all the time when we draw on the rich history of graphic design and visual arts. But we’re not limited to sibling disciplines. If we can identify the abstractions and patterns that constitute our challenges, we can look to any source for guidance. We can look to a seemingly unrelated field, such as psychology or music. We can even look to an episode from the early 18th century about Johann Sebastian Bach.

In this article we’ll look at what Bach has to do with modern Web challenges — Particularly the challenge of designing for devices with diverse attributes and capabilities.

Bach And “The Well-Tempered Clavier”

In 1722, Bach put together a book of solo keyboard works intended as a collection of educational pieces for young musicians. The book contained 48 pieces — a prelude and fugue in every major and minor key. Now a staple of the Western canon, it’s regarded as one of the most important works in the history of Western music. He named the book The Well-Tempered Clavier.

To appreciate the historical significance of the work, you have to understand that in Bach’s day the notion that one might play keyboard music in all keys was unorthodox. It was a matter not of philosophy, but of physics: a fixed-pitch keyboard instrument could be in tune only with a selection of keys at a time. In the tuning systems of the era, playing in tune in all 12 major keys was simply not possible.

While the laws of physics can be tough to bend, human perception moves fairly easily. The solution was to redefine what it meant to be “in tune.” By adjusting certain intervals so that they deviated just slightly from perfect intonation, a tuning system was produced that allowed one to play reasonably in tune in all keys. This practice of compromising granular qualities for the greater good of the system is called temperament.

Opening measures of the first Prelude of Bach’s Well-Tempered Clavier. (Image credit: Wikipedia)

The name of the alternative tuning system made famous by Bach and The Well-Tempered Clavier is, unsurprisingly, “well temperament.” Today, most intonation in Western music is based on “equal temperament.” The methods are different, but the goal is the same: to make each of the keys slightly imperfect so that all of the keys can be used. It’s like utilitarianism for acoustics.

What This Has To Do With UI Design

Probably the most exciting development in Web design in the last few years has been the shift to designing for multiple devices. It’s no longer just about how a website functions in two different browsers, but about how it functions on various devices with completely different characteristics: different screen sizes, different capabilities, different use contexts, different interfaces.

Although responsive design and device-specific websites enable us to tailor designs for diverse experiences, there will still be times when we have to make universal decisions — and when we do, the metaphor of well temperament can be helpful.

The application of this concept to UI design is straightforward: in order to deliver a good experience for a range of devices, we have to allow for occasional imperfections in individual interfaces. We have to make little compromises here and there to make sure that our design travels well to other environments.

Touch-First Design

A common example of well temperament in action is the effect that touch interfaces have had on recent desktop website designs.

As a pointing device, a finger, being much larger than a mouse, requires a larger touch target than what’s required by a mouse cursor. So, to ensure usability, interactive elements need to be bigger. As interactive elements increase in size, other things need to increase in size to maintain balance. This leads to an aesthetic characterized by generous margins and padding.

The new Gmail design has a lot of white space and extra padding on buttons and is very touch-friendly, even though it’s a desktop design.

The rise in popularity of the iPad, which bridged the gap between touch interfaces and desktop screen sizes, is what accelerated the influence of touchscreens on desktop interface design. If you look at recent redesigns of major products such as Gmail and Twitter or browse CSS galleries, you’ll see that design on the Web is starting to look a little different. Things look more… plumpish. There’s more white space, buttons have more padding, things in general feel bigger. Of course, other factors are at play, such as the steady increase in desktop screen sizes.

What we end up with is a design that might afford too much space for a mouse but an appropriate amount of space for a finger. We allow for a slight deviation from the norm in one experience in order to better support all possible experiences.

It’s important to note that making a UI touch-friendly in this way also results in a UI that might be more useable for mouse-and-desktop users. A button that’s easier to touch is often easier to click. By erring in the direction of usability, we get the bonus of improved performance of the design in its original desktop context.

Microsoft’s Metro design language is inspired by a touch-first approach to interaction design.

Universal Design via Responsive Design

Although much of the discussion on responsive design tends to focus on techniques of responsiveness, responsiveness itself is never the goal. It’s a means to an end. The design responds in order to do something else. That something else might be to supply different content, to serve low-bandwidth images, or to adapt the layout for better presentation on smaller screens. That something else might also be a goal of providing a universal experience to a large number of different devices.

Riding the responsive design train to arrive at universal experience design, we’re likely to pass through some form of well temperament. A great example of this — and an excellent example of responsive design in general — is the Boston Globe’s website.

The Boston Globe is a shining example of responsive design on a large-scale website.

This responsive strategy enabled a single design to adapt to any device that a reader might use to read The Boston Globe (even the Apple Newton!). But this wasn’t just a feat of front-end engineering. Accompanying the media queries and JavaScript wizardry was a simple malleable design that lent itself to adaptation.

This is a tempered design. While the minimalism might be purely stylistic, I suspect that if it had been a desktop-only design, we’d have seen more gloss and embellishment. There would have been a longer runway on which to perfect the experience for a single-use context. But instead, the designers made little trade-offs to produce something that could be transposed to all possible environments — something that could play in all 12 keys.

Mobile-First Design

The preceding examples were concerned more with graphic design, but the concept of temperament can be applied to product design, user experience, information architecture — almost any other area of design. Let’s look at product design and the idea of designing for mobile first.

If you’re designing for mobile first, then you’re already working with tempered design. By starting the design process with mobile and building a product around the demanding constraints of the mobile environment, you’re obligated to focus on the most essential elements of the product. As Luke Wroblewski writes:

So, when a team designs mobile first, the end result is an experience focused on the key tasks users want to accomplish, without the extraneous detours and general interface debris that litter today’s desktop-accessed websites. That’s good [for the] user experience and good for business.

When these design decisions extend beyond the mobile experience to define the overall product, then the design takes on a form of temperament. The latest redesign of Twitter (i.e. “New Twitter” or “New new Twitter”) demonstrates some of these principles.

New Twitter has a simplified design and a consistent experience across devices.

One of the objectives of the Twitter redesign was to give users a consistent experience across computers and mobile phones. Achieving a consistent look and feel is a UI challenge, but achieving a consistent overall product experience is a deeper challenge. In both cases, designing for mobile first puts us on the right path.

Something I found interesting about the Twitter redesign was the influence that the mobile experience had on the product’s overall design. For example, aside from the tweet button, all of the actions have been organized under four tabs: “Home,” “Connect,” “Discover” and “Me.” It’s a simplification that plays wonderfully on a small screen. Four items fit perfectly in the tab bar.

On the desktop website, other features have been added, but the simplicity established in the mobile version carries over. Although the desktop version has plenty of room — both pixel-wise and figuratively — for more complexity, the design is restrained, tempered, to ensure a universal multi-device experience.

Beware Of Wolves

In the natural tuning systems that predated the standardization of well and equal temperament, notes of the out-of-tune intervals that were played simultaneously produced a harsh and howling sound. Musicians had a great name for this: they called it a “wolf.”

Applying this idea to interface design, we can think of a wolf as a visual or interactive element designed for one experience that breaks down to some degree when transposed to another. Think of the times you’ve struggled to finger-tap a small link that was made for a mouse cursor, or had to read tiny text on a mobile screen, or, on a touch device, used an interface that relied on hover states. Wolves in the UI.

These article present links that are designed for interaction with a mouse. When viewing on a touchscreen mobile device, their usability is greatly impaired.

New York Magazine provides useful and well-designed drop-down navigation menus — but only if you’re using a mouse.

Closing Thoughts And Practical Tips

Again, it’s true that responsive design and device-specific experiences can offer us a way around many of these problems. If we can tune the size of a button to a particular environment, then we don’t have to accept blunt, across-the-board treatment. But the number of devices we have to support will only increase, and customizing for every possible scenario could quickly become unreasonable.

Even if we are able to provide perfectly tailored design at the execution level, there is still value in thinking about tempered, universally accessible design at the conceptual level.

Additionally, just because we can tailor design to particular experiences doesn’t mean that users will not carry expectations over from one experience to another. The boundaries might blur whether we like it or not.

Tips and Things to Keep in Mind

• Think responsively.
  Even if you’re not implementing a full responsive design, simply thinking in responsive terms goes a long way to achieving usable universal design.
• Think touch-first.
  A button sized for a fingertip will always work for a mouse cursor. But a button sized for a mouse cursor will often be too small for a fingertip. Designing for touch first ensures that your website or application translates well to other contexts.
• Think universally.
  “Test early, test often” the saying goes. In your design process, think early and often about how your design will function on various devices.
• Think mobile-first.
  Starting your design with mobile focuses you on what really matters to your users. By maintaining focus on the essential features, achieving a consistent experience across devices will be much easier.
• Be careful with interaction behavior that is not supported universally across interfaces. Hover states don’t function the same on touch devices. Touch gestures can’t be performed with a mouse. It doesn’t mean we can’t use these things, but we have to be aware of their limitations.

In The End…

Bach believed that people should be able to write and play in any key they wish. He argued for it by writing beautiful music that compelled the world to agree. He designed for the system he wanted.

We want our users to have great experiences with our websites and applications on any device they choose. We want our work to be as usable and accessible as possible.

What will you design?

Other Resources

You may be interested in the following related resources:

• The Well-Tempered Clavier, Book I, played by Glenn Gould, Rdio
• Audio examples comparing different tuning systems, The Pyxidium
• “Wolf Interval,” Wikipedia
• “Multi-Device Web Design: An Evolution,” Luke Wroblewski
• Responsive Web Design, Ethan Marcotte
• “Non Hover,” Trent Walton

(al)

Resolution Independence With SVG

• By David Bushell
• January 16th, 2012
• CSS
• 45 Comments

In this article, we’ll look at Scalable Vector Graphics (SVG), one of the most underused technologies in website development today.

Before diving into an example, let’s consider the state of the Web at present and where it is going. Website design has found new vigor in recent years, with the evolving technique of responsive design. And for good reason: essentially, responsive website design moves us away from the fixed-width pages we’ve grown accustomed to, replacing them with shape-shifting layouts and intelligent reflowing of content. Add to that a thoughtful content strategy and mobile-first approach, and we’re starting to offer an experience that adapts across devices and browsers to suit the user’s context.

When we look at the breadth of Web-enabled devices, responsive design is sure to provide a better user experience. Scrolling horizontally, panning and zooming the viewport have their place in user interface design, but forcing the user to do these things just to navigate a website quickly becomes tedious. Fitting the website to the viewport is about more than just layout: it’s also about resolution. In this article, I’ll demonstrate why SVG is a perfect addition to future-friendly Web development.

Introducing SVG

SVG offers a truly resolution-independent technique for presenting graphics on the Web. SVG is a vector graphics format that uses XML to define basic properties such as paths, shapes, fonts and colors, and more advanced features such as gradients, filters, scripting and animation. Create the file once and use it anywhere, at any scale and resolution.

Consider the use cases: UI and navigation icons, vector-style illustrations, patterns and repeating backgrounds. For all of these, a scalable graphic is the perfect solution from a visual standpoint, and yet fixed-resolution images are still the norm. In the example below, we’ll show you how to expand on a common development technique to take advantage of SVG.

A Case Study: CSS Sprites

We all know about the CSS sprites technique. (If you don’t, then have a quick read through Sven Lennartz’ article. And Louis Lazaris points out its pros and cons.) In the example below, we’ll show how seamlessly SVG replaces normal raster images. If this technique is not for you, you can certainly imagine a whole array of similar situations in which to use SVG.

Vector icons play a big role in user interface design. Pictures express concepts with vivid clarity, whereas their textual counterparts might carry ambiguity. In UI design, where space is scarce, a simple illustrated icon could be greatly welcome.

I’ve mocked up the following example:

I’ll be first to admit that this row of icons won’t win any design awards, but it will suffice for the sake of this article! Let’s look at the HTML:

<div class="actions">
   <a class="a-share" href="#">Share</a>
   <a class="a-print" href="#">Print</a>
   <a class="a-tag" href="#">Tag</a>
   <a class="a-delete" href="#">Delete</a>
</div>

I’ve kept the HTML to a minimum for clarity, but in practice you’d probably want to mark it up with an unordered list. And you’ll almost certainly want to replace those hashes with real URLs (even if JavaScript provides the functionality, having a fallback is nice). Let’s look at the CSS:

.actions {
   display: block;
   overflow: auto;
}

.actions a {
   background-image: url('sprite.png');
   background-repeat: no-repeat;
   background-color: #ccc;
   border-radius: 5px;
   display: block;
   float: left;
   color: #444;
   font-size: 16px;
   font-weight: bold;
   line-height: 20px;
   text-decoration: none;
   text-shadow: 0 -1px 2px #fff;
   padding: 10px 20px 10px 40px;
   margin-right: 5px;
}

.a-share  { background-position: 10px 0; }
.a-print  { background-position: 10px -40px; }
.a-tag    { background-position: 10px -80px; }
.a-delete { background-position: 10px -120px; }

Note the fixed-pixel sizing and the PNG background, which we can see below framed in full Photoshop production glory:

This implementation of a CSS sprite is basic, and at today’s standard, it’s not good enough! How can we enhance this? First, let’s consider the following issues:

1. We’ve rasterized the image at a very early stage. Even at full size, icons in which points sit between pixels, such as the one for “Print,” have blurred.
2. If we zoom in, the image will blur or pixellate even more; there is no additional data to re-render the image at larger sizes.
3. Everything has a fixed size, which is neither good for responsive design nor good for accessibility, because the browser’s default font size is ignored.

As you’ve probably guessed by now, we’ll show you how SVG solves these problems. But first, let’s reiterate each point thoroughly to understand the issues at large.

1. Rasterization

Devices such as modern smartphones have a very high pixel density; some already surpass the 300 pixels-per-inch (PPI) mark that is assumed to be the limit of the human eye’s ability to distinguish fine details. A pixel has no real-world equivalent in size until it sits on a screen of fixed dimension (say, 3.5 inches diagonally) and fixed resolution (say, 640 × 960 pixels). At this scale, text with a font size of 16 pixels would be incredibly small to the eye. For this reason, devices simply cannot translate 1 CSS pixel unit to 1 device pixel; instead, they double up. Thus, a 16-pixel font size actually takes over 32 pixels when rendered.

The same applies to images; but they are already rasterized, so doubling up the pixels has no benefit. In our example, each icon has been rasterized at around 25 × 25 pixels (the whole sprite being 30 × 160), so they cannot take advantage of the double pixel ratio. One solution is to use CSS media queries to detect the pixel ratio. This is already implemented in Webkit- and Gecko-based browsers.

To improve our example, we can add the following CSS declaration:

@media only screen and (-webkit-min-device-pixel-ratio: 2)  {
   .actions a {
      background-image: url('sprite@2x.png');
      background-size: 30px 160px;
   }
}

The alternate background image supplied in the code above has been saved at 60 × 320 pixels (i.e. double the original dimensions). The background-size property tells CSS to treat it smaller. Significantly, now the device has the additional data to render a better image (if capable).

This solution isn’t bad, but it doesn’t solve the problems we’ll run into in points 2 and 3 below. It also requires that we maintain multiple files of increasing size: a potential burden on bandwidth and a real hassle. For non-vector images, such as photography in JPG format, we can’t do much more than that.

2. Zooming

At their default size, our rasterized icons look acceptable, at least on low-pixel-density screens. However, should the user zoom in on the Web page, these little UI delights will degrade very quickly.

Zooming is a common action when users find a website too small for comfortable viewing. Or, to put it another way, websites that are designed too small are very common. There is really no “perfect” size, because almost everyone has at least some level of visual impairment, since our eyes inevitably deteriorate with age. Secondly, with the rapid increase in touchscreen devices, pinch-to-zoom has become the standard way to enlarge fixed-sized content designed for larger screens (i.e. much of the Web today).

We should develop websites in a way that minimizes the need for user input — that’s where responsive design comes in (see point 3 below) — but zooming is here to stay. There’s simply no way to provide pre-rasterized images for every level of zoom (in theory, an infinite scale). Scalable graphics are the solution, and we’ll show you how to enhance our example. But first, a related word on fixed sizing.

3. Fixed Sizes

Presenting page elements at fixed sizes forces many users to zoom, but it also disables a very useful browser feature. Users can set their preferred font size (the default in browsers is 16 pixels). By sizing everything in pixels, we override this preference. Sizing elements based on this default is much better, so that, if the text is bigger, everything adjusts to match. This essentially mimics the zooming effect but happens without the user having to manually do it on every visit. Ethan Marcotte has written a great article that explains relative font sizes.

Let’s re-implement our sprite example with a solution to these three issues.

A Scalable Implementation

Here is the HTML again. We don’t need to change anything here.

<div class="actions">
   <a class="a-share" href="#">Share</a>
   <a class="a-print" href="#">Print</a>
   <a class="a-tag" href="#">Tag</a>
   <a class="a-delete" href="#">Delete</a>
</div>

The updated CSS is where the magic happens:

body { font-size: 100%; }

.actions {
   display: block;
   overflow: auto;
}

.actions a {
   font-size: 1em;
   line-height: 1.25em;
   padding: 0.625em 1.25em 0.625em 2.5em;
   margin-right: 0.3125em;
   border-radius: 0.3125em;
   background-image: url('sprite.svg');
   -webkit-background-size: 1.875em 10em;
   -o-background-size: 1.875em 10em;
   -moz-background-size: 1.875em 10em;
   background-size: 1.875em 10em;
   /* styles carried over from the original implementation */
   background-repeat: no-repeat;
   background-color: #ccc;
   color: #444;
   display: block;
   float: left;
   text-decoration: none;
   text-shadow: 0 -1px 2px #fff;
}

.actions-em .a-share { background-position: 0.625em 0; }
.actions-em .a-print { background-position: 0.625em -2.5em;  }
.actions-em .a-tag { background-position: 0.625em -5.0em;  }
.actions-em .a-delete { background-position: 0.625em -7.5em;  }

In this version, we’ve made the following changes:

• The background-image is now an SVG file.
• All sizes are based on the default of 16 pixels, or 1 em. If the user’s default is larger or smaller, then everything will scale relatively. (If you multiple each em size by 16, you’ll get the number of pixels used in our initial fixed-size example.)
• The background-size is very important. By setting this in em units, we’re telling the browser to scale the sprite relative to everything else. You’ll notice that 1.875 × 10 em multiplied by 16 becomes 30 × 160 — the base size at which we produced the sprite in pixels.
• The background-position of each sprited icon is also based on relative units.

Now that we’re using SVG and relative sizes, we have solved the three big issues highlighted above. A scalable graphic can be rasterized on demand to perfectly suit any device resolution and any zoom level. By using relative sizes, we can continue implementing a responsive design, minimizing as much as possible the need for the user to zoom. We’re also respecting the browser’s default font size, and enabling our design to adapt accordingly.

I actually produced the SVG sprite first and the PNG version from that. (I imported the SVG in Photoshop before exporting it as a PNG — Illustrator’s PNG export had very poor rasterization.) Below is the header in my SVG file. Notice the same 30 × 160 initial size.

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
   width="30px" height="160px" viewBox="0 0 30 160" enable-background="new 0 0 30 160" xml:space="preserve">

You can see that the attributes for width and height are set in pixels (width="30px" height="160px") in the opening svg tag (as generated by Adobe Illustrator). This actually causes it to render early in Firefox, before the graphic has scaled to match the em sizes in background-size. Webkit-based browsers seem to scale the SVG perfectly, regardless. I’ve found that editing the SVG file to use em units in these two attributes fixes any rendering issues in Firefox.

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
   width="30em" height="160em" viewBox="0 0 30 160" enable-background="new 0 0 30 160" xml:space="preserve">

I don’t know which browser actually implements this scaling correctly, but let it be noted that extra care is needed to ensure cross-browser perfection. Mozilla MDN has an excellent in-depth article, “Scaling of SVG Backgrounds,” which explores more practical examples. For more ideas, see Alex Walker’s article “A Farewell to CSS3 Gradients.”

Here’s a super-close screenshot showing the SVG sprite:

The sprite scales beautifully. (Sadly, the same can’t be said for my tacky text-shadow effect.)

It’s best to experience the joys of scalable graphics and relative sizing firsthand. I’ve uploaded a side-by-side live demo demonstrating a combination of all the techniques mentioned above.

Browser Support

At the start of this article, I said that SVG was underused. I believe that has generally been the case due to poor browser support. But things are different now! Browser support for SVG has blossomed over the last year to the point where implementing it is a viable use of development time.

According to the website When Can I Use?, support for SVG across multiple implementations is as follows (I’ve combined support for both CSS’ background-image and HTML’s img source — the most useful attributes):

• Internet Explorer 9+
• Firefox 4+
• Chrome 4+
• Safari 4+
• Opera 9.5+

Mobile browser support is also pretty much across the board. If a workable fallback exists for older browsers, then SVG is a very viable solution.

For some of the new additions to Web standards, we can implement them safe in the knowledge that old browsers will simply ignore them and that they aren’t even required. We call this “progressive enhancement”: better browsers get a progressively better experience. SVG is slightly different, because for most practical purposes, it simply replaces other images in CSS backgrounds and HTML elements. The image format — be it SVG, PNG, JPG or GIF — is either supported or it isn’t. We can’t simply follow the practice of progressive enhancement here, because an image failing to render is not an acceptable experience.

Browser Sniffing or Feature Detection?

We could make an educated guess and say that we need to worry only about users of Internet Explorer 6 to 8. In this case, the conditional comments technique for IE-only styles enable us to re-apply a second CSS background-image of a supported format such as PNG, instead of the default SVG background.

Browsing sniffing is always a dangerous game. While Internet Explorer tends to be the main offender, we can never assume it is the only one.

The safer and highly recommended option is to detect SVG support and use it only if it’s found. I suggest using Modernizr if you need to detect multiple features. Modernizr applies a class of svg to your root html element if detected (to which you can apply SVG as a background-image). If you’re using SVG as the source of an image element in HTML, then implementation is a little harder. You’ll have to write more JavaScript to find and replace all sources once support has been established.

The problem with these methods is that the browser will download the fallback image before SVG is detected — the only exception being the conditional comments technique for IE. Users will also likely see a flash of re-styled content when the source image changes. This shouldn’t be the case for long; but at least for now, these problems may be enough to hold you off on SVG usage.

File Size

In our sprite example, the raw SVG file was 2445 bytes. The PNG version was only 1064 bytes, and the double-sized PNG for double-pixel ratio devices was 1932 bytes. On first appearance, the vector file loses on all accounts, but for larger images, the raster version more quickly escalates in size.

SVG files are also human-readable due to being in XML format. They generally comprise a very limited range of characters, which means they can be heavily Gzip-compressed when sent over HTTP. This means that the actual download size is many times smaller than the raw file — easily beyond 30%, probably a lot more. Raster image formats such as PNG and JPG are already compressed to their fullest extent.

Performance

Rendering performance is a concern with SVG, especially on mobile devices, whose hardware is limited. Raster images can be rendered pixel for pixel after decompression and de-encoding. Vector graphics need to be rasterized at a specific resolution every time they’re viewed.

SVG has consistently proved slower than Canvas as a platform for animating vector graphics; but our concern here is basic rendering, not manipulation a thousand times per second, and if that is possible, then simple rendering shouldn’t be a concern. The more intensive SVG features are things like clipping masks and filter effects. These are unnecessary for many practical purposes (like our sprite example), but, if required, the best way to check performance is by testing. A lot of Web development is supported in theory, but in practice results are far from perfect.

Alternative Methods

Hopefully you agree that SVG is extremely useful but not always the ideal solution to resolution independence. Ultimately, the trick is to avoid raster images while maintaining the scalability of visual styles. Below are a few more ideas to think about.

CSS3

You’ve probably already started combining CSS3 properties such as linear-gradient, text-shadow and box-shadow to create more complex styles. Web developer Lea Verou curates a CSS3 pattern gallery that shows off the impressive potential of gradients alone.

In his article “Mobile Web in High Resolution,” Brad Birdsall introduces a technique to maintain pixel perfection for high-resolution displays using the pixel-ratio property.

Then there are pure CSS “icons,” which Faruk Ateş rightly points out as being absolute “madness” — certainly so if you’re using CSS to create a logo! But you could argue the benefits of a small handful of very specific techniques, such as CSS triangles, as demoed by Chris Coyier.

Web Fonts

Dingbat Web fonts and look-a-like Unicode glyphs are two interesting alternatives for vector icons, both with accessibility and semantic challenges. Jon Hicks has a write-up of perhaps the best practice for this. SVG seems a more appropriate technique for icons, but both have an immediate visual impact at high resolutions — and we’ll be paying increasing attention to that in coming years.

Looking Forward

As you can see, SVG usage is very much a possibility, and browser support and performance will only improve in future. What’s important to note from this article is that we really should be building websites that are as resolution-independent as possible.

Consider the “one Web” philosophy and the vast range of devices we use to access it — there is no single user experience. The more we can do to stay device-agnostic, the better. Responsive website design addresses many of these needs and certainly provides many benefits. Using vector graphics may not be as apparent, but its little improvements really do make a difference.

With today’s level of support, many users can experience the beauty of crisp scalable graphics… or perhaps that’s the wrong way to think about it. Most users won’t say “Wow! Kudos on the vectors.” To our dismay, they probably wouldn’t even consider them (and certainly wouldn’t recognize the effort required to craft them). And that’s a good thing; each time we improve the user’s experience, we don’t necessarily need to make a song and dance about it. Letting things continue to grind away under-appreciated is OK. It’s the lack of such things that gets recognized and sniffed at. Raise the user’s expectations in visual aesthetics, and they’ll start to notice the websites that do look shoddy. If you don’t do it, others will.

(al)

How Commercial Plugin Developers Are Using The WordPress Repository

• By Siobhan McKeown
• January 13th, 2012
• Plugins
• 18 Comments

A few weeks ago I wrote about how you can put together a great readme.txt for the WordPress plugin directory. In addition to using a WordPress readme as a tool to help out your users, you can use it to promote your commercial products and services. While commercial theme developers are already promoted on WordPress.org, this promotion isn’t extended to commercial plugin developers. But restrictions often lead to creativity, and developers have had to get a bit creative in figuring out how to monetize the WordPress repository. API keys, complementary plugins and lite versions are just a few of the ways that plugin developers are exploiting the WordPress plugin directory for commercial benefit.

(Image: Bowe Frankema)

What’s Allowed?

Back in 2009, Mark Jaquith posted this on the WordPress development blog:

Plugins that merely exist as placeholders for a plugin hosted elsewhere (like a “requirements check” plugin) are out, but “lite” versions, etc are in. The goal is to have the directory be free-to-download plugins. A placeholder for a premium plugin is against that spirit.

He goes on to say:

If your plugin is actually a plugin, not just an advertisement or a placeholder for a plugin hosted elsewhere, you’re fine, as far as this rule is concerned.

Related to this, Matt Mullenweg posted on the WordPress.org support forums:

There are plenty of plugins that tie into third-party services, for example Google AdSense, and some of them have no free versions. That’s totally fine as long as the plugin is totally GPL.

I emailed Matt to see if anything has changed since he posted this, and he directed me to WordPress.org’s “Detailed Plugin Guidelines.”

Briefly, if you’re a commercial plugin developer, here’s what you need to keep in mind if you’re planning to use the repository:

• The plugin must be GPLv2. (Explicitly state this in your license. If you don’t, it will be assumed that your plugin is GPLv2.)
• Trialware is not allowed.
• Upselling is allowed (but not by being annoying or disabling features after a time period).
• Serviceware is allowed, even for paid services (i.e. a plugin that serves to interface with a third-party service). The service must be doing something substantive, not just providing keys or licenses.
• No phoning home without the user’s consent. This includes:
  • No unauthorized collection of user data;
  • No remote images or scripts (everything must be part of the plugin);
  • Banners and advertising text should not be included in the plugin;
  • Advertising spam is not allowed.
• No sending executable code via a third-party system (unless of a service-client model).
• External links may not be included on the user’s public website.
• No hijacking the admin page.
• No sponsored links in the readme.
• WordPress.org reserves the right to edit the guidelines and to arbitrarily disable or remove a plugin for any reason whatsoever.

Adhering to these guidelines is a delicate balance, and not everyone who tries to monetize the repository is successful at it, as the people behind Plugin Sponsors recently found out.

That said, let’s look at some models whereby developers have managed to create synergy between free plugins and paid plugins or services.

The API Key

No one likes spam. (Image: Thomas Hawk)

Who’s doing it?

• Akismet
• Scribe SEO
• YoLink
• WPMU DEV Anti-Splog

If you’ve installed WordPress, then you’ve met Akismet. Akismet is the anti-spam plugin that comes bundled with WordPress. It’s free for non-commercial use, but if you are using it for a commercial website, then you have to pay for it. The whole Akismet issue pops up every so often in the WordPress blogosphere. Many people feel that a commercial plugin shouldn’t be bundled in WordPress, although I don’t plan to get into that debate here.

Whatever you think of it, providing an API key for a service is a viable way to create a WordPress plugin, host it in the WordPress repository, and yet charge for the service that it provides. Another plugin provider that adopts this model is YoLink, a search service that offers advanced search functionality for websites. Personal websites (i.e. without advertising) that have fewer than 5,000 monthly visitors per year can use it for free; after that, the pricing varies.

“We’ve found that once a user has ample time to test-drive the plugin on their site, they come to realize its value and upgrade to a paid subscription,” says Joe Pagliocco of YoLink. “We are seeing this most often with commercial sites looking for additional flexibility and indexed pages.”

However, you don’t even have to offer a free version of your service to get a plugin with an API key into the repository. Scribe, a popular service from Copyblogger, is a plugin that integrates with your WordPress website. In order to use Scribe, you have to sign up for an API key, which is a minimum of $17 per month. While the plugin is GPLv2 and free, the service is not. This approach might make some people hate you, but it is still a viable way to make money from a plugin in the directory.

Pro: You’re able to offer a plugin that provides a service and make money from it.

Con: People might hate you for it.

Upgrades And Support Forum

Jigoshop offers a commercial-level e-commerce plugin — for free!

Who’s doing it?

• Jigoshop
• WP eCommerce

Jigoshop is a free e-commerce plugin, available in the WordPress repository. It includes everything that you need to run an e-commerce website. If you like the plugin (and many people do), then you can pay for premium upgrades and support. Premium upgrades include MailChimp integration, BuddyPress integration and various advanced payment gateways.

I spoke with Dan Thornton at Jigoshop, and he said that they had considered going down the lite/premium route, but because the free version was embraced so quickly, they didn’t want to duplicate their work. By including all of the standard payment gateways in the free version, they made it possible for a small business to get a store up and running and then invest its money in extending the store’s features and functionality, rather than have to pay for all of the bits and pieces up front.

When Jigoshop launched earlier this year, it got a lot of promotion throughout the WordPress community purely because it is a totally free, fully-functioning e-commerce solution. “If we’d gone for a different business model,” says Dan, “we couldn’t have afforded the marketing and advertising to match the recommendations and promotion that we’re grateful to have had from users, designers and developers.”

Pro: Massive community of developers has gathered around Jigoshop, adding their own expertise to the product.

Con: A fully-functional GPL plugin is open to being forked by bigger players on the scene.

The Lite Plugin

Do you like your plugins with less calories? (Image: Niall Kennedy)

Who’s doing it?

• WPMU DEV
• Event Espresso
• Cart66

This is probably one of the most common ways to use the repository to up-sell, and it can be a great option for a variety of plugins. Basically, you restrict the features in the free version and offer a paid version for people who want more features. Putting a lite version of a plugin in the repository is fine, provided it is GPL and adheres to the “Detailed Plugin Guidelines.”

WPMU DEV, a shop for WordPress plugins, has a number of lite versions of its commercial plugins in the repository. It offers lite versions of its Google Maps, eCommerce, Chat, Wiki and Membership plugins, among others. In theory, these plugins should be adequate for the average WordPress user who wants the given functionality on their website, while the commercial versions are available for those who need even more functionality.

I asked James Farmer, of WPMU DEV, what he holds back for his members. “We started holding back quite a bit,” he says. “Now we hold back very little. It’s really just the extended stuff and extra support, etc, that premium users get.”

With little functionality being held back for members, I asked James why they bother including free plugins in the repository. “I suppose you could say to ‘give back,’” he says. “But really, it’s just about business: if folks get to try our plugins for free (and the WordPress.org repository is the best place to get them to do that), then a proportion of them will be keen on our full offerings… At least that’s the plan.”

Pro: Give back to the community while maintaining your business model.

Con: Have to split your support base across WordPress.org and your own website.

Complementary Plugins

Some things just work better in pairs. (Image: Martin Hartland)

Who’s doing it?

• WP Types & Views

Two new plugins on the WordPress scene are taking a different approach. Developed by OnTheGoSystems (the folks behind the popular WPML), Types is a plugin for creating custom post types, while Views is a plugin for displaying content. Drupal users will recognize similarities between Views and a certain Drupal module.

Types is free and can be found in the WordPress repository. Views, on the other hand, is a commercial plugin available through the developer’s website. Types is a fully-functional plugin, and if all you’re interested in is creating custom post types and taxonomies and custom fields, then you might stop there. But Views is used to display the content in complex ways by querying the WordPress database for you. And, of course, the Types readme.txt tells you all about what you can do with Views, to tempt you into grabbing the complementary commercial plugin.

OnTheGoSystems developed Types and Views hand in hand, and it markets them that way, too. Views needs Types to create content, and Types is made better when Views displays it. A synergy between the two fuels the business model. “Types complements Views,” says Amir Helzer, CEO of OnTheGoSystems, “by making it easy to create and manage custom data. Marketing 101 says that when you want to promote your product, you work to turn its complements into commodities. This is what Types does. It makes creating of custom data into a non-issue, so that people can concentrate on its display (via Views).”

Pro: Exploit a ready-made market for your commercial plugin.

Con: The market might decide that it only wants your free plugin.

Offer Commercial Themes

There’s big business in WordPress e-commerce. (Image: Thristian)

Who’s doing it?

• WooThemes

The plugin directory isn’t being used just by commercial plugin developers. If you run a successful commercial theme shop, then it’s perfectly within your power to give away a functional WordPress plugin for free, dedicate a team of developers to it, and then let the money roll in as people look for commercial themes to power your plugin. That’s what WooThemes has done with WooCommerce.

You can get WooCommerce from the WordPress repository for free; and with more than 30,000 downloads since launch, it’s proving to be a pretty popular e-commerce solution. What it’s really got going for it, though, is the large collection of dedicated e-commerce themes that work with the plugin.

While already successful as a commercial theme shop, WooThemes was keen to test its legs in the freemium waters. E-commerce seems like a perfect fit for it: free core functionality, while charging for design. I asked Adii Pienaar, WooThemes’ founder, what effect WooCommerce has had on its business. He says, “WooCommerce has been quite a diversification for us on two fronts. First, it diversifies our revenue models and allows us to include the freemium model, which means a higher volume of users. Secondly, it has added a whole new class of products to our offering. To that extent, we’ve already seen a bump in our overall revenue, and our WooCommerce-related revenues are already establishing themselves as a firm chunk of that pie.”

To follow this model, Adii suggests that you develop a great core product and then monetize add-ons to that core. Because the core is free, you get high-volume adoption, and you need only monetize a certain percentage of it to be profitable.

Pro: Great way to expand your current market.

Con: Works best if you’re already backed by a strong brand.

Installation And Set-Up Services

Everyone needs a bit of help sometimes. (Image: Carol Browne)

Who’s doing it?

• s2Member

s2Member is powerful membership plugin. In fact, it’s so powerful that a dedicated installation service runs alongside it. Simplicity in a plugin is always a bonus, but out of necessity some plugins end up being seriously complex. That isn’t a bad thing, but it can get confusing for less advanced WordPress users. From my own experience, membership plugins can be extensive and pretty difficult for users to set up.

A great way to monetize a plugin like this is to offer an installation service alongside it. To set up s2Member, you can employ s2Installs. This is the team of developers behind s2Members, and they can install and set it up for you, as well as provide custom coding to extend the plugin to fit your needs. What better way to set up and extend a plugin than by employing its own developers to do it?

This is a really good model in which everyone can access the plugin for free, while commercial help is available for people who aren’t able to use the plugin to its full extent.

Pro: You are the best person to provide set-up, installation and customization of your plugin, so capitalize on it!

Con: Only works with big plugins. Might not work so well with your Google +1 button.

Is It Really Worth It?

Now that we’ve looked at some of the models, you might be wondering if this is actually worth it. Many commercial plugin developers, including those of popular plugins such as Gravity Forms, don’t adopt the freemium model and yet are still incredibly successful. In fact, a number of the plugin developers I spoke with said that the amount of traffic they get from the repository is minimal, not to mention other developers who don’t want a whole lot to do with WordPress.org. Some feel that the tightrope that has been set up for commercial plugin developers who want to use the repository is too precarious and not something they want to put effort into. Commercial themes are supported on WordPress.org, but there is nothing similar for plugin developers. Most of the developers I spoke with felt that a commercial plugin page will probably never appear on WordPress.org.

That said, if you are going down the freemium route, then using the WordPress repository is definitely a viable option, provided that you do actually use GPLv2 and provide some kind of useful service. The WordPress plugin directory will always be the best way to get your product into WordPress’ back end.

Like everything, the WordPress plugin directory has its upsides and downsides, and it’s not a one-size-fits-all solution. But in addition to directly promoting your product and services, having a plugin in the repository has a load of indirect benefits:

• Self-promotion and branding
  You might not be making a living off of your plugin, but you will be making a living off of yourself. A great example of this is Yoast, which is available for free in the plugin directory; while its developer doesn’t make any money from it directly, his business is built on his SEO expertise.
• Networking
  Having a plugin in the directory helps you to connect with other people in the WordPress community. People will be like, “Oh, you’re the guy who made that plugin. I love that!” The more popular your plugin, the more people will be interested in you.
• Custom work
  Offering a plugin means that someone out there might want your plugin to be customized, and they might be willing to pay for it.
• Job leads and opportunities
  You never know who is looking in the repository. Some big-wig might love your plugin and could be hiring. You could also use it as part of your CV, letting potential employers check out your code before even getting shortlisted.
• Kudos
  Everyone loves a plugin developer — and if they don’t, they should!
• Giving back
  Part of being a member of an open-source community is finding a way to give back. After all, we get the software that we build our livelihoods on for free. A free plugin in the directory is a great way to give back, especially if it’s a good one!

Of course, it’s not all happiness and sparkles. There are some aspects to having a plugin in the repository that put some developers off:

• Double the support
  If you offer support on your own website, too, then you’ll have to keep on top of two support forums.
• Unreasonable support expectations
  It’s sad, but some WordPress users feel that developers who give their plugins away for free should be at the beck and call of users. This leads to flaming in forums, hostile emails, angry tweets and the occasional midnight phone call.
• Keeping up with WordPress
  WordPress has a fast development cycle, with around two to three major releases a year (along with security updates and the like). Maintaining a plugin can become quite a chore, as is apparent from all of the orphaned plugins in the repository.
• #17 in the “Detailed Plugin Guidelines”
  This states that WordPress.org can revise the guidelines and arbitrarily disable or remove plugins whenever it feels like it. This arbitrariness does put people off.

A Commercial Plugin Shop?

It has long been fabled that Automattic might create some sort of WordPress app store where commercial plugin developers can sell their plugins to users straight from the WordPress dashboard. This will likely remain a fable, with no whisper from Automattic that anything of the sort is planned. Of course, there are places where you can purchase commercial WordPress plugins, such as WPPlugins and Code Canyon, but neither of these has the advantage of delivering plugins directly from the WordPress dashboard.

PlugPress tried a different approach. It created an “app store” plugin that WordPress users could install from the WordPress directory and then use to browse commercial plugins and themes. It uploaded the plugin to the WordPress repository and announced that it was live, and then the plugin was removed.

It’s a pretty clear signal that this type of store plugin won’t be allowed in the WordPress repository.

Amir Helzer (who we met earlier) has another approach. He posted a few months ago on the WPML blog about an alternative repository for commercial plugins and themes. His premise is similar to the approach taken in the Linux world. Every theme and plugin author can become their own repository. So Theme Forest could have a repository, as could Mojo Themes, as could whoever else. A central plugin would enable WordPress users to select commercial sources from which to search for themes or plugins. This would essentially make commercial plugins available in the dashboard and enable people to easily upgrade. It’s a novel idea, but given PlugPress’ swift exit from the repository, you won’t be seeing this in the WordPress directory anytime soon.

Conclusion

I firmly believe that placing restrictions on something spurs greater creativity, and the models above demonstrate how commercial plugin developers are thinking outside the box to use a directory that is essentially for free plugins. If it were simply a matter of a WordPress app store, then all of us would be in danger of buying plugins that aren’t very good (Apple’s App Store, anyone?). Plugin developers think creatively, which can only be a good thing for end users. Astute plugin developers will always find ways to use the WordPress plugin repository to promote their products, and I hope that their plugins are the better for it.

Developers are undoubtedly creating synergy between their commercial products and the repository in other ways. If you know of any, we’d love to hear about them in the comments!

Further Resources

• Looking for a service to sell your plugins? Try WPPlugins or Code Canyon.
• “Plugin Repository and Commercial Plugins,” WordPress Tavern
  A discussion about commercial plugins in the repository.
• “How to Improve Your WordPress Plugin’s Readme.txt,” Siobhan McKeown
  An article by me, right here on Smashing Magazine.

(al)