Martin Kool
games - web - dad - sarien.net - q42 - livejs - handcraft
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.
TweetTweetHi. 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.
Tweet
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…
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:
- Offer possible technical solutions
- 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.
TweetUPDATE:
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:
http://bricss.net/post/33788072565/using-sass-source-maps-in-webkit-inspector
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:
- You work locally in .scss (or .sass) files.
- 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.
- 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). - 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:
- SASS needs Ruby, so install it from here: http://rubyinstaller.org/downloads/ (and check to add Ruby to your PATH)
- Open a command propmpt and type
gem install sass - 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 - Then, download the SASS inspector extension for Chrome.
- Inspect the webpage that you’re testing the above in.
- Party Hard

Other ways to go about
And if you’re on a Mac, you really might want to give SASS Sleuth a try.
TweetTweetSo, we’re Designing a Pirate-themed card game. Yes, a genuine card game for pirates of all ages. The name of the game is…
Carrrds!
Today we’ll be starting the first of a series of blogposts to shed some light on character design, art choices, influences and rules.
First up: the Gun and the Gunslinger.
Q:Hi Martin, I was scouring through stackoverflow for some idea on how to package JS and CSS in a large project and I was really intrigued by your answer on the following question: "How do I concatenate JavaScript files into one file?"Unfortunately the author of the question never bothered to ask you for some samples on your solution. I understand that this was awhile ago, so I am not sure if you still use this solution and/or have improved it.
At the time of that post we had a custom service for this - it did things the way you’d expect: iterate over the files, join them together, minify and store (either in memory or as a static file, I don’t remember).
But I think that most frameworks have evolved to offer packages that help you with this. I believe this post will get you on your way:
http://robertnyman.com/2010/01/19/tools-for-concatenating-and-minifying-css-and-javascript-files-in-different-development-environments/
Q:Please post when you think DK2 for DS is finished. Thanks.
It will not be finished - I am sorry. No work will be done for it anymore as I have moved towards other projects. Sorry :(






