Thunderbirds Are Go

Well folks, after the last few weeks of promising an update the day is finally upon us. Today sees a pretty significant update to Five Second Test both in terms of functionality and aesthetics. While there is a great deal of new stuff going on under the hood (almost a month's worth of full-time work) I'll go over some of the more exciting features that will benefit our users. First and foremost, the site has undergone as significant visual overhaul. What started out as a redesign of the manage page to make it more useful turned into a site wide redesign. We have tried really hard to try and make creating and doing tests more intuitive and effortless than before. Most noticeably the test manage page now offers a great deal more in terms of actually managing tests, offering the ability to share your test links, delete tests and even toggling whether it's public or private after you have created it. The biggest new addition is the introduction of premium test upgrades. Test creators are now able to upgrade a test with purchasable tokens to increase the rate and quantity of responses from random testers. We know give a sumary of site wide test stats for the week right on the manage page. This allows people to see at a glance how many responses they can expect to get based on site activity and how quickly they will be getting them. We wanted to ensure that while creating and running tests always remains free, people who are willing to support us get that something extra. Additionally the test results page now has an extra little bonus. When a registered Five Second Test member helps you out by doing your test, you will be able to return the favour and do one of their tests by clicking on their name. This is the first step towards what we're calling our karma system where users will be able to reward each other when they do each other's tests. Be sure to watch this space as there is still more to come. So far I've only mentioned a few of the new and exciting additions to the site but I don't want to spoil the fun by going over every detail. Instead we encourage you to explore and rediscover the site on your own. As always we appreciate your feedback and look forward to hearing what you have to say. Happy testing! update coming soon...very soon!

We've been working hard on the latest update to We've made a lot of changes, many of which won't be visible in the update, but there are some fairly notable changes that WILL be visible in the next few days. The first major change is the addition of Premium tests. Yes, we all knew it was coming eventually! The first thing I have to mention is that our free tests will remain free in exactly the same state that they are now, and will forever remain free! Premium tests, however, give you three benefits (with more to come!). 1. You will receive double the number of responses given to free tests. 2. You will receive your results much quicker than free tests. 3. You get to feel good about supporting! One thing, that hasn't been terribly clear in the past is that tests don't keep getting results forever. Whilst it may seem a little unfair, currently most tests will receive about 12 results. We don't decide this, it is a factor of how many tests are created versus how many responses are given. At the moment, that ratio is 12 to 1. That means for every test that is created today, 12 tests are viewed. The upshot of this is that we spread the love evenly, ensuring that all users get roughly the same number of results. For some people, 12 results isn't enough, whilst for others 12 is plenty. So we're giving you the choice. Upgrade if you wan't, but don't feel obligated! Keep in mind this also about the speed in which you get your results, not just the quanitity! The astute among you may realise that if premium test are getting MORE results, then everyone else must be getting less! You'd be correct. Partially. Another thing we're trying to do in this release, and more so in the future, is promoting the idea of Karma. We're letting you see who is doing your test, to give you an opportunity to do theirs in return. At the moment this is purely to help you help those that helped you. In the future, their will be benefits to your kindness...and yes we ARE watching who is being naughty and nice. Another feature we're adding is the non-repetition of tests. Once you've done a test, you should never see it again. If you do, one of two things has happened... someone has created multiple tests that LOOK the same, or my code is which case, let me know!! We've now added a really nice manage page. This is a central location for managing your tests. Here you can enable, disable, upgrade, share and delete all your tests. In the future we'll be adding more features here, for example, the ability to get results in your inbox, or subscribe to an RSS feed for a test's results. We haven't changed the actual test process too much, although we've made it a little quicker for people who've seen the instructions before, you won't have to sit through them again. The upload process has been revamped to clean up our front page, and we've changed how we show site activity on the front page. There have been a lot of other little changes here and there, and a lot of changes in the background that will enable us to release some much requested features in the near future. Anyway... this is just a heads up! Matt will be giving another update when we go live, which should be in the next few days! Cheers and thanks for your awesome support to date! Angry Monkeys

Yes we ARE still working!

It's been a while since our last version of, and for that we're sorry. We are working hard though, I promise! We hope to be providing a major update in the next couple of weeks. This will include a newly designed front page, manage page, results page and well...pretty much every page! In addition to that, we'll be including a couple of new features. These are top secret at the moment, but we'll give you another update early next week with some more details! In the meantime, keep sending in your feedback! Whilst we may not always respond as timely as we should, we always read and take note of your ideas and suggestions! would be a lonely place without you guys, and for that we thank you! We'll be back with another update next week!

How game designers can help application developers : Part 2

Last week I discussed how application developers often forget to think about the user in ways that would seem farcical in game development. If you didn't read it, go back here first and have a read! This week, I'll go into more detail about how the lessons learned from developing games (or even playing them!) can help you create better web applications. There is a great presentation by Dan Saffer here which I think is well worth a read. He speaks in some more depth about some of the topics I will brush over here. The crux of the problem for application developers is that an application is developed with an end result in mind and the experience of how the user gets there is secondary. In game development the process is obviously the other way round. The objective in a game is generally secondary to the experience. Often a game has NO objective other than the experience itself. So, going back to my example from last week of an RTS with an impending onslaught of enemy forces. In a poorly developed game, it may be possible to build the structures and forces you need to fend off the enemy, but it may not be enjoyable. If a game isn't enjoyable no one will play it. In application development we all to often say, "yeah it may be clunky...but it works". Just "working" isn't acceptable any more, if it ever was. Your application needs to engage, excite and promote word of mouth. Particularly if you're a startup, and particularly if you don't have a big marketing team to get out there and spruik the value of your software. As discussed by Dan in his presentation, we need to focus on making the user happy. In particular we need to make sure we aren't requiring too much of our user's: a) time b) effort c) attention In our RTS if we require too much from the user of any one of these things, the game will cease to be enjoyable. Things which take too long to do, are too hard to do, or require too much focus aren't fun. This is as true for applications as it is for games. Whilst our application may never be "fun", it should at least be enjoyable. Is your app too time consuming? Think of how annoying games can be with long load times before every level. Think of how bad it looks when an in-game menu stalls before loading. Think of how frustrating it is when you need to perform an action in the game and you lose simply because the action took too long for the game to complete.
  • Look for interfaces which are used frequently, or systems that involve repetition.
  • Can you cut down on page reloads? Perhaps look at AJAX to load sections of data rather than reloading the entire page. If you're using .NET do your controls NEED to do a postback??
  • When asking the user to add multiple items can you get them to add them into a list and then hit enter instead of "click add - type - click ok, click add - type - click ok, click add - type - click ok".
  • If you're building a web app, make sure you're pages aren't huge! Make sure you load your JS and CSS files effeciently. Reduce image size where possible.
Does your app take too much effort? Think about how annoying games are which require you to open 3 menus to use a spell and have no assignable hotkeys. Think about games which make you walk back to town to sell items instead of just opening a portal. Does the game become too difficult to manage with many controllable units on the screen?
  • Look for cumbersome interfaces, or non-obvious controls.
  • If you use drag and drop or right-clicks, is it obvious to the user?
  • If the page loads a lot of data, does it become a hassle to use? Scrollbars, "next" and "prev" buttons all add to the effort required to complete a task.
  • Make sure your users only have to fill out data that they MUST fill out. Don't ask for information you don't need to complete the job.
  • Is your navigation easy to use? User's should be able to get anywhere within 1 or 2 clicks.
Does your application require too much attention? Think of a SIM game that presents the user with individual salary data for every SIM in the game when all we really want is the unemployment rate. Think of a game with 20 active quests but no way to see what they are. Think of an adventure game with no mini-map or that requires you to remember where your next objective is.
  • Your application should ideally only show information relevant to the task at hand.
  • Banner ads are evil (Animated ones in particular!). Is the money you make of them really worth distracting your user?
  • Are frequently used items more visible than the less frequently used ones?
  • Is it always clear what the user needs to do next, or do they need to guess?
Hopefully this will give you some food for thought when you design your next interface. Once you stop thinking about your application in a goal oriented way and start thinking in terms of the user experience, you'll already be on the way to designing better applications. This week we talked about how application interfaces can be improved by thinking like game developers. Next week we'll discuss making applications fun to use by bringing a little bit of game to your application!

What's next?

Truly successful interaction design relies on continuously asking yourself that question, so your users don't have to. Early on in the redesign of Five Second Test we focused a lot of our attention on how users created tests. We removed the need to register, we reduced the number of steps to the bare essentials, and eliminated all but one test type. What we had failed to do however, was to ask ourselves what we needed to do once a test was created. As it turned out, our users, having gone through the painless test creation process would wind up looking at their test results screen. This had made perfect sense to us from an application point of view, the only problem was there were no results to look at. To make matters even worse the most prominent button on the page was the one allowing users to export their non-existent results. Had we more carefully considered what our next action should be we would have realized that getting people to run a test needed to happen prior to viewing any results. It's seems like a laughable oversight but it's a surprisingly easy one to make when you're focusing on application state instead of the needs of the user.

How game designers can help application developers : Part 1

I'm a gamer. Our house has an Xbox 360, PS3 (the new slim variety) a Wii, an old xbox, an old ps2, a Gamecube, 2 Nintendo DSs and even a Gameboy Micro, plus the PC and a pair of iPhone 3GSs. Most of these get a fairly regular workout, except for perhaps the Micro and the Gamecube. Suffice to say, we're a gaming house. My wife is a Nintendo nut, and I'm more into PC and Xbox gaming. The PS3 is a blu-ray player.... What's this got to do with application design? More than you'd think! Usability, in application design, is often an afterthought. Not only in terms of interface design, but in terms of the user experience or user journey. This is mostly true for developer driven application design. The sort of design that evolves at the hands of a developer only to be "spruced up" by a designer later (if we're lucky). We consider how things work, but not really how they will be experienced. You can spot these apps a mile away. I know, because I've built plenty of them in my time. You don't realise how bad they are until you see someone trying to actually use your application in a real world environment, something many developers never ever witness and as a result never learn. Some typical examples, if I may:
  • Features that were clearly important at the start of development, remain visually prominent well after the feature has been demoted in importance or the focus of the application has changed.
  • Repetitive tasks use interfaces which are too cumbersome and time consuming to work, often as a result of a developer building an interface in isolation rather than as part of a work-flow.
  • Building a data interface which requires pre-existing data but with no way to add it, requiring the user to leave their current process to add the prerequisite data somewhere else.
  • Interface elements which are either non-obvious in their function or "tricky" to use for the inexperienced.
  • The worst offender, inconsistent design and implementation. When a developer is left to their own devices, they will often come  up with different solutions to the same problem. There is nothing worse than using an application which implements the same process two different ways in two different areas!
I'll be honest, you'll see a few of these issues in our own But we're working on addressing these... I promise! Whilst most of these issues could be easily addressed by a better pre-build process or even just some rudimentary user testing, this is often something that is out of the hands of the developer. Often in a small team, these tasks fall into the hands of the dev, something which, let's face it, we're all ill equipped to deal with. Not only that, but often the entire build process is focused on getting the job done quickly, rather than having a good product at the end. So, back to the games.... Imagine you're playing an RTS like Command and Conquer, Age of Empires or Starcraft. The enemy is approaching and you're in dire trouble. You need to build a wall, some defence towers and at least 20 units to fend off the attack. If all that isn't enough, you have only about 5 minutes in which to do it. The pressure is on! If the game is well designed, you will have enough time to fend off the horde. If the game is well designed, you will be able to achieve it all with a minimal amount of effort (time pressure aside!). Finally, if the game is well designed, there will be minimal interference from unrelated factors whilst you attempt to achieve your goals. Let's think about that more for a moment. If it takes too long for us to complete our task, we will be overrun by the Zerg Swarm and lose the game. If it is too difficult to complete the task, we will most likely give up and go play something else. If the game interrupts us constantly by notifying us that our citizens are unhappy, that another player wants to trade with us and that we should consider building more farms, we will get annoyed at the game and blame it for making us lose. Game developers spend crazy amounts of time considering these issues to ensure their game is fun to play, and yet in reality the same issues face us as application developers. We may not expect our users to have fun, but we still want them to be able to achieve their goals, and hopefully enjoying it enough to come back again next time! Come back next week for Part 2 of, "How game designers can help application developers"

Of stacks and faces

I have recently been considering the issues involved in using fonts of varying x-heights in my font stacks. As Andy Clarke explains:
...there’s the problem with CSS, right there. Different typefaces, even common ones, that have been designed with different x-heights, need different amounts of line-height. Calibri less than Verdana and different again to Arial or Helvetica. But CSS does not provide the facility to specify a varying line-height if a font in the stack is not installed, as it retains the same set line-height value for all typefaces specified in the font-stack.
One possible way of addressing this issue is to detect which fonts a user has installed via font detection scripts like this or this. Using this method a script could automatically adjust the font size at runtime to ensure a consistent layout. However, a lot of people worked really hard to ensure the content, presentation and behaviour of our websites remain seperate and we don't want to be pissing on their parade. The answer to this problem potentially lies in the newly adopted @font-face declaration in CSS3. The @font-face declaration to those unfamiliar allows designers to reference a font for embedding inside a page. The syntax looks like this:
@font-face {
  font-family: <a-remote-font-name>;
  src: <source> [,<source>]*;
  [font-weight: <weight>];
  [font-style: <style>];
The syntax currently has support specifying a font's weight and style, this is because they act as constraints on the actual embedding and therefore reduce how much of the font needs to be downloaded. What I would like to see is the addition of the font-size property so that designers would have a greater degree of control over their typography. Below is how you would potentially normalise the x-heights of your font stack using @font-face:
@font-face {
  font-family: L-Calibri;
  src: local(Calibri);
  font-size: 115%;
@font-face {
  font-family: S-Verdana;
  src: local(Verdana);
  font-size: 85%;
body {
  font-family: L-Calibri, S-Verdana, Arial, sans-serif;
I'd be quite keen to hear other people's thoughts on this, and to see if anyone else has any ideas on how to move typography forward on the web.

I turned to the dark side...

I have a confession.... I bought an iPhone. Actually, I bought two. One for me, and one for my wife. I didn't want one, I swear. But I had no choice. We have a couple of clients who really want iPhone versions of applications that we are currently building for them (and probably websites too I am sure). So what can you do? We use .NET solely because that is what our clients want us to use, and now we have iPhones solely because our clients want us to build stuff for them. I'm a late comer to the iPhone craze. I sometimes think that I get on these things just as the rest of the world is moving on to something else. But I have to say, the possibilities in terms of applications and/or games is pretty amazing. At the moment a fairly large proportion of stuff on the app store is frankly shit. The sort of thing you see advertised on late night TV by those dodgey $6 a week sms clubs. But I would imagine it is only a matter of time before the quality is given a chance to rise to the top of the cesspool. Once the platform matures a bit it will definitely become something worth targetting. At the moment, I'm not entirely sure it is worth developing a game or an app which you plan on selling for 99c, unless it is a throw away app you built in a couple of weeks or while on holiday. For me, it'd be hard to justify building something which I'd need to sell 20,000 copies of to break even on. Of course, the more you spend making something, the more copies you need to sell, or the more you need to charge. Even if you develop a great tool or game and charge a minimal amount for it, there is still only a very small chance that your app will even be seen by the vast majority of iPhone owners. Given the sheer number of apps for sale at bargain basement prices, it seems to be a pretty tough marketplace to break into. We'll keep you updated when (or if) we start developing for the iphone. In the meantime, it's back to "paper toss" for me!

ExtJS and .NET MVC

I've been using JQuery with .NET MVC for a while now, and it works wonderfully. I've made a couple of post previously on the subject. In my most recent project I've been using ExtJS with .NET MVC and it works wonderfully well (for the most part!). Since the latest version of ExtJS (v3) came out, it has gotten a whole lot easier with full REST support for data stores. When I first sat down to write my data components for this particular project, I made my subclass of the Store class (or JSONStore depending on what I was doing), and implemented my own REST-style interface. This basically involved providing a URL and then appending _get, _set, _delete etc to get the appropriate URL. It was messy and ugly and didn't work like REST should. Fortunately, around this time version 3 of ExtJS came out and solved all my issues in one go. Now by including the property "restful:true" into your Store, the store will automatically wire up the get, set, update and delete methods for you.
var store = new{
restful: true,
In my case, I am using a datagrid with a row editor. This means that when I click add, delete, update or load, the data store will take care of everything. All I need to do is provide a URL. Now, most ASP.NET developers will have never come across this, but it's definitely something you should be aware of. All 4 actions use the same URL (and hence the same method name in the controller) but with varying HttpVerbs.



What this means is that in your controller you can have ONE method name (but 4 separate methods) to handle all requests for this data type. Not only is it a lot neater, it's a lot easier to understand.

Hello World!

I suppose it's fair to say that my joining up with Angry Monkeys has been a long time coming. Alan and I have had the pleasure, sometimes not, of working together in various capacities over the last 3 years. Amusingly, over the course of the last 12 months, our collaborations have been so numerous that our respective portfolios became almost identical. I am incredibly excited by the prospect of being a full-time Angry Monkey and working in an environment where my sometimes obsessive enthusiasm for all things web is not only tolerated but appreciated, also as Alan pointed out, it beats "whoring". With that, I'm off to make msyelf another cup of coffee :)