Zeitgeist is a great word which according to Wikipedia means spirit of the age or spirit of the time. I think the spirit of the current digital age could be mobile apps.
Apps is very much a blanket term that can cover all manner of software but in this context I am referring to the kind of apps that you will have on your mobile device.
So very much surfing the Zeitgeist I felt that it was worth running a workshop about how to build mobile apps.
Why you may ask? Well for a number of reasons.
I could sense from a number of conversations with colleagues that more of them were making the mental cross-over of thinking about how tools that they use outside work (apps) might be relevant in the work environment. A couple of possible examples had already been suggested. There was also the possibility that there might be some great ideas for apps floating around that just needed to be captured and investigated. However it was also fairly obvious that there is more to apps than meets the eye and that actually getting one up and running might be deceptively hard.
However I was conscious that its a lot easier to talk about doing something than actually doing it. So what better way to find out than from learning by doing? Hence the idea of an apps workshop.
Of course I had no idea how to create one so I checked around with a few suppliers to see what might be realistic and cost-effective.
In the end it was one of the developers who helped with our data lab Giuseppe Sollazzo who was our partner in this venture into the unknown.
So we spent some time discussing what would be useful in the NAO context to illustrate the key issues and provide the most learning points.
The somewhat tricky bit was sorting out the technology as we wanted to learn about apps on Android, IOS and Windows; though we decided not to worry to much about Android for the moment since NAO users Windows internally and a potential key audience for it externally are MPs who use iPads.
As a result with the help of my colleagues in the IT department we had five new issue Windows 8.1 machines loaded with the relevant developer software and phone emulators. I also hired five iMacs which again needed the relevant software installed.
In the meantime I publicised the event internally trying to get a nice mix of what I would call pure auditors, geeky auditors and developers – so a real mix of experiences and knowledge.
On the day we spent the morning running through the history of mobile phone development and related apps. They are much older than you think. This was to help set the context and clarify what an app is. We also covered other perspectives such as Tom Loosemore’s argument that a well built website does not need apps.
This is when we hit on our first key learning. Explaining how IOS worked took about four times longer than Windows. This is because IOS has been around such a long time it has layer upon layer of interactions to cater for. By contrast Windows was much more straightforward as familiar coding languages can be used to build apps. No one expected that.
We soldiered on after lunch to start working on apps following the cheat sheets that Guiseppe had created for us. Again the split between Apple and Windows became apparent as the team working on the iMacs melted into a pit of despair at the difficulty of what they were doing whilst the Windows team had some reasonable successes.
I should say that overall everyone did really well as they were using devices they were not familiar with, new software and new concepts.
So what did we learn?
It does look as though if any iPad apps are ever needed that they should be outsourced. A fair number of apps for Windows could probably be built in-house or at least a significant amount be started on them.
As part of the ‘show and tell’ we ran a brainstorm of potential apps and generated 15 or 16 ideas. There are probably a lot more out there in the organisation which we need to coral into the same place.
We would still need to work out some kind of consistent production process and quality control. Making sure that there is a genuine user need is also key.
It goes without saying that one should never underestimate the ingenuity and persistence of auditors.