My geek origin story

Delicate Genius (aka Microsoft’s Michael Kordahi) tweeted me a while ago about putting this up, and in the interest of historical accuracy, here it is! Other geek origin stories can be found from his blog post.

I wasn’t terribly geeky as a young lad, except I loved Lego and got into roleplaying games in a big way. At university I fell into a crowd that were much geekier than I (hat tip to Justin McLean), and along the way got pulled into doing an Information Systems major for my Bachelors of Commerce degree.

Something must have happened because by the time I met and married my lovely wife I looked like a true geek! (gotta love the Doc Martens)

Looking back I think the same qualities that caused me to fail Accounting Financial Management 1B led to my success as a geek. Things like:

• Always wanting to improve the system,
• Searching for truth,
• Wanting my work to matter.

None of those things applied to rote learning T accounts and double entry accounting, but they sure do matter when you are building fantastic tools for web developers to build awesome, award-winning sites with.

So that’s how I ended up becoming the geek t-shirt wearer I am today – although I no longer have those DMs ...

Context may be key to blended learning

I have been reading two excellent books recently, John Medina’s Brain Rules and Dan Coyle’s The Talent Code (see other Personal Transformation Books), both deal with how our brain works, and there are interesting things they tell us about learning skills that we can apply to how we structure and run blended learning programs.

I have mentioned before David Maister’s article Why (Most) Training Is Useless in the context of saying that behaviour is what we should be aiming to change, and measure, not simple skill identification. The point was that it is not good saying I want to train your consulting skills if I don’t know what behaviour indicates that you are have learnt and are applying them. Maister also wants incentives made to match those behaviours, based on seeing his training undermined by the structure of the organisation’s incentives.

Coyle breaks down two ways we can affect skills development, ignition, which is a combination of incentives/encouragement/vision and deep practice, which is the focused practicing of technique at the edge of our ability, with the aim of achieving perfection in the small components of a skill, and then building into perfection in the larger components. Maister’s complaint about incentives not matching behaviours is talking to the ignition side of skill development.

Medina’s book is interesting because it gives us lots of clues about how memory relates to instructional methods, with the main points being that repetition is important, but so is learning in the context in which we want to be able to remember what we learn. In this sense it relates well to Coyle’s idea of deep practice.

This last point is the one I want to focus on. If Medina is correct when he says that we recall things more easily when in the physical/emotional context we learned them in, then most teaching is done in the wrong context!

This suggests that eLearning is best used when the skills being taught are to be expressed online, with use of much the same tools that the learning occurred on. It is one reason learner drivers are encouraged to use their own cars when learning and when going to do their driver’s test.

Classroom learning may suit well skills that need to be exhibited in front of other people, in social or meeting situations, where the ability to perform before your peers may be required (it may also help people perform better in classrooms - any professional students listening?). Even then the layout of the room may benefit from being closer to their likely environment. When Anthony Milner and I did the excellent NIDA Corporate Performance Course the format was that of a class, but the frequent practice sessions were done in front of the group with us facing them as a very real audience, an experience that made it easier to recall the skills learnt when actually presenting in front of audiences later.

One on one mentoring may be the best approach when the skill must be exhibited in the context of a  personal relationship, and even then it is best done in the workplace. This is how we handle important parts of facilitator training in the Careforce Lifekeys’ courses – the small group facilitator is given the opportunity to practice their skills in the context of a one on one conversation with a trainer playing the role of a small group member.

There is one caveat to this, both Medina and Coyle point out that the ability to comprehend the big picture is a vital component of skill competency – one of the factors that differentiates experts form beginners in a particular field is that the experts have a mental abstraction that allows them to deal with the complexities of the problem domain more easily. Getting that big picture view across need not necessarily take place in the environment the skill is exercised in – in fact it may benefit from the distance provided by being away from that environment.

Why web will win the mobile app race

Everyone wants a mobile app, banks, health funds, airlines, pubs and all sorts of marketers want us interacting, playing with and using their mobile apps. This is fine and dandy, and is a Good Thing for the future of humanity, but … which OS do you want to target?

Is your app going to target iPhone, Android, Blackberry, Windows Phone 7 or (heavens!) Symbian?

The right answer will, of course, be all of the above. It really isn’t hard to figure out, and there is a precedent you see.

What do you do if you want to target users on MacOS, Windows 7, Linux (a bazillion flavours itself), Google OS or (heavens!) Unix?

The answer to that question is you created a web app, because the browser environment was designed to be (reasonably) neutral between vendors. The same paradigm exists in the mobile world. Creating a specific OS version just limits your app to that OS, and who wants that?

However there is one big difference, the mobile app needs to deal with being occasionally (dis)connected, right? Solving that problem has been hard enough that mobile apps are still sprouting up that basically show content offline.

Riding to the rescue of the beleaguered user comes HTML5 with its cache manifest offering to give web apps a completely sane way of specifying what content should be held offline and what resides online. The  only problem is the memory limits most browsers place on the cache – except for Opera they all only let you have 5MB (or 10MB if you are on IE) – and in these days of fast connections and rich media that simply isn’t enough to get the job done.

There are various ways around this, with Google Gears, Microsoft Sync Framework and Flash also offering ways of getting offline storage to work, and there are some jQuery plugins that hint at the promise of getting this working in a framework that leaves the browser sensitivities to someone else (although I’m always leary of potentially leaky abstraction layers).

Personally I don’t care how we solve the problem of sufficiently large offline storage, but I think the future of web development demands that solve it we must.

In the meantime we will continue to see niche agencies offering native applications for various phone OSs, but not necessarily delivering the value the business needs because the cost is so high to develop cross-platform apps – and some other applications that target specific OS flavours, most notably Apple iOS or Android, and get away with that because the user base can be targeted that way (for now).

EDIT – 23rd Jun 2011

GigaOM recently weighed in, telling us that native mobile apps were beating HTML5 ones. One commenter, Roshan Shrestha, mentioned that:

“I see that many of the apps are just a wrapper against an HTML browser component. Most of them do not store much data locally and require internet connection, so these are basically web apps.”

I agree that most apps could be web apps, and I think it will end up there, but not yet. In the meantime everyone needs an Android app, wants an iPhone app and should have a Windows Phone 7 app.

Arthur Douglas Burgess

I just got delivered a very nice present. The National Library of Australia maintains an online archive of Australian newspapers for the last hundred years or so called Trove (http://trove.nla.gov.au/). A couple of weeks go I found a reference to my grandfather on my mother’s side, and a few days ago I ordered a copy of it via PDF. Thanks to the miracles of scanning + the internet, here it is:

My other grandfather was also involved with Fairfax and the Sydney Morning Herald, but in the capacity of a typesetter on the printing presses.

Is knowledge all there is?

I spent a fair bit of time this week helping a client with their information strategy and information management policy. Their definition of information included “Emails, Databases, Documentation and Knowledge”, which is a mixed bag if ever I saw one!

Clearly they needed to get a better handle on what they were dealing with, so I introduced them to a little pyramid that I had worked on several years ago (back when I was thinking about pursuing a career in knowledge management). I call this the Wisdom Pyramid, and use it to help differentiate between raw data, meaningful information, contextualised knowledge and applied wisdom.

Wisdom Pyramid

The example I usually use to bring it to life is that of a traffic light changing colour from amber to red.

At a data level there is a single bit of information, isolated from context and basically without meaning, unless one is familiar with that particular data type.

That data becomes information when meaning is given to it so that a human can more easily understand it.

The information becomes knowledge when context is considered, in this case that the traffic light is one I am heading towards.

Wisdom is exhibited when that knowledge is applied to my situation, so that I stop the car at the red light.

The pyramid is pretty useful, although there is a catch with wisdom as we only call an action wise when knowledge is applied correctly to a situation. Incorrect application is at worst foolish, and at best thoughtless.

Much ado has been made about the management of corporate knowledge, especially the attempt to capture explicit knowledge, although tacit knowledge is also sometimes acknowledged as something that must be transferred. The real issue however is how do we inculcate wisdom into our staff so they make wise decisions and not foolish ones?

“Take hold of my words with all your heart; keep my commands, and you will live. Get wisdom, get understanding; do not forget my words or turn away from them. Do not forsake wisdom, and she will protect you; love her, and she will watch over you. The beginning of wisdom is this: Get wisdom. Though it cost all you have, get understanding.”
Proverbs 4:4-7 (NIV translation)

You grow wisdom by growing people, and that’s where most knowledge management should start – tools are useful (and Elcom has some good KM tools) but mentoring, teaching and encouraging wisdom in our people is where the real benefits come from.

Fresh design!

In case you’re reading an RSS feed, I have updated my blog design to use a core Blogger template, and done some (slightly) artistic tweaking to get a look that I’m happy with.

Occasionally (Dis-)Connected is the Future

As web application developers we tend to build for always connected scenarios. They simplify the problem of web development and allow us to keep the complexity of our solution hidden on web and application servers back at corporate headquarters.

Pity the poor rich GUI developer who needed to handle both connected and disconnected modes – mainly for corporate management with laptops. This requirement increased the complexity of their applications and forced sharing of business logic with the client GUI layer. Recently mobile developers have realised the need to provide the same service, and with HTML5 web developers are now being pushed to as well.

At the same time, the ability of any client machine to get connected is increasing dramatically. Modern cities provide plentiful sources of free, commercial public and private wifi services, and most modern telecommunications devices allow for secondary use as internet modems.

It is now clear that most web applications/websites are likely to be accessed via mobile devices, and there are far more people with internet access via their mobile devices than via landlines/roaming broadband.

One might wonder whether disconnected clients still need to be supported, or whether the vast majority of clients in the vast majority of locations are best handled by assuming connected, always-on access?

The problem with this thinking is that it ignores a fundamental truth:

“Space is big. Really big.” – The Hitchhikers Guide to the Galaxy

OK, so these are not all apps that will be used in space (has the first iPhone gone to space yet?), but they can’t all assume that the user is always connected.

There are two fallacies with the premise of always-on access, the first is assuming that most people’s situations mimic the developers’ own ultra-connected, hyper-geek, lives, the second is limiting “everywhere” to the points on the daily commute. For most people in the world, in most places, there are going to be frequent losses of signal – even in Australia most telcos can’t get reliable mobile signal to all urban locations, let alone cover the vastness of our Outback.

Of course mobile developers know this is a problem, and might decry that their app can handle the phone losing and resuming signal flawlessly. But is there still value in the app when it is disconnected?

The most interesting opportunities lie with providing access to applications that can still provide value during the occasional disconnection – these are the applications that will be truly useful all the time and everywhere. For example the mapping application on my Nokia N85 can operate with three levels of connection:

1. Connected to the internet and GPS.
   In this mode I get the latest map updates and can tell where I am on the map.
2. Connected to GPS only.
   In this mode the maps used are the ones stored locally but my current location is derived from GPS.
3. Disconnected.
   In this mode the maps are available to be read, queried or manually moved around on, but my current location is not available.

Even in the most disconnected mode the maps are useful, I can lookup addresses and perform most of what I would have with an old-school street directory. When they connect further I get increasing amounts of value. Because of this sort of disconnected operation, the map and email applications are the most useful aspects of the phone to me (the other is the clock). They are more useful than a static application because they can occasionally connect and update themselves.

There is a term for this sort of behaviour that web developers have coined with websites that offer substantial value for all browser clients, but increase their value for some special browser clients.

Progressive enhancement

The point is to view the extra potential as something great to have, but not necessary for the application to fulfil its value proposition.

I really think this is the killer feature for a mobile app – provided of course that there can still be a value proposition in the disconnected mode. I also think that the best mobile apps will be web apps that respond and adapt to the restrictions of the mobile space rather than custom built ghetto-apps that can only prosper in one particular mobile OS. But that can be another post …