How we ran our mobile apps workshop

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.

 

 

 

Does digital transformation really exist?

I have heard the phrase digital transformation bandied around a lot around and it made we wonder what does it actually mean?

I suspect that we all having an image in our minds when we think of digital transformation.

Does the meaning of the phrase depend on our roles and mindsets?

So if you speak to a certain group of people in central government, particularly those with links to the Government Digital Service, they might start talking about the 25 odd digital exemplar projects. Here is their list of projects on a page labelled transformation.

If you talk to someone who works in communications their idea of transformation might be killing off press releases and having a longer term relationship with audiences based around engagement and outreach.

Some of my colleagues are interested in getting rid of paper in certain meetings and they see this as digital transformation.

Or does it relate to the collection and manipulation of data?

Are these all aspects of the same thing called digital transformation or totally separate changes?

What happens if we separate out some of these words and ideas?

What does digital transformation really mean?

Is it one of these phrases a bit like the ‘industrial revolution’ which first referred to a short period of say 1780 to 1825 but then got stretched back to cover tin mining in Cornwall centuries before; and went much further into the nineteenth century. How long does transformation take? One month, one year, one decade?

Is transformation just the steady migration of functions and services into an electronic format? In theory we could probably map this and see where it is heading next. Is this process a bit like industrialisation which led to the standardisation and mechanisation of previously individual, often manual labour?

When we look at say, the exemplar projects, are these much more than the application of business process management, (Lean etc) to functions in the aim of rationalising and making them more efficient using the tools available now?

When did digital communications start to be transformed? With the introduction of the morse code, radio, telephone, television?

I’m not sure that I know the answer to the question ‘does digital transformation really exist’.

However it would be nice if the real digital transformation could stand up and reveal itself while the imposters run away.

 

 

Are there any common principles for digital services?

I have recently been involved in looking at some internal digital services in the role of Digital Architect.

During this process I have a mental model of the key points that I would expect in any service.

These are pretty generic and I would ask them for any new service, or an old one which is being transformed.

They might not all apply to every service.

I am not saying that we should always take the relevant action but we should make sure that we consider them.

See what you think. Would you add anything extra?

 

People
  • We will focus on our known user needs: if we do not know what these user needs are we will find out
  • We work based around personas, user cases and tasks
  • We will provide a consistent user experience (e.g. buttons look the same and generate the same action)
  • User feedback is integrated into every product creation process and inbuilt once a product is live
Information/data
  • When users look for information they should be confident that they have found everything on that topic
  • We should always aim to be able to re-use information/data externally for the benefits of our clients
  • Information/data should be input once and retrieved many times
  • Content should only be in one place either internally or externally and not duplicated
Technology
  • We follow an agile, modular, design and build approach
  • Wherever possible we will create API to allow the easy reuse of data/information internally or externally
  • We will always consider if content or processes can be made as a app
  • We should focus on open standards and avoid vendor or supplier lock-in
  • Any information or data should be easily exportable from any system
Processes
  • Each process will have a high level process map to fit into the NAO QMS
  • We will identify poorly performing processes with a view to transforming them
  • We aim to minimise the number of user actions/clicks for every process
  • We will create agreed performance metrics and create a performance dashboard
  • We must follow recognised governance and risk management procedures

Microservices or mammoth services?

I suspect that I need to explain both these terms so here goes.

Microservices

The word Microservices has become popular recently as short hand for a particular approach to online services. The basic idea is simple. It is that when new services are created that they are sliced up into discrete parts that can operate as standalone items but collectively provide a full services. Oddly there is no definition that I can find on Wikipedia for microservices or I would have linked to a better explanation.

One of the best examples of microservices would be something based around APIs (see my post from last week). So in the case of 7digital.com  their overall service is selling music. On their homepage they have tabs for ‘New albums’ ‘the best of 2014’ etc. Each of these tabs of content is no doubt fed by APIs. If something broke one tab of content might be unavailable but the others would still work. So resilience and flexibility are built into the system.

As so often this sounds like a really obvious idea but how far is it widely used?

Mammoth services

Well this definition is not in Wikipedia as I just made it up. I was trying to think of what is the opposite of Micro. Here are some possible examples.

If you live in England and do a tax self assessment the HMRC website will be used. Under the current set up the interface works to cater for every potential user journey. Therefore on each page there are numerous boxes to complete often not relevant to the particular user. It is time consuming and can be confusing. If the site went down no one would be able to complete any of their tax returns.

What would happen if this was split up into microservices? Well potentially the different user journeys could each be a microservice with their own little server. Each journey could be tested and launched separately as it was ready. If one server (or virtual machine) went down all the other services would still be available.

So it seems to me that there is some value to microservices and it might be an approach worth considering if you are looking to launch new services or tweak existing ones.

Do you have an API economy?

APIs have been around a long time. Not sure what an API is? The Next Web is worth reading on this…

As ever Wikipedia has a good answer: ‘In computer programming, an application programming interface (API) specifies how some software components should interact with each other.’

Sounds straight forward, or is it? Of course as is usual in the software world there are a number of different languages and schools of thought which we do not need to worry about here.

This might sound a bit geeky so what is the relevance to the real world or indeed the public sector?

Guess who is one of the biggest user of APIs? Its Amazon.

Internally all their teams create products that interact with other teams via APIs. This serves a number of purposes – it is a business tool to help Amazon build its own organisation in a modular manner – it’s a kind of plug and play. As a by-product these APIs are in effect being tested internally. If an API is seen to have a wider value it is made public to the outside world and this allows us as consumers to use the data either directly or indirectly.

But what is an API really? How about calling it a data stream that is documented so that others can use it. For example at the NAO we could make an API of a list of report publication dates, report titles, audit topics – this list would update as more reports are published. Someone in the outside world could then tap into this data stream and feed it into their own website or merge it with related data.

I have been to a couple of talks recently which brought home why people talk about an API economy.

There were two companies who generate significant portions of their revenue via APIs. For example 7digital.com an online music store with 22 million tracks is built on numerous APIs that feed the data they hold on all these tracks in different formats. Holidays Extra is another site built around APIs. One of their developers explained how recently they released a set of APIs and in a short time a whole ecosystem grew up around it using their data generating the kind of ideas and use of data that they would never have thought of themselves. Indirectly this led users back to their content and generated new revenue.

If you want a bit of fun Tesla the car company has just released some of their information as an API If you take a look you can see that by releasing this data it has allowed external developers to start building new applications based on this information.

Or look at the Transport API  if you want to see how an API economy can develop. The team pull together lots of different data sources, add value, and charge above a certain level for usage of the APIs.

Ok so that’s the private sector what about us in the public sector. Well take a careful look and you will see that organisations like the Office of National Statistics or DVLA are starting to release APIs. Why because they want others to use the data that they have collected; in some situations there could also be revenue generating opportunities.

So if you have a good data source or something that could be turned into an data source there might be some mileage in considering creating an API. You never know before long you might have your own API economy.