O’Donnell’s 3 Laws of User Dynamics

Remember kids: You don’t have to please ALL your customers, just the ones you want to keep.

sheepThe first Law: conservation of users

Users are not created or destroyed, only converted to or from using a competitor’s product.

All other things being equal, you should remember that brand loyalty counts for less and less these days. If you don’t want to do what your users are asking for, maybe your competitors will.

polar bearsThe second law: the progress of disorder

Evolve your product, in order to fight ‘design entropy’.

As users’ needs change, so should your product. If you don’t have the right metrics in place, you won’t realise that your product is obsolete until you become the next Woolworths.

designThe third law: chasing perfection

Invent something idiot-proof and someone will invent a better idiot.

Humans are complex and often unpredictable. Therefore, human-computer interfaces are, at best, imperfect systems. Test your design assumptions and always have documented justification for design decisions that can be re-tested against new iterations of your product.

GuinnessPint

Wait for it…

Improving the usability of an interface, by making it do more or less what the user actually expects of it, is a pretty good route to an overall sound user experience. Yet, there’s one key mistake almost every interface I’ve looked at makes in this regard – what I call the Spurious Stimulus Response. That is…

responding to user input in the context of stimuli they haven’t been given the time to acknowledge.

For example, consider a dialog box, suddenly appearing centre-stage in an interface, as the result of an incoming message, error condition, or some such situation. If the user was to click on it, or press a key, within 250 milliseconds of it appearing, then they are not reacting to its appearance – instead they were probably intending to action something else.

In an interface without a pointing device, such as on TV, using a traditional remote control, the problem is exacerbated, since the user only need press OK to commit whatever action happens to come into focus. When using an infra-red remote control, this problem is compounded further, because it usually takes a fraction of a second for the receiving device to recognise the incoming IR pulses as something it needs to deal with and push that signal up through the software stack to the UI layer.

I suggest employing a simple fix, which draws its inspiration from the behaviour of nerve stimulation – called the refractory period. That is…

to render a control inactionable, after a change in UI state, long enough for the user to assimilate said state change.

The few interfaces which loosely employ some such technique, do so usually just as a side-effect of having some animated transition when a dialog appears, for example. Sometimes, a button or other control is disabled until the transition completes. This is actually a very good way of ‘easing the user into’ the change in UI state – but a refractory period should still be implemented where animation is absent.

The refractory period could be some function of the amount/importance of information provided. A good example of this is the Firefox Add-on confirmation dialog, which forces you to wait a few seconds, rather than letting you mash RETURN and install some random plugin.

But, in its most simple incarnation, a refractory period may simply be used to filter out double-click mania. Please start designing this kind of behaviour into your UIs – your users will thank you.

Chinese Handwriting Recognition App

Chinese Handwriting Recognition App

Unlike the iPad, the BlackBerry PlayBook has rather poor international keyboard support, with no method for entering chinese characters. I like the way iOS achieves this, so went about building my own version in ActionScript.

This was mainly an academic exercise and to help me to learn to write chinese. My approach was to sample the strokes drawn into the app as a series of up to 8 directions, including the relative position of a given stroke to the previous stroke, again as one of 8 directions. This pattern, represented as a string of numbers is then put through a smoothing algorithm, to remove some unnecessary noise and then compared with a dictionary of pattern keys, which may contain one or more suggested characters. If there are no hits, an advanced search occurs, by mutating the given pattern in specific ways, in order to find alternative suggestions. I can also find characters based on the next most likely character to the one you’ve just entered, using frequency analysis on given sample text.

The app will eventually be a PlayBook App, but is still unfinished and currently in ‘training mode’, so that character patterns can be trained into the database. It’s currently primed with some simplified sample data, from which it picks the most popular few characters to learn. If you write chinese, give it a go.

aliasAndAntiAliasComparison

SmoothBitmap – How to enforce pixel smoothing on a Bitmap

A common oversight when using Bitmaps with loaded content is that Flash will revert a Bitmap’s smoothing parameter to false when you replace its bitmapData. It’s simple enough to fix, but since you may not know if someone is going to replace the bitmapData of a Bitmap you have created – then it’s often better to code defensively around it.

This little SmoothBitmap class is for just such an occassion. Instantiate it like a regular Bitmap and, no matter what another developer does with it, smooth pixels when scaling/rotating will be ensured.

flip-table

CODING WRONGS – Where do I start with the bad?

It gets scary out there sometimes. During my freelance career I’ve worked at a lot of different companies and have seen such coding horrors as you cannot imagine. So I thought I’d start immortalising some of them – so that we can all learn better coding practices, by looking at the bad.

Starter for 10 – What’s wrong with this picture?

Did you spot the fubar? It’s not an obvious one.

This code potentially replaces a Bitmap’s BitmapData, without first explicitly disposing any existing BitmapData.

I see this kind of thing quite often and it’s the source of many a memory leak. AVM2 isn’t that great at dealing with this kind of situation and there’s a crucial difference between GC cleaning up out-of-scope objects for you and things like BitmapData: GC will reclaim the memory associated with objects ‘when it feels like it’, whereas explicitly calling the ‘dispose’ method of a BitmapData will immediately give you back that memory.

In the case of platforms with hardware accelerated graphics (such as mobile or set top box), the memory associated with the pixel data itself (video memory) will be reclaimed immediately.

The lesson?

Don’t make more work for the Garbage Collector when you can avoid it.

confused-dog

TextField.getRawText() what it does

I was recently creating an API that required extending TextField and happened across the getRawText() method. I assumed this returned the text from the field without formatting or something – so I looked up the AS3 docs for flash.text.TextField.

Nothing there – gee thanks Adobe. A quick search turned up this which, it turns out, isn’t quite accurate.

So, with a tad of testing, it appears that getRawText() returns the text, stripped of any HTML tags (if you had set htmlText). I now wonder if this is faster than using a RegEx to strip the tags and why Adobe didn’t document it?

furniture

How the hell do I build this?

I had a conversation yesterday with a friend and colleague about how his company should standardise their development environment for all Flashers – be they contract or perm, junior to senior.

He, like many of us, was sick of contractors building projects and leaving them in various states of repair. Required libraries or fonts are often missing, bits of code never even get checked into source control and, frustratingly, it is often unclear how to build a project. The makeup of Flash projects can vary from an FLA file/s full of timeline based code, to source code set up to compile under one specific, mystery environment.

The problem:
You need to set some kind of reasonable standards, so that ActionScript projects can be easily verified, maintained and recompiled, not necessarily by someone with intimate knowledge of the OS, environment and the project – ideally even a developer without intimate knowledge of ActionScript or a copy of Flash CS5 and Flash Builder to hand.

The solution/s:
There are obviously many ways to skin this cat. But, the way I see it, the best solution needs also to be reasonable, achievable by everyone and cost-effective for a typical digital agency. As such, the ‘best’ solution may not be the ‘ideal’ solution – by which, I mean an idealistic solution based purely on software development ‘ideals’.

Flash IDE
We have to start somewhere and, at the risk of a flaming, I’ll act as its advocate for a bit. There will often be a need for those FLA files knocking around and you won’t get designers building their banner’s with the Flex SDK. However, since the Flash IDE isn’t free, open source, understood by non Flashers and (with the exception of CS5) creates nasty binary balls of mud (namely FLA files), we’ll assume from here on in that we’re talking about compiling project with the Flex SDK.

Flash Builder
Adobe’s own latest development environment for Flash/Flex, built on the very popular and mature Eclipse is certainly feature-packed and already industry standard. But is it the sanest choice to enforce that everyone use this particular environment, just so projects are more maintainable? Will it work and, since it’s not free software, is it even cost-effective? Personally, I think perhaps not. Since Flash Builder isn’t free, requiring its use for all Flash projects within a company will probably solve one problem and create all new ones.

FlashDevelop
FlashDevelop is my favoured editor and, without getting into the FDT vs FlashDevelop vs Flash Builder debate – I favour it primarily because, whereever I work, I can always get IT to install a copy on my machine, without having to wait for budget approval, bring my laptop instead, etc. However, FlashDevelop is currently for Windows only and is still just one development environment. Even though it’s free and open source, we want to abstract away a project’s configuration and setup from any software that isn’t also cross-platform and industry standard.

Maven
So why not enforce that everyone builds and configures their projects so that they can compile under Maven from a POM? I think it’s a little unrealistic to expect every calibre of ActionScripter to even know what Maven is. At very least, it would create a rather high barrier to entry for prospective developers, making recruitment even more difficult for any company. I agree that it’s a bonus for many, larger projects that may need to pull in dependencies from other projects.

Ant
Ant is a cross-platform solution for software automation, built on Java. Since it’s open source, free, industry standard and pretty easy to set up and use, I’d say its the best choice for configuring the building of projects in a standardised way, without tying anyone to a particular code editor, platform or requiring expensive any software.

Ant can be integrated into most development environments and provides a sensible ‘how the hell am I supposed to build this?’ answer to any project. This also means that, for those people that use it, the Ant script can be used for building with Maven/Hudson, for automatically ensuring all projects will build – even if you only use this to ensure a contractor has left the project in a buildable state.

I also found this helpful article on integrating Ant with FlashDevelop – so if you like that free, open-source feeling, then take a look.