This is the talk I gave at Fosdem 2015 about a proof-of-concept
personal datastore called Habitat.

Slide 1 - Habitat - A programmable personal geospatial datatoreGeospatial devroom - Fosdem 2015 Richard Pope

My name is Richard Pope, and I am going to talk to you about a proof of concept service I’m building called Habitat. Habitat is a self hosted, programmable geospatial datastore, or a kind of digital assistant, an external brain like google now or IFTT. Or rather it could be, for now Habitat is just a proof of concept to try and scratch some particular itches:

Slide 2 - Our mental models of our environment are personal data- map of where I live with outline of what I consider my neighbourhood

What we consider to be personal data is going to change to include things like our mental model of our neighbourhood. Hint: it’s probably about a 15 minute travel form where you live, but it will be different for everybody, or the hash of your journey to work each day. This stuff is too important to loose control of for the sake of pure convenience.

Slide 3 - Context and push - photo of Google Now push alert on a pebble watch

As software becomes more woven into our lives, context and push will will come to define user interfaces. Mice, keyboards, activly visiting websites are on the wane. That certainly seems to be the play Google Now, Facebook, EasilyDo, Amazon are all making anyway. Geospatial/location feels like the most important context in that world.

Slide 4 - Mobile web and sensors - screen grab of github repo showing list of HTML5 APIs including battery status and page visibility

A web page on your mobile phone knows where it is on the planet, which way it is orientated, where it is in 3d space, how much battery it has, how close it is to your face and what the ambient light is. Who will be the broker for all the data you are generating?

Slide 5 - Cucumber tests are not just for testing - photo of hand written cucumber test about ammonia levels in the River Avon

Cucumber tests can be used for much much more than testing software. They will be used to verify public datasets and as a user interface onto changing datasets. This photo is from a hack day organised by the UK Environment Agency, exploring the idea of using cucumber tests to check for environmental breaches in open environmental data.

Slide 6 - The real value in OpenStreetMap is in the polygon - photo of a phone showing a test web page

OpenStreetMap’s value is not in the map, it’s in the data. The polygons represent an open, queriable land use map of the whole planet, and you can do some interesting things with that. This was an experiment I did to build an api for testing if I was indoors or outside by loading the outlines of London buildings into a mongo db instance.

Slide 7 - Schematic of how Habitat works - core server with input and editing apps accessing it via oauth, outputting various actions

Habitat is a self hosted, personal, programmable geospatial data store.

Slide 8 - Example cucumber test - Scenario: Near a point in space When I am within 100 meters of “[0,0]” Then ping “http://example.com/tad-ah”

The tests look like this… WHEN I am with in 100m of [XXX,XXX] then ping the url example.com/tad-ah

Now, that is about the limit of what I’ve actually implemented, it is a proof of concept, which I’ll show you in a minute, but the idea is to be able to do other things.

Slide 9 - Example cucumber test - Scenario: In a park and rain dueWhen I am in a “park” and the weather looks like “rain” Then send an sms “RAIN!!!””

So taking public data, for example about the weather, and building alerts based on location - so if I’m in a park (OpenStreetMap polygons define what areas are parks), and the weather (from the Met Office API) looks liek rain, then send me an SMS.

Slide 10 - Scenario: Bicycle barometer When I am “at home” and the weather looks like “snow” and the tube status of the “Victoria Line” is “good”Then ping “http://barometer.memespring.co.uk?value=10””

Eventually it could be used for much more complex use-cases like powering a thing I made called the bicycle barometer (which currently runs on bespoke code).

Slide 11 - Annotated schematic of Habitat”

A quick word on what it is build with, then a demo. Habitat is built using Flask, a Python framework, and exposes an oAuth secured API using Flask Restful and Flask oAuthLib. It stores personal and public data in a MongoDB database, and runs cucumber tests against the data using Behave and Celery.

There are currently client apps for reporting your location and editing cucumber tests.

Slide 12 - Demo”

Demo Gif: editor client, edit a cucumber test”

The server itself doesn’t have much of an interface, you can just login and see what apps have been granted access.

Demo Gif: location client - report client and then see test run successfully”

This is an example client for writing cucumber tests. In this instance, I’m going to amend the latitude and longitude where this test is triggered.

Demo Gif: Singing into the server”

This is an example (very basic) client for reporting a single location. Really this should be a native mobile app running in the background continually reporting my location.

Reporting the location causes the cucumber test to be run, and you can see it running successfully.

Slide 12 - Thanks”

github.com/memespring/habitat

February 11, 2015

• Web pages in Firefox are getting a Bluetooth API for pairing and sharing data directly between devices and web apps.
• GeoTrelis is a tool for doing fast queries against geospatial raster data. The demo I saw was priocessing several GB in a few sseconds on a standard laptop.
• GeoGig is distributed versioning of geospatial data.
• Matrix a distibuted comms system, but looks like it could also be used as a distributed immutable datastore.
• DIY book scanning [is a thing].(http://www.diybookscanner.org/)
• Pump.io is a library for building distributed social network type things. I bet there’s a couple of hyperlocal things in that.
• Media Goblin is a decentalised Flickr/Youtube type thing. When we all have tiny home server, and it has had some UI love maybe this will be a goer.
• Scrapy is simple, serious looking scraper library for Python.
• Open Food Facts is building an open database of what is in our food, indexed by barcodes, collected via phone apps.

February 9, 2015

Usernames and passwords are on borrowed time as a design pattern. Examples of the damage it does are everywhere. The only thing keeping it credible is two factor authentication via SMS or a mobile app, and that can’t reasonably survive the switch to mobile as the dominant way of accessing the web (because it’s not really two factor if it’s on the same device, right?).

The future, probably looks something like this from the FIDO Alliance, which sets out specifications for the use of hardware dongles for strong 2-factor authentication in association with a pin or password. (It also sets out specs for the slightly more problematic / scary use of fingerprint scanning, speech etc for authentication).

Hint: if you are a designer or developer, buy a Yubikey hardware dongle right now and start experimenting. Even if that particular bit of hardware doesn’t win, it will give you a feel for the sort of interaction patterns you will be dealing with in the near future.

Anyway, what I’m interested in, is what changes when signing-in to a service becomes an order-of-magnitude quicker and more secure?

My hunch is we quickly get used to signing in more often, to a greater number of services at once, and the oAuth style permissions pattern that is currently the preserve of large platforms like Google or iOS starts getting implemented by smaller, more discrete services.

The result: and it becomes much easier to build composite-services made up of lots of loosely joined parts.

February 6, 2015

I went to hear Vernon Bogdanor talk about the (first) 1974 General Election the other day. It’s part of a seris about post-war elections that is well worth a watch.

In passing he used a phrase that stuck in my head:

Democracy is government by explanation

Apparently it comes from Prime Minister A.J. Balfour and/or Geoffrey Howe.

What I think it is saying is this: it is a characteristic of a democratic system that people have clear opportunities to be able to understand the workings of that system, and that one of the ways you build trust in government and health in the system is by actively exposing how it works and why things are how they are, be it planning permission, taxation or hospitals.

It reminded me of what Aneurin Bevan was supposed* to have said when setting up the NHS:

The sound of a bedpan dropped on the floor of Tredegar hospital should reverberate in the Palace of Westminster

That normally gets cited in terms of ministerial accountability, but there’s another way to look at it - that there should be a direct link between service delivery and its accountability mechanisms, and that link should aspire to be as understandable and effective for someone using a hospital in Blaenau Gwent or Wesminster.

As public services start becoming digital, both those things - exposing the workings, and providing understandable feedback mechanisms that are useful to politicians and the public - become a lot easier. You can reveal the workings of a policy by clicking a button directly in the service and send feedback from within the service (that sort of integration is just harder with paper forms and disparate organisations).

Maybe rather than some attempt at online direct democracy, or a dozen new ways to do consultations or petitions, this will be the real democracic revolution of the digital age: transparency, accountability and democracy at the point of use.

Democracy at the point of use

• it’s hard to find a definitive quote

January 23, 2015

This is a second attempt at articulating this issue, and was inspired by a conversation with @psd who also pointed me at a TEDx talk entitled A time traveller’s primer. The first attempt is here.

It took 4 or 5 years of ajax / XMLHTTP being a thing for it to change almost everything about the sort of things that were built on the web. That was 4 or 5 years when lots of amazing things didn’t get built, not because it wasn’t possible, but because people just, didn’t. There were probably lots of transient reasons - browser support, users might not understand it yet, hard justifying it to co-workers, lack of examples - but fundamentally, there was lots of potential that was not realised until later in time. When that potentual was finally realised everything that went before suddenly felt dated.

This is faster than the 700 year example of pasteurisation that Ryan North gives in his TEDx talk A Time Traveller’s Primer (and yes, ajax is significantly less significant than pasteurisation) but the principle is the same:

If you want to design for the future, look for unrealised but present potential, look for what people could be making right now but are not. Design what is lacking.

The web is going though an Ajax moment right now, and it is happening (or rather has the potentual to) for 2 reasons:

2. The things browsers can do The web browser on your phone has access to sensors, outputs and offline storage to make proper contextual design a reality. It can:

• capture a screen
• check if a tab has been backgrounded
• check the battery
• check orientation of the device in 3 dimensions
• check and lock the orientation of the screen
• detect the pitch of a sound
• listen to you
• record video and audio
• respond to ambient light
• share all or part of your screen
• show notifications
• talk to you
• talk, type or video conference someone
• use your camera
• vibrate
• work offline Most of those won’t work if you try them on a laptop browser, but they will on your phone or tablet if you use chrome or firefox. This is partly the point, the technology is here, but not in the tools that we use to design things for the web (laptop browsers), but is in the place where users are spending more time.

Designing in a laptop web browser and testing with a mouse rather than fingers may come to look very out of date soon.

2. Stable mobile design patterns The 7 years of the Apple App Store and the android equivalents have, in effect, been mass, micro funded experiments in UI design for small, touch sensitive devices with lots of sensors and outputs. They have generated winning patterns like:

• Checkboxes replaced by switches
• Check-ins
• Edit without save button
• Everything can be contextual, any bit of UI can disappear between pages
• Everything has it’s own settings page
• Floating buttons
• Keeping primary navigation off canvas (hidden behind the page)
• Minimal or zero page header (the context an old school page header / nav gives seems less important when you are holding the app in your hand.)
• Multiple, focused apps for the same service
• Offline by default
• Overscroll to refresh
• Reserving dropdown menus for actions on the current context
• Search scoped to their current context (the app) These are patterns that people use day in day out on facebook, Gmail and WhatsApp. These are the new normal, what people expect.

But with a few notable exceptions - eg the mobile versions of Wikipedia and Forecast - these are not patterns that are making their way on to the web.

So, here is the challenge for anyone designing and building for the web in 2015. There are a set of technologies and design patterns that are here, right now, not experiments in an innovation lab, but things you can use to design better tools for people. Today.

At some point in the next few years, some of these will become as widespread on the web as ajax and responsive design, so why wait 5 years? Design what is lacking.

January 17, 2015

It’s nice when things just become quietly, abundantly useful.

QR codes have gone from something people plastered over business cards and adverts in failed attempts to appear cutting-edge, to the default pattern for moving information along the following interaction:

a web transaction → time passes → queuing up for something → human interaction → scan → some sort of change of state.

Quickly thinking back over the past year I’ve:

• Printed a paper ticket and had it scanned using an abnormally large laptop in a rainy queue at The Fall gig at Electric Brixton.
• Had a PDF scanned to get on the Amtrak Coast Starlight.
• Had a printed ticket scanned using adapted phone scanner in the queue for some club in Portland and Bob Mould / Liars at Village Underground.
• Waved a code embeded in an app against an entry gate to the Eurostar.
• Printed out a label and stuck it to a package to Amazon via Collect+
• Had a an email scanned on my phone queing to see a film at the Ritzy.
• Had a ticket in Apple’s Passbook scanned on the way in to see a baseball game
• Scanned my laptop screen using my phone to load a TOTP security token to a Yubikey

January 14, 2015