Tag: kranthi
A Pixel Identity Crisis
Resolution Independence With SVG
 |
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:
- 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.
- 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.
- 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-imageis 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-sizeis 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-positionof 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)
© dbushell for Smashing Magazine, 2012.
How Commercial Plugin Developers Are Using The WordPress Repository
|
|
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 version 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 Jacquith 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?
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 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?
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?
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?
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 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)
© Siobhan McKeown for Smashing Magazine, 2012.
Inclusive Design
|
|
We’ve come a long way since the days of the first Macintosh and the introduction of graphical user interfaces, going from monochrome colors to millions, from estranged mice to intuitive touchscreens, from scroll bars to pinch, zoom, flick and pan. But while hardware, software and the people who use technology have all advanced dramatically over the past two decades, our approach to designing interfaces has not. Advanced technology is not just indistinguishable from magic (as Arthur C. Clarke said); it also empowers us and becomes a transparent part of our lives. While our software products have definitely empowered us tremendously, the ways by which we let interfaces integrate with our lives has remained stagnant for all these years.
In the accessibility industry, the word “inclusive� is relatively commonplace; but inclusive design principles should not be reserved for the realm of accessibility alone, because they apply to many more people than “just� the lesser-abled. Interface designers frequently think in binary terms: either all of the interface is in front of you or none of it is. But people are not binary. People aren’t either fully disabled or not at all, just like they aren’t merely old or young, dumb or smart, tall or short. People sit along a vast spectrum of who they are and what they are like; the same is true when they use interfaces, except that this spectrum is of expertise, familiarity, skill, expectations and so on.
So, why do we keep creating interfaces that ignore all of this? It’s time for us to get rid of these binary propositions!
What Is “Inclusive� In The World At Large?
In the world at large — meaning not one particular industry, country or demographic — the term “inclusive� applies to cultures in which, for example, women are as welcome to contribute their opinion as men are; in which a person’s race or sexual orientation has no bearing on their acceptance by a group; in which everyone feels safe and comfortable, and no one feels suppressed, stymied or silenced; in other words, a culture of equal opportunity. But when we apply the term to interfaces, it doesn’t mean that interfaces should be equal for everyone; rather, it means that they should be equally accessible to everyone, and equally empowering no matter what the user’s skill level or familiarity. When these two aspects are combined, the product gets the best of both worlds: it is accessible to more people, without being compromised for advanced users.
Super Mario Bros. was accessible to play for anyone, and fun (and sometimes frustrating) for all.
An excellent example of software that has done this well is in the video game genre, going back as far as 1985 with Nintendo’s Super Mario Bros. It was a game that truly anyone could pick up and play, with an invisible interface that taught you everything you needed to know to get started and become good at it. The screen would only scroll right, so you couldn’t walk left. You could jump, but standing on top of special bricks did nothing, so you would try to jump against them from below. Pipes visibly led down, so you’d try your luck with the down arrow on the direction pad. And at the end of the level, the bonus flag was raised high, encouraging competitive players to jump to the very peak for top points. All of the game’s mechanics were explained in one level, without a single instruction, tutorial or guiding word.
Many games since 1985 have not featured this principle to any significant degree. Super Mario Bros. truly was a game whose interface was equally empowering; meaning, the interface and product magnified the results of your efforts based on the (skill) level of your input. Put differently, beginners would see good results from their efforts, while advanced users would see far greater results from theirs. These principles aren’t limited to video game design either; they apply just as much to software applications and productivity tools, even websites! So, let’s start with some simple inclusive design concepts.
Language And Aesthetics
Language has an impact on everything, because it is the primary way we communicate as a species. Its significance is also frequently overlooked; a Duke University study revealed that gendered language in job listings affects a job’s appeal, independent of the type of job. There’s more: while not a single participant in the study picked up on the gendered language, each of them did find the listings more or less appealing as a result. This raises the question: how much of an impact does the language chosen for our designs have on the number of new users who sign up or the number of customers we convince to purchase our products? No good study in this area seems to exist or be readily available, but one study (of a sort) that is available is the W3C’s own resource on people’s names around the world and its effect on form design. Let’s call it a good start and do more research into how language shapes the Web.
But language is just one metric that we don’t take into consideration as often as we should. Aesthetics play a significant role as well, yet there is a lot more to aesthetics than taste and general appeal. The placement of elements, whether shapes are angular or rounded, and our use of color all affect how different genders, demographics and cultures respond to interfaces. Because no one color scheme will please everyone all the world over, the more international our (targeted) audiences are, the more fully designed our localizations will need to be.
Interface Design Legacies
In the world of interface design, being inclusive means being accepting and welcoming of the many different cognitive skills and levels of expertise among users. Historically, we have striven for the perfect middle ground between approachable and empowering. Making interfaces more intuitive plays a significant role in that process, but it often demands that we dumb interfaces down (i.e. remove features), which can be undesirable for the advanced user who wants more functionality or control. With more comprehensive interfaces, a frequent “solution� to this problem is to allow users to customize the interface to their needs. But is this truly empowering? When research shows that less than 5% of people adjust default settings, it is highly questionable whether customization and settings are truly empowering in interfaces.
Earlier, I mentioned how most interfaces offer a binary proposition: either the application is open or it isn’t. When it’s open, the entire user interface (UI) is typically available to you, whether or not you need all of it. This makes sense from a historical perspective—when all we had were physical interfaces—but it makes little sense with our modern software ones, especially since most software interfaces are far more comprehensive than a typical hardware interface.
When Steve Jobs announced the iPhone at MacWorld in 2007, he compared the yet-to-be-revealed iPhone to popular smartphones of the time, noting their main problem as being “the bottom 40%� — i.e. the hardware buttons on all of those devices. The buttons were there “whether you need them or not.� The solution, according to Apple, was a large touchscreen with fully software-based UI controls. That way, each application’s interface could be optimally designed for its particular purpose.
The point Apple made along the way was that sticking to convention is a bad idea if you want to move an industry forward. Hardware buttons used to be all a phone had. Then, they were used to supplement a tiny screen. The iPhone showed that, when it comes to innovation in interfaces, the screen should be the full surface, a blank canvas onto which software could paint any interface. The unparalleled success of the iPhone suggests that Apple has proven their point well.
But as fantastic as the iPhone may have been compared to the smartphones before it, it still suffered from this same binary UI problem. The iPhone merely shifted the problem from being device-wide to being specific to individual applications, and then it masked the remaining issues by removing features or hiding them in drill-down views, until one very elegant, simplified UI remained for each app — one that lacked the ability to become more sophisticated for users who wanted, or needed, more.
To pilots, this is a familiar view. To others, it is a smörgåsbord of buttons. Image Source: Julien Haler
To be clear, removing features is not in itself a negative. Most interfaces get better from the process, because every visible feature, every UI control adds to the overall cognitive load of the user. Think, for instance, of an airplane cockpit and its countless little controls, dials and meters covering every surface. If you are not a pilot, the mere sight of it would overwhelm you. To an experienced pilot, however, it is simply what they need in order to fly the plane. Is this really the best we can do, though? Super Mario Bros. showed us we can do better.
In software, we have a situation that calls for the kind of innovation I’m talking about. As it is, more complicated, advanced and powerful applications feature more complex interfaces, and some can be downright overwhelming to first-time users. But not everyone wants to fly a plane — some of us are just trying to get some simple work done. Application developers try to alleviate this problem with tutorials, guided tours, help screens and overlays that explain each aspect of the UI; a great solution these things are not. What we need are better interfaces, interfaces that understand that we are human beings with different needs. What we need are…
Adaptive Interfaces
For interface designers with an eye on accessibility, most of their efforts have long focused on the technical challenges faced by users. Many commentators have encouraged us to consider cognitive (or learning) disabilities as one part of the broader area of (Web) accessibility, but rarely has anyone explained how to do this. Additionally, when someone sees the term “cognitive disability,� they understandably think of the mentally handicapped. But there is a huge range of cognitively able people, and they exist not on a linear scale: a quantum physicist might have a tough time figuring out how to use a feature phone, whereas the average teenager would have no problem with it.
People invest in an application (and, thus, its interface) in varying degrees, depending on how important the product is to their daily lives. This means that your interface should cater to varying degrees of investment in addition to differing levels of expertise and familiarity.
In an interface, each additional UI element increases complexity and asks for a deeper investment on the user’s part. This is why invisible interfaces (like the one in Super Mario) are so powerful: an interface that appears only when needed reduces the cognitive load, reduces the investment required to understand the product, and makes it easier for the user to focus on the task at hand. A button that is relevant only in certain contexts should be visible only in those contexts.
But we can take this principle to a level even beyond that. An interface that is truly inclusive of all kinds of users is one that begins with only the fundamentals and then evolves and adapts alongside the user. During this process, the interface can both grow and decay, acquiring more features and controls as the user becomes more fluent in using it, and dropping or reducing the prominence of UI controls that the user does not use much, if at all.
Doing this automatically also makes more sense than offering the user a large number of options to customize the UI, for two reasons: first, users shouldn’t be expected to spend a lot of time making an interface usable to them; secondly, people might not always know exactly what they want, but their behavior might make clear what they need. A system that intelligently measures what the user needs in order to deliver the most efficient, effective yet still understandable interface could allow such a thing. A highly effective interface is one that can be changed not to how each user wants it, but to how each user needs it.
Of course, measuring the cognitive skill of a user is difficult, and even then it can only be approximated. Certain aspects of the user’s behavior can be measured, which helps to inform us about how familiar the user is with the interface overall and how fluent they are in using it. The speed with which a user navigates an interface and uses or explores its features is a good metric for how comfortable they are with the interface. The frequency of their use of “Help� and “Undo� features suggests a certain confidence level. Users of keyboard shortcuts are almost certainly looking for more powerful features, and someone who uses quotes and AND and OR in their search queries is likely technically minded. These and many other measurable aspects of people’s behavior can help shape your application’s interface, which can then be adapted to better suit the needs of users.
The Nest thermostat learns from you.
This is not the end of the story; rather, it is only the beginning. Tony Fadell’s new product, Nest, is a great example of an adaptive interface in the real world. The Nest Thermostat learns from your behavior patterns as you go about your daily and weekly routines, and it becomes predictive, so that you need to adjust the thermostat less frequently the more you use it.
That’s but one example. The possibilities open up even more with inclusive and adaptive interfaces. One type of user might need Feature A very frequently, whereas another might need Feature B instead; a truly inclusive interface would adapt to these needs and be equally powerful for these two different types of users.
Conclusion
We’ve overcome the various technical challenges of interfaces and designs through Web standards, accessibility and ARIA, responsive Web design principles and touchscreen devices. But we have focused so much on these technical challenges that we’ve almost lost sight of innovating the human aspects of interface and design. The next stage of evolution for our industry is to explore how to make our applications and products more inclusive, taking into account the vast spectrum of differences in our audience, and to make our interfaces smarter so that they serve a wider range of people more effectively. Let our exploration of inclusive design begin!
(al) (il)
© Faruk Ates for Smashing Magazine, 2012.
It Works For “You”: A User-Centric Guideline To Product Pages
|
|
Product pages for e-commerce websites are often rife with ambitions: recreate the brick-and-mortar shopping experience, provide users with every last drop of product information, build a brand persona, establish a seamless check-out process.
As the “strong link in any conversion,� product pages have so much potential. We can create user-centric descriptions and layouts that are downright appropriate in their effectiveness: as Erin Kissane says, “offering [users] precisely what they need, exactly when they need it, and in just the right form.�
Beyond that, a user-centered creation process for product pages can help brand the information as well as reduce the content clutter that so often bogs down retail websites.
User-centric product copy garners positive results because it anticipates the user’s immediate reaction. As Dr. Timo Saari and Dr. Marko Turpeinen, authors of “Towards Psychological Customization of Information for Individuals and Social Groupsâ€� suggest, individual differences in processing information implicates dramatic variances in type and/or intensity of psychological effects, such as positive emotion, persuasion, and depth of learning (2).
We can describe products in various ways. Highlighting certain aspects of a product will elicit different reactions from various users. Gearing product descriptions to a particular audience encourages those users to effectively process the information, heightens persuasion, and increases the potential to predict what the users want (but didn’t know they needed). The effort required of user-centric product descriptions demands that we understand how certain descriptors, contexts and inclusions of details affect the target user, and that we then put our discoveries into action.
This article offers a user-centric guide to producing product pages and provides examples of successful e-commerce websites that present user-centric approaches to product page descriptions and layouts.
Get To Know Your User
Approaching product page description and layout from a user-centric perspective demands that we have a rich understanding of the target user. As Saari and Turpeinen suggest, Web customization starts with some type of model, be it individual, group or community. With your user models in place, you can best assess what they need and how to write for them.
In her book Letting Go of the Words, Web usability expert Janice Redish suggests these strategies for getting to know your target user:
- Scope the email responses that come through the website’s “Contact Us” form and other feedback links. Consider the profiles of the senders. You can discover commonalities in lifestyle, technological capability, education level and communication preference through these channels.
- Talk to the customer service or marketing employees at your company. Don’t approach them with a broad demand to describe the typical client. Rather, ask questions about their interactions with clients. Who is calling in? Who is stopping by the office? What queries and complaints are common?
- Offer short questionnaires to visitors to the website. Redish suggests asking people “a few questions about themselves, why they came to the site, and whether they were successful in finding what they came for.”
- If possible, acquire a sense of the client simply by observing the people who walk through the front doors of the business. This is a great way to pick up on key phrases, jargon, emotional behavior and demographics.
Once you’re able to confidently brainstorm the major characteristics of your target user or group, then developing the models to guide the writing process comes next.
Keep in mind that gathering and compiling this information can take as little or as big an investment of time and money as you (or the client) can afford and still be effective. As Leonard Souza recently noted, even stopping in a nearby coffee shop to engage five to ten people in your target demographic can yield useful insight. With a bit of flexibility, you can find learning opportunities that are convenient and on the cheap.
The models created from your user research can be fashioned into personas, which Souza describes as “tools for creating empathy among everyone in the project.” Use personas to guide user-centric copywriting by establishing very specific user goals and preferences.
A persona is a fictional person amalgamated from the characteristics of your target user. You can get creative here with the persona’s name and image, but not too creative. The persona must be mindfully constructed according to the age, education, family status and other personal details culled from your research.
Now that you have a persona to please as you construct a product description and layout hierarchy, staying user-centric is that much easier. Take a look at the product description from Lululemon, a British Columbia-based yoga-wear retailer:
Product description from Shop.lululemon.com
The product description assumes that the reader knows a specific set of jargon: How many non-yoga participants would know what downward-dog means? Or “pipes�, as the “Key Features� section refers to arms? This content drives right to the needs and preferences of a very specific user. She wants warmth (four of the “Key Features� note the thermal quality of the product), convenience (pre-shrunk fabric, easy layering), and motivation for an active lifestyle (she recognizes the yoga jargon and enjoys giving her “pipes some air time�).
A rich understanding of the user has made this product page effective and delightfully specific to both the user and the brand.
Master S.M.A.R.T. Content and Layout
Without specific, measurable, actionable, relevant and trackable user goals driving the copy on the product page, the information will sag. I draw here from Dickson Fong’s enlightening article “The S.M.A.R.T. User Experience Strategy“ to suggest that care should be taken to develop user goals that guide the writing process for product pages.
The S.M.A.R.T. formula will keep you on track as you plot out product details and decide what descriptive angle to use.
Fong provides an excellent user goal for a product page: “I want to learn more about this product’s design, features and specifications to determine whether it fits my budget, needs and preferences.�
This will help you create a checklist when assessing what to present first and what to offer as optional information when structuring the layout of the page (more about that in the “Create Information Hierarchies� section below). It provides direction when you’re writing content and helps you focus on the benefits to the user. And as Darlene Maciuba-Koppel suggests in The Web Writer’s Guide, “In copywriting, your end goal is to sell benefits, not products, in your copy.�
For users, benefits and accomplished goals go hand in hand. A product that doesn’t fit their budget, needs or preferences offers them little benefit. So, in order for S.M.A.R.T. goal-driven product pages to serve user-centric purposes, the text must follow suit. Fong suggests presenting relevant content details that are specific to the consumer of that product type.
Let’s take Fong’s S.M.A.R.T. user goal for product pages and assess the specifications at play on the following two pages from Dell:
Product page for Alienware on Dell.com
Featured on Alienware, Dell’s computer subsidiary for high-performance gaming, the description for this desktop computer has been tailored to the primary browsing goal of a very specific user. The needs and preferences of the user have already been predicted in the bullet-point outline, highlighting optimum graphics and top-notch liquid-cooling capabilities, thus harmonizing the checklist of features with a checklist of benefits for the user. A number of the product’s features could have been highlighted, but for optimal ease, the specifics most likely to help the user accomplish their goals are featured.
With the next Dell desktop computer, another goal of the target user is covered in the description:
Product page description for Inspiron 570 on Dell.com
With a noticeable absence of technical details and a heavy emphasis on product personalization, this description plays to a user with very different needs than the Alienware shopper’s. Even the tabs have been re-arranged to best meet the user’s goals. The Inspiron 570 page shows “Customer ratings� as the first tab, while the Alienware page offers “Design� first and then “Tech specs.�
These decisions are all geared to accomplishing very specific user goals: find the required information and assess the benefits.
Use Personal Pronouns
Consider again Dell’s description of its Inspiron 570:
Make It Yours
The Inspiron 570 desktop is everything you want and nothing you don’t. Available in vibrant colors, so you can complement your style or stand out from the crowd. Plus, you can build your desktop according to your needs with a choice of multiple AMD processors and NVIDIA ATI graphics cards as well as other customizable features. So whether you are surfing the Web, emailing friends and family, downloading music and photos or blogging about it all, the Inspiron 570 desktop can handle it.
Your wants, your style, your needs, your friends and your Internet past-times. Including the title, eight instances of “you� or “your� turn up in this 86-word segment!
Personal pronouns in product descriptions are perfectly appropriate and quite effective at engaging users, because, as Redish states, “People are much more likely to take in [messages] if you write with ‘you’ because they can see themselves in the text.â€�
With Dell’s content, the personal pronouns target a specific user (one who is savvy enough to download music and email and who is interested in customization and feeling unique), while also managing a broad gender appeal.
Outdoor equipment retailer REI employs personal pronouns in its online product descriptions, creating dynamic scenarios aimed at a specific user:
Product description for REI.com
The description asserts that this canoe will help you navigate a waterway that “you’ve recently noticed,� anticipating a specific user reality (or dream).
The product showcase is devoted to the user’s needs and showing how the user will benefit from purchasing the canoe. Using “you� is the clearest and most direct way for this retailer to grab the user’s attention and to convince them, at any time of the year, that this canoe is the right buy.
Angie King backs this up in her article “Personal Pronouns: It’s Okay to Own Your Web Copy.� She suggests that using first- and second-person pronouns helps users connect with the content, and “reflect[s] the way real people write and speak,� fostering an immediate connection.
For a product description to speak directly to a specific user or group, the “you’s� should flow freely.
Use Information Hierarchies
Adopting a user-centric approach to the layout and copy of product pages helps you tackle the challenge articulated by Kean Richmond: “How do you cram so much information into a single Web page?�
In addition to technical specifications, shipping information, item details and preference options (and don’t forget that compelling product description), product pages must also list every describable service that the product performs for its user, including customer benefits (as Darlene Maciuba-Koppel explains, too).
By all means, provide the user with every last detail possible. Answer every conceivable question, or make the answer visible for discovery. Do so with information hierarchies that are based on a rich understanding of targeted users. This will keep each page tidy and drive users to complete your business goals.
In a structure in which, as Kean Richmond states, “all the important information is at the top and [the rest] flows naturally down the page,� details that might not be a top priority for the target user can be tucked into optional tabs or presented at the bottom of the page. The key is to gauge the structure of the page with the sensibilities of the targeted user in mind.
Look At User Context
Here’s where you become a mind-reader of sorts. Erin Kissane points to the approach of content strategist Daniel Eizan in understanding what specific users need to see on the page in order to be drawn into the information. Eizan looks at the user’s context to gauge their Web-browsing behaviors. Eizan asks, What are they doing? How are they feeling? What are they capable of?
Establishing user context aids in planning an information hierarchy, and it is demonstrated by small and large e-retailers. On the big-box side, we have Walmart:
By making the price and product name (including the unit number per order) immediately visible, Walmart has anticipated a possible user context. A Walmart visitor searching for granola bars has perhaps purchased the product before. With the unit price made visible, perhaps the anticipated user is judging the product based on whether this box size will suffice.
Details such as “Item description� and “Specifications� are options that are convenient to the user who is making a large order of a familiar product.
The user’s context shapes the hierarchy: the user seeks a quick calculation of units per product versus price. The targeted user does not immediately need an ingredients list, allergy information or a description of the flavor. But if they do, they are available in a neat options-based format.
Walmart has built its reputation on “Everyday low prices,� and the brick-and-mortar philosophy has crossed over to its website. Walmart anticipates users who have some familiarity with its products and who have expectations of certain price points. These factors play into the information hierarchy across the website.
Now look at the product page of a different kind of retailer, nutrition bar manufacturer Larabar:
Cashew Cookie product page from Larabar.com
Here is an online presentation of a retail product that is similar to Walmart’s Nature Valley granola bar (though some might argue otherwise). However, the information hierarchy clearly speaks to a different user — a specific user, one who might be looking for gluten-free snack foods or a vegan protein solution. The Larabar user’s context is much less urgent than the Walmart user’s. The product page does not reveal pricing or unit number. Ingredients are visible here, with simple images that (when scrolled over) provide additional nutritional information.
The anticipated user has more time to peruse, to browse several varieties of product, and to read the delightful descriptions that help them imagine the tastes and textures of the bars.
This user might be very much like the targeted Walmart user but is likely visiting the Larabar website in a different context. This product page offers more immediate information on nutrition and taste, selling to a user who is perhaps hunting for a solution to a dietary restriction or for a healthy snack alternative.
However, the red-boxed “Buy Now� is positioned in a memorable, convenient spot on the page, leaving no guessing for the user, who, after reading a description of this healthy bar full of “rich and creamy flavor,� will likely click it to find out the purchasing options.
With these two pages for (arguably) similar products, we see two completely different ways to structure product details.
Both are effective — for their targeted users. A person seeking gluten-free snacks for a camping trip might be frustrated having to search through the hundreds of granola bar options on Walmart’s website. But they wouldn’t be going there in the first place; they would use a search engine and would find Larabar.
Information hierarchy solves the content-overload challenge that can overshadow the process of constructing a product page, and it is an opportunity to bolster user-centric copy and layout. As mentioned, the key is to gauge the user’s context.
Conclusion
While a user-centric consideration of product pages is not the only way to go, it does provide a focused approach that has appeared to be effective for some pretty successful e-commerce players. Consistency in product pages is key, especially when building a brand’s presence; a reliable guide can ease the writing process. The user-centric method does require some primary research, but this lays a sturdy foundation by which to gauge every bit of content on the page according to how it benefits the user.
As Maciuba-Koppel says, as a content writer or designer, your goal should not be to sell products, but to sell benefits.
Now watch the conversions multiply.
(al) (fi)
References
- Writing for the Web: Creating Compelling Web Content Using Words, Pictures And Sound Lynda Felder (New Riders: 2011)
- “The S.M.A.R.T. User Experience Strategy� Dickson Fong (Smashing Magazine)
- “Personal pronouns: It’s okay to own your Web copy� Angie King (Brain Traffic)
- “A Checklist for Content Work� Erin Kissane (A List Apart)
- “Writing Copy that Works for a Living� Erin Kissane (A List Apart)
- The web-writer’s guideDarlene Maciuba-Koppel (FocaPress: 2004)
- “Letting Go Of The Words�: Writing Web Content that Works. Janice Redish (Morgan Kaufman Publishers)
- “Anatomy of an Effective Product Page Design� Kean Richmond (Six Revisions)
© Sarah Bauer for Smashing Magazine, 2012.