Recently on Twitter, Jeff Croft mentioned the Terms of Services page of the photo gallery site 500px. That made me think of content usability. You can do all sorts of things to help users get to your content; clever navigation, a good search function, few disturbing items around the content etc. While those definitely add to the overall usability of a website, let us not forget that most people visit our sites for the content.

500px 'translates' their terms into everyday language

The user terms page of 500px is focused on the user reading it. Every section is explained in everyday terms, making it very transparent what your rights are when uploading photos.

You’d be surprised at how many hard-to-read Terms of Use pages you can find — and how few easy-to-read. Other than 500px, I found that, among others, Facebook, Pandora and Wikipedia have taken a different and more user-friendly approach to Terms of Use and Privacy Policy pages.

We spend so much time on making our interfaces simpler — why not think about the content too?

All you have to do is follow me on Dribbble and post a comment below including the following:

• A link to your Dribbble prospect account
• A link to your three best shots
• A short explanation of why I should pick you

I will decide who gets the invite in a week or so. I also tweeted about the invite, but got surprisingly few replies, so now I’m trying here.

… and the winner is

Thanks for the great submissions! The invite goes to Adomas, who submitted three awesome shots that really stood out. Be sure to check out his Behance portfolio as well — wicked good stuff! And now, also visit his Dribbble profile.

When designing icons, you want to strive for creating/using isomorphic icons — that is, icons that represent their real-life companion — eg. trash can, brush, eraser, etc. As long as you can do a somewhat decent depiction, these icons will be usable. But what when there is no real-life companion?

As an example, I’m going to use the icon for a link. “A link?” you say. “Everyone knows what the icon for a link looks like!” What is the first icon that comes to mind when thinking of inserting a link in an e-mail, a blog post, or in your CMS? A chain? A globe? A …? Yeah, there are a couple of different icons for inserting links, and you might think they’re all logical. But they’re not necessarily.

How do the big guys do it?

Examples of link icons in apps and websites

As you can see, most CMSes and apps use a chain. The only one really separating from the rest is Facebook, using a note — and I think that makes even less sense than a chain.

Only geeks understand link icons

I’m a geek myself, so I can say it — only geeks understand link icons. In 2010, I wrote my bachelor project with Morten Keilow. The project aimed at exploring how little documentation you could leave in a CMS, and still have even the most non-savvy person use it with no issues. When we created the interface design, we used a chain icon without even giving it any thought.

We gave the test participants a list of assignments to perform, one of which was inserting a link. What really surprised us was, that almost no one could figure out how to insert a link. We decided on testing the link icon out of context together with other icons regularly used in CMSes and text editors, and the results were really surprising.

The icons used in our test

Several of our test participants understood the chain icon as “binding something together” or “linking to elements together”, which is not altogether wrong — the issue is that they do not understand what they are binding together — and thus, the icon doesn’t work as intended. The globe icon brought comments like “You can visit the Internet”, “Search”, or “Upload to the Internet”.

All in all, only 35.29 % of the test participants understood the chain icon, and only 25 % understood the globe icon. While we didn’t set a minimum for success, clearly, 25 % is not good when it comes to usability. When being interviewed one of our participants asked:

“Why not just write WWW? Everyone understands that!”

It is possible that someone would understand WWW as “visit the internet” or similar, but we found that every single test participant understood this icon. This probably isn’t the best solution — however for now, at least based on our tests, it is the most usable icon for explaining a link.

I would love to do another test of any other icons that might be better, so if you have any ideas, please write in the comments below.

Test your test

Before conducting the test, be sure to test it on a couple of persons. Nothing is worse than noticing an error when you’ve already run through the first test subjects. Instead of focusing on the test results, ask about your skills as test conductor, if they felt uncomfortable, if your questions were understandable, etc. They will most likely find the most crucial errors, and it’ll be a huge help in the real test.

Environment

The environment surrounding a usability is crucial for receiving usable results. You want your subjects to feel comfortable, and to focus on nothing else than your product — you want them to feel home. Make sure to find a place with no noise, get a good chair, air out, throw out the trash — create a place you would want to work.

Declaration of consent

A declaration of consent makes sure that you’re actually allowed to use the test results, recorder sound or video, or whatever you write in there. Just like a photographer, you need to collect signatures from your subjects — and remember to do so before running the test.

Ask more questions than you need answered

One of the usability tests we did on campus went terribly wrong. When we were analyzing the results, we found out that we needed to ask some more questions in order to be able to use the results, and we had to do a lot of it all over again. Be sure to ask for age, occupation, etc. — usability testing relies a lot on demographics. Also, be sure to ask the questions in the same tone for every test subject. Your test participants can be swayed just by changing the tone of voice, and you want your test to be credible.

Rehearse and have everything in place

Show that you’re serious about what you’re doing – that you believe in your product. When your test subject arrives, it’s your job to guide them. Take the lead, show them where to sit, but don’t be bossy.

Have extra of everything

You always want to keep extra paper, pens, declaration of consents, batteries, question sheets, etc. It may seem like an obvious advice, but I tried running out of question sheets once, and we had to go print in the middle of the test.

Computer

Unless specified in your target group, you can’t be sure that your test participants use the same operating system as you. The best would be to let the test participant use their own computer, but if that’s not the case, at least have both a Mac and a PC to ensure that the OS will not confuse them so much they’ll have a hard time actually taking part in the test. Also, be sure to have a decent mouse.

Payment

Students have little or no cash to give for testing, so we often just made a cake and gave the subjects a piece after the test. However, if you work in a company, many people might find it strange that they should volunteer to help you make money. Try to convince your boss to put some money in usability testing — people tend to be more willing to help if they’re paid. Be sure not to buy nice words, stress that you want their whole-hearted opinion.

These are some of the things I have learned in usability testing. I hope you can use the advice — feel free to share your own in the comments.

Published in July 2010, it’s a fairly new book, divided into 10 easy-to-read chapters written by one of the two authors. The book is kept in a light language, but still is advanced enough to learn something even if you are already familiar with most of HTML5′s features.

The book covers most new features of HTML5, including canvas, multimedia, forms, and storage. Each chapter features great code examples to help you understand the features even better.

The first two chapters of the book are written by Bruce Lawson, and they provide a great overview of the new elements of HTML5 (header, section, article, etc.)—and an excellent explanation (with examples) of the semantic values of these. Before reading this chapter, I found it hard to interpret the very formal phrasing in the spec, but Lawson explains (and discusses) the semantic values of the new elements, making the book perfect for using as a reference.

Chapter 3 gives a great introduction to the use of form elements in HTML5—including information on fallback methods for older browsers, and how to override the default browser settings.

The video element of HTML5 is one of the most discussed right now. In chapter 4, Lawson and Sharp explains how to use both that, and the audio element. You’ll also get some great information on codecs, and they’ll even teach you how to make custom controls for your video player.

If the video element is the poster boy of HTML5, the canvas element is definitely the Han Solo of HTML5.

— Sharp, page 115

Another very discussed part of HTML5 is the canvas element, which provides a 2D drawing API to use in HTML5. Remy Sharp gives examples of how you can use canvas—from drawing lines to animating. However, Sharp also explains that canvas is not necessarily the best part for the job, just because it’s a part of HTML5—be sure to read the infobox about when to use canvas and when to use SVG.

The latter five chapters of the book more or less describe the web application part of HTML5; data storage, offline detection, drag and drop, geolocation, messages, workers, and sockets. These chapters are also the more advanced part of the book. The first chapters will, if you know HTML on advance, basically just give you some new tools to play with. But these guys—they’re the reason HTML5 is awesome.

You’ll learn how to avoid using cookies, and instead using HTML5′s storage options—both session storage and local storage are incredibly handy tools. As Sharp puts it; “In a nutshell, the Web Storage API is cookies on steroids.” You’ll learn how to take advantage of these, and when to use which.

If you’re creating a web application, offline detection also can become quite useful. How awesome is it, that you can let your users use your web app when they’re offline? Sharp leads you through the process of making your web app available even when there’s no internet connection—including all the quirks you need to pay attention to.

One of the cool things about the book is, that Sharp and Lawson dare to criticize the spec—and that is especially expressed in chapter 8: drag and drop. First, you’ll get a little history of the API, and why it’s even a part of HTML5. And even though they don’t like it, they’ll teach you how to use it. The problem with the drag and drop API is, that it’s very hard to implement across browsers, and thus, you’ll often have to fall back to JavaScript.

Chapter 9 is about geolocation, something I guess we’ll see a lot more as mobile devices becomes more advanced. With Gowalla, FourSquare, and Facebook Places, it is obvious that people like to tell about their whereabouts. However, it’s not only a stalker tool, you can really give your visitors a great experience using geolocation—showing nearby places to by your product, etc. The cool thing about it is, that you really don’t need that much code to use it. This chapter explains both how it works and how to use it—in the same light language as the rest of the book is written in.

Even though only the Message API is a part of the spec, Sharp has chosen to include both Message, Sockets, and Workers in the final chapter. Once again, through simple examples you’ll learn how to take advantage of these advanced tools. If you’re serious about creating web applications, you need to look into this chapter.

Conclusion

The great thing about this book—which I by all means will recommend—is, that it not only tells you how to use HTML5, it also tells you why. Why should you use the new input types, why should you use the video element, etc.? On top of that, they relate every part of HTML5 to accessibility—something I would love to pay more attention to in the future.

In a humorous tone, Lawson and Sharp provides what is definitely going to be my HTML5 reference.

Be sure to check out the book website, where you’ll find examples and source code to the book chapters.

In this article I’m going to give you a very short overview of the three technologies, to help you know the difference.

CSS3

CSS—or cascading stylesheets—is a specification under development. Many features are already supported by modern browsers such as Safari, Firefox, and Chrome (and soon to come: IE9). Let’s have a glance at the W3C’s (those guys who work on developing standards) description of what CSS is:

“CSS is the language for describing the presentation of Web pages, including colors, layout, and fonts.”

Okay, so it’s got something to do with layout. What can you do with CSS? Well, you can style HTML elements. You can animate them. It’s awesome. But it’s not HTML5! I feel tempted to, once again, quote W3C:

“The separation of HTML from CSS makes it easier to maintain sites, share style sheets across pages, and tailor pages to different environments. This is referred to as the separation of structure (or: content) from presentation.”

For me, that settles it. In case it doesn’t for you, separation is the keyword here. We’re separating structure (HTML) from presentation (CSS). Structure. And presentation. Not the same. But equally important.

Even though CSS3 is not HTML5, it doesn’t mean that it isn’t cool. You can do all sorts of amazing stuff with CSS3. So many people have created lists of stunning CSS3 effects, and I’m not going to attempt to do it over again, ’cause they’re all really good.

To learn more about CSS3 and what it does, check out CSS3.info.

JavaScript Frameworks

JavaScript frameworks/libraries/whatever are might popular these days. With relatively few lines of code it’s possible to do Ajax interactions, animations, and a bunch of other stuff. Popular frameworks include jQuery, Prototype, and MooTools—and they all share the same thing: it’s JavaScript. And JavaScript is not HTML5.

You can use JavaScript to enable HTML5 elements in older browsers (check out Modernizr), or you can use it to develop incredible web applications. JavaScript is amazing. Being able to do modifications on a website without reloading it is great. But it isn’t HTML5.

HTML5

“HTML is the language for describing the structure of Web pages.”

Yeah, I’m quoting W3C again. HTML5 is an emerging standard to take over HTML 4 and XHTML 1.1. With focus on structural elements and web application features, HTML5 really is going to be the next big thing. Recently, Apple launched their “HTML5” showcase. What’s funny is, that most examples are actually showcasing CSS3 and JavaScript. And as you all might remember—neither CSS3 nor JavaScript is HTML5.

It seems that HTML5 is becoming the generic term for “cool stuff you can do on the Internet”. I feel sorry for HTML5. It deserves to be recognized for what it is, and what it’s good at. As do CSS3. As do JavaScript. This confusion of concept isn’t doing good for anyone. Few years from now I fear my clients saying: “The design is a little bit boring. Maybe if you add some HTML5 effects…”.

So please, help spread the word: CSS3 is not HTML5. Neither is JavaScript.

Inspiration

Fonts

As you can see in many of the designs above, calligraphic fonts are often used in wedding invitations. Be careful when choosing your font—your want your guest to be able to read the text. There’s no reason not to mix font. For instance, you can use a calligraphic font for your names and a serif font for the rest of the text. The possibilities are endless. Here are some free fonts you can use in your wedding invitation designs.

Also, be sure to check out the ampersand in Baskerville Italic (which you probably have on your computer).

Brushes and Patterns

Ornaments and florals are often seen in wedding invitations. Here are some Photoshop brushes and patterns to use in your designs.

I hope you enjoyed the post, and found some great inspiration and resources for your wedding invitation project. Be sure to post a link to your wedding invitation in the comments.

We’re going to start with an HTML5 document (why not?), and include a stylesheet, as shown below:

<h1>Messy List</h1>
<!DOCTYPE HTML>
 
<html lang="en">
 
<head>
	<meta charset="utf-8">
	<title>Messy List</title>
	<link rel="stylesheet" href="style.css" />
</head>
 
<body>
 
	<header>
		<h1>Messy List</h1>
	</header>
 
	<section>
 
		<ul>
			<li>Lorem ipsum dolor sit amet</li>
			<li>Duis aute irure dolor in reprehenderit.</li>
			<li>Excepteur sint occaecat cupidatat.</li>
			<li>Ut enim ad minim veniam.</li>
		</ul>
 
	</section>
 
	<footer>
		<p>Copyright &copy; 2010</p>
	</footer>
 
</body>
 
</html>

That’s a pretty simple HTML document—and of course the most important part is the list. Next, here’s the stylesheet (with an HTML5 CSS reset in it as well). You can get the background from SeamlessTextures. I’ve modified it in color and size, so you can also just get my version.

/* HTML 5 Reset */
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small,  strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	vertical-align: baseline;
}
 
body {
	line-height: 1;
}
 
table {
	border-collapse: collapse;
	border-spacing: 0;
}
 
section, article, aside, header, footer, nav, dialog, figure {
	display:block;
}
 
body {
	background: url(background.png);
	width:600px;
	margin: 40px auto 0;
	font-family: Georgia, serif;
	color: #333333;
}
 
h1 {
	font-size: 3em;
	margin-bottom:1em;
}
 
ul {
	list-style: none;
}
 
ul li {
	padding: 8px 15px;
	margin: 10px 0;
}
 
ul li:nth-child(odd) {
	background: rgba(50,50,50,0.1);
}
 
ul li:nth-child(odd):hover {
	background: rgba(50,50,50,0.3);	
}
 
ul li:nth-child(even) {
	background: rgba(50,50,50,0.3);
}
 
ul li:nth-child(even):hover {
	background: rgba(50,50,50,0.5);
}
 
ul li:nth-child(3n+1) {
	-webkit-transform:rotate(-0.6deg);
	-moz-transform:rotate(-0.6deg);
	transform:rotate(-0.6deg);
}
 
ul li:nth-child(3n+2) {
	-webkit-transform:rotate(0.5deg);
	-moz-transform:rotate(0.5deg);
	transform:rotate(0.5deg);
}
 
ul li:nth-child(3n+3) {
	-webkit-transform:rotate(0.2deg);
	-moz-transform:rotate(0.2deg);
	transform:rotate(0.2deg);
}

I guess there’s not much new for you here, but let’s break it down a bit anyway. First, we define the width of our body to be 600px. Also, we include the aforementioned background, specify font and color, and add a top margin. Next, we define the size of our H1. And now comes the fun part.

We remove the dots from our list with list-style: none;, and add a little padding to our list elements. We’ll look at the nth-child selectors in bits. Check out the first one:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

ul li:nth-child(odd) {
	background: rgba(50,50,50,0.1);
}
 
ul li:nth-child(odd):hover {
	background: rgba(50,50,50,0.3);	
}
 
ul li:nth-child(even) {
	background: rgba(50,50,50,0.3);
}
 
ul li:nth-child(even):hover {
	background: rgba(50,50,50,0.5);
}

We choose every second li element, and add a background to it. In this case, we choose a dark gray, and set the opacity to 0.1 (RGBA is new in CSS3), so we can see the background through the li elements. We do exactly the same for our even elements, with the opacity set to 0.3. This is just basic zebra striping. You can add several selectors to an element, so we also add a hover background color a little darker than the original element.

Next, we target 3n+1—that is, every third element, starting with the first.

1
2
3
4
5

ul li:nth-child(3n+1) {
	-webkit-transform:rotate(-0.6deg);
	-moz-transform:rotate(-0.6deg);
	transform:rotate(-0.6deg);
}

We rotate the list element by -0.6 degrees. We do the same thing for both 3n+2 (every third element, starting with the second) and 3n+3 (you get the idea). By rotating every third element, and doing zebra striping with every second element, the list seems sort of random, which, I think, is a really cool effect.

If you use Safari, Firefox or Chrome, this is what you should have:

UPDATE: You can target Opera with the following (thanks to ToMzorz):

1

-o-transform:rotate(-0.6deg);

You can also check out the demo again, or download the source code.

Thanks for reading.

But should they be? This post is in not an answer, it is an introduction to discussion—and hopefully reflection.

So, which comment fields do we see in comment forms today?

Name

Name is pretty obvious. We need a name to know who writes the comment.

E-mail

Is the e-mail field necessary? Well, many websites uses an e-mail field in the fight against spam. But is that really necessary? Most spam bots can figure out how to put an ‘@’ between two words in order to cheat. Still, it’s better to have a little security than none at all.

Website

In this field, the user can put the URL to their website—if they have one. Most people that visit my website don’t have a website—at least they don’t write the URL in the website field.

Comment

This field is of course obvious, as it is the comment itself.

So, these four fields are the basics of a standard comment form. But what could we else be needing? Let’s look at where we might be able to improve.

Headlines

Why not give your users the possibility to give their comment a headline? It, of course, depends on each website, but headlines can be a good way to summarize a comment, and help people find the comment they are looking for a lot faster.

Age

Depending on your site’s topic, age might be a good field to add. It might even replace the name field in case the site is based on the anonymity of the user.

Gender

Like with age, a site allowing you to be anonymous would be a good place to use a gender field in your comment section.

Social media

Social media is here to stay. Whether it’s Facebook, Twitter, Flickr, etc., social media connects people. And even though the primary function of a comment section on a website is not to connect people, I don’t see why we can’t add to social media by letting our users link to their social media accounts in a comment form.

Let your users write the URL to their Facebook account, their Flickr user name, their Last.fm account, whatever! Still, you shouldn’t let it get too clumsy by filling the comments up with way too much information. If there’s no need to let them write it, don’t give them the option.

If those reading the comment find one comment particularily interesting, it is very easy to get in touch with the person who wrote it, as the e-mail address isn’t public.

Category

You might want your users to give different categories of comments, such as review, support, criticism, etc. The comments can be styled in different colors or within tabs. A great example of this is The Idea Shower, as seen in the picture below.

Final Thoughts

Remember, before everything, that you shouldn’t add a field if there is no use for them. The most important part of the comment is the comment itself—don’t confuse your visitors with too much information; you still want your comments to be readable.

This was my thoughts about adding new fields to a comment form. What do you think? Do you think it should stay the way it is or should we take advantage of being able to make every comment form different? Please write you comment in the standard comment form below…

Google Maps are more fun when you can get directions. And now you can! The recent release of the Google Maps API adds two new classes in order to enable directions. In this article I will show you how to add an input field in an infobox and use that to render a route.

But before that, here’s how it looks when it is done:

Because of the size at the page here the infobox gets a scroll bar, but just ensure to make your map large enough, then it will not happen.

Overview

• What’s New?
• Corrections
• The Directions
• Calculating the Route
• Conclusion

What’s New?

Since my last article a couple of new features have been added to the API, as you can also read about in the changelog. The most important, in my opinion, is of course the support of directions, and that’s the only function I will discuss here. Worthy to note, though — you do not have to use an API code anymore.

The support for directions is possible via two new classes, DirectionsRenderer and DirectionsService. DirectionsRenderer… Well… Renders the directions, and DirectionsService computes the actual directions. But the big question is — how do we use them?

Corrections

Before we rush into the new code, we should make some corrections in our excisting code. If you haven’t read my article Adding Custom Google Maps to Your Website, do yourself a favor and do so before continuing on this one.

[ad#ad]

Next, look in your code where you define your markers and ensure that your values follow these rules:

var companyImage = new google.maps.MarkerImage(’images/logo.png’, new google.maps.Size(100,50), // (width, height) 
new google.maps.Point(0,0), 
new google.maps.Point(50,50) // (width/2, height)
); var companyShadow = new google.maps.MarkerImage(’images/logo_shadow.png’, 
new google.maps.Size(130,50), // (width, height)
 new google.maps.Point(0,0),
 new google.maps.Point(65,50) // (width/2, height)
);

Dividing the image’s width by 2 ensures that it’s the bottom center point of the image that’ll be used for the marker. Thanks to JM for this solution.

The Directions

So, first we have to call the DirectionsService constructor. Before your initialize(), create a new variable:

var directionsService = new google.maps.DirectionsService();

Next, we have to create the renderer. Right before the variable you just created, define a new variable directionDisplay. This variable is going to contain the renderer.

var directionDisplay;

In your initialize() function, right after the latLng variable, set the directionDisplay variable to this:

directionsDisplay = new google.maps.DirectionsRenderer();

Further down in your code, find the map variable (right after the settings variable. Write this:

directionsDisplay.setMap(map);

This renders the marker on the specified map, which in this case is map. Next, let’s define what we want to write in our infobox by expanding the contentString variable:

	var contentString = '
<div id="content">'+
	'
<div id="siteNotice">'+
	'</div>
'+
	'
<h1 id="firstHeading" class="firstHeading">Høgenhaug</h1>
'+
	'
<div id="bodyContent">'+
	'
 
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
 
'+
	'
 
Find your way here from:
 
'+
	'
<form action="index.html">'+
	'
<input id="start" type="text" value="prinsensgade 5, 9000" />'+
	'
<input type="submit" value="Find directions" /></form>
 
'+
	'</div>
'+
	'</div>
';

Let’s look a bit into the form used to ask the user for an address:

	'
<form action="index.html">'+
	'
<input id="start" type="text" value="prinsensgade 5, 9000" />'+
	'
<input type="submit" value="Find directions" /></form>
 
'+

First, we write “index.html” in our action attribute. This path should be to the file where your map is placed. In onsubmit we call the function calcRoute() (which we will define later), and next we write return false to prevent the site from reloading when the user submits the form. The next two lines should be pretty self-explainable. If you want the user to be able to enter both addresses, you can just add an extra input field called end. The value of the start field can be empty or you can write a pre-defined address.

Calculating the Route

At the very end of the initialize() function, write the following:

In the form we called the function calcRoute(). That’s the one we are defining here. The first thing to do is define the two variables start and end. If you inserted an extra input field before write document.getElementById("end").value; in end instead of the coordinates.

Next, define the variable request. The attributes of this one are fairly logical, but let’s explain them just in case. We define the origin of the route to our variable start, and the destination to end. Also, we define a travelmode —. This can be either DRIVING or WALKING.

Lastly, insert this code:

directionsService.route(request, function(response, status) {
	if (status == google.maps.DirectionsStatus.OK) {
		directionsDisplay.setDirections(response);
	}
});

This issues the actual search request, and completes the initialize() function.

Conclusion

With very little effort you can show your visitor how to get to your address directly from your website, instead of sending them to Google Maps or some other place. I hope you enjoyed the tutorial — please let me know if you have questions or suggestions. You are of course free to download the source files.

While you are here, why don’t you follow me on Twitter or subscribe to the RSS feed?