My Nabaztag bunny

The bunny ears experience of ambient awareness inspired my first (and, so far, only) Arduino project: Monitoring electricity using Christmas lights. The red/orange lights indicated the current electricity usage of my house and the blue/green lights indicated the current electricity usage of Mum and Dad’s house. The more electricity currently being used, the faster the lights flashed. Again, it was just that tiny tiny insight into what was happening 250 miles away. Just the mundanity of everyday life shared.

So I was curious about the Kickstarter project for the Good Night Lamp. The Good Night Lamp is a really nice and simple concept. One person has a Big Lamp (shaped like a  house) and they give Little Lamps, associated with the Big Lamp, to friends and/or family anywhere in the world. When the owner switches off the Big Lamp (when they go out or go to bed), the associated Little Lamps also switch off. An appealing part of it is that you can collect a Little Lamp from each of your family or group of friends and arrange them on a shelf so that before you go to bed at night, you can see each of them ‘say goodnight’ as their respective lights go out.

Good Night Lamp

The problem I see with the Good Night Lamp is similar to the one with the Nabaztag. While I think it’s great having simple devices that do just one thing well, it doesn’t half clutter up the place. These kinds of devices need shelf-space. And it has to be shelf-space you can see easily in a place you’ll often be or they don’t work. Maybe as people replace all their books with the more easily stored ebooks, living-room bookcases will become filled with ambient devices instead. I got to chatting with Ambient Orb fan Andy Stanford-Clark about it.

While my and my Mum’s’ Nabaztags have now died or gone into hibernation and the Christmas lights never made it as far as the tree, our more lasting providers of ambient awareness don’t even have their own physical forms. Instead, they’re software on our smartphones and tablets, devices that we have around anyway, wherever we are. In particular, SMS updates of my Mum and Dad’s Tweets.

Every morning, my Mum wakes up, has a coffee with my Dad, and reads interesting articles on her iPad. I know this from when I’ve visited them and because when she reads an interesting article, she tweets or retweets it and I receive about half-a-dozen txts in quick succession. Later in the afternoon, after they’ve got home from wherever they’ve been that day (or have found free wifi somewhere while they’re out) and are drinking another cup of coffee or tea, I receive another half-a-dozen txts pointing to interesting articles online. Just receiving the txts gives me an awareness of them waking up or sitting down to read the paper. Clicking the links to the articles gives me an insight into what they’re reading and how they’re probably feeling about the topics of the articles. The fairly mundane, everyday things that we wouldn’t remember, or bother, to talk about on the phone a week or so later.

As drinking coffee or tea seems to play a regular, if side, part in the activities I’m notified about, Andy and I came up with the idea of the Ambient Kettle. In my house, we have a whole house Current Cost monitor that is connected to a server out on the Internet. It was the feed from this server that we used in my Christmas Lights project. Since then, though, I’ve added individual appliance monitors (IAMs) to a few of the appliances around the house, including the kettle. The feeds from these IAMs also go to the server and so can be used by applications that know which data to request.

So Andy hacked up a (private) Twitter account, @ambientkettle, which my Mum follows. Each time the kettle boils in my house, the @ambientkettle account tweets to my Mum:

@ambientkettle tweets

Without being physically present or explicitly letting her know that I am making a cup of tea, she can get a sense of what I’m doing. The messages in the tweets that @ambientkettle sends are pre-canned and chosen at random but made to be chatty enough that it seems a bit like the start of a conversation. Indeed, Mum sometimes tweets back to it to say that she and Dad are also having a cup of tea or are looking forward to one when they get home, or whatever. As I say, it’s mundane but it’s those kinds of mundane things that make everyday life.

I’ll be interested to see how the Good Night Lamp gets taken up. It was featured in the very mainstream Daily Mail yesterday and its founding team has a good record of startups, product design, interaction design, and Internet of Things creativeness. And there’s something very appealing about having ambient awareness of friends and family when we’re geographically spread apart.

The theme of the conference was “scaling craft”, a pretty ambiguous theme which over the next two days was nicely pinned down by the wide variety of speakers. This theme was roughly translated into answering the question: “how do we maintain quality when scaling up to mass production?”.

Some of the speakers invited included, most importantly, Phil Gilbert of Design@IBM fame, who discussed how he is trying to bring a culture of design into the company, and to name a few more: Rafe Colburn from Etsy, Chris Aniszczyk from Twitter, Shanley Kane from Basho, Steven Citron-Pousty from Redhat and Ted Nyman from Github.

The conference was more than just good speakers. Fantastic food (specifically Japanese and Vietnamese) was provided on both days for lunch, along with some craft beers; coffee was available all day from an artisan coffee company, and the evening entertainment was hosted at London Fields Brewery where we were given a five course meal cooked by a top London based street kitchen. Quality was a theme in every aspect of the conference that mattered, whereas the hall where most of the talks were given was quite plain and basic, but all attention was on the speakers.

The first question that was addressed by the speakers was that of “What is craft?”. Rafe Colburn did a great job of opening the conference by discussing the common misconceptions associated with “hand crafted treasures compared to mass produced crap”. Not everything that is made at home is high quality, and not everything that is massed produced is is low quality. There are benefits to both – craft maximises the skill and creativity of the individual artisan and mass production optimizes predictability and repeatability.

Other speakers approached this topic too: Chris Thorpe has set up a company called The Flexiscale Company where he uses 3D-scanning technology to scan rare train engines so they can be forever preserved in their current state. Using these scans he is then able to 3D-print accurate models of the trains to any scale a model train enthusiast would desire. I personally have never seen the attraction to model trains, but his talk was one of the highlights of the conference as it honestly and unintentionally captured something really special about craft – the unashamed enthusiasm and passion for what you do. This same enthusiasm was displayed in the talk given by Diane Mueller (ActiveState) about a personal project to geotag Totem Poles in the Pacific Northwest (at the end of her talk she invited anyone interested to join her in tagging the totem pole in Virginia Waters). Manufacturers were given a good slogan for this mentality by Chris: “Make things people want, rather than make people want things”.

So how does a software company maintain this sense of passion, and craftsmanship, when it is scaled up to a company the size of IBM? Phil Gilbert’s talk was centred around design, but he touched on this idea when he asserted that developers can lose sight of the value, and ultimately the end result, when they only work on a small part of a huge product (and as part of a small team within Message Broker development I sympathise). His solution was something known as “Commander’s Intent”, the idea that in battle all soldiers are briefed on the overall goal of the mission before they are in the chaos of the battlefield. When they then enter the battlefield no further orders are given; it is the responsibility of the commander to ensure that everyone has understood their goal and how to reach it so they are able to make informed decisions themselves rather than have minute details dictated at every move.

To apply this to software development Phil suggests appointing someone to own the decision making process, and a trusted community of people reviewing (but not dictating) outcomes. But most of all, ensure that your staff prepare for (great) outcomes and understand the value of what they are working on. Cyndi Mitchell from ThoughtWorks expanded on this, adding an analogy from her experiences growing up on a hog farm (where the product is the hogs and the developers are the farmers), in particular she stated that “everyone in the system has to understand quality”.

In the most extreme example of this, Ted Nyman from Github discussed how their organisation has no managers. In response to this every employee must have a sense of ownership, and if this is effective everything the employee needs to get done will get done.

Although the conference was a technical one, it became clear that software development was only the medium in which people were discussing their ideas. Instead the conference was really about culture, and on this topic there was a lot of food for thought. In Heroku, a platform as a service company, the number of deploys a day are in the high hundreds. “Move fast and break [stuff]” was the (family friendly version of the) mantra for their organisation, and this was only possible if developers’ time became sacred. They introduced the headphone rule: headphones on means ‘do not disturb’, and the fantastic piece of advice “work in caves, dwell in commons”. This demonstrates the flip side to protecting developers time: when you’re not working, communicate! Coffee breaks become an important part of the working life (hence the title of their presentation “Coffee as collaboration”) as this is when ideas can be shared and discussed. Taking time to document your work to get the recognition you deserve and killing off projects that aren’t working can only happen if communication is just as important as the development.

This protection of the developer was also discussed by Rafe Colburn, whose advice for companies looking to scale was to automate everything that could be automated, leaving time for developers to work on their beloved craft. Phil Gilbert suggests using release hills with clear goals (three maximum) so that people can reclaim their craft, but also building in regular iterations of design and innovation to keep the craft fresh.

On the topic of iterations, Government Digital Services (GDS) discussed how in the space of two years they scaled their team from a handful of people to 200 employees. They attributed their success to constant iterations of processes, tools and people, avoiding the dreaded “single point of failure”. Understanding how to effectively do this comes down to understanding your “ecosystem” (a term commonly misused), as explained by Steven Citron-Pousty. He used his background in ecology to encourage people to think about nature’s ecosystems in comparison to those in their organisation, in particular identify the keystone developers as well as the day-to-day developers, and understand the sometimes unexpected relationships between them and their colleagues.

Another point of discussion (initially introduced by Mazz Mosely from GDS) was the issue of “rock star” developers. These can be the aforementioned “single point of failures”, but more importantly they are those mysterious developers that the entire success of the product is pinned onto. Other than not being what they may be hyped up to be, rock stars can also be disruptive to teams – feeling that only their opinions count and not using the shared knowledge of their colleagues. A better approach is to cultivate an environment where everyone is respectful and understands that the “users” of your product are not just the end-users, but also your colleagues.

In summary (some takeaway coffee if you will), culture is one of the most important aspects of a company. Culture, as asserted by Shanley Kane and Ted Nyman, is not the furniture in your office or the perks your company offers, but it is what eventually picks between two good ideas. With this in mind, it becomes increasingly important that the whole organisation has the same mentality behind their work. As software engineers we like to think of ourselves as craftspeople, and can easily become frustrated if our work becomes mindless, so how can we avoid this happening? Here are some top tips to avoid this kind of disappointment:

• Teams should be honest about what they can achieve in an iteration, at the risk of losing faith in the product and only completing the easy tasks just to tick them off a list,
• expect, encourage and respect feedback from your colleagues
• and understand the quality and value of what they are working on.

Monkigras goody bag

The work of William Morris, my GCSE history teacher said, was a bit of a moral dilemma. Morris was a British designer born during the Industrial Revolution. British (and then world) industry was moving rapidly towards mass production by replacing traditional, cottage-industry production processes with the more efficient, and therefore profitable, machines. One thing that suffered under this move to mass production was the focus on function and quantity over decoration and quality. Morris reacted against this by designing and producing decorations like wallpaper and textiles using the traditional craft techniques of skilled craftspeople. My history teacher’s point was that although Morris, a passionate socialist, was able to create high quality goods by using smaller-scale production methods, only wealthy people could afford to buy his designs; which was hardly equality in action. On the other hand, the skills of craftspeople were being retained, quality goods were being produced, and the craftspeople were getting paid for that quality of their work.

My pretty, handcrafted latte

Monkigras 2013, in London last week, took on this theme of ‘scaling craft’ in the context of beer, coffee, and software. All parts of this trinity of software development can benefit hugely from a focus on quality over quantity. Before I went to Monkigras, I wasn’t really sure what to expect from a tech event advertised as having a lot of beer. It did have a lot of beer (and coffee) available but if you didn’t want it you could avoid it (several people I talked to said they didn’t usually drink beer). And no one seemed to get ridiculously drunk. And there were a lot of very cool talks.

The beer was also a fun analogy to apply to software development. Despite pubs in the UK closing hand over fist at the moment, microbreweries are on the rise. Microbrewing is about producing beer in small quantities on a commercial basis so that quality can be maintained whilst still viable as a business. One of the things we learnt from a brewer at Monkigras is that the taste of water varies according to where it comes from. Water is a major component of beer so if the taste of your water supply changes, the taste of your beer changes. To maintain the quality of the beer you brew, you must work within the natural resources available to you and not over-expand. Similarly, quality comes from skilled and knowledgeable people who need to be paid for their skill. If you take on cheaper staff and train them less so that you can make more profit, you will end up with a poorer quality product. You get the idea.

Handcrafting a wooden spoon.

This principle applies to all areas of craft, whether it’s producing quality coffee, a quality wooden spoon, quality conference food, or organising a quality conference, you have to focus on quality and ensure that if you scale what you do so that it’s more readily available to more people, you don’t sacrifice quality at the same time. And, importantly, that you know when to stop. Bigger doesn’t necessarily mean better.

Software is misleadingly easy to produce. Unlike making physical objects, there is very little initial cost to producing software; you can make copies and then distribute them to customers over the Internet at very little cost. Initially, at least, it’s all in the skill of the craftspeople and their ability to identify their target users and market. If they can’t make what people will buy, they will go out of business very quickly. As software development companies get larger, the people who make the software inside the company become further removed from the selling of their software to their customers. So they become more focused on what they are close to, the technology but not who will use it.

Phil Gilbert on IBM Design Thinking

Phil Gilbert, IBM’s new General Manager of Design, comes from a 30-year career in startups, most recently Lombardi, where design was core to their culture. IBM has a portfolio of 3000 software products so, when Lombardi was acquired by IBM, Phil set about simplifying the IBM Business Process Management portfolio of products, reducing 21 different products to just four and kicking off a cultural change to bring design and thinking about users to the centre of product development. Whilst praising IBM’s history of design and a recent server product design award, he also acknowledged at Monkigras: “We are rethinking everything at IBM. Our portfolio is a mess today and we need to get better”. Changing a culture like IBM’s isn’t easy but I’ve seen and experienced a big difference already. Phil’s challenge is to scale the high-quality user-focused design values of a startup to a century-old global corporation.

One of the things that struck me most at Monkigras, and appealed to me most as a social scientist, was the focus on the human side. Despite it being a developer conference, I remember seeing only one slide that contained code. The overriding theme was about people and culture, not technology; how to maintain quality by maintaining a culture that respects its craftspeople and how to retain both even if the organisation gets bigger, even if that naturally limits how much the organisation can grow. Personal analogy was also a big thing…

Laser-scanned model of the engine

Cyndi Mitchell from Logspace talked about her family’s hog farm and working within the available resources. Shanley Kane from Basho used Dante’s spheres to describe best product management practices. Steve Citron-Pousty from RedHat use his background as an ecologist to manage communities and ‘developer ecosystems’ (don’t just call it an ecosystem; treat it like one). Diane Mueller from ActiveState talked about her 20%-time project to build a crowdsourced database of totem poles and the challenges of understanding what gets people to want to contribute to such projects. Elco Jacobs talked about his BrewPi project: automatically managing the temperature of his homebrewing fridge using a RaspberryPi based controller, and how he has open-sourced to build a community to kick start it as a potential small business. Rafe Colburn from Etsy more directly makes the link between craft and software engineering in his slides.

3D printer making a spoon

I don’t know much about William Morris so I don’t know which presentations he would have enjoyed or disagreed with. Morris was a preservationist and started the Society for the Protection of Ancient Buildings to ensure that old buildings get repaired and not restored to an arbitrary point in the past. So maybe he would have found laser-scanning and 3D printing interesting. Chris Thorpe is a model train geek and likes to hand-make his own models of real-life objects. He too is interested in alternatives to mass manufacturing and has started to look at how to make model kits. He uses a laser to scan the objects and a 3D printer to prototype the models. He can then send the model to a commercial company who can make it into kits for him to sell. He has recently used his laser-scanning technique to scan a rediscovered old Welsh railway engine to preserve it, virtually at least, in the state in which it was found.

I had a great time with lots of cool and fun people. Well done to @monkchips for scaling a conference to just the right level of intimacy and buzz. The last thing I saw before I left was the craftsman making a wooden spoon pitted in competition against the 3D printer making a plastic spoon.

You can find many of the slide presentations and more about the conference Lanyrd.

The reason I wanted to try and get MQTT on the Joggler was to make use of its light sensor, and publish light levels over MQTT. It all turned out to be pretty simple since most of the work has already been done by other people!

• Andrew de Quincey has code to read the Joggler’s light sensor
• Andy Piper has a handy quick start guide for Paho
• The MQTT C client documentation has simple publish examples

First thing to do was read the light sensor and get that working with an MQTT client. I had to skip some of Andy’s instructions and just built the client code rather than attempting to get doxygen working. Once I’d mashed up the light sensor code and publish example I could compile the worlds most pointless MQTT publisher:

gcc -Wall publightsensor.c -L../bin/linux_ia32 -I../src -lmqttv3c -lpthread -o publightsensor

Next it was time to check the results. This too was quick and easy thanks to the MQTT sandbox server, which has a handy HTTP bridge. And the final result… was a completely unscientific and slightly dingy light level 4! Now I’ll be able to turn on a lamp using an unreliable RF controlled socket and see whether it worked or not!

Update: the code really is all in the existing examples but I’ve created a Github Gist in case it’s any help: mqttjogglermashup.c (11 February 2013)

A highlight of the afternoon was Stephen Hawking – perhaps one of the best examples of the power of technology to enable someone to reach their potential. He also supported the event by lending his voice to a promotional video which explains the idea better than I can.

“Who is Technology Made For?” (YouTube)

There were several speakers. I won’t do them justice, but I did jot a few notes…

Panel discussion with Rupert Goodwins (ZDNet UK) & Damon Rose (BBC)

They talked of the stigma of using “special” equipment created especially for the blind. There were examples where even when technology or tools exist that can help, people don’t always want to use them. Maybe because they feel embarrassed, or they don’t want to be different, or even that they’re struggling with feeling forced to join a group of people they don’t feel a part of.

They discussed how it was more acceptable to use technologies when they are “standard” and how some felt more comfortable using technology that doesn’t single them out as being different.

Someone noted how people can be embarrassed wearing a hearing aid to help them hear, whilst few people would be embarrassed to wear glasses to help them see. Why are some assistive technologies more culturally acceptable than others?

There was a lot of mention of iDevices and appreciation of assistive technology being delivered as iPhone apps. To everyone else, it’s an iPhone and doesn’t stand out as being different. In addition, the fact that it’s mass-manufactured has meant that an expensive collection of advanced sensors and processing capability can be made affordable. An equivalent device produced purely as an assistive technology would be prohibitively expensive. The iPhone sparked a smartphone revolution that made this technology affordable in a way that it wasn’t before.

There was also discussion about how the app culture removed barriers between potential users and developers. Affordable sensors and technology made widely available, combined with a low-cost delivery mechanism for software innovations, make possible innovations in assistive technology that would have been impossible a few years ago.

Presentation on accessible architecture by Paul Kalkhoven

This looked at parallels between buildings and software. Disability became accepted as important in architecture and you can’t build a new building without considering accessibility. This isn’t yet true of technology.

He talked of the conflicting interests of design and utility. When designing a building, you want it to be unique and different. However, you want it to be obvious. If you want to find a toilet or fire exit, you want to understand the layout immediately. The same applies to technology: we want to make something new and exciting. But there is an expectation that it should be usable without a manual. It needs to be accessible.

One observation I hadn’t really recognised: transport buildings lead the way for accessible architecture, often abiding by a common, albeit unwritten, set of standards.

He challenged us to consider what technologists could learn from their experience.

Presentation on talking TVs by Mark Vasey (Panasonic)

Voice guidance is included as standard in most new Panasonic TVs, offering text-to-speech guidance for complex TV menus.

Perhaps more interesting was how they made it happen. He talked about challenges such as the cost of development, licensing and royalties for a feature they include “for free”. There were challenges in marketing to a minority, without wanting to classify it as a specialist product, and without making sighted users think that they were paying for a feature they didn’t need or want.

Similar to the discussion of the iPhone’s impact, he explained how the only way they could do this and make it affordable was to make it standard. Making a specialist TV with accessibility features for the visually impaired would not have been affordable. Spreading the cost across their entire product line is what made it possible.

“Introduction to Voice Guidance on Panasonic talking TVs” (YouTube)

Presentation on Threedom Phone – Antony Ribot (Ribot)

Antony gave a thought-provoking presentation about their project to make the world’s simplest smartphone.

The smartphone revolution has been great for many, but isn’t suitable for everyone. For some, the controls are too small, or too fiddly, or just too complicated. What if we made a smartphone that had only three buttons? Could we provide the essential functions that people need on a device with three large, easy to press, easy to understand, buttons?

He had an example with him and made a convincing case that there is a need for a device like this, in a market where devices are racing to get more complicated.

Everybody Technology : rlsb.org.uk/everybody

A year ago, I wrote about RLSB’s event which brought together a handful of representatives from tech companies, consumer-facing businesses, Universities, and charities for the blind. We talked about a vision of a Conversational Internet.

A year later, and RLSB got together a couple of hundred people to talk about projects that had happened – both by them, such as the Conversational Internet prototype that I presented, and by others such as Panasonic’s collaboration with RNIB to produce Voice Guidance.

They talked about what comes next, establishing a new group to bring together technologists and designers with people who understand disabilities, to make real their vision where everyone is taken into consideration.

If you think this is something you can help with, either as a developer, designer, or someone who understands a disability, then why not join them.

This week I had a day out of the office to go to Zurich to talk at this years IBM developerWorks Days. I had 2 sessions back to back in the mobile stream, the first an introduction to Android Development and the second on MQTT.

The slots were only 35mins long (well 45mins, but we had to leave 5 mins on each end to let people move round) so there was a limit to how much detail I could go into. With this in mind I decided the best way to give people a introduction to Android Development in that amount of time was to quickly walk through writing reasonably simple application. The application had to be at least somewhat practical, but also very simple so after a little bit of thinking about I settled on an app to download the latest image from the web comic XKCD. There are a number apps on Google Play that already do this (and a lot better) but it does show a little Activity GUI design. I got through about 95% of the app live on stage and only had to copy & paste the details for the onPostExecute method to clear the progress dialog and update the image in the last minute to get it to the point I could run it in the emulator.

Here are the slides for this session

And here is the Eclipse project for the Application I created live on stage:
http://www.hardill.me.uk/XKCD-demo-android-app.zip

The MQTT pitch was a little easier to set up, there is loads of great content on MQTT.org to use as a source and of course I remembered to include the section on the MQTT enabled mouse traps and twittering ferries from Andy Stanford-Clark.

Here are the slides for the MQTT session:

For the Demo I used the Javascript d3 topic tree viewer I blogged about last week and my Raspberry Pi running a Mosquitto broker and a little script to publish the core temperature, load and uptime values. The broker was also bridged to my home broker to show the feed from my weather centre and some other sensors.

by Stewart Addison (photo by Steve Haskey, who arranged the visit)

An introduction for those not familiar with the Pi …

Yesterday Eben Upton (the guy behind the Raspberry Pi foundation) took time out of his very busy schedule to give a talk in Hursley. For those who are not familiar with it, the Raspberry Pi (here is the FAQ) is basically a small credit-card sized computer circuit board with a Broadcom BCM2835 chipset and a 700MHz ARM CPU powered via a microUSB socket, HDMI+composite video output, stereo audio output, ethernet port, 2 USB ports, an SD slot used for booting the device, and another proprietary expansion port, and a high performance graphics subsystem that can decode video at full HD resolution with h.264 (MPEG-2 available at extra cost) hardware playback support in XBMC/OpenElec – all for $35 for the “model B” version. They were initially built in China, but much of the manufacturing is now in the UK and is therefore supporting the UK economy! Keyboard/mouse/power/screen/SD card are not included in that price, but many people will have suitable ones lying around to connect to it, which certainly suited me as the last thing I need is more of them cluttering the place up.

As someone who was interested in the project from some time prior to the launch it was great to see Eben in person, particularly as I’m someone who owned a BBC Micro and lost many hours to Elite (co-written by David Braben, who is also involved in the project). If that though is making any of you feel nostalgic, why not try the ZX Spectrum port of Elite running in a java applet!) The Pi as a project is trying to bring back a bit of that sense of “playing” that the BBC Micro probably did better than any other machine of its time.

(Quick disclaimer: This article is a mix of things that Eben spoke about from the notes I took, plus a few extra pieces of background information and external links that I have added myself)

The detailed background to the original idea was something I had not heard in detail before. A director of studies at St.John’s college in Cambridge, he was concerned by the declining numbers of applicants for computing university positions, as well as a drop in the quality of those applicants (basically changing from getting many people of the type who could likely already code in assembler for two different architectures to a smaller number who’s experience predominantly “I know HTML” – people who would need more time spent educating them to get to a suitable standard to teach them further) This meant that it would take longer to get them to an adequate standard on the low level aspects of computing – or by throwing them at Standard ML programming for 6 weeks to make them depressed (I remember going through that!)

BBC Micro comparisons

I mentioned the BBC Micro in the opening paragraphs – earlier this year there was a “Beeb@30” event to celebrate 30 years of that machine, and here is a BBC article looking back on it. It hass been well documented that they did try to get the BBC branding on the device, but the “unique way the BBC is funded” means that it was nowhere near as easy for the BBC to support such a commercially available device as happened in the 1980s. Having said that, the ARM-designed processor used in the Pi (and probably, your mobile/cell phone) had is roots in Acorn (here is a brief history of ARM) who built the BBC Micro. And there is a – possibly somewhat indulgent – project to port RISCOS (the OS designed for the BBC Micro’s successor – the Archimedes) to the Pi.

The other thing of note on the Pi is the GPIO port. Now one of the things that made the BBC Micro special was the inclusion of easy I/O on the device, through the “user port” and “parallel port”. In fact even the “joystick” port was marked as an “analogue in” to plant the suggestion it’s use could extend far beyond games. This allowed a good quality of control of external devices and responding to inputs, something that allows many more interesting control projects to be done with it. At school I did a prototype satellite tracking system using it! But I digress, the GPIO port on the Pi even looks superficially very similar to the user port on the BBC Micro. The most popular interface using it so far is the Gertboard. (I wish a could remember the name of the blue boards we used on the BBC Micro – anyone know?)

A squashed marketplace

Another good point raised by Eben was about where the previous marketplace for the BBC Micro and comparable machine has now in modern times. With the home computers of the 80s you powered them on and you got a command prompt for a programming language interpreter that almost begged you to start programming straight away – almost as though, as Eben said, you had to actively choose not to program! It was easy for anyone to go into their local computer store and make them display scrolling rude messages up the screen, and anyone owning one of those computers would have almost certainly had the knowledge to do so!

Nowadays it is less easy. Games consoles have taken over the high performance graphics market, with high barriers to development entry. It a similar story for the consumer tablets on the market at present – from a practical perspective the development needs to be done in another environment rather than on the device itself. Even most consumer PCs do not ship with any reasonable programming language out of the box. While that is less of an issue in the high download speed internet of today, during the 90s it took real will and effort to be able to program. The concept of having to choose not to program got completely lost. And that is some of the spirit that the Raspberry Pi is now trying to recreate. It does appear to be a bit of a gap in the market, even ignoring the Cambridge admission quality problem. There are real low-level boards around, but not so much of an all-in-one device like the Pi. And one interesting thought was that the aforementioned relatively simple bloat-free non-content-enriched RISCOS with the ease of switching to a traditional command line from the desktop, could rekindle some of the mentality from the 80s home computers.

Interest and getting to market

The amount of early interest in the Pi took the foundation by surprise – 600,000 views on Rory Cellan-Jones (BBC Tech correspondent) brief video with Braben – could that really be an indication of how big the market was for such a device? And could they deliver that many at the target price point, which was pretty much set at $25 from the start (At the time of writing only the $35 model B mentioned in the first paragraph – which includes a 100Mbit ethernet port, 2 USB ports instead of one and the 512Mb upgrade recently announced – is shipping). But the foundation has kept to the target price point for the units, and the 512Mb upgrade for the model B has not resulted in a price change. The other remarkable thing was the number of downloads – in the tens of thousands – of the SD-card operating system image for the Pi that was released some time before the device was even on sale, so no-one could use it!

The vendor partnerships with Farnell/Element14 and RS were important as it allowed them to move from being a risk-averse charity to more of an IP licensing company to get the number of units they were going to need. And it was a good decision. The first day on sale, as those like me who were up at 6am to order will be aware, was a bit of a disaster (and I blogged to vent my frustration at the time, questioning the motives of many of those buying and how it was pitched by some parts of the media). 100,000 orders were placed by the lucky people who even managed to get to the manufacturing partners (Farnell/Element14 and RS) websites. Both crashed badly under the load, preventing people from buying their resistors or other electronics from those suppliers, not just Pis! A lesson in robust scalable web sites for those two companies.

Another interesting point for those who have been interested in the Pi is that although most of them used in relatively rich countries such as the UK and will therefore make use of the on-board HDMI output (HDMI-DVI-D adapters can be had for under £2 on ebay if needed – make sure you get male/female as required for your setup!), the Pi also has a composite analogue video output. For me, this is convenient as it allows me to attach it to my in-car screen, but as Eben pointed out it also allows it to be sold in much poorer/emerging countries in the world, where second hand analogue TVs are still in use, and the Pi can give them a new lease of life for a price point far less than, for example, a tablet.

So it was good to have the talk from Eben, and I chatted to him about some other things afterwards. Fantastic to get his time, and of course this blog has been written in a browser running on one of my Pis

Friday was IBM’s internal Social Business Hackday. There was some MQTT hacking, a z/OS hack, hacks with Lotus Connections, hacks that could be the future of Lotus Connections, and I was attempting to hack a work around for a Jazz work item. And that was just at the Hursley local event! We were able to link up with a few other labs, but over two days there were IBMers hacking around the globe. There are going to be a lot of amazing projects to choose from when it comes to voting.

(There are a few more photos from HackDay X, and previous hackdays, on the IBM hackday group on flickr.)

For round two, today was the soutHACKton hack day. By the time I arrived the soldering and drilling had already begun!! Unfortunately I wasn’t able to stay long so I’m hoping there’ll me more of these in the future. I did just about have time to try out an idea I had to hack an old doorbell to sense people using the door knocker. A while ago I had accidentally created a touch sensor with a 555 timer while attempting to build another circuit. So my cunning plan was to deliberately create a 555 touch switch and connect it to the bolt on the inside of the front door. Unfortunately the best I could manage today was a two wire touch sensor, which isn’t going to work. At least not without leaving a wire hanging out of the letter box with some instructions attached! Unless someone who knows more about electronics can suggest a plan B, I may just resort to a boring doorbell button instead!!

tl;dr

We’ve built a prototype to show how we could interact with the Internet using a command-driven approach.

• A screen reader, but one that uses machine learning and natural language processing, in order to better understand both what the user wants to do, and what the web page says.
• One that can offer a conversational interface instead of just reading out everything on the page.

It’s a proof-of-concept, but it’s an exciting idea with a lot of potential and we’ve got a demo that shows it in action.

The problem : screen readers today

I’ve written about this before but here is a recap.

Visually impaired people can interact with the web using screen readers. These read out every element on a page.

The user has to make a mental model of the structure of the page as it’s read out, and keep this in their head as they arrow-key around the page.

For example, on a news site’s front page, once the screen reader has read out the page, you have to remember if the story you want is the fifth or sixth story in the list so you can tab the right number of times to get to it.

Imagine an automated telephone menu:
“for blah-blah-blah, press 1, for blather-blather-blather, press 2, for something-or-other, press 3 … for something-else-vague, press 9 …”

Imagine this menu was so long it took 15 minutes or more to read.

Imagine none of the options are an exact match for what you want. But by the time you get to the end, you can’t remember whether the closest match was the third or fourth, or fiftieth option.

The vision : a Conversational Internet

Software could be smarter.

If it understood more about the web page, it could describe it at a higher, task-oriented level. It could read out the relevant bits, instead of everything.

If it understood more about what the user wants to do, the user could just say that, instead of working out the manual navigation steps themselves.

The vision is software that can interpret web pages and offer a conversational interface to web browsing.

Making the vision a reality

This idea came from a meeting that I wrote about last year with the RLSB : a charity for the blind.

I was convinced that we could do something amazing here. Earlier this year, I proposed it as an Extreme Blue project. It was accepted, and this summer I’ve mentored a group of interns who did amazing work on turning the vision into a prototype.

I want to talk about Extreme Blue, but I’ll save that for another post.

The prototype : what it does

We’ve developed a prototype that shows what the Conversational Internet could be like.

It is a proof-of-concept that can interpret many websites. In response to commands, it can navigate around them, and identify areas of the page, and the types of text and media. It can use this to provide a speech response with the information that the user wanted.

Commands can be typed, or provided as speech input.

a video of some of the capabilities of the prototype

The prototype : what it is

Our prototype is built using a UIMA architecture. It is made up of pipelines of discrete annotators, each using a different strategy to try and identify meaning behind areas of the web page the user is viewing.

Some of these strategies include using natural language processing (using IBM’s LanguageWare) to interpret meaning behind text.

Some use machine learning (using IBM’s SPSS Modeler) to learn from patterns in trends in the way web pages are structured and organised.

Architecture : the idea

There are two main tasks here.

1. Interpreting the web page that the user has just visited.
2. Responding to commands about the page

Firstly: Understanding the web page

When the user visits a webpage, the system needs to try and interpret it.

The contents of the web page – both the text contents, and the DOM structure of the HTML markup, including any semantic tags used – go through a UIMA analysis engine. It goes through a pipeline made up of several annotators, each of which is looking for something different in the page.

By itself, no one of these strategies are fool-proof. But they’re not stand-alone applications. As elements in a pipeline, contributing a strategy to a collection of results, they’re each useful indicators. Each of the annotators in each stage of analysis contributes it’s own metadata, building up our picture of what the page contains.

Secondly: Responding to commands

Once analysed, the system is ready to react to commands about the web page.

The prototype : status

This is not a finished, fully-implemented product. It’s an early work-in-progress. It’s not yet truly general purpose, and many of the key components are hard-coded or stubbed out.

However, there are real example implementations of each of the concepts and ideas in the vision, showing that the basic idea has potential and that these technologies are a good fit for this challenge. And the UIMA pipelines are real and coordinating the work, demonstrating that the architecture is sound.