An often overlooked feature of HTML5 is the new “onpopstate” event.

This new feature offers you a way to change the URL displayed in the browser* through javascript without reloading the page. It will also create a back-button event and you even have a state object you can interact with.

This means you won’t have to use the hash-hack anymore if you want add state to your AJAX-application, and search engines will be able to index your pages too.

So how does it work? Well, it’s fairly simple. In Chrome you write:

window.history.pushState(“object or string”, “Title”, “/new-url”);

Executing this line of code will change the URL to my-domain.com/new-url (3rd option). The “Title” string (2nd option) is intended to describe the new state, and will not change the title of the document as one might otherwise expect. The W3 documentation states:

“Titles associated with session history entries need not have any relation with the current title of the Document. The title of a session history entry is intended to explain the state of the document at that point, so that the user can navigate the document’s history.”

So if you want the document’s title to change to match the title of the history entry, you’ll need to write a hook for that (hint: just tie a function to the onpopstate event). Finally, “object or string” (1st option) is a way to pass an object to the state which you can then use to manipulate the page.

You can programmatically invoke the back-function by running:

window.history.back();

And you can of course go forward too:

window.history.forward();

Or even go to a specific history state:

window.history.go(2);

The object you pass as the first option to the pushState function will stay with each state, so if you go back in the history, you’ll get the object for that state. If you need to manipulate a state (instead of creating a new one) you can use:

window.history.replaceState(“object or string”, “Title”, “/another-new-url”);

Note that while this will change the URL of the page, it will not allow the user to click the back-button to go back to the previous state because you’re replacing the current state, not adding a new one. So, this is the correct behaviour.

Personally, I think the URL should be the first parameter and then the two other options should be optional. Regardless, this feature will certainly come in handy when working with AJAX- and Flash-applications that need state (read: bookmarkable pages and back-button support). Anyone looking to make their Flash- or AJAX-application indexable by search engines so they will get better raking in Google and the likes, should also have a look at this new feature.

The most prominent implementation of this HTML5-feature that I’ve seen is in the new Flickr layout. Here’s an example page (remember to enable the new layout if you haven’t already). Now, if you’re using the latest version of Chrome or Safari and click one of the sets, e.g. “Strobist”, it will slide open and the URL will change but you’ll notice that the page doesn’t reload.

It’s worth noting that Flickr uses replaceState instead of pushState – in other words, they don’t add a back-button event. I’m guessing they feel that switching back and forth between opened/closed sets is too small a change for a back-button event (I’d certainly agree with them on that decision), so instead they just replace the URL so if you copy/paste the link to a friend, they’ll see the exact same page that you did.

Another interesting thing is how Flickr still use the old hash-hack as a fallback if you’re running on browsers that don’t support this new HTML5-feature. I predict/hope that a lot of the plugins that help you easily implement the hash-hack will bake this into their core so people with new browsers can start reaping the benefits.

The latest versions of Chrome and Safari already have support for “onpopstate” and Firefox 4 will have support for it as well. Unfortunately, it seems like IE9 won’t be supporting this feature if we are to believe this Wikipedia article (”Trident” is IE’s layout engine).

Check out the W3 specification for more info.

* For security reasons, you can only change the path of the URL, not the domain itself. So you can change anything in the URL after my-domain.com/[change-the-stuff-here.html].

When working with multilingual sites and apps, it is important to have a clean and systematic way to translate strings with dynamic content (like a number or date), e.g. “Showing results from {{date}}”.

Now, this functionality is built-in in frameworks like Rails. However, I recently wanted this functionality in javascript too. I ended up with this fairly simple approach.

Basically you define a translations variable, a hash. Since this is structured data, it could easily be generated from a back-end document or database (to keep all your translations in a single place). Here’s an example:

var translations = {
  'results': {
    'from_date': 'Showing results from {{date}}',
    'header': 'Search results',
    '...': '...'
  },
  '...': '...'
};

Then I wrote this simple function to handle the translations, inserting the dynamic values if present:

function translate(key, hash) {
  string = eval('translations.'+key);
  if (string && hash) {
    var hash_keys = [];
    for (i in hash) {
      if (hash.hasOwnProperty(i)) {
        hash_keys.push(i);
      }
    }
    for (q in hash_keys) {
      regex = new RegExp('\{\{'+hash_keys[q]+'\}\}','gi');
      string = string.replace(regex, hash[hash_keys[q]].toString());
    }
  }
  return string;
}

And now we can just do:

translate('results.from_date', {'date':new Date()});

Which will output “Showing results from Tue May 25 2010 17:19:06 GMT+0200 (CEST)”, where the last part is obviously the current date, inserted dynamically each time you call the translate function.

When you call the translate function, all you have to do is define the translation string you want to use and then optionally pass in a hash of dynamic values. Any part of the translation string that’s encapsulated in two curly-braces will be replaced with the value of the matching key from the dynamic values-hash.

So there we go, translations with dynamic value replacement in javascript.

It should be noted that this solution comes with a fairly strong assumption: the actual language change and setup is handled by the back-end. However, since you’ll likely want to handle language sessions, etc. in your back-end anyways, this hasn’t been much of an issue to us. You’ll likely want to generate the translations variable dynamically too (which was the reason it was defined as a low-level variable).

Yesterday the “internet overlords”, Google, made their open web font directory available for the public. The library contains open-source fonts that you can embed into your website and thereby doing what other services like Typekit etc. are doing as well. I doubt that Typekit and the others are intimidated as they host a lot more licensed fonts which you can lease by subscription via their website, where I can see Google will most likely primarily support open-source fonts. In any case it’s great news for making websites use more than the usual Arial, Georgia and other families – making websites more unique and nicer to look at without using comprehensive font methods or images.

Find out more about Google’s font directory here.

(Photo by Chase Hoffman on Flickr)

Usability studies (qualitative)

You sit down individually with anywhere between 5 and 20 people (preferably all in your target audience, though this isn’t vital), and give the subject a task to complete.

You then observe how they complete this task and ask open-ended questions along the way.

Good for:

• Testing preliminary designs and drafts. Your can even test hand-drawn drafts.
• Understanding your customer’s behavior and reasoning. During the test you can (and should) ask your subjects why they reacted the way they did.
• Testing out structural changes and see how people respond to them. Because you can observe how people use your site and can ask them questions about it, you get a good idea of what information structure makes the most sense to your users.
• Uncovering points of failure. Is a certain form field overlooked constantly?
• Unveil your customer’s expectations. Often your customers will expect your site to work in a different way than it was designed to.

Pitfalls:

• Don’t care about your subject’s opinions. The sample size is waaaay too small to provide any meaningful data on stuff like what colors to use (use a/b split testing instead), so ignore whether your test subjects like the design or not.
• Be careful not to influence your subject during the test. Leading questions and constant interruptions will result in bad data.

When?

These studies should be done during initial drafts and before final design.

A/B split testing (quantitative)

You show different versions of the same page to those people visiting your site, and then measure which version converts the most visitors (convert can mean anything from buying a product, signing up for a newsletter, contacting you, etc.).

Once you have a statistically significant number, you choose a winner and show that version to everyone. You then repeat the process, testing something else. Continual improvement.

Good for:

• Testing specific features. It can be anything:
  • Copy: should the button on the product page read “Buy” or “Add to cart”? Should we write long or short product descriptions?
  • Color: should the headline be black, blue or red? Should we color-code our menus?
  • Images: should we use the image with the baby or the one with the half-naked lady or the one with the 30-something man reading a book? Should the image be big or small?
  • Price: how much do sales decrease if we raise the price by 30%? Do they even decrease? Perhaps they increase because people perceive it to be better.
  • …
• Getting insight on how your customers actually behave. The data is based on what your customers actually did in real life, not what they said they would do during an artificial study.
• Proving one thing works better than another. You will with high statistical probability be able to say that green headlines are better than blue for this site, and be able to show real data to back up your statement.

Pitfalls:

• Can be technically difficult to set up because it is a complex matter juggling around with multiple versions of the same page and making sure the same user sees the same version every time he visits that page.
• Requires a decent amount of visitors to yield statistically valid data which can be a problem for brand new sites from unknown brands.
• Many will neglect to do a/b split testing because it is done post-launch and takes patience to conduct.
• You need clear goals to test. If your goal isn’t directly related to selling a product, you need to look at all parameters and not just “time on site” or “pages visited” as your indicator for success.

When?

These studies should be done after launch (whether it was launch of the entire site or just a specific feature that made its way into production), ideally in a never-ending cycle.

As internet connections and servers get faster, we’re seeing more and more sites using autocomplete to assist their visitors in making complex searches in a snap. Unfortunately, a lot of these sites are styling their autocomplete results in a less-than-optimal fashion. Here’s three guidelines for how to style autocomplete results:

 

Google is a poster child for designing autocomplete results.

1) Highlight the differences, not the commonalities

You should always highlight the differences in your autocomplete results since your visitor will already be aware of what he has searched for. Also, when given a list of results with commonalities, it’s the differences in the results that are meaningful, not the elements that are being repeated (typically the search term).

Unfortunately, many sites highlight the search term – the commonality – as opposed to the differences. The popular jQuery autocomplete plugin even has this as its default styling, which could be the reason why so many people highlight their results this way. (Whenever you use open source plugins, take a second to think about the default styling and see if it actually makes sense.)

Guideline #1: highlight the differences in your results (preferably by making it bold).

2) Avoid visual clutter if results are simple

Unless your typical search result is going to extend over multiple lines, you should keep your results as clean as possible. Just highlight the differences (see the above guideline) and the active row.

Many sites use all sorts of different visual clues to separate even simple results, alternating row colors and horizontal lines being the two worst sinners. This is unnecessary clutter, which makes it difficult for your visitors to quickly scan the results you’re presenting them.

Guideline #2: don’t use alternating row colors and horizontal lines, unless your typical result is very lengthy (longer than a single line).

3) Only show a few results at a time

Don’t show anymore than 10 results, you can show more results on your actual search page, and if your your typical result is more than a single line you should probably show even less results in the autocomplete.

Autocomplete results are for quickly making a complex search query or selecting a specific item from a list of possible options. It shouldn’t be considered a replacement for an actual search page. Also, a visitor looking for very specific results will have no trouble finding them since she can quickly filter out everything that’s irrelevant by typing in a few extra characters.

Guideline #3: only show 10 or less results at a time (use a dedicated search page if you need to display more).

Show me the meaning

All of the above guidelines are about emphasizing the meaningful data. You want to put that in the spotlight and have everything else fade into the background (or not appear at all).

When getting back a list of suggestions for better search queries, it’s the differences in those results that are meaningful. When reading a list of search results or suggestions, it’s the text of each result that’s meaningful. And of course, when searching a huge database, it’s only the 10 most relevant results that are meaningful.

Good design is about emphasizing the meaningful data. This goes for styling autocomplete results too.

The majority of applications available in the iTunes App Store is displaying information from the Internet, and those applications need a way of refreshing their data.

There are three widely used interface design approaches:

1. The simple and effective refresh button
   «TweetDeck for iPhone» has the simple and very effective refresh button in the tab bar. Other applications like the «New York Times» have the refresh button in the application top bar.
   Such a refresh button is very easy to spot, but of course takes space from these two bars which could be used for other controls.
    
   

 

2. The hidden, clickable item in a scrollable view
   As seen for example in the Facebook application, there is a hidden, clickable item in a scrollable view where the user has to scroll to the top and then tap on the item to invoke a refresh.
   This solution is hard to find when using it for the first time, but once found, it’s a very neat way to save some space for content or other buttons.
    
   

 

3. The hidden item in a scrollable view without tapping
   The guys behind Gowalla took Facebook’s solution a step further and just cut out the tapping part. The user only has to scroll to the very top and a bit further to activate a refresh.
   The problem that this functionality is hard to spot still exists, but once used, it is in my point of view the most intuitive and therefore most preferred solution.
    
   

Wildcards in Ruby’s regular expression (reg-ex) are by default greedy, meaning they will capture as much of the string as possible.

Let’s say you have to parse some strings which will be either “Sweet entertainment!” or “Great entertainment!”. Now, for the sake of this example, let’s say you want to grab the first word of these strings (”Sweet” or “Great”) using a regular expression with wildcards.

If you wrote the regular expression like this /^.*t/ it would capture “Sweet entertainment” because it’s greedy by default, so everything up to the very last “t” will be captured, hence, “entertainment” is included too.

Luckily, there’s a simple way to make your wildcards non-greedy: Just append a question-mark to it like this: /^.*?t/. Now, the wildcard is non-greedy and you get the wanted outcome “Sweet” or “Great” without the “entertainment” part.

The highlighted characters represent the matching part of the string:

/^.*t/ = “Sweet entertainment!”
/^.*?t/ = “Sweet entertainment!”
/^.*t/ = “Great entertainment!”
/^.*?t/ = “Great entertainment!”

So there you go. Just append a question mark to the wildcard to make it non-greedy. This rule also applies to the plus character, which by default is greedy too, but can be turned non-greedy by appending a question mark the same way: /^.+?t/.

A few days ago I had to implement some check boxes for a back-end system and I realised just how badly check boxes are labeled online. Most of the time, it’s actually really difficult to predict what impact it will have to leave the check box ticked or unticked.

In my case, the check box represented the ability to hide a page from all navigation on the site so it would effectively be a “hidden page” (yet remain accessible, so you for example could send people to this special page from an ad campaign without making it an integrated part of the entire website).

So in the page’s settings area, there was a check box which you could use to either hide or display that page in the site’s navigation. If the check box was ticked the page should be hidden from all navigation.

Below is the 4 iterations I went through in an effort to clarify what outcome you as a user would expect when leaving the check box either ticked or unticked.

1. Absolute nonsense

Now, by default the label name was mapped to the name used in the database, in this case “Menu hide”. Not very meaningful, at all. In fact, this was complete nonsense and the check box was also on a new line which seemed a bit strange. As a user, you had no idea what the check box would do unless you yourself coded the system. Rubbish!

2. Better, but far from good

I started by changing the label to something more meaningful – “Hide this page from the navigation”. Better, but still not crystal clear what would actually happen when the check box was ticked. Also, the check box seemed a bit lonely, being on a new line all by itself. The label was also difficult to scan because it was quite lengthy, which was a problem since there were 5 other fields (with their own labels) on this page, so getting a quick overview of your different options would be difficult without brief labels.

3. Close, but no cigar

So I had to make the label shorter. Then it hit me: why not put a longer description after the check box and then shorten the main label above? I gave it a quick stab, putting “Don’t show this page in the navigation” next to the check box in a slightly smaller font, indicating that this was a more detailed, secondary description. I also shortened the main label to “Hide this page” to make it more scannable. This definitely had potential since the labels that were now scannable yet also had an in-depth description of the outcome you should expect when ticking this check box.

4. Great

Still, the labels were still a bit unclear. There could still be confusion as to whether or not the ticked-state would hide the page or display it. Also, the two labels didn’t seem to interact, so there was obviously room for improvement in the wording.

After a few short iterations and a quick chat with Casper, I ended up with the final version, where the main label asked “Hide page?”, and the secondary label answering “Yes, hide this page from all navigation”.

The previous “Hide this page” label was actually a question, yet it didn’t end with a question mark which was confusing (and grammatically incorrect). Also, the “this” in “Hide this page” was a bit redundant, so I removed it to make the main label even more scannable. After these two changes, I ended up with a really concise question as the main label: “Hide page?”

With this change in place, I suddenly had an obvious way to make the two labels interact – by answering the question! To make things super clear, I answered the question with an unambiguous “Yes, …”. Now it would be really obvious that when the check box was ticked, the page would be hidden because it was now a question with a very clear reply: “Hide page? Yes.”

There was still one last problem, though – the secondary label was written in negative-form: “Don’t show this page in the navigation”. This didn’t make sense with “Yes” in front of it, but also – and this was more critical – the label told you what you didn’t do.

When you have a yes/no question you don’t want the label to be written in negative form, since people will then have to juggle around with the fact that yes means no, and no means yes. Or wait.. does it? By using a direct word like “hide” instead of “don’t show”, I got rid of any confusion and the final version of the secondary label would read: “Yes, hide this page from all navigation”.

Here’s the final result: “Hide page? Yes, hide this page from all navigation.”

Nice and clear. (It definitely beats “Menu hide”.)

Within only a few days, Russell Quinn’s new iPhone app developed for the San Franscisco indie publishing house McSweeney’s attracted mass attention via Twitter and managed to beat the iPhone app from bestselling American author Dan Brown on the U.S. iTunes App charts. So what’s so special about this app?

What can I use your iPhone application for?

McSweeney’s is a multi-media subscription app. Actually, it’s pretty much the first multi-media subscription app on the market! The purchase price includes a 6-month subscription and each week you’ll be pushed a new piece of content. This can be a film, a short story, an interview, a song, some artwork, or… well it’s pretty flexible. As well as this, you get daily updates from the McSweeney’s website, which will continue even if your subscription lapses.

How has the application been received following the launch?

We had a pretty wild launch night. There was lots of activity on Twitter and other social networks that propelled us to the number 1 spot in the books category (U.S. iTunes) beating Dan Brown’s new app. Since then sales had been stable and there’s been a lot of media interest in how McSweeney’s is pionerring such a new format. We had coverage on several major websites and I was interviewed by the Journalism Lab at Harvard University.

What will you focus on during next rounds of updating the application?

We have many exciting ideas for future versions. We really want to push the app in lots of new directions. Currently these are all secret, not for any other reason that we want them to be a surprise.

Have you considered making your application available on other platforms?

The McSweeney’s brand fits wonderfully on the iPhone I think and currently we’re too tired from the current launch to think about other platforms. However, we’re not ruling anything out.

What do you think the future of mobile applications holds?

Subscription-based publishing is fascinating, as is the rumoured Apple tablet.

Read more or head directly to McSweeney’s in the App Store.

Mr. Andreas Zecher – the key force behind our recent Stromzukunft game and declared game enthusiast – recently launched Mr. Bounce for the iPhone platform. Read his thoughts about the captivating game and find out where he thinks mobile gaming is heading.

What is your game about and how is it different from other iPhone games within the same category?

Mr. Bounce is based on the classic breakout game genre, but we throw in a couple of things to make the gameplay feel fresh and unique. We put the player into an unstable environment, where the ball bounces off simply everywhere. In return the game offers very precise control mechanisms like slowmotion and trajectory projection. So chaos and control are the two poles of the game.

We have a very coherent style with the game, both visually and musically. The music also plays an important part in the player’s motivation: We reward the player by building up the music successively with each level, supporting the flow of the game.

How has the game been received following the launch?

We got roughly a dozen of reviews during the first two weeks, the majority of them being very favorable. We also got some positive responses from players on Twitter and Facebook who really like the game.

What will you focus on during next rounds of updating the game?

We are planning to do more levels including new music tracks in the future, possibly with new game elements as well. We are also thinking about an online level editor, so people can build and share their own levels, but nothing is decided yet.

Why did you choose to target your game to the iPhone/Apple segment?

The App Store offers a very good infrastructure for selling your product instead of being dependent on revenue from advertising, which is the case with Flash games for example. The original Flash version of the game also looked very suitable for the iPhone. A lot of players told us that they prefer the touch controls of the iPhone over the keyboard controls from the Flash version. It is a more intuitive and direct game experience.

Have you considered making your game available on other platforms?

We currently have no plans to port the game to other platforms, but the Flash version is still available online at http://www.pixelate.de/games/mr-bounce.

What do you think the future of mobile gaming holds?

We are already seeing the rise of independent games on the PC, where developers experiment with new, innovative ideas, new art styles and sometimes also very personal games. I believe we will see more of that on mobile devices like the iPhone in the future as well.

Get started on the bouncing: http://www.pixelate.de/games/mr-bounce-iphone/