We’ve had QR codes in our lab for years, though I don’t think they’ve ever been the significant part of a real project (feel free to shout me down ETS colleagues). The technology behind them is solid, but their usability problems are well documented, or the butt of a joke. Despite being derided they do have industrial applications, are looked upon more fondly in China and Japan, and even Western consumers use them more than they think. It tends to be in generating the codes rather than scanning them (paying with the Starbucks app, printing airline boarding passes). Nonetheless there is still an awkwardness in using them and their ugliness ruins many slickly designed posters.

I was interested to hear talks by Scott Jenson and Stephanie Rieger at October’s excellent Beyond Tellerrand, both discussed Google’s Physical Web. The open sourced project replaces QR codes with Bluetooth beacons, transmitting URLs to nearby smart phones (no awkward scanning required). The idea is that it makes more sense to control Internet of Things devices via the web, rather than installing an app for each connected device. Broadcasting a URL provides the link between the physical device and its web interface.

Google’s implementation (via Chrome or a Physical Web app on iOS) displays meta data for each URL, currently a title and a description, when the beacon’s signal is received. Stephanie talked about how nearby beacons might be integrated in to web search results and Scott described examples where the meta data is changed dynamically to provide realtime information for the beacon. This is a neat trick. The beacon continues to transmit the same fixed URL, but the meta data at that URL is changing, giving the appearance that the beacon is transmitting live data. Scott gave an example of a beacon transmitting bus tracking information using this technique.

The ETS group in the UK are already working on IoT projects and ideas: Node-RED, Conversational IoT and Smarter Buildings. The Physical Web appealed to me because it was so simple. The software is web based and all the hardware can do is broadcast a URL. Counterintuitively, having such a tightly specified technology provides space and a challenge to be creative in its use. IoT feels quite messy at the moment, there’s lots happening, but many different technologies and approaches are trying to gain a critical mass. I find it difficult to explain what it is. The Physical Web is trying to address one tiny part of the space and it makes sense in its own right.

Kevin is working on using IoT to enhance the physical workspace. I’m interested in why our internal meetings are terrible, actually I’m less interested, more frustrated. We tend towards group decision procrastination. As cliched as they may be, post-it notes and a bias towards writing instead of talking has helped. In online meetings we have tools to support decision making, specifically voting, but this isn’t something we use in physical meetings. It could easily be done, but isn’t. As an experiment in using the Physical Web I wanted to create a voting system for physical meetings. A meeting would have a current question and attendees could vote with one click. There would be no entering URLs, downloading apps, or scanning QR codes.

Prototype

I considered using a simple bluetooth beacon, something like an Estimote, with a fixed URL to represent the current meeting question. The question would be displayed on the user’s phone, they’d click on it and then select the answer. It’s not terrible, but there is friction. Ideally I wanted all the possible answers to be visible directly. I could have used multiple beacons, one for each answer, but you don’t necessarily know how many options (and therefore beacons) a question needs. Also, we didn’t have many beacons. Instead, I used a single bluetooth device connected to a computer so that I could programatically update the URL it was transmitting. There’s only enough space to transmit one URL at a time, so I made the code cycle though an array of URLs - one for each answer, transmitting a URL for a few seconds before moving on to the URL for the next option. Smart phones show the beacons even if they’ve not transmitted for a few seconds, so the result is a list of question answers on the user’s device, using just one physical bluetooth device. It may take a few seconds for all the answers to become visible, but in practice it didn’t seem to be a problem

I don’t think beacons and the Physical Web were really meant to work quite like this. As far as I understand I’m not breaking any protocol rules, but I suspect rapidly cycling though broadcast URLs is against the spirit of beacons, if not the Physical Web. While this currently works, it is something that could break in a future Physical Web update, it’s up to the Physical Web clients to decide what they make of the Bluetooth signals they receive.

The Physical Web relies on a proxy server to supply the meta data to the smart phone. This is done for speed, but also for security, the URL needs to be accessed without the user’s intervention, so going to an untrusted and unknown URL would have security implications. Scott talked about using dynamic updates of meta data by setting the cache headers on the URL’s page. This isn’t quite true at the moment. Google’s proxy servers cache the meta data with a minimum refresh time of 5 minutes, regardless of the headers. There’s nothing to stop you using your own proxy, but this would need the user to install an app, which defeats the main advantage of the Physical Web. The result of this is that a new question’s meta data might not be visible for 5 minutes, which isn’t particularly usable for meeting votes. To get around this I generate a new URL for each question that’s asked.

Next

The prototype is running in our lab. The next step is to wait, this will only become useful if the Physical Web takes off. For that to happen support for it will need to be built in to both Android and iOS. It’s been useful to explore the limits of what you can do wth the Physical Web and how it might be used. It’s work you can only do by trying it out and pushing at the edges, something that I think the Emerging Technology group is good at doing. Whether voting in meetings is useful is mute, it’s easier to explore a technology using a problem.

In this project there’s a question over what the physical ‘thing’ is that I’m attaching the URL to. Usually the thing would be a device, be it a printer, parking meter or fridge. In this case, I’m not sure if the physical thing is the meeting room, or the meeting itself. How would someone would know that a meeting has a Physical Web interface? If you have to put a sign up saying “Scan for this meeting’s URLs”, it feels like you’re not far from having a QR code again, or just a URL in English. The interface to the meeting that I’ve created is invisible. Is an invisible design a good or bad thing? It’s clearly a problem in this case, more thought is needed, but again it’s useful to find real problems or questions by building something.