Gadgets, Programming, Python

Creating the Guardian’s Glassware

For the last two months on and off I’ve been developing the Guardian’s Glassware in conjunction with my colleague Lindsey Dew.

Dealing with secret-pre-alpha hardware has at times being interesting but the actual process of writing services using the Mirror API is actually pretty straight-forward.

Glass applications are divided into native, using the Glass SDK, and service-based Glassware using Mirror. Mirror is built on web-friendly technologies such as HTTP, JSON and OAuth2. It also follows the Google patterns for APIs so things like authentication, discovery and the client libraries are all as you would expect if you’ve used a modern Google API before.

For our project, which was focussed on trying to create a sensible, useful newsfeed to Glass, we went with Mirror. If you want to do things like geolocation or picture and video upload then you’ll want to go native.

For various reasons we had a very narrow initial window for development. Essentially we had to start and finish in May. Our prototyping was done with a sample app from Google (you can use Mirror without an actual device), the Mirror playground and a lot of imagination.

When we actually got our Glass devices it took about a week to get my head round what the usecase was. I was thinking that it was like a very lightweight mobile phone but it is much more pervasive with lots of light contact points. I realised that we could be more aggressive about pushing information out and could go for larger sets of stories (although that was dialled back a bit in the final app to emphasise editorial curated content).

Given the tight, fixed deadline for an unknown product the rest of the application was build using lots of known elements. We used a lot of the standard Glass card templates. We used Python on Google App Engine to simplify the integration service and because we had been building a number of apps on that same stack. The application has a few concerns:

  • performing Google Authentication flow
  • polling the Guardian’s Content API and our internal Notification platform
  • writing content to Mirror
  • handling webhook callbacks from Mirror
  • storing a user’s saved stories

We use Content API all the time and normally we are rendering it into widgets or pages but here we are just transforming JSON into JSON.

The cards are actually rendered by our application and the rendered content is packaged into the JSON along with a text representation. However rendering according to the public Glass stylesheet and the actual device differed, and therefore checking the actual output was important.

The webhooks are probably best handled using deferred tasks so that you are handing off the processing quickly and limiting the concern to just processing the webhook’s payload.

For the most part the application is a mix of Google stock API code and some cron tasks that reads a web API and writes to one.

Keeping the core simple meant it was possible to iterate on things like the content mix and user interactions. The need to verify everything in device served as a limiting factor.

Glass is a super divisive technology, people are very agitated when they see you wearing it. No-one seems to have an indifferent opinion about them.

Google have done a number of really interesting things with Glass that are worth considering from a technology point of view even if you feel concerned about privacy and privilege.

Firstly the miniaturisation is amazing. The Glass hardware is about the size of a highlighter and packs a camera, memory, voice synth, wifi and bluetooth. The screen is amazingly vivid and records and plays video well. It has a web browser that seems really capable of standard HTML rendering.

The vocal recognition and command menus are really interesting and you feel a little bit space age when you fire off a Google query and get the information you’re looking for read back to you in seconds.

Developing with the Mirror API is really interesting because it solves the Android fragmentation issue. My application talks to Mirror, not to the native device. If Google want to change the firmware, wire protocol or security they can without worrying about how it will affect the apps. If they do have to make breaking changes then can use the standard webapi versioning they already use.

Unlike most of the Guardian projects this one has been embargoed before the UK launch but it is great to see it out in the open. Glass might not be the ultimate wearable tech answer; just as the brick phones didn’t directly point to the iPhone. Glass is a bold device and making the Guardian’s journalism available on a new platform has been an interesting test of our development processes and an interesting challenge to the idea of what web-capable devices are (just as the Pixel exposed some flaky thinking about what a touch device is).

What will be interesting from here is how journalists will use Glass. Our project didn’t touch on how you can use Glass to share content from the scene, but the Glass has powerful capabilities to capture pictures and video hands-free and deliver it back to desk editors. There’s already a few trials planned in less stressful feature pieces and it will be interesting to see if people find the interface intuitive and more convenient that firing up their phone.


Google Apps and App Engine

If you use Google Apps to provide you with email then you should also really be thinking about enabling and using Google App Engine as well. Internal applications are much easier to deliver to the business as a whole and having a ready-made platform makes it easier to try out ideas that previously would have been impractical.

The first advantage is that Google Apps that are bound into your domain allow you to create something that is easy to access for an existing user (no additional login is required) but also gives you peace of mind that you are exposing virtually zero surface area for attack.

The second is that for Python at least it is easy to access a very full featured environment with a minimum of code. Want to send emails, have task queues, access to memcache, serve static content? It is all a YAML configuration line or import away.

I love services like Heroku but a lot of internal apps have relatively light usage and benefit from the batteries included approach rather than combining various plugins. It makes it easy to switch between different approaches and react to different demands.


Google please adopt a humane markup language

What do Google Pages, Blogger and Google Sites have in common? A rubbish HTML WYSIWYG editor component is what. Using the WordPress editor I am consistently impressed at how good the HTML generated is and how rarely I need to go from the Visual view to the raw HTML.

With Google’s version though you never know when you’re going to be dealing with a set of <br> instead of the paragraphs that you might have thought you were working with. In fact sometimes when the visual editor is going wrong I dread to switch views and find out what has actually been going on behind the scenes.

There are two ironies in this, firstly Google Docs actually has a decent HTML editor dressed up as a word processor. It still suffers from switching between paragraphs and break returns but it is generally pretty good at keeping in the same mode once you’ve manually set it.

The second irony is that I have been using Markdown in both and Tumblr and I have to say that while there is some overhead in learning the syntax the truth is that Markdown pretty much gets everything right from a HTML point of view and is much quicker to right than a WYSIWYG component that you have to keep double-checking.

Please Google, if you really cannot cooperate internally to create one HTML editor that does the right thing could we please have an option to use a humane markup language. I don’t mind which one: Textile, Markdown, Wiki Creole – take your pick. Throw a power user a bone!


Google Chrome: what browses what?

Okay, so nearly a month after it lauched how is Google Chrome changing the way we browse? Well for Linux and OSX users, not very much. However on Windows, Chrome is finding a place into my day to day browsing. Firstly I have started to tend to use it with Google products. There’s nothing rational about this, it seems to be just brand fetishism.

I have also started to use it for any site that uses Gears. Since Gears is built in to the browser it just seems to make sense. I liked Gears a lot before Chrome and although I have it installed in Firefox I figure it is easier to use the features when they are integrated into the browser and have the advantage of the V8 Javascript engine.

I also use Google Chrome on sites where I actually expect a lot of Flash, script and Fail. Being able to kill poorly programmed sites while keeping on trucking with the browser is a pretty killer feature.

Finally I also use it to view links where I want to look at something briefly and then do nothing more with it. I don’t know whether it really makes a difference but I always wonder how much stuff Firefox caches when I am briefly checking a link for something a blog post.

Web Applications

Google Sites: What I would like

I am not going to deny that the basic Wiki functionality is all there but there are a few things that I would like to see. Now I know it is a free service but I would actually be prepared to pay for some of this on a WordPress model (i.e. buy what you want when you need it).

  • Categories or page tagging
  • The ability to send a page to Google Docs or alternatively the ability to export to external formats as you can for a Google Document.
  • The comments section should collapse if there are no comments; ditto the attachments. If something does not apply to my page then I just need a simple text link to add it.
  • Most of all, proper HTML markup rather than a massive paragraph consisting of my whole page, with a BR tag… if I’m lucky. If I want to reuse my content then I cannot export it and its not even decent HTML. Blogger is no better but crazily Google Pages does the right thing!

As with Blogger I think Google is having some major integration issues with all the companies it has bought up. If one of the applications or systems has a cool feature then I think it is natural to assume that it will be available in all Google branded applications.

Web Applications

Try our new, new services!

So on Friday not one but two long awaited beta service invitations arrived. The first was the announcement of the addition of Jotspot to Google Apps (finally) and the other about the Amazon Simple DB service. Typical buses…

I didn’t have a lot of time this weekend so I plumped for signing up for Google Apps and trying the new wiki functionality as I was hoping for a beefed up version of Pages. The Simple DB service also needs me to beef up my Web Service scripting fu.

It is too early to say much about either service but after signing up for a Google Apps account (apparently you cannot simply drive one off your regular Google Account). I was slightly underwhelmed by the new Google Sites service. It has taken how long to make a basic and acceptable wiki service available?

Still you can have a lot of separate wiki sites and you have a lot of flexibility on how you share and collaborate on them so maybe I need to build up some content first and then try to share it around. I would like to know whether you can hook Analytics up to some Sites content. That would be useful for some of the content that otherwise would go on something like a WordPress page.