CountryEx’s current dashboard

As you may be aware, I’m creating a stock trading game called CountryEx for my final year project at university. It’s been in development for over six months and last week I opened it for a private beta test.

Since CountryEx is a social game in which every player’s actions affect other users, it’s impossible to properly test without real people playing it. Getting feedback while the game is still in development is also a huge bonus since any flaws can be ironed out before it’s exposed to the general public.

The numbers

So far, I’ve recruited over 40 friends and users of the Thunderbolt forums and the game has been running 8 days. In that time, the traffic it’s received has been remarkable. Google Analytics has logged over 12,400 page views, which works out to 33 page views per person per day. The average visit time is over 18 minutes and the average number of pages viewed per visit is over 16.

An individual country

It seems that I’ve got people addicted. While this was never a goal I had in mind, it’s apparent that the success of any game like CountryEx relies on keeping players interested over a long period of time and encouraging them to return. At the moment, it seems that the ability to compare scores with other players and the predictable nature of updates are two of the most compelling features, but perhaps it’s best to save the subject of designing for addiction for another article.

The road to a public launch

There’s still plenty of work to be done on CountryEx before it can be unleashed on the public. Key pieces of core functionality like dividends and user profiles are either still being developed or have just been added with little testing. Time also needs to be taken to properly balance the game and adjust the various models that control how the it alters over time.

I’m currently targeting a full launch at the end of the month. If you’d like to get involved with testing, please get in touch and I’ll give you access – all you have to do is play the game, nothing more. If not, then follow CountryEx on Twitter and stay tuned for updates.

Let’s play a game

Can you recognise which websites these screenshots belong to?

How did you do?

Anyone who’s used these sites should immediately recognise their distinctive styles. They are, of course, BBC News, Facebook, The New York Times and Wikipedia.

The importance of identity

What that hopefully demonstrates is that a website’s identity is not simply its logo, but the entire design. Identity is not just a small trademarked name or symbol, but all of the other details that define its visual style. It’s the typography, the borders and lines, the use of colour and images.

Within specific industries, identity is even more important. Standing out from your competitors is crucial and so you need a recognisable visual style. This is one area in which I believe Microsoft made a huge mistake when they launched Bing.

Compare these two screenshots:

Which of these is Google and which is Bing?

It’s hard to tell at first, because Bing’s visual style (top) is an almost exact copy of Google’s, which is one of the most recognisable on the Web. When you see Bing’s search results, you don’t see Bing, you see Google.

Perhaps Microsoft would interpret this as what search looks like, not what Google looks like, but either way it’s a telling sign of the extent of Google’s influence.

Designing the visual style first

If you accept the premise that a website’s visual style is comprised of and defined by many things and not just the logo, then this allows you to change the way you design. Instead of creating a website to fit a logo, you can design a logo to fit your website.

Thunderbolt’s design is unique because we pay particular attention to the legibility of our articles and because we don’t have any adverts. Where other videogame websites are cluttered and overwhelming, ours is clean and tidy. Consider this comparison of another videogames website and Thunderbolt:

When it comes to redesigning a website, it’s okay to change the logo if you retain the visual style. That doesn’t mean copying it exactly, but making sure that certain details are recognisable. Take, for example, the current and new versions of Thunderbolt:

In the second, development version, there are a number of changes to this area of the design, but it still looks like Thunderbolt. The background and font size may be different, but by using the same border styles and typeface, we retain the aspects of the design which define our identity.

You are not your logo

Logos are an important part of any organisation’s image and are a useful communication tool, but on the Web, they aren’t alone in defining identity. The other 99% of your visual style is what makes you truly recognisable and what you should be more concerned about.

This exercise proved to be interesting not only because it was the first of its type that I’d done, but because it exposed the vulnerabilities of designing with assumptions when such a wide range of people are the target audience.

Dealing with the ‘obvious’

During one of my studies, I asked someone to walk me through the process of importing a photo from a camera to their computer, as they normally would. Of the entire process, the following screen caused by far the most problems:

At first glance, this looks fairly straightforward; you choose a name and pick a folder, then click “Next”. However, what may be obvious for some of us might not be for everyone else.

When I asked the participant about this screen, he mentioned that he didn’t know what the “\” symbol meant. For people who have grown up with computers, this is immediately recognisable as a folder separator. With this knowledge, the assorted letters in the drop-down are a clear file hierarchy, but without it, they’re simply a jumble of words. If you didn’t know what a backslash represented, which would you pick?

Designing with assumptions

So how can you design around problems like this? First of all, you need to know your audience. In this instance, the target audience includes anyone that takes photos and uses a computer, so it’s extremely broad. On the other hand, you might be designing an interface for a very narrow audience, such as medical professionals.

Understanding who will be using your product is essential because the number of assumptions you can rely on is inversely proportional to the size of your audience. In other words, the more varied your audience is, the fewer assumptions can be made.

If you’re designing something with a tightly controlled user group like a commercial airliner, you can almost guarantee that they will know certain things. However, if you’re working on a screen like the one above, you have to greatly reduce the user’s assumed knowledge.

To conclude

Almost every task we’re faced with in everyday life relies on using assumptions that we’ve learned. When you use a new toaster for the first time, you assume that by pushing the lever down, it will toast bread.

This is obvious, but what if you didn’t know that? Are there affordances and clues that allow unfamiliar users to operate it? How would you learn about that common, assumed knowledge for the first time? Asking similar questions about your user interfaces often pays dividends.

Of the most commonly available methods for visualising data, radar graphs seem to be the least used. When I asked for examples on UXExchange, there were very few that people could think of. So what makes people avoid them and why are they so rare?

Under the radar

When you look at a radar graph, it’s easy to appreciate their limitations. Less than three items and they become useless, but add too many items and they quickly turn into a mess. Although adding elements to a bar graph increases its size in one axis, doing the same to a radar graph forces you to expand its height and width so that it doesn’t become unduly cluttered. The data also needs to be on the same scale for a radar to be used.

Stephen Few explored these deficiencies in an article (PDF) in which he contrasts the relative readability of a radar and bar graph using the same data. As he points out, it’s more difficult to determine the value of each radar graph point because you have to count the number of bars on the axis and compare it to the scale provided. The ordering of the items is also unclear, since the radar has no obvious beginning and end.

In this example, it’s clear that the more commonly used bar graph is far superior to the radar graph and that the latter offers no perceivable benefit. However, this is not the full story.

Effective use in videogames

Persona 4

There’s one place where radar graphs appear far more often than you might expect and that’s in videogames. When I asked for examples on the Thunderbolt forum, I quickly got half a dozen instances of their use. These were not just confined to a particular genre either, but a whole variety of games.

The key difference between the type of radar used in videogames and Stephen Few’s examples is not the type of data that’s visualised, but the level of granularity. In the previous example above, the radar graph is inferior because it’s difficult to compare the absolute values in the data. However, in videogames, radar graphs are not intended to be measured, but are merely an indicator of value.

Football Manager 2010

When radar graphs are used in games, the absolute value of each point is not important. They also have scales which have a finite end and so are always percentages, as opposed to the data used in Stephen Few’s example. This means that you can determine a value by merely glancing at the graph instead of having to understand the scale and use that to estimate the associated value. If the point is about half way along the axis in a game, it’s about 50%. In the previous example above, doing the same is much more difficult.

Other potential uses

In videogames, it’s not the absolute value of a particular point that is important, but the overall size and shape of the graph, which can be recognised quickly. This characteristic lends itself to other applications where monitoring changes is critical. Imagine patient data in a hospital or temperature values in a nuclear power plant. If these were visualised as a radar graph and people learned what the graph’s normal shape and size should be, then spotting changes could be easier than a table of numbers or a bar graph.

Radar graphs in CountryEx

Radar graphs have also proved useful in an interface I’ve been designing. In my university final year project, CountryEx, there are countries which have a number of statistics associated with them. Players of the game need to be able to look at a country’s page and quickly analyse it, but a simple list of numbers doesn’t make that easy.

So above this simple list, I’ve included a radar graph. Like the other examples from games, my graphs have no scale or exact numbers, but are merely an indicator that can be glanced at. The fact that all of the statistics are out of 100 also makes this particularly applicable. In theory, players should now be able to easily check how developed a country is. However, whether this method of visualising information is actually useful will have to be determined by a usability test at a later date.

In conclusion

Although radar graphs may perform poorly when used to represent the majority of data, videogames show that they can be effective. If the information you need to visualise fits within the limitations of radar graphs, then give them a chance.

It’s a reasonable question; last year, Thunderbolt had over 3 million page views from over 600,000 unique visitors. Sure, it’s not anywhere near the numbers that the big sites get, but it’s enough to make a few thousand pounds a year. So why don’t we?

Adverts suck

Adverts frequently overwhelm other content.

The only people that like adverts are advertisers. In almost all cases, they’re a unwanted distraction that detract from the user experience. The larger game websites like Eurogamer are plastered with adverts and it’s often overwhelming.

There’s value in more than money

As a volunteer-run website, we have the luxury of choosing how to use Thunderbolt’s popularity. We could make money directly from it using adverts, but there’s also value in not doing so.

Since the site isn’t covered in adverts, it’s more pleasant to read and this is a great incentive for people to return. The lack of adverts differentiates us from commercial sites and gives us an edge over them.

What would we do with the money?

What would Scrooge McDuck do?

Like any organisation, we have bills to pay and we need money to do that. While commercial sites have costs that run into the tens of thousands, Thunderbolt costs around £70 a year to run. We can easily cover that through donations and our small Amazon Associates earnings, so there’s little need for us to have adverts.

But what if we did? The most obvious thing that we could do is to employ someone full-time. If we only paid the minimum wage, this would still cost around £15,000 a year with all the legal and other overheads. With the traffic that we have right now, we would fall well short of that mark.

This gap between the amount of money that you could make and the minimum amount that is actually useful to have is sizeable. Sure, there are things that we could do with less money, but would their value be greater than the value of not running adverts and compromising our site? I don’t think so.

A matter of principle

Walt Disney was a smart guy.

Walt Disney once said:

“We don’t make movies to make money, we make money to make more movies.”

There are few better ways to sum up the alternate mindsets of creative work. This isn’t just a fancy but pointless quote though; the difference between websites that write articles for money and those like Thunderbolt is huge. It’s a gaping chasm. A vast gulf that’s hard to miss.

When you rely on advertisements to pay the bills, you need page views and lots of them. Before you know it, they start to influence your editorial and design decisions. Why write a thoughtful opinion piece when you could knock up a ‘top ten’ list that would get five times the traffic? Why keep articles to a single page when you can force people to click through several to read the entire article? Why research an article properly when you could write two in the same time?

If you run adverts on your website, you immediately have a fundamental conflict of interest. To make money, you have to put as many adverts on your site as possible and get those all important page views. To please your readers, you have to maintain the quality of your content and not compromise the user experience. This battle is impossible to win.

By avoiding adverts, we only have one master to please at Thunderbolt: our readers. That’s a battle we can win.

However, by concentrating on blind users, we may be missing an even greater problem: colour blindness. While around 0.3% of the UK population is registered blind and a similar number partially blind, 3% of the UK population is colour blind. This problem is especially prevalent in men, with 1 in 20 suffering some kind of colour vision deficiency.

Types of colour blindness

Before we can design around the issues that our users may have, we first have to understand the different types of colour blindness. Let’s first take a look at a quick example, the Google logo. For users with no colour blindness, it looks like this:

The most common form of colour blindness is a deficiency called deuteranopia, which makes it difficult to distinguish between red and green. Here’s the Google logo again, this time viewed with deuteranopia simulated:

As you can see from the last two letters, red and green, two colours which are commonly used to designate very different things, are almost indistinguishable. Another form of red-green blindness is protanopia, which produces similar results:

A rarer form of colour blindness is tritanopia, which makes it difficult to distinguish between blue and green. Here’s the logo again, this time with simulated tritanopia:

As you can see, the ‘g’ and ‘l’ which are very distinct for people with no colour blindness are practically indistinguishable for someone with tritanopia.

These are by no means the only forms of colour blindness. In even rarer cases, people suffer from achromatopsia, or total colour blindness. With this, people can only see things in shades of black, grey and white.

Designing for colour blindness

One of the most important things to consider is how colour is used on your website. Colour is commonly used to show meaning, such as green for positive and red for negative. This is fine, but problems begin to appear when colour is the only way you’re showing this meaning.

Let’s take the BBC’s Celebdaq stock trading game as an example. It has lists of celebrities and how their prices have fluctuated. This is how it looks for people with no colour blindness:

Now contrast this with simulated deuteranopia:

Although the meaning given by colour is now gone, the arrows retain this information. If these symbols were removed, the list would be next to useless:

So one key rule when designing for colour blind users is don’t use colour alone to communicate information.

You also have to consider how these colour changes affect the contrast of text and images on your websites. What might be perfectly legible for you might be impossible to read for someone else. Noticing when this might be the case isn’t easy though, but fortunately there are some free tools available which make it easy.

Tools to test for colour blindness

One of the best tools on the web is Vischeck, which renders a simulated page for three of the most common conditions. Another excellent resource is the Colorblind Web Page Filter, which has a greater number of conditions and allows you to change between them while browsing a site. A newer and slightly different tool is Check My Colours, which lists all of the page elements and checks them for contrast issues. These aren’t the only tools, but they’re a great starting point.

To conclude

There are many colour blind users and probably far more than you might think. By using the free testing tools available and follow a few simple rules, you can dramatically improve the experience colour blind users have on your website.

More info and references

• Department of Health statistics
• Colour vision deficiency at the NHS

When I founded Thunderbolt over nine years ago, the web was a very different place. There was no Facebook, MySpace, YouTube, Flickr or even Wikipedia. Nine years is a huge amount of time on the web and most sites don’t manage to last half of that, especially smaller ones. So how did we manage to keep our little website going and grow it into what it is today?

Our greatest asset is also our biggest problem: people’s time. We’re a volunteer-run site and all of our editors are employed full-time, either at regular day jobs or as students. Even with six editors capable of publishing articles, it could be hard to keep up with the constant stream of articles. However, over the last couple of years I’ve worked on making Thunderbolt sustainable by slimming down our publishing workflow.

Analysing the submission process

Let’s first take a look at our workflow from three years ago:

1. An author writes their article.
2. They post in a private staff forum.
3. Other writers peer-review the article, checking for typos, grammar and other errors.
4. The author submits the article in the content management system (CMS).
5. An editor finds suitable images on the web and downloads them to their computer.
6. Screenshots are renamed.
7. Then resized.
8. Three header images are created.
9. All of the images are uploaded to the CMS.
10. The editor adds the image HTML to the article.
11. The article is given a final check and then published.

As you can see, it can add up to a lot of work! There are some things that we can’t remove or trim down though. Articles still have to be proofread, images need to be found and the data needs to be input into the CMS one way or another. However, we have managed to remove the most time consuming part of the process; sorting out images.

Image finding assistance

The new image finding tools cut down on precious seconds.

The first task is to find suitable images and this is done by checking multiple websites. Depending on the obscurity of the game and the availability of watermark-free screenshots, this can take easily become the most time consuming part of the whole process.

We generally look for images on three websites and for each one, the editor used to have to do the following:

1. Select the title of the game.
2. Copy the text.
3. Open a new tab or window.
4. Go to the website they want to search.
5. Find the search bar and paste the text into it.
6. Click the search button.
7. View the results and pick appropriate images.

Much of that process is unnecessary and when you consider that we might do that three times per article, it can add up to a lot of time. However, we’ve managed to eliminate almost all of the steps above with a simple addition to our CMS. When you open an article to edit, there’s a box in the sidebar called “Find images”. This contains links to search result pages on the sites we commonly use, with the search query automatically filled out in the URL. The video below shows the difference between this process before and after the “Find images” box was added.

Automatically processing images

In the old CMS, once an editor has saved screenshots to their computer, they had to rename each file and resize them to the correct dimensions. This could take several minutes, significantly adding to their overall workflow time. In addition to screenshots, header images must be created. These come in three sizes, each of which has to be created.

However, in our current CMS, the image uploader does all of the file renaming and resizing of screenshots. It also creates one of the three header images automatically. Editors still have to create two of those header images, but this isn’t too bad when you don’t have to edit a bunch of screenshots as well.

Highlighting the current state of articles

When new articles are submitted by writers, they appear at the top of the CMS’s homepage in a large red box, showing editors that they need to be published. I started to notice an interesting pattern of behaviour around this though. Sometimes writers would prepare and upload images themselves before submitting them to the CMS. All editors had to do was click one button to publish the article. However, those articles which were ready never got published any quicker.

The reason behind this was that editors associated the same amount of time with every article. If they saw an article in the CMS that needed to be published, they would wait until they had 15 minutes spare to deal with it. They never knew that it was ready to go because they assumed that all unpublished articles need images.

To solve this, I added a simple icon to the list which indicates what state an article’s images are in. At a glance, editors can now see if the screenshots, the header images or both are ready. Now if writers prepare their own images, their articles are published quicker, which is a great incentive to do so. The by-product of this is that editors have to prepare fewer images and the workload is more distributed.

Every second counts

When you’re running an organisation staffed entirely with volunteers, every morsel of time that they contribute is precious. Recognising which parts of our workflow were the most time consuming and streamlining them has been one of the main reasons why we’ve been able to make Thunderbolt sustainable. Concentrating on removing actions that add seconds to a process can mean the difference between it taking 3 minutes or 10, and can reap huge rewards in the long run.

When I was in Edinburgh last May, I met Philip Roberts, who handled the development for the games website SquareGo at the time. It was the first time that I’d talked to someone who does a similar job to what I do at Thunderbolt and it was incredibly interesting.

Over a few drinks, we chatted about website design and development, recruiting and motivating volunteers, games PR and a lot more. It was refreshing to talk to someone else who does the a similar job and faces the same issues that I do.

People who run sites like ours rarely speak to each other. Sure, there are a few forums, but on the whole, we don’t share that many ideas. I’ve been running Thunderbolt the way I have, not because of some established best practise, but because that’s just the way that I’ve figured out to be the best.

There isn’t somewhere you can go to read about how the most respected sites are run and how they’ve become a success. While web designers have sites like A List Apart and 24 ways, people who run videogames websites have, well, nothing.

So in the summer, I got in touch with the guys at DarkZero and Gamestyle about starting an organisation for our kind. I chose these two sites because I feel they have the same core values that we do at Thunderbolt.

The result of our discussions is The Association of Independent Game Websites. As you can see from the website, the AIGW’s goal “is to support non-commercial videogame websites, provide their owners with a place to exchange ideas and promote best practises.”

We haven’t sorted out exactly how the AIGW will be run and what we’re going to first, but we’ll be meeting up in London in March to do so. If you’re interested in the AIGW, check out the website and follow us on Twitter.

Perhaps you won’t have noticed it, so let’s first take a look at what the message toolbar used to look like:

Looks fine, right? Well focus on the right hand side, where the buttons are for navigating between messages. Without proper labelling, these are ambiguous. Does the left arrow take you to an older or newer message? It’s not clear at all and Facebook aren’t the first to fall for this.

This left and right button layout also doesn’t tie into the mental model of how the Facebook inbox works. When you’re looking at all of your messages, they’re stacked on top of each other. When you’re looking at single messages, you’re moving up and down the stack, not side to side.

So how did Facebook solve this problem? By simply switching the navigation buttons around:

Now when you look at them, it’s obvious where the buttons will take you because they conform to the mental model of the inbox. It’s a straightforward solution to an otherwise tricky problem.

The most direct competitor to Coda is Espresso, made by the same guy who created the outstanding CSSEdit. After using Espresso 1.1 for the last four days solid, I thought I’d write up my observations and compare the two.

Things that Espresso does better

When you’re working on a website, you’re usually concentrating on writing a handful of files at a time. In addition to these, you open others to check code in them and use them for reference. In Coda, all of the open files sit in tabs, like you would have for a web browser. However, this means that the files you’re most interested in working on are equally important to the ones you’re just referencing.

The workspace is where the files you’re working on right now live.

Espresso has a different approach. Instead of tabs, it has a workspace, where the files you’re really interested in live. Below this is the normal file view, but when you click on something in that, it just shows you it, but doesn’t seem to open the file properly. I found this workspace metaphor far more natural than the traditional way of handing files, as Coda does.

When you upload files in Coda, they are processed one at a time, or at least it seems that way. In Espresso, they are transferred in parallel and much quicker, especially when you have a few of them. Espresso also allows you to have multiple servers per project/site and lets you upload a file instantly whenever you save it.

Espresso’s quick PHP function lookup is also much faster and more convenient than searching Coda’s books, which are cumbersome at the best of times.

Where Coda still has the edge

Coda (1.6.8 tested here) has built in SVN support, a console window and a visual CSS editor, all of which Espresso lacks. You can also easily alter the colour and typeface of code in Coda, but not in Espresso, where the default font size is one size smaller than I’d like it to be.

Although the tabs metaphor falls apart when you do this, splitting the window can be very useful.

Coda also allows you split each tab so that you can have two windows side by side. This can be extremely useful, allowing you to compare files or preview changes right as you’re editing code. The tab metaphor falls apart when you do this, but it’s still a feature that once you start using, you can’t imagine not having.

Although Coda’s file upload is slow than Espresso, it does a far better job of keeping track of the changes you make. Whenever any file is changed, a little ‘Publish All’ button appears and when you click it, files start transferring immediately. In Espresso, you have to review changes made – which can take several seconds – before you can upload files.

There are a number of little details in Coda which are also a huge help. Whenever the text cursor crosses a bracket, it highlights the other bracket it’s linked to. When you’re code becomes fairly complicated, this is an invaluable feature. There’s also a plug-in available which can quickly add PHPDoc tags to your code and does so in a superior manner to the equivalent function in Espresso.

So which is it to be?

Over the last four days, I enjoyed using Espresso immensely. However, now that I have Coda working again (thanks Panic!), I’ll be returning to use it.

Espresso is an awesome program whose workspace metaphor is simply better than the tabs used in Coda. It’s so good that it almost negates the many features that Coda has which it simply doesn’t. However, the overall impression I have is that Coda’s maturity shows through and right now, you’re probably better off choosing it. That said, once Espresso has some of the features that its competitor does, it may be a proposition too tempting to resist.