Design weaponised

Having purchased a secondhand Nintendo Wii + games (of which I believe Metroid Prime Corruption shall become my biggest life-waster) -for the kids, we stupidly left it until 4am this morning to set up and test it before wrapping. We got so far as setting up an internet connection before hitting the parental lock screen, which had obviously been accidentally left in place by the store we bought it from.

Like anyone reading this probably would, we consulted Google results and discovered that the Wii parental lock can be reset by:

  1. At the parental lock code input screen, choose "I forgot",
  2. at the security question screen choose "I forgot".
  3. Type the displayed code into a form on a Nintendo webpage.
-Aaand at this point we notice that we have to wait until office hours for an email reply due to the call centers being closed. At 4am Christmas day, kids primed to wake in roughly an hour. More Google combing required, it would seem..

Then we saw this.

Input the security code from your Wii then put the resulting code back into the Wii. Done.

Thank you marcansoft.com. You saved (part of) Christmas.

Onto part two.

The neighbours bought one of their kids an MID 7" Android tablet.

I nearly got one of these for my girlfriend as an ebook reader before settling on a Kindle 3 instead; The hackable nature of this device makes it perfect for me, and I have no doubt that when (yes, when) I own one the first thing I'll be doing is installing linux. Having used one now I have to say I was impressed with the build, which I assumed must be the nice side of the chinese ipad rip-off market, and the occasionally terrible framerate improves as soon as animations are turned off and better firmware is on there.

This beast however, had a problem. Hours after first use, transfer of a few photos somehow led to the device becoming stuck at the loading screen even after hard shutdown (holding the power button for 5 seconds), and without any more specifics about how it happened my assumption was that either the device had been turned off while transferring or its internal memory was full.

A detailed search on the problem turned up nothing but recommendations to either reflash it or get a refund, and having the slightly tearful new owner standing over me meant a judgement call of epic proportions:

Reflash a brand-new malfunctioning device, the main present of a tech-happy young'un on Christmas day, risking completely bricking it and voiding its warranty, or hand it back to her in the same sorry, spirit-destroying state that it was handed to me in and tell her to get her mum to send it back?

Of course the reflash worked.

It's an Android device. When you first power it on it displays the firmware version in the bottom-right hand corner of the screen, -this was WMT2.1.2_105- I found firmware version 2.1.6 for download, unzipped it, copied the folder titled "Scripts" to the root of a microSD card, put the card in the tablet and rebooted it. After a few screens of "Copying ROM files..Please wait" blahblahblah, the device reset and greeted us with a fresh install of a newer operating system than what it came with.

After 20 minutes of "testing", I found nothing that didn't work with the new install.

Winner.
Code-free explanation for creating pixel-perfect clickable areas within HTML5/Canvas displays.

Roughly a year ago I was commissioned by a friend to do all the graphic design for his business, a soundsystem/PA build/hire/sales company. The brief, covering a logo, flyers and a website, consisted of those four most magical of words "Do what you want." -so that's what I did.

A personal obsession with clockwork and complex, well engineered mechanical devices led me to decide that I wanted to emulate the look and feel of such an object as the user interface for the website.

Besides animation, such an effect relies heavily on per-pixel interaction. If you can see that a button seems to be attached to the end of a lever, then pressing the lever itself should have the same effect as pressing the button. Also, when the graphic of the selected button moves, it should remain clickable throughout its motion unless visually hidden behind other objects.

This presents a problem; Usually, click detection within a non-interactive graphic would rely on coordinates. When the user clicks somewhere on the display, the code would grab the x/y location of the mouse cursor, then check those coordinates against a list detailing the clickable areas of the display by their individual top, right, bottom and left extremes. This solution works fine until you either have clickable areas ontop of other clickable areas, or clickable areas of irregular shape; -or especially, both.

With overlaying areas, the situation will arise where a user has clicked a location that lies over more than one designated clickable area. The solution to this is to give each area a value to reflect it's depth in the display, so when the user clicks over more than one area the code takes the depth value of all underlying areas and only considers the highest(in value, shallowest in depth) to have been clicked. Now we're storing coordinate values for top, right, bottom and left, along with a depth value for each clickable area. So far so good.

Start using clickable areas of irregular shape though, and our whole setup starts to break. Imagine for example a percentage sign %. We want the crossbar and each of the zeros to be clickable. Using the above method of having a depth value assigned to each object, we end up with something like this:


User clicks crossbar, no problem. However, user tries to click either zero and it will also be recognised as a click on the crossbar, due to the crossbar's overlaying bounding box and higher depth value. We could make sure that smaller objects are at a shallower depth, but the same problem remains:


With both zeros now placed at a higher depth than the crossbar, clicking here will be recognised as a click on the top left zero.
Besides these bounding box annoyances, using depth as an identifier also means having to base the design of the interface upon this limitation of the underlying code.

The solution is colour. When the user clicks an area of the user interface, the colour of the pixel directly underneath the cursor is compared to a list of colours belonging to each clickable area. This allows for precise clicks on objects nomatter what their depth or location happens to be, so we could now click objects through cutouts in overlying clickable objects, if we wanted.