October 29, 2010
While my previous code example showed how to recreate the past, this next example points out the possibilities of the future — Multitouch gesture interfaces, on the web!
The UI designer in me is chafing at the bit to start giving people web-apps with multitouch-based interfaces. The possibilities are enormous, and the advantages of multitouch UI – rich input, direct manipulation, natural mappings, fewer widgets, instant feedback, and a certain fun factor – are many.
But unfortunately, since this is still an emerging technology, it’s not exactly a standard yet. It’s not available on all hardware. On hardware where it is available, it’s not always made available through the browser. Different browsers expose multitouch events to web content in different ways, if they expose them at all. For this reason, the demo I’m about to show you won’t work on all browsers, sadly. So far, I’ve only been able to make it work using the Firefox 4 beta and only on multitouch-enabled computers running Windows 7 – which drastically limits the audience that will be able to try out this demo, I’m afraid.
So, I’m sorry to give you a demo that’s not fully cross-browser-compatible or standards-compliant. But! I think multitouch will become standardized, and soon. It won’t be too many more years before multitouch input becomes an everyday part of the Web experience on all platforms. So why not start experimenting with it now? We can start trying out new interface possibilities now, and work towards full cross-browser compatibility as the standards emerge.
And what better forum for experimenting with interface possibilities than the Game On 2010 contest?
Anyway, here’s the demo:
Multitouch Gesture Interpretation Demo
October 20, 2010
If you’re at all interested in writing games for the web, and if you’ll be in or near Mountain View next Thursday (October 28), then you — yes, you! — are invited to the Labs Night Gaming event at Mozilla. There should be a lot of cool game demos; I’ll be showing off some multitouch input stuff I’ve been working on; and there’s free pizza. It should be a real good time, and a chance to network with other people who are excited about the Web as a gaming platform.
October 12, 2010
Mozilla Labs has announced Game On 2010, our first-ever game development contest.
My first example is a set of classes for implementing a top-down, tile-based map screen that scrolls to follow the player’s movement. If you, like me, wasted your youth playing 8-bit and 16-bit console RPGs (like Dragon Warrior, Ultima, and my favorite under-appreciated classic: Phantasy Star) then this ought to look a bit familiar:
Old-School RPG Map Demo
Move the character around with the arrow keys, and notice how the screen scrolls when you get close to the edge.
October 9, 2010
I can always tell whether someone understands statistical research or not by describing Test Pilot to them. If their very first question is “What about the self-selection bias?” then they understand statistical research!
Self-selection bias is the bias that creeps into your results when the subjects of your study are people who choose to be subjects. It’s a bias because a group of people who choose to be subjects is not the same as a random sample of the population.
Think of product reviews on Amazon: they’re mostly 5-star reviews or 1-star reviews, because only the people who really love something or really hate it are motivated enough to write a review! If you randomly sampled the people who had read a given book, you might find that the majority of them found it mediocre – but indifferent people don’t take the time to write reviews. The self-selection of the reviewers skews the average rating.
This is the same reason why dialing random telephone numbers gives you better poll results than setting up a poll on a website – the telephone polling is (closer to) a random sample, while people who answer the website poll are self-selecting.
The relevance to Test Pilot is obvious. Only people who chose to install the Test Pilot extension or the Firefox 4 Beta get the studies; and only people who click “submit” send results back to Mozilla.
Therefore, it would be a mistake to rely only on Test Pilot submissions when redesigning Firefox UI. We’d be over-tailoring the UI to a particular subset of users, while potentially making it worse for the “silent majority” of users not represented in the sample.
Just how skewed is our sample, anyway?
The results of a survey in March 2010 (which was taken only by users of the Test Pilot extension) gave us a portrait of users who were:
- More likely to be Linux users…
- More likely to self-describe as “Tech-savvy”…
- More likely to be in the 18-35 age range…
- Much more likely to be male…
- Likely to spend 4-8 hours a day using the Web…
- More likely to be using Chrome in addition to Firefox…
- Much more likely to have been using Firefox for 4 or more years…