Skip to main content

Hack Highlight #4: How Did We Do?

This is the fourth in a series of blog posts highlighting hacks from Hack the Police.

Rory was the first person to explicitly state in his presentation something we were all thinking:

Police officers care deeply about the victims of crime.

That's why they go out every day to do what they do - to face not only danger, crime and disorder, but also the endless reams of bureaucracy and paperwork, seemingly invented to prevent the police from helping people.

The police service currently relies on paper-based feedback, or telephone calls to find out just how well teams, departments and officers are performing. That makes it very difficult to record and analyse the thoughts, feelings and opinions of large swathes of those who interact with police - simply because there isn't the capacity.

feedback welcome!
Rory's solution is much better suited to scaling quickly and much easier for members of the public to participate in - making it quick, easy, and cheap to give, receive and analyse feedback - and linking that feedback to specific incidents.

His hack, aptly entitled "How Did We Do?" does just that. It's an app that can be used by police officers or members of the public to take or give feedback. It collates that data, and makes it available to the appropriate teams.

Rory's system relies on 2 components: the app, which interacts with the public, and a back-end services that retrieve, store, and present the feedback for analysis. That creates 3 challenges:

  • Distribute the app: As this is a public-facing app, this challenge is overcome: we can use the regular public-facing app stores.
  • Store the data: Depending on the anonymity of the data, there are various levels of challenge to overcome. If, as I suspect, the data recorded runs the risk of representing personally identifiable information, then this is going to have to be stored in a secure server (likely IL3), which means it will have to sit inside PNN (the Police National Network).
  • Communicate between server and app: Again, as the server will likely sit inside PNN, reaching it represents a significant hurdle. There are well understood ways and means to do this, and plenty of advice from the home office and GCHQ on the matter - but no apparent will to actually perform this piece of work and stand up a gateway.
The over-arching challenge here, then, is to generate the interest and will from the departments and contractors that control PNN to allow the implementation of a gateway. 

It's interesting to note that the components required to build the gateway are a series of VMs, each hosting freely-available and open source software to provide the various security functions required of it. The cost of building and maintaining it is negligible as compared to the staggering size of the contracts in place for today's IT systems. It is widely acknowledged that those systems offer poor value - and in many cases actually impede the work police officers do.

Even this incredibly simple app that directly feeds into public confidence and police performance is held up by bureaucracy - fueled by the distaste of incumbent suppliers and contract negotiators for flexibility or change.

As I've stressed in previous posts on this topic, police services could cut out this blockade and deliver new apps and services to police and public quickly, efficiently and at far less cost - simply by employing staff with technical skills - and will continue to argue for this.

In the meantime, we will continue to develop and innovate - as there's still no better argument for change than being able to demonstrate new skills, benefits, cost savings and rewards for police and the public. 

Ultimately, we all want to make the world a better, safer place. The question is how to persuade the decision makers in policing IT that they should prioritise that as highly as we do.

Popular posts from this blog

Google Play Services with Android Studio

Edit: This post is extremely deprecated -- with prejudice! It was written in an era when Google Play Services were not well integrated with Android Studio project work, and Android Studio itself was in its infancy.

This is a very quick guide to incorporating Google Play Services with your new Android Studio project.

Edit: [16:20 22/05/2013] I'll investigate the runtime NoClassDefFound error reported in the comments, and follow up later!

Edit: [23:17 27/05/2013] I'm coming to the conclusion that - as many have already pointed out - you really do need to include the entire library project in your solution. I'll post an update once I've fully tested this. 

In the meantime, please consider the advice below to be deprecated!

The first thing to say is: I fully expect the advice and guidance about how to work in Android Studio to change over time. Android Studio is in early access preview right now, and I'll bet my bottom dollar (is that a thing?) that over time it becomes m…

What's the best way to handle the Android camera?

This article is adapted from a response I gave on Reddit to the question "What's the best way to handle the camera?" in r/androiddev...

The Camera and Camera2 APIs are far from painless to use. If you've ever written an app that uses the camera (embedded in an activity or not), you've almost certainly come up against orientation issues, stretched previews, or weird quirks that change from manufacturer to manufacturer...

There are three good libraries out there that can save you from many common pitfalls:
Google's (unofficial) CameraView library.Mark Murphy's CWAC-Cam2 library.Dylan McKintyre's CameraKit for Android library. Each has different strengths. If you don't have time to read this whole article, here's a quick rule of thumb:
If you want to capture photos in a full-screen preview, but you don't want to have to rely on the native camera app, then use CWAC-Cam2.If you want to embed a preview into your Activity, use CameraKit. It's f…

Wriggler

It was 1998 and I was 17. My tool of choice was QBasic and this is a game I wrote based on a concept I stole from another game called Wriggler.

The original Wriggler is a race game through a maze of bugs and creepy crawlies - played against the computer. My game would have been a race, had I gotten around to writing the computer player.

Instead it pits you, a plucky young worm (comprised of 4 lines and a blob), against an army of anatomically incorrect spiders in your mission to see a duck and solve a single puzzle. Also there are some chocolate bars.

I fired it up once again to make a playthrough video. The game features some pretty old-school beep/boop sound effects, which really hit me right in the nostalgias!

Warning, this playthrough video contains spoilers for the puzzle... 😂


I don't suppose there's much to be learned from my code, but you can see it all on Github if that's your groove and you're welcome to have a tinker. I had some success running it with DOSBox