Fanbolt schrijft:

"[Carrrds is] a quick bit of filler that’s fun for everyone. It’s easy to learn, easy to play, and can create its fair share of commotion when a duel breaks out!"


Lees de hele review hier of bezoek de Carrrds website.



I was playing around in Chrome trying to see how many DOM elements the browser would give me if I had just one html tag… this one:

<link href="nojs.css" rel="stylesheet">

My experiment ended up looking like this:


Using images from the OpenTyrian project it became a vertical scrolling shoot-‘em-up where you can fly left and right, see a wave of enemies and finally a boss ship. You can’t fire, it only works in Chrome (due to my lack of time) and it has many glitches, but I thought I’d put it online just for the fun of it.

Here it is:


Be sure to view the source :)

Allow me to briefly go over the technical details for your entertainment.

Read More


(Heads up: this post will not answer the question above)

I’m no marketeer nor a UX specialist. But I wonder if it feels better to end-users if they get free shipping on products that have been made slightly more expensive as opposed to seeing a lower price tag but an additional shipping fee at the end.

Personally, I never like shipping cost. This is me shopping: Say there’s a product in my shopping basket worth $75. I know that, because I clicked “add to cart” where it said "This will cost you $75".

In my head there’s now a product-value binding of some sort. I don’t know the name or what it is, but for me I am going to buy a product worth of $75. And hey, I’m going to really buy it, so let’s proceed to the checkout.

"$5 Shipping"

It doesn’t add value to the product. I need to pay this in order for me to hold and use the product, but once I have it in my hands it’s worth $75.

Not $80.

What if I had been considering this product being $80 from the start? In my head that product would have a higher value, and …

"hey - BONUS! Free shipping! Thank you shop!"

I am just naively wondering what the negatives to this would be. And I can imagine a few:

  1. I would be more likely to buy a $75 product than an $80 one. If another shop has the same product for $75 I’d probably start there.
  2. Once I am searching for the product I want, added it to my basket, went through checkout and filled out my details - well, I don’t want to give up so yeah sure I’d pay that $5 just to get it.

But the mental flow of deciding you want to pay a certain amount for a product and taking that through the payment process and finding a bonus free shipping plus getting a higher-value-for-money product in your hands, wouldn’t that make users happier? 

I don’t know. I think it could. Your thoughts?

Update: Here are a few interesting related posts on pricing and psychology:





The other day I was having a discussion on twitter over something really unimportant. So where you probably ;) Both me and my friend Rahul had some arguments backing up our side of the story.

Then a mutual friend showed up and favorited one argument. Just one. (Mine. Not that it matters, but Rahul was wrong and I was right ;)). Anyway, that favorite backed up an entire side of an ongoing discussion. In one press, he picked a side and left.

I hadn’t seen a favorite being used in this particular way that much, and personally only use it for small praise or bookmarking. I thought it was an interesting idea so in the days ahead I started paying more attention to favorites done by followees, followers, mutual friends and others.

And I noticed so many more subtle uses.

Read More


Using touch devices over a mouse and keyboard has probably been one of the biggest improvements in user interface friendliness for young children. That said, here are a few things that would really take a child’s experience with an iPad a whole step further:

1. Detect accidental touches from wrists and the lower side part of the hand. When this is active, pass the actual movement of the finger to the app as the primary movement (for the app to act on).

This does lead to the question of responsibility: shouldn’t it be the app builder to take care of these things? Well, yes and no. An app builder could always listen to the most primary movement and detect accidental secondary touches, but the overall app experience for young children would improve by making these changes on the OS level as well.

2. Be more tolerant to distinguish between a swipe and a tap. More often than not, young fingers start swiping icons on the home screen when they actually meant to tap.

3. Disable all five finger gestures, regardless its specific setting in the Settings panel. These gestures happen. And they’re never intended.

4. Lock the maximum volume to a parental controlled setting. My youngest daughter sometimes can’t hear any sounds so she turns up the volume… to the maximum, after which she gets scared and starts crying. I believe a Child Mode setting with my personal tweaking of the volume would really help.

5. Play time limitation, control and play-turn indicators. This is not just about limiting the time children should be allowed to play, as that is totally the resposibility of the parent, but it’s would be a welcome feature to just set this once so children who can’t tell the time yet know when it’s almost time to stop. And it would really be helpful if this could be used to add an indicator for when it’s someone else’s turn.

The above settings would really be helpful, IMHO.



Hi. We’ve been hard at work to get Quento out in the open. And today this has become a fact. Quento has just been released for FREE on the App Store and pretty soon it will become available on Android devices, the Windows 8 store and Chrome Web Store. If you like puzzle games like Sudoku, Quento is definitely for you!

For more information, visit quento.com or download it directly from the App Store.





What do you think? Looks good, doesn’t it? Feels a bit like an old 1993 DOS game that’s being sold on eBay. Check the back:


We’re gearing up to that big moment where we send our beloved game to be printed, so we can wait in agony until the delivery boy rings the bell.

Interested in some of the cards that made it to the deck? Read on…

Read More


Last week I posted this question to StackOverflow: Detect iPad Mini in HTML5.
In short: a webpage can’t differentiate between an iPad 2 and an iPad Mini.

Today I offered a bounty of half my StackOveflow rep which made frontpage Hacker News and caused people to respond in two ways:

  1. Offer possible technical solutions
  2. Defend Apple’s Human Interface Guidelines and state that if we follow it, we shouldn’t need to be able to detect the difference at all

I find the latter a complete load of BS, so I updated the original question with some more arguments as to why I think we should be allowed to know if someone is using an iPad Mini or not.

And as I feel that’s a totally different discussion than the search for a solution, I thought I’d post my update as a separate blogpost here (so yes, the text below is an exact copy of my update on StackOverflow).

Personally, I think browsers should be able to tell the differece between an iPad Mini and an iPad 2.

The iPad mini is not only a much smaller device (9.7 inch versus 7.9 inch) but its form factor allows for a different usage. The iPad 2 is usually held with 2 hands when gaming unless you’re Chuck Norris. The mini is smaller but also much lighter and allows for gameplay where you hold it in one hand and use another to swipe or tap or whatnot. As a game designer and developer myself, I’d just like to know if it’s a mini so I can choose to provide the player with a different controlscheme if I want (for instance after A/B testing with a group of players).

Why? Well it’s a proven fact that the majority of users tend to go with the default settings, so leaving out a virtual thumbstick and putting some other tap-based control on the screen (just giving an arbitrary example here) when the player loads up the game for the first time is what I and probably other game designers would love to be able to do.

So IMHO this goes beyond the thick fingers / guidelines discussions and is just something Apple and all other vendors ought to do: allow us to uniquely identify your device and think different instead of following guidelines.

Look at how it’s advertised:

Even the first paragraph on Apple’s iPad Mini page states the big difference:

And you can hold it in one hand.”

That’s right Apple. It’s not an iPad 2. So don’t fool us into believing it is.



Sass and Less are two flavors of stylesheet language extensions that offer syntactic awesomeness which should’ve been built into plain CSS in the first place. Stuff like variables, mixins and whatnot. 

Read More



OMG! Forget what I wrote below. Get on the Chrome DEV channel. Chrome 24 and up has SASS debuggin support built-in. Full details here:


And forget what I wrote below :)

The missing link when using SASS or LESS over vanilla CSS has been the ability to properly debug the sources in Webkit Inspector. Debugging in Firebug has been possible already, but not in Webkit - and especially Chrome which has been the development environment for me and most of my colleagues here/

However, googling on how-to’s provide you with enough info to set everything up, though I did encounter most tutorials focus on Mac developers. So I thought I’d sum up the requirements here for people who - like me - are on Windows (for whatever reason ;-).

Here’s what my Webkit Inspector on Chrome looks like right now:

How it works

First, here’s how the entire process works just to make things clear:

  1. You work locally in .scss (or .sass) files. 
  2. There’s a “sass watch” command running in the background monitoring for changes to these files. When detected, they are recompiled into plain .css files.
  3. The generated .css is (optionally) enriched with debug information providing tracebacks to the originating sass files. This debug information is rendered in css using specific media queries that looks like this:

    @media -sass-debug-info{filename{font-family:file\:path\/to\/style.scss}line{font-family:\000042}} 

    (The debug information values containing the path and line-number are stored in the font-family property, as that’s the only one that allows quite an extended character set without getting the browser upset).

  4. By using a Chrome extension called SASS Inspector you get a new pane in the bottom right of webkit inspector providing you with the sass sourcefile info you need. Sass Inspector parses these extra media queries and shows the information provided within in a more readably form.

How to get it to work

Let’s assume you have never installed anything remotely close to sass or any of its requirements. On Windows, here’s what you need to do:

  1. SASS needs Ruby, so install it from here: http://rubyinstaller.org/downloads/ (and check to add Ruby to your PATH)
  2. Open a command propmpt and type 

    gem install sass 
  3. Now make SASS watch your .scss or .sass file or files and provide debug information. You can watch a single file:

    sass —debug-info —watch path/to/style.scss:path/to/style.css

    Or watch a folder:

    sass —debug-info —watch path/to/sass-folder:path/to/css-folder

  4. Then, download the SASS inspector extension for Chrome.
  5. Inspect the webpage that you’re testing the above in.
  6. Party Hard

Other ways to go about

And if you’re on a Mac, you really might want to give SASS Sleuth a try.