Skip to main content

I Was Wrong About Gamification: It Works.

What feels like way back in early 2012 I was still dabbling with a little bit of coding from time-to-time and scoffed when Microsoft announced that they were bringing the XBox to their Professional development environment, Visual Studio.

VSAchievmentUnlocked

Visual Studio Achievements, as the plug in for Visual Studio was called, meant that developers could ‘Unlock Achievements’ and take part in leader boards to exhibit their prowess in particular areas of Visual Studio.  They could even share their achievements on social media, their blog and in a public leader board.

This was part of the emerging trend of Gamification – the act of taking game like characteristics such as point collecting, leader boards and the like, and applying them to other areas.  This was (and still is) spilling over from digital marketing, where it’s proved a very effective marketing tool for big and small brands alike.

My background has always been in Line-Of-Business application development, and predominantly for engineering or process-orientated companies: I worked in what I regarded as ‘the grown up world.‘  I didn’t like this approach and didn’t see how it would encourage quality code – although I could see how it would increase quantity.  It seemed like the ‘dumbing down’ of the business world, and where would it end?

Gamification – I Was Wrong & It’s Addictive.

I was wrong, and I may even be a convert. While I don’t use Visual Studio as a daily tool any more, so VS Achievements doesn’t apply to me, I do use a To Do List tool called ToDoIst to help me manage the tasks I have to do and remember those coming up.

I started using ToDoIst because it had some great reviews in some productivity blogs I happened to be reading at the time, it is easy to add tasks to, you can add them to ‘projects’ and it works easily across various devices.  I soon became addicted and it earned its place as a pinned tab in Firefox next to GoogleApps and Trello.

Then I noticed the ‘Karma‘ tab at the top.  It was gamifying my to-do list.  You get karma points for adding tasks to the list, more karma points for completing them and there are even achievement levels for karma. I found myself checking this often – it’s a really handy, easy measure of how productive I am being!

ToDoIstKarma

The real killer for me though, was the ‘Last 7 Days’ and the ‘Streak’ function.  You can set a target number of items to get done each day, tell ToDoIst what days you work and it’ll tell you whether you’re hitting that goal – and it’ll keep a track of how many days in a row you’ve done that.

Once you get on a roll and get a few days in a row when you’ve hit your target, you really don’t want to drop out, and you want a longer streak.  My record is 9 days – but I’m not doing so well this week! DailyStreak

So, I’ll have to admit: When presented well gamification can be great motivation.

It’s just evolution though…

That got me thinking about what was really going on… is gamification really any more than an evolution of the long established industrial / business tool of ‘visualisation’.   In factories and process businesses across the world, output and problem visualisation is a core component of getting the most out of the process – it dates back decades and is linked to The Toyota Production System’s concept of Jidoka.

andonBoard

Jidoka is the second of the two core principles of TPS and relates to the stopping of work as soon as a problem occurs (thus eliminating root cause as early as possible and increasing quality).  In manufacturing environments, Jidoka normally manifests itself as a production board which shows the problem when it occurs, but in normal running those boards (called Andon boards) display output… much like my ToDoIst Karma graphs.  I can see a problem immediately: my graph drops off and I’m not being productive – the root cause is harder to find though!

Could Gamification just be the application of Jidoka and Visualisation to non production / process work?

WPF, Binding, Internationalisation, Fail.

I’ve been working on a WPF browser application for a client for the past couple of months now; and am just getting round to sorting out some of the niggles with internationalisation (this app will be used in 39 countries).

I have a line of XAML which should display a date in the correct short format for the user.  (IE: 31/12/2011 for UK, 12/31/2011 for US etc):

<TextBlock Text="{Binding ElementName=SheetHeader, Path=DataDateTime, StringFormat='{}{0:d}'}" />

The important bit being the StringFormat='{}{0:d}’; this should format the date correctly.  But it doesn’t.  If I load this on my PC in the UK I will get the date in en-us format.

It turns out that WPF does not respect the current culture when it comes to bindings,it defaults to EN-US; so dates formatted when bound will always come up formatted as if you were in the US.  What a massive oversight on the part of MS, and hopefully they will fix this at some point.

There is a way around this though – you have to override Language Property of the application on application load.  Adding the following code to the Application Startup event will ensure you get correctly formatted bindings.

            FrameworkElement.LanguageProperty.OverrideMetadata(
                            typeof(FrameworkElement),
                            new FrameworkPropertyMetadata(
                                XmlLanguage.GetLanguage(
                                      CultureInfo.CurrentCulture.IetfLanguageTag)));

Test