You’ll find mobile-interface-like toggle switches in various places around the web but I wanted to improve existing examples.

Specifically, I wanted a solution which:

1. progressively enhanced standard checkboxes
2. did not use superfluous HTML tags or attributes
3. supported input labels
4. used only CSS without images or JavaScript
5. used relative units so the controls are resizable/responsive
6. had some slick animation
7. ideally worked in a range of mobile browsers, and
8. degraded gracefully so it remained usable in all browsers

View the demonstration page and the HTML/CSS code…

The HTML

We require a input checkbox and a label:

<div>
	<input type="checkbox" id="switch1" name="switch1" class="switch" />
	<label for="switch1">first switch</label>
</div>

The input has a class of “switch” assigned. This ensures we can retain normal checkboxes should we need them.

HTML purists will be horrified to see a wrapper div but it’s only necessary if you require two or more toggle switches — you cannot have more than one switch (or further labels) in the the same parent container. Besides, you’ll probably need div wrappers to separate form elements anyway.

The HTML will render well in most browsers with minimal styling. IE6, 7 and 8 users will see this:

The CSS

Now for the interesting part. First, we’ll hide the input box using a negative margin — this can be preferable to display:none which often disables it on mobile devices:

input.switch:empty
{
	margin-left: -999px;
}

You may have seen the :empty selector used in my recent post, How to Create a Responsive Centered Image in CSS3. It only matches elements which have no children but, since it’s not supported in IE8 and below, those browsers won’t attempt to apply the styles.

Next, we’ll style the sibling labels of the input checkbox:

input.switch:empty ~ label
{
	position: relative;
	float: left;
	line-height: 1.6em;
	text-indent: 4em;
	margin: 0.2em 0;
	cursor: pointer;
	-webkit-user-select: none;
	-moz-user-select: none;
	-ms-user-select: none;
	user-select: none;
}

The main properties to note are position:relative, the text-indent which provides room for our switch, and the line-height which defines its height.

The toggle itself is created using :before and :after pseudo-elements for the colored background and the white switch accordingly:

• both elements are absolutely positioned at the left-hand edge of our label
• the white switch is set to a smaller size and has a left margin applied to align it on the background
• a border-radius and inset box-shadow is applied to give some depth, and
• a transition is defined for the animation.

input.switch:empty ~ label:before,
input.switch:empty ~ label:after
{
	position: absolute;
	display: block;
	top: 0;
	bottom: 0;
	left: 0;
	content: ' ';
	width: 3.6em;
	background-color: #c33;
	border-radius: 0.3em;
	box-shadow: inset 0 0.2em 0 rgba(0,0,0,0.3);
	-webkit-transition: all 100ms ease-in;
	transition: all 100ms ease-in;
}
input.switch:empty ~ label:after
{
	width: 1.4em;
	top: 0.1em;
	bottom: 0.1em;
	margin-left: 0.1em;
	background-color: #fff;
	border-radius: 0.15em;
	box-shadow: inset 0 -0.2em 0 rgba(0,0,0,0.2);
}

Finally, when the checkbox is checked, we move the switch to the right-hand edge and change the background color:

input.switch:checked ~ label:before
{
	background-color: #393;
}
input.switch:checked ~ label:after
{
	margin-left: 2em;
}

View the demonstration page and the HTML/CSS code…

Everyone likes a toggle switch! Please use the code however you like. A link back to this article or a “hey Craig, that’s awesome/awful” tweet is appreciated.

An interesting point was raised by Brendan Davis in my recent post “Responsive Web Design and Scrollbars: Is Chrome’s Implementation Better?”: are RWD breakpoints affected by high pixel-density screens?

The short answer is: no — but we need to delve a little deeper and look at the problems they can cause.

What is Retina?

“Retina” is Apple’s brand name for double-density screens but other manufacturers are creating similar displays. The technology is used in recent iPhones, iPads, MacBook Pros and other high-end devices.

For example, the MacBook Pro 15″ has a resolution of 2,880×1,800 or 220 pixels per inch. At this scale, most people are unable to notice individual pixels at typical viewing distances — applications and websites would be too small to use.

Therefore, the device reverts to a standard resolution of 1,440×900 but the additional pixels can be used to make fonts and graphics appear smoother.

What’s the Problem?

Standard-resolution bitmap images can look blocky on a Retina display. A 400 x 300 photograph is scaled to 800 x 600 pixels but there’s no additional detail. This can be noticeable when compared to smooth fonts and other high-resolution images.

Real-World Usage

If you look around the web, you’d be forgiven for thinking everyone has a Retina display. Currently, it’s only available in high-end devices, but these are coveted by developers so it leads to a disproportionate volume of online discussion. In the real world, the percentage of people using similar displays is in low single figures.

Let’s put it into context: if you’re not developing for the 1% of IE6/7 users, you probably shouldn’t be too concerned about people using Rentina — especially since they can still view your website.

That said, Retina-like screens will eventually migrate to all devices. There’s little reason to fret now, but there’s no harm in some forward planning. Let’s look at the options in order of recommendation…

1. Use SVGs and CSS3 Effects

The clue is in the name but Scalable Vector Graphics are … scalable! It doesn’t matter how big an SVG becomes — it will always be smooth because it’s defined using vectors (lines and shapes) rather than individual pixels.

SVG is not practical for photographs but is ideal for logos, diagrams and charts. The primary drawback is a lack of support in IE8 and below but you could always provide a PNG fallback or use a shim such as Raphaël or svgweb. See also: How to Add Scalable Vector Graphics to Your Web Page.

You may also be able to replace some images entirely. For example, titles, gradients, corners or shadows defined as graphics can be reproduced using CSS3 alone. They will render at a better quality, result in fewer HTTP requests and use less bandwidth.

2. Use Webfonts Icons

The more I use webfonts icons, the more I love them. Like SVGs, fonts are vectors so they’re scalable so you can use font sets which contain icons. They’re ideal for small, frequently used shapes such as email envelopes, telephones, widget controls and social media logos. They also work in every browser including IE6+.

There are plenty of commercial and free icon font sets available:

• Typicons
• Font Awesome
• Iconic
• Foundation

Or you can use a hosted font service such as We Love Icon Fonts.

I recommend creating your own small set of custom icons using online tools such as Fontello or IcoMoon.

3. Use High-Resolution Images When Practical

Retina has four times more pixels than standard screens. If you have a 400 x 300 image (120,000 pixels), you’d need to use an 800 x 600 alternative (480,000 pixels) to render it well on a high-density display.

However, the high-resolution file size may not necessarily be four times larger. Every image is different but if it contains solid blocks of color or details which can be omitted, it may be practical to use a 800 x 600 image and scale it in the browser.

Be pragmatic: if the standard image is 200Kb and the high-resolution version is 250Kb, there is negligible benefit using image replacement techniques. Use the better version throughout.

4. Use CSS Image Replacement

There will be times when high-resolution versions of your image are four times larger — or more. In those circumstances you may want to consider image replacement techniques, i.e. the standard image is replaced by larger alternative on Retina displays. The following media query code could be used:

#myimage {
	width: 400px;
	height: 300px;
	background: url(lo-res.jpg) 0 0 no-repeat;
}
@media
screen and (-webkit-min-device-pixel-ratio: 1.5),
screen and (-moz-min-device-pixel-ratio: 1.5),
screen and (min-device-pixel-ratio: 1.5) {
	#myimage {
		background-image: url(hi-res.jpg);
	}
}

The drawbacks:

1. You will need to create and maintain two sets of images.
2. Some browsers will download both images.

Remember that many of these users will be using smartphones or tablets on slower mobile networks. Detecting the connection speed would be more beneficial than determining the pixel density.

5. Use JavaScript Image Replacement

Retina display detection can be implemented using the following code:

var isRetina = (
	window.devicePixelRatio > 1 ||
	(window.matchMedia && window.matchMedia("(-webkit-min-device-pixel-ratio: 1.5),(-moz-min-device-pixel-ratio: 1.5),(min-device-pixel-ratio: 1.5)").matches)
);

Once a Retina display is determined, you could:

1. Loop through all page images and extract the URL.
2. Append ‘@2x’ to the file name and attempt to load the resulting image URL using Ajax.
3. If found, replace the current image with the high-resolution alternative.

Fortunately, the hard work’s been done for you at retinajs.com. While it only adds 4Kb weight, high-density display devices will download images twice — although the second time will occur as a background process after the page has loaded.

My advice: be practical and keep it simple. Don’t spend inordinate amounts of time attempting to solve minor rendering problems on devices with proportionally few users. Of course, none of that matters when your boss receives his new iPad and starts to complain about image quality…

How’s your site’s bounce rate? How many of the people who downloaded your app ever actually use it? What’s the comment rate like on your company blog?

If your answers to these questions are less than stellar, you might have a problem.

A problem with words.

The hidden hurdle

Every one of us can string a sentence together. In many cases online, sentences aren’t even needed: we can all type “Buy now” or “Log in” onto a button or “Click here” into a link.

When most people think of web writing, they think of long copy for informational pages, ebooks and emails.

What they don’t consider is interface text.

Interface text is the words that tell people what to do on your pages: what your site or app does, and how they can access those features. Think: orientating sentences, descriptive text, links, buttons, menus and labels.

Text directly influences the interactivity, functionality and usability of interfaces. I’d go so far as to say it’s as important as design.

Don’t believe me? Well, let’s take my theory for a spin.

See for yourself

If there’s one thing the web is great for, it’s setting a trend. Just as there are trends in design and development, there are trends in interface text.

One example is the humble Get Started button. Ten years ago, Get Started wasn’t a popular CTA—people were still focused on Click Here and Buy Now.

But today, Get Started is the go, particularly as a call to action for what the press loves to call “disruptive” online services—Learnable and 99designs are just two examples.

However, as Tweaky recently discovered, even a straigthtforward, concise Get Started CTA isn’t necessarily as clear as it could be.

Following professional advice, they tweaked Tweaky.

Three out of the four changes Tweaky made to their site were text-based. They didn’t change layout, imagery or even IA. All they did was change wording in three places on the site, and increase the color contrast on the Chat tab.

Wiht regard to their primary call to action, they added a caption so users will know what happens when they click.

The results? Conversions increased by 43%.

As Tweaky found out, a few little words can make a big difference to a site’s conversions.

But that particular solution demands extra reading and attention from users. Is that the best option?

Other examples from around the web—Create your store now, Register, Create your free account, Search, Log in, Buy now—show that there’s a lot of variety in terms of common CTAs.

Which one do you want to use on your site?

Is it time you focused on the hidden hurdle?

In the coming weeks, we’ll be looking more closely at a range of interface and usability-related text issues that digital developers, designers, and entrepreneurs face—whether you realise it or not—every day.

The aim is to help you get a grip on the text-related issues that might be holding back your site, your app and, ultimately, your business.

If you have any specific questions you’d like to ask, tell us in the comments below.

Next week, we’ll see whether the way you talk about your offering is actually confusing site’s users, rather than educating (or even exciting) them. See you then.

As a person with a disability I find navigating most websites fairly straightforward. I can use the keyboard or a mouse to scroll up and down to view content. With just the space bar I can scroll the page a frame at a time.

Until my browser is hijacked by elements on the page. Then I have to use my mouse to get control of the experience.

Here are four frustrating ways websites hijack my browser.

Search Bar

Hey Google (and now Yahoo!), I’m talking to you!

I get that you want to make it easy for someone to get going on that search, but does my cursor really have to jump to the search box as soon as the page loads?!

You can set up the tab order using tabindex to take the cursor to the box on the tab click.

<input type="text" id="search" tabindex="1">

I get that Google has built this into their system and it’s the expected behavior, but it is a nuisance for people like myself who navigate with our keyboards.

First, it interrupts the browsing flow because I am unable to follow my keyboard shortcut (just backspace on most browsers) to go back a page.

Second, when I start pressing the space bar and want to scroll the page I’m just filling in the search bar. It just doesn’t work.

Confirmation Alert Box

Every now and then I’m surfing the Web and end up on a site with a confirmation box. Sometimes the box pops up on arrival, other times it pops up when I try to leave the page.

I know enough about programming to recognize an opportunity to insert malware. So I never click the confirmation. I don’t know if pressing okay will close the tab or take me to russianhotties.xxx.

My remedy is shutting down my browser then reopening it and tromping through history to the sites I had open.

Popup Ads

This one drives me crazy and I’ll wager most developers are guilty of this one.

Attractive popup ads are no longer an annoyance, but part of the business model of many websites. I’m left to watch the popup obscure my content. I get it. The company has to generate revenue. But the ad should get out of my way.

The standard was to timeout the popup years ago. Some ads creatively move to the sidebar in a static ad. Regardless of the technology, this is available functionality. Another former standard was to tie a keyboard shortcut like esc or x to a close function on the popup. But rarely do I see a popup that I don’t have to click an action item or a tiny close link in the top corner with the mouse.

Static Navbar

Finally, there’s the static navigation bar across the top of the page. Sometimes these are three or four lines tall. They are convenient, giving users easy access to site information.

But go back to scrolling.

When I tap space bar on a typical webpage the window scrolls down one frame. This is such a convenient way to quickly browse a page. As I pointed out above, hijacking my cursor gets in the way. But so do those fancy navigation bars.

Some websites account for the navbar adding padding to accommodate the bar across the top. However, plenty of popular websites are oblivious. As the content scrolls, several lines are obscured by the handy bar.

Am I Just a Curmudgeon?

Our lives as developers are already full of UX demands.

Another accommodation now from this guy who just wants to click his spacebar to scroll is not floating to the top of my list.

I get it. But imagine how all of the little tweaks you build into your workflow save you steps and then having to do away with them because somebody else just changed the way things are done. Look at recent decisions by Adobe and Google to shut down services, for example.

For people with mobility impairments, added obstacles to the content are a real barrier. Just getting a mouse cursor in the precise spot can be a chore.

But thoughtful design and graceful transitions can give the browser back to users like myself to enjoy our convenient web experience.

At the recent Web Directions South 2012 conference held in Sydney, Sara Wachter-Boettcher, an independent content strategist, gave a talk on “Getting Unstuck: Content Strategy for the Future”. Among the detailed and varied presentations on everything from responsive design to MVC to JavaScript performance patterns, here was someone keen to step back and tackle the more nebulous subject of web content — specifically, what we’re meant to be doing with it.

Content is king, right? Well, maybe. The web would certainly be one lonely place without it. But while the technologies underpinning the web evolve at a dizzying rate, attitudes to how we publish content — the stuff that actually populates our applications and sites, whether video, text, forms, widgets, whatever — hasn’t necessarily kept pace. Many of the characteristics of contemporary web publishing still glaringly show their roots in the world of print media. Skeuomorphism remains in the most common design patterns. Grids, paragraphs, captions … is it time web content grew up?

Which is where content strategy comes in. It’s a field you may or may not have heard of — and if you have, you might not grasp its nuts and bolts. What does a content strategist do? Where did the vocation originate? Maybe it’s just best to let Sara explain.

Hi Sara. Before we drill into content strategy, it might help to tell us a bit about your background, and how you got into the field.

I went to journalism school in Oregon, then worked at community newspapers writing features. Then I moved to Arizona and ended up copywriting for ad agencies, which was fun for maybe six months. I just wrote clever little one liners and somebody would hand me some money. But it got boring really quickly.

And then you got into web editing.

I learned a lot of things along the way. The first few years I talked to developers and product managers, getting closer to project work, and asked tonnes of hard questions about why things were being done the way they were being done, and why the concept of content wasn’t being included in these projects. Projects often got delayed because the client was trying to work on their content — how could we stop this happening, so that the client wasn’t left with a website containing no content? These kinds of issues kept coming up again and again.

Then, around the end of 2008, I found people were talking about this thing called content strategy. It was just emerging. Shortly after that, Kristina Halvorson wrote an article for A List Apart about it,  and all of a sudden a name was attached to the practices I’d already started to formalize. It became clear that I needed to change where I sat with an organization and how I approached things. I wormed my way into dozens of projects with a content strategy approach, and that also led me to speaking and writing about content strategy. I realised other people were struggling with the same stuff. It’s useful to know you’re not the only one struggling.

Content strategy seems to cover a broad area, and the definition of what it is seems a little hazy. Do you have a definition for it?

The trouble with content strategy is that as much as it was an emerging discipline in 2008 or so, it also wasn’t — it had been around for a long time, but really hadn’t caught on. It was a term that had been in use in a few different communities — technical communication, some elements of the web, large-scale entertainment media. It’s not so much a practice as it is a collection of practices involving the planning of content that’s going to be good for an organisation and good for its users.

Purely in an online context?

Not necessarily. The online context tends to be the most important one because it’s changing so quickly and it is clear that businesses can’t operate without the internet anymore. Businesses can stop putting out brochures, say, but they couldn’t function without a website.

I believe there was always a need for content strategy. Endemic problems kept happening on the web projects I worked on, and I heard the same stories: “We’ve built a website and the client hasn’t entered their content into a CMS yet, so we can’t build the last 25% of the project!”. There were issues about content that was never completed, or was horribly out of date, or broke the design. I think I knew it was something that always needed consideration, but the reason we weren’t considering it was because we had people in the industry who were doing more complex designs, and clients became more demanding, so completing content became really hard. Dealing with lots of content got even harder. People didn’t want to do it.

There are issues of user-generated content, issues with mobile, issues that have made content even more of a challenge than it ever was. These problems aren’t always new, they’re just more pronounced, or harder to avoid. More organizations are willing to ask for help now.

You talk a lot about a mobile-first approach. How does that apply to content strategy? When we talk responsive design, for instance, it’s a lot simpler to delineate a design strategy for mobile — breakpoints, media queries, mobile wireframing. With content it seems more amorphous.

I hear people talk about mobile content and the desire to cut everything down to micro-size, and I take issue with that, because you’re making assumptions about what people might want. My take on it is that mobile content should probably be the same as your regular content for the most part, or at least, that’s your baseline. But for a long time we put whatever the hell we felt like up on the web, and didn’t necessarily think about what was going to provide the clearest solution for users. Different departments of the same companies have been posting overlapping content all over the place, resulting in humungous corporate sites.

Mobile is an opportunity to fix a lot of that, and bring things back to what is needed in the first place — to fix sad, excessive, outdated content that we’ve allowed to fester for so long. Mobile can make you focus on what really matters. The question you have to ask is, if a mobile user doesn’t need this, then does anybody need this? Especially when you start looking at trends with how mobile usage is going to overtake desktop usage. Trying to say that there is a single mobile usecase, you’re fighting a losing battle.

How do we get clients thinking about what a mobile approach might entail, rather than simply saying: “Make me a mobile site”?

I think it’ll take some time. It wasn’t very long ago that mobile was a novelty. But people are becoming comfortable with the idea that there isn’t a mobile web — it’s just the web.

You also mention clutter in your writing — specifically, that getting rid of clutter shouldn’t just be reserved for mobile development and design, but extended to web content in general; that there’s no room for cruft on the web.

Well … the thing is, there is room for cruft on the web — I mean, you can put anything you want up there! There’s room to do it and that’s why people have done it for so long. For a long time it didn’t occur to people that they needed to pay attention to what they put up. That’s the wrong perspective: it’s only the perspective of the person who’s posting. If you take the perspective of the person who has to wade through that information and buy your product or choose your service, things gets problematic.

Just because you can, you should? That goes against any strategic endeavour an organization would be involved in. If you’re putting up content that has no purpose, who are you serving? What’s the point?

And this is where content strategists come in?

The key to a good content strategist is they’ll realise if they want to publish good content, it’s not just a matter of who’s going to fix it, it’s a matter of actually changing how content is handled for the long term.

I think one problem regarding web publishing is that the bulk of content is delivered via a handful of similar content management systems.

I think what’s shocking is that a huge amount of content is not delivered via a CMS!

Really?

Start talking to organizations and you realise that a lot of big companies are actually hand coding a lot of things. Which is surprising, yeah. I talk to a lot of clients who say they want to get structure from their content, and have authors enter content into 12 different fields, say, to achieve that. They want to use an interface where an author can edit content literally like they would on the front end of the site. The problem is, this assumes a desktop perspective — it doesn’t deal with a mobile approach, it doesn’t get authors thinking differently about their content. It makes them think about it as just “stuff they put on a page”.

The interfaces we give the public can be beautiful and pleasurable to use, and the interfaces we give to authors are generally crap. We have not spent nearly enough time trying to improve the way our CMSs work.

Are there any CMSs you prefer, or recommend?

I’ve used a lot of custom CMSs. In tems of off-the-shelf ones, I’ve used Drupal a bit. But Drupal requires customization to achieve the things you want to do with it.

I don’t make CMS recommendations because I’m not a CMS person. And anyway, I could have a personal website that runs on WordPress, but it doesn’t mean it’s going to work for every situation. People can get hung up on one solution. After my talk at Web Directions, I had somebody send me a tweet that just said: “Drupal … that is all”. I think they missed the point, because Drupal might be well and good, but it doesn’t solve all the underlying problems about what you might need your content to do.

People also get hung up on the technology part. It’s easy to put blinders on. And developers have been encouraged to have their blinders on — there’s this mentality about not bothering the dev team, that they need to focus. They do need to focus in order to code — I get that. But that doesn’t mean they can’t be part of the decision making. It doesn’t mean they shouldn’t be part of a discussion about how to structure data in a way that users will benefit from.

Another concept you talk about is how we need to look at the web as a series of patterns, as opposed to pages. Can you elaborate a little on that?

When you’re dealing with a big site, and when you’re looking at hundreds or thousands of pages of content, you have to be able to see what’s underlying them. The word “page” isn’t a semantic term; it doesn’t mean anything in a web context. “Page” is a term we took from print.

You have to look at what the content actually comprises. What is it communicating? What purpose is it serving for that organization? What does it do for a user? And when you start evaluating those questions, you can find patterns — how content is similar in certain ways. You can’t isolate your content into merely pages, and then neglect to build any rules or systems for what happens to that content in different contexts. You need to have specifics built in so you can say, “OK … this type of content needs this type of treatment”. That’s how you respect what the content is communicating.

Finally, if SitePoint readers were interested in moving into a career in content strategy, what skills would they need, and where would they start?

There are many flavors of content strategists. Some of them come from editorial backgrounds, some from publishing. Some come from more technical fields, like technical communications, information architecture, or studying taxonomy and metadata.

The key is that if you want to get involved in content strategy, you have to be willing and able to ask tough questions, and get your organization or client talking. Facilitation is an important skill in addition to having expertise in some facet of content work. You have to be that bridge, capable of identifying areas where disconnects are happening and finding ways of overcoming them. So you have to be a therapist sometimes, too!

Sara, thanks for your insights. We’ll leave it there.

Thank you.

For anyone interested in finding out more about the future of content strategy, check out the details of Sara’s upcoming book, Strategy and Structure For Future-Ready Content.

Understanding your customers and their habits is critical to creating compelling positive user experiences.

Here, author Jodie Moule shares an excerpt from her new SitePoint book Killer UX Design, which explores:

• What makes a habit
• How do you measure a habit
• What does a habitual user (of your product/website/service) look like?

—

What makes a habit?

When you think about some of the great technology solutions of the last 20 years, many share a common ground: they create a habit. When technology has created a habit in people, a person’s use of a product is automatic, without thought.

Technologies with a social aspect are clear winners in the habit-formation stakes. Facebook, Pinterest, and Twitter all have users coming back to their sites several times a day to check what has been said, posted, or liked about content—sometimes even several times within an hour.

The additional game-changer in habit formation has been the explosion of mobile devices. Even traditionally non-habit forming sites that are more transactional in nature have the ability to become habit-forming when made available on a mobile phone (for example, mobile banking). Consider how smartphones have changed how we interact with business.

Products used daily create a barrier to entry for competitors in their market. If your users are unable to imagine life without your product, you can safely say you’ve met your goal. So what makes a habit?

The more you do something without making a conscious decision, the stronger the habit. Frequency of use leads to the creation of a habit in your users; so if your users are coming back regularly, it’s likely that habits are forming.

How do you measure a habit?

Measuring the effectiveness of your design in creating habits can be broken down into those tasks you perform before you launch, and those that you do after.

Before You Launch Your Product

Define a habitual user

How often do they use the site? What do they do? How long do they stay? How often do they visit? These questions will help you to outline what you are expecting up front before you launch. This is easier to do if your product already exists, but try to estimate what you’d expect or hope for, at a minimum.

Define the frequency of use

How many times a day, week, or month do you see as realistic usage? Set a clear expectation for overall frequency of use of your product, but try to be realistic. Everyone wants users to engage daily, or even hourly—but few products manage this. The context of your product will help guide what you can sensibly expect.

Use the product yourself

Keep note of how often you use your own product. Average out your ideal-use scenario with the number of times you have used it; adjust expectations from there.

Focus on behavior

Remember, we are focused on users’ behavior, and what creates a habit varies for the type of service you deliver. Focus on individual users and what they are doing, and assess if they’re making your product a habit or not. The overall active user rate is not predictive; it is what they are actually doing that should be the focal point.

After You Launch Your Product

Set the baseline

Once launched, you are in a position to collect and analyze data around habits. Measure at intervals how many of your users actually fit the definitions you set at baseline, and then at different time periods post-launch (monthly, quarterly, six-monthly).

Who is dropping off and why

Understand who engages with your product and who dumps it. Try to uncover why that might be the case using UX methods.

Crunch your numbers

Watch as user data and patterns emerge and then see how many of your users actually meet the expectations you originally set. If no one is using the product in the way you expected, then decide from your audience pool what they are doing and monitor as behavior changes or adjusts over time (a few examples of monitoring tools to consider include Flurry, Localytics, Google Analytics, ClickTales, and so on).

Be patient!

Measuring behavior is a job done longitudinally and there is no way of hastening time. The best results are taken over a long period, and during this time anything could change—so hang in there. There are also slow starts.

There is no magic percentage you can assign to assess whether your product is creating a habit. Actual user behavior patterns are most predictive of an eventual habit.

Monitor your users’ movements through the product, engage with them (for example, through interviews and evaluations), and continue to watch and learn.

Evolution, Not Revolution

Iteration as an approach to learning continues even after you’ve launched, and is backed (or refuted) by larger volumes of customer data that reflect actual use of your product.

You need to take these learnings and continue to evolve your design, but keep in mind that it is about evolution rather than revolution at this stage of the game. You are not looking to fundamentally change your design approach, but rather to tweak and refine based on a new level of understanding of your customers’ needs and habits.

Observe the Early Adopters of Your Product

Watching the early adoption of your product will allow you to ascertain where the real value of your product lies for your users, helping you to then shape the product in new or unexpected ways.

A great TED talk with Evan Williams, the co-founder of Twitter, reveals how watching early adopters of the product helped to uncover hidden value that was not imagined in its creation.

In this talk, Evan discusses how Twitter was originally created as a broadcast medium. Users shaped its evolution by inventing ways of doing things; for example, using the @ handle evolved from users shouting out to other users they knew whom they wanted to draw into their discussions; it was not part of the original design.

Similarly, the use of the hashtag [#] to search for like items was not originally designed, but created by a third-party provider as a way to locate content as the service grew and evolved. Twitter then purchased this service, and the hashtag became an invaluable way of locating content across all posts.

What does a habitual user look like?

Once you’ve launched, identify the behaviors that differentiate your habitual users from the rest, and try to identify the tipping point that took them from normal user status to habitual user status. It will take more than stats to uncover the answer, and this is where follow-up contact with your users will be useful to uncovering the “why.”

Before you go see users in the wild, check your data and formulate a hypothesis about their usage and why they might have taken a certain pathway that other users have not.

Model Your Top Users’ Habits

Target your devoted users and try to understand their usage and behavior in detail so that you can apply learnings from this group to the rest of your user group. Understand what it was that hooked them more strongly than standard users so that you can then use this information to attract a new group or convert others.

You could focus on data and drill down to see what they did and where they went within your product, uncovering the patterns and areas that drove their usage. Alternatively, pull out your UX methods again and talk to your most passionate users about how they use the product; monitor them in their own context and ask them to keep a diary through the trial so that you can uncover greater detail than stats alone can give you. Your devotees will love it!

Identify from your data commonalities among the habitual users to see if there is a pattern that led to a habit that can be translated across a wider group.

UX Is Critical to Habit Measurement

Usage statistics are invaluable as a first step as they give you a high-level idea of how people are using your product; however, users can be interrupted in different ways, and what you see in the data might not be the result of the design. Instead, it may reflect a certain situation or circumstance. Like everything, data needs intelligent interpretation.

In many ways, we come full circle in our UX process. To uncover habitual behavior, use benchmark testing, contextual interviews, and diary studies. In your diary studies, you can leave a select group of users with your product and monitor usage over an extended period of time—say, two weeks to two months—and ask them to record instances of use and general notes about the product.

UX helps you to see what is most valuable and habit-forming about your product, so that you can create something that really resonates and makes a difference to your users and the wider product landscape.

Modify Based on What You Learn

What you learn post-launch will allow you to focus on aspects to further develop and refine your product. You’ll also be able to market your product to new users in a way that directs them towards the end you seek.

To reach a deeper level of understanding, head out of the office and start talking to the real users of your product once again. This should help you to add context to the analytical data you’ve collected. Key areas for expanding your learning at this stage are:

• What are hurdles to engagement with the product or features, if any?
• What gaps do competitor’s products fill that yours don’t?
• Is the problem your product solves one that customers want solved?
• Are your strategies influencing users’ behavior towards the desired result?
• Which aspects of the product resonate with users, and which do not? (In this sense, you understand the aspects of the original vision that have been validated, and those areas that are not resonating.)

Remember: with product design, it’s about evolution, not revolution.

—

And that’s a wrap on the excerpt.

Learn more about adopting the latest user experience skills by checking out Jodie’s full book: Killer UX Design. If you’re quick, there are some great launch discounts on offer!

Great user experience (UX) design is at the heart of compelling and memorable sites. And it’s a skill Jodie Moule can help you to master in her new book Killer UX Design (just released here on SitePoint).

In the book you’ll learn how to harness the power of user experience to build interfaces that influence and inspire, and keep your users coming back—time and time again!

Watch Jodie as she introduces the book (below) and make sure you download our fun UX Design Infographic (PDF)

Page load time is one of the most important aspects of user experience on the web. When pages load too slowly, users quickly become frustrated and take their business elsewhere. Unfortunately, troubleshooting a slow page load is not typically a straightforward process because many factors contribute to the overall time. For example, a page’s load time can be influenced by the user’s browser, network conditions, server load, and application code, among other things.

As a developer, methods for gathering data on these various factors has been limited in the past. For many developers, the JavaScript Date object has long been the standard for gathering performance data. For example, the following code measures load time by comparing timestamps once the page’s load event handler is invoked.

var start = new Date();
window.addEventListener("load", function() {
  var elapsed = (new Date()).getTime() - start.getTime();
}, false);

There are several problems with this approach. First, JavaScript time is notoriously inaccurate. Second, using the Date object introduces overhead and clutters the application code. Third, the Date object can only measure the execution time once the code is running in the browser. The Date object cannot provide any data regarding the page load process involving the server, network, etc.

In order to provide more accurate and comprehensive page load data, the W3C has proposed the Navigation Timing API. The proposed API provides more detailed timing information throughout the page load process.  Unlike the Date object, the navigation timing API can provide measurements related to DNS lookup, TCP connection establishment, page redirects, time spent building the DOM, and various other metrics. Navigation timing is also built directly into the browser, meaning that no additional overhead is created.

Detecting Support

The Navigation Timing API is currently only supported in Internet Explorer 9+, Firefox, and Chrome. Therefore, support for the API should be detected before attempting to use it. The API is defined in the window object as “window.performance.timing”. The following function detects whether or not the API is supported.

function supportsNavigationTiming() {
  return !!(window.performance && window.performance.timing);
}

Recorded Events

The API records the time when numerous milestones in the page load process occur. Each of these events is stored as a property of the “window.performance.timing” object. The following list describes each event. If a given event does not occur (for example a page redirect), then its value is zero.  Note: Mozilla claims that the events occur in this order.

• navigationStart ― This represents the time immediately after the browser finishes prompting to unload the previous document. If there is no previous document, then “navigationStart” is equal to “fetchStart” (see next item). This is the beginning of the page load time as perceived by the user.
• fetchStart ― “fetchStart” represents the time immediately before the browser begins searching for the URL. The search process involves checking application caches, or requesting the file from the server if it is not cached.
• domainLookupStart ― The “domainLookupStart” value corresponds to the time immediately before the DNS lookup for the URL occurs. If no DNS lookup is required, then the value is the same as “fetchStart”.
• domainLookupEnd ― This value represents the time immediately after the DNS lookup occurs. If a DNS lookup is not required, then the value is the same as “fetchStart”.
• connectStart ― This denotes the time immediately before the browser connects to the server. This value is equal to “domainLookupEnd” if the URL is a cached or local resource.
• connectEnd ― Once the connection to the server is established, the “connectEnd” time is set. If the URL is a cached or local resource, then this value is the same as “domainLookupEnd”.
• secureConnectionStart ― If the HTTPS protocol is used, “secureConnectionStart” is set to the time immediately before the secure handshake begins. If the browser does not support HTTPS, this value should be undefined.
• requestStart ― “requestStart” represents the time just before the browser sends the request for the URL. The API does not define a “requestEnd” value.
• redirectStart ― “redirectStart” represents the start time of a URL fetch that initiates a redirect.
• redirectEnd ― If any redirects exist, “redirectEnd” represents the time after the last byte of the last redirect response is received.
• responseStart ― This corresponds to the time immediately after the browser receives the first byte of the response.
• responseEnd ― This represents the time immediately after the browser receives the last byte of the response.
• unloadEventStart ― This represents the time immediately before the previous document’s “unload” event is fired. If there is no previous document, or if the previous document is from a different origin, then this value is zero.
• unloadEventEnd ― This represents the time immediately after the previous document’s “unload” event is fired. If there is no previous document, or if the previous document is from a different origin, then this value is zero. If there are any redirects that point to a different origin, then “unloadEventStart” and “unloadEventEnd” are both zero.
• domLoading ― “domLoading” represents the time immediately before the “document.readyState” value is set to “loading”.
• domInteractive ― “domInteractive” corresponds to the time immediately before the “document.readyState” value is set to “interactive”.
• domContentLoadedEventStart ― This represents the time immediately before the DOMContentLoaded event is fired.
• domContentLoadedEventEnd ― This represents the time immediately after the DOMContentLoaded event is fired.
• domComplete ― The “domComplete” value represents the time immediately before the “document.readyState” value is set to “complete”.
• loadEventStart ― This value represents the time immediately before the window’s load event is fired. If the event hasn’t been fired yet, the value is zero.
• loadEventEnd ― This represents the time immediately after the window’s load event is fired.  If the event hasn’t been fired, or is still running, then the value is zero.

Navigation Types

The Navigation Timing API also defines an interface for determining how a user landed on a particular page. The “window.performance” object also contains a “navigation” object, which contains two properties ― “type” and “redirectCount”. The “type” property provides the method by which the user navigated to the current page. The following list describes the values that “type” can hold.

• If the user navigates to a page by typing a URL, clicking a link, submitting a form, or through a script operation, then the value of “type” is zero.
• If the user reloads/refreshes the page, then “type” is equal to one.
• If the user navigates to a page via history (back or forward buttons), then “type” is equal to two.
• For any other circumstances, “type” is equal to 255.

The “redirectCount” property contains the number of redirects taken to the current page. If no redirects occurred, or if any of the redirects were from a different origin, then “redirectCount” is zero. The following example shows how the navigation data is accessed.

var navigation = window.performance.navigation;
var navType = navigation.type;
var redirectCount = navigation.redirectCount;

Making Sense of the Data

The Navigation Timing API is useful for calculating certain components of page load time. For example, the time taken to perform a DNS lookup can be calculated by subtracting “timing.domainLookupStart” from “timing.domainLookupEnd”. The following example calculates several useful metrics. “userTime” corresponds to the total page load delay experienced by the user. The “dns” and “connection” variables represent the times taken to perform DNS lookup and connect to the server, respectively. The total time taken to send a request to the server and receive the response is stored in “requestTime”. Finally, the total time to complete the document fetch (including accessing any caches, etc.) is stored in “fetchTime”. Notice that the setTimeout() function is called from within the window load event handler. This ensures that the navigation timing data is not used until immediately after the load event finishes. If the timing data were to be accessed from the load event handler, the value of “timing.loadEventEnd” would be zero.

window.addEventListener("load", function() {
  setTimeout(function() {
    var timing = window.performance.timing;
    var userTime = timing.loadEventEnd - timing.navigationStart;
    var dns = timing.domainLookupEnd - timing.domainLookupStart;
    var connection = timing.connectEnd - timing.connectStart;
    var requestTime = timing.responseEnd - timing.requestStart;
    var fetchTime = timing.responseEnd - timing.fetchStart;
    // use timing data
  }, 0);
}, false);

The Navigation Timing API can be used in conjunction with Ajax calls to report actual user data back to a server. This is useful because it allows developers to see how the page behaves for users in the real world. The data can also be used to create a visualization of the page load process. In fact, Google Analytics already incorporates navigation timing into its reports.

Things to Remember

• The JavaScript Date object cannot accurately measure page load data because it has no knowledge of the request prior to running in the browser.
• The Navigation Timing API is built directly into the browser, and provides more detailed timing measurements.
• The API also tracks how users navigate to a page.
• Navigation timing data can be sent to servers for analysis.

Q: What separates the world’s best web designers from the rest?

A: The pros appreciate that true design excellence can only be achieved with a great design process. 

Our new book “The Web Designer’s Roadmap” will help you consistently produce world-class web designs, time and time again. Before you jump into your next design, learn how the best of the best go about it – with insights and interviews from the likes of: Donald Norman, Daniel Burka, Shaun Inman, and a host of others design pros.

Join author Giovanni DiFeterici, as he walks you through the concept for the book, and what you’ll likely glean from it.

As usual, we have a great launch special:

• Save 50% when you order the PRINT and DIGITAL EPACK Bundle
• Save 42% when you order the DIGITAL EPACK (epub + mobi + pdf versions)

Adverts pay for many of the resources we take for granted on the web. No one begrudges a few ads — you wouldn’t be reading this if you did — but some sites take adverts beyond a reasonable level. Google’s latest search algorithm change attempts to improve user experience by downgrading sites with too many adverts.

According to Google’s Inside Search blog:

We understand that placing ads above-the-fold is quite common for many websites; these ads often perform well and help publishers monetize online content. This algorithmic change does not affect sites who place ads above-the-fold to a normal degree, but affects sites that go much further to load the top of the page with ads to an excessive degree or that make it hard to find the actual original content on the page. This new algorithmic improvement tends to impact sites where there is only a small amount of visible content above-the-fold or relevant content is persistently pushed down by large blocks of ads.

The algorithm analyzes adverts in fixed positions; the Pagerank for sites using pop-ups, pop-unders or overlays will not be affected.

Google estimates the change will impact 1% of searches, i.e. you could encounter result reordering for one in every 100 searches. If your site’s affected, they recommend testing it with the Browser Size tool.

Perplexing Prerequisites

As with most search algorithm changes, Google is holding all the cards and gives us little to go on…

1. What do Google consider to be an advert? They’re not always banners or third-party scripts?
2. What do Google consider “above-the-fold”? It’s a dubious design term which changes from device to device and has no authoritative specification.
3. How do Google know whether an advert is above the fold? It’s easy to reposition advert blocks with CSS or JavaScript which wouldn’t necessarily be noticed by the algorithm.
4. How do they rank pages which use responsive design and reposition or remove adverts according to the screen size?
5. Google AdWords recommends advert positions above the fold. You may have received messages stating that you’re losing revenue because you’re under-utilizing the maximum number of slots. Could you be penalized for using Google’s own advice?

It’s great Google want to improve the web and search is their core business — they can do what they like and we’re free to use them or not. That said, should a company as powerful as Google be able to dictate something as subjective as design or user experience?

The Apple and Microsoft websites are essentially huge multi-page adverts. Could those sites be downgraded because Google (a major competitor) considers them to offer a bad user experience?

And where could it end? Could Google consider downgrading predominantly red designs because it’s considered a danger color in some cultures? Are they impeding your creative freedom? Is it censorship?

Don’t Panic

The vast majority of site owners need not be alarmed. Google’s announcement sounds more like marketing spin than an advanced new technology which will change the way designers approach pages.

I suspect the algorithm loads each page in a browser engine which emulates a 1024px width screen. CSS and JavaScript effects parsed during the initial page load may be applied but event or timer-driven code wouldn’t run. It then works out the vertical position of the first major content block and if it’s more than, say, 600px down, the Pagerank would be reduced accordingly. The overall impact is likely to be tiny, though. Factors such as keyword relevancy and even page weight will have a bigger effect.

There’s an easy way for site owners to avoid downgrades: simply place all your adverts at the bottom of the page then rearrange the content using CSS3 animations or JavaScript events. I’m no fan of intrusive advertising but that’s a horrible user experience — far worse than a little scrolling. Unfortunately, Google won’t know unless they manually check the site.

Will Google’s new algorithm affect your site? Is the policy at odds with Google’s advertising business? Is Google using it’s power to dictate website design and code quality?

A few years ago free shipping was taking the e-commerce world by storm … we saw several of our competitors implement free or flat-rate shipping and decided it was time to give it a try. In our e-commerce business we decided to offer free shipping on orders above $100, and flat rate shipping on all other orders (to the contiguous US). We created a coupon code that customers had to enter into the shopping cart at checkout to claim the promotional shipping offer, and added banners to every page of our website advertising the promotion and code.

The free shipping offer was very successful, and we saw a noticeable spike in conversion rate and orders. There were also a number of people who didn’t select the free shipping offer, and we just assumed they wanted their order shipped via a specific carrier. After a while, we started to get a few complaints from customers that overlooked the coupon code or couldn’t remember it once they were on the checkout screen. They would email us asking why they paid for shipping, when our site advertises it as being free.

During the holiday shopping season that year we did some user testing through UserTesting.com and quickly realized the free shipping offer was a major source of confusion with potential customers. Many didn’t see the banners advertising the offer, and of the ones that did, quite a few overlooked the coupon code.

I decided to make the flat rate shipping the default, and automatically select free shipping for all qualifying orders (in US over $100). Our e-commerce software wasn’t really set up to handle that kind of scenario, so I actually wrote a custom shipping module for our e-commerce platform.

When we implemented the new shipping options on our website, our conversion rate increased by 50% overnight.

Find Areas of Frustration

Adding the free shipping offer increased conversions, sure. But the way we implemented it also caused a lot of confusion and frustration. For months, we didn’t even know we had a problem. Looking back, I shudder to think how much revenue we lost in that period of time.

We get so used to our own websites, it’s hard to see it from a visitor’s perspective. Usability testing is the answer. Use a service such as UserTesting.com to let real users evaluate your website or landing page. UserTesting.com is a very affordable remote usability testing service that employs real users to test your website according to criteria you determine. You choose your target demographic including age, income, gender and even web experience. The user follows your instructions, recording their screen and audio as they tell you what they are thinking through each step of the process.

The real feedback you get from these users will likely give you several areas in need of improvement.

You can also use tools like CrazyEgg.com to see where people click, even areas that aren’t hotlinked, and your web analytics package can often shed some light on potential problem areas as well.

Survey Your Visitors

Another great way to find out about potential problem areas is to conduct an exit survey on your visitors. Invite visitors who started filling out your contact form, or have added an item to their shopping cart but didn’t complete the transaction to tell you about their experience.

You might be surprised to hear the reasons they left. Some may have just been doing research or comparison shopping, but some will have experienced problems along the way that prevented them from completing.

Test Changes

Using a tool such as Google Website Optimizer, test changes to problem areas (one at a time). I have made changes I was sure would increase conversions and to my surprise they actually made things worse. Even with all our experience, some things just aren’t “logical.” Test, test, test.

Using simple A/B split testing in GWO, test a couple of different variations and see which one performs best. Then move on to another problem area, make a change and test. Continue making changes, and testing, to continuously improve your conversion rate over time. You’ll likely find that some changes will have drastic improvements, like ours above, and others may only increase conversion rates by 5% or 10%.

Always Work to Improve Conversions

You should always be working to improve your conversion rates. If you run out of areas to test, check out this great article by Conversion Rate Experts. That will give you a few things to try: 108 to be exact!

WebGL is amazing. Take a look at X-Wing or First-Person Tetris in Firefox. What do you mean it’s not working?

My laptop’s two years old but, despite having a reasonable dedicated graphics card, WebGL is disabled in Firefox. Mozilla blacklist specific GPUs based on the driver version number, i.e.

• NVIDIA cards require a driver numbered 8.17.12.5721 or greater
• AMD/ATI cards are 8.741.0.0 or greater
• Intel cards normally require 6.14.11 on XP, 7.15.10 on Vista or 8.15.10 on 7 (although some products are completely blocked)
• Macs require OS version 10.6 or newer

In general, blacklisting is a good thing. You don’t want WebGL crashing the browser because your card doesn’t support the right number of Z/Stencil ROP Units, 128-bit floating point HDR, anisotropic texture filtering or some other bizarre feature no one understands.

Unfortunately, hardware vendors stop producing drivers for legacy products (anything released before last Tuesday). In some cases, your PC vendor will insist on releasing their own modified driver updates and there’s no guarantee they’ll do that. Your graphics card may be WebGL-compatible, but it’ll be blocked in Firefox if the driver version is 0.0.0.1 behind the approved list. Type “about:support” in the address bar and scroll down to the “Graphics” section at the bottom to discover whether your card is suitable.

And all you Chrome users can stop giggling — Google is adopting GPU blacklists in their browser shortly.

Big Red Warning

We’re about to bypass Firefox’s GPU blacklist. It’s a dumb thing to do and involves tinkering with dangerous configuration settings. Do this at your own risk: I can’t accept responsibility for any catastrophic PC failures, migraines, plagues, explosions or spontaneous human combustion caused by these changes … But it’s worth the risk to play X-Wing!

Here Be Dragons

Type about:config in Firefox’s address bar and make the following changes:

• To enable WebGL, set webgl.force-enabled to true.
• To enable Layers Acceleration, set layers.acceleration.force-enabled to true
• To enable Direct2D in Windows Vista/7, set gfx.direct2d.force-enabled to true

Now, cross your fingers, restart Firefox and try running a WebGL application. It’s probably best to undo those changes if smoke starts pouring from your PC.

I’m stunned. I’ve written several web page bloat articles over the years but it’s all been in vain. According to Pingdom, a performance monitoring service, total web page file sizes have increased by 25% during the past 12 months.

The average web page now weighs 784KB compared to 626KB in November 2010. Remember that’s an average: 50% of sites will exceed that size. To put it into context, a single page can be 10% of the browser application which was downloaded to render it.

The Pingdom article concludes that the main culprits are:

• JavaScript: an increase of 44.7% (103KB to 149KB)
• images: an increase of 21.2% (372KB to 451KB)

But why? HTML5 technologies are far more common. I would have expected a minor increase in HTML and CSS code — especially to cater for CSS3 vendor-prefixes — but shouldn’t JavaScript and image sizes should be dropping? There’s less need for image-generated gradients, coded animations, rounded corners, shadows, etc.

I also expected Flash usage to drop but it’s increased from 77KB to 87KB (13%). I suspect it’s primarily used in advertising, but HTML5 alternatives and Adobe abandoning mobile platforms are yet to have an effect.

So, is the problem that designers and developers rarely worry about page bloat? Anyone moving into the industry within the past five years has enjoyed the luxury of reliable broadband. Those who experienced the pain of dial-up connections often needed to optimize every byte — I can remember omitting closing tags and attribute quotes just to squeeze pages further.

Obviously the situation has progressed and few people would limit themselves to the 50KB maximum developers adhered to during the late 1990s. But there are many good reasons why you should habitually minimize your file sizes…

1. Search Engine Optimization
If two sites have similar content and page-ranks, the one which loads faster will gain a higher position in Google.

2. Reduced Cost
Smaller file sizes result in reduced hosting costs, bandwidth charges and user time. These factors are never free and, the more popular your site becomes, the more you’ll be charged.

3. Slow Connectivity
Just because you have fast unlimited access, don’t assume everyone else is sitting on a fat pipe. The situation is especially dire in the western countries which are dependent on aging copper telephone networks. A proportion your market will have a slow connection — or even dial-up — because that’s the best they can get.

4. Mobile Access is Increasing
Web access from smartphones tablets are popular. Eventually, they’re expected to overtake desktop browsing. Even those with reasonable 3G access will be waiting 30 seconds for your 1MB monolithic page to appear. Is that progress?

5. Developing Markets
Unlike the West, Asia and Africa will experience explosive internet growth during the next decade. The relative area sizes and population distributions mean that slow or mobile connectivity are the only option for the foreseeable future.

Perhaps those markets aren’t important to you now, but they will be. Besides, unlike the west, many of those economies aren’t bankrupt … they may become your only market!

Finally, let’s not forget that smaller file sizes normally results in more responsive applications. That’s good for everyone.

Let’s hope Pingdom’s 2012 report shows a big reduction in file sizes.

Whatever your motivation — the client told you to do it, you’re tired of white or light backgrounds, or your deep-seated anger over your own father cutting your hand off (just don’t be a hater!) — designing dark websites can be a serious challenge. Careful use of the Creative Force is in order as dark designs have special considerations. A few design tips will keep you from fully giving in to the Dark Side, although this might just be your destiny… For those of you looking for some inspiration, check out this collection of 20 dark websites with some excellent examples. If you need some design advice, keep reading

Read more here:
DesignFestival: Designing for the Dark Side