Hummingbird: "Pre-Arduino" for Kids (or, I'm hoping, for adults who find Arduino still quite daunting)
Hummingbird: "Pre-Arduino" for Kids (or, I'm hoping, for adults who find Arduino still quite daunting)
I was greatly moved yesterday after listening to the This American Life episode on conditions at Foxconn, the plant in China than makes (among other things) iPhones, iPads, and most other Apple products. I just made a post on Facebook relating to this and a related Forbes article and I encourage you to chime in there or here. Is this just “business as usual,” or is there something wrong happening here that needs to be fixed?
Today, I start my new job as Head of Product Management for BlueVia, a unit of the newly forming Telefónica Digital. Why, after 10 years at Vodafone, have I chosen to pull up stakes and move to BlueVia? The answer is simple: BlueVia are actually doing something that I’ve been talking about doing since 2006 and even earlier – they are taking operator network capabilities and exposing them (via APIs) to Web and app developers. And they are bringing these APIs to real grass-roots developers. Read what I wrote in 2006 about exposing enablers. Most of the other predictions in that post have been borne out (mobile Web, connected apps, social media, etc…) but mobile operators have so far not been able to expose the capabilities of their networks to developers in a simple, straight-forward way (a-la market-leading Amazon Web Services).
Well – BlueVia are actually doing that: taking the capabilities of the network and making them available to developers through an accessible developer program. If you combine that capability with the emerging idea that applications will exist in the cloud and be accessed by users through a range of connected devices, the important role such a provider can play becomes clear.
I don’t want to give the wrong impression here. Vodafone is a great company and working there has been a fantastic experience. I’ve worked with some great people on some amazing projects. I’m immensely proud of the work I’ve done there. The work I’ve been engaged in at Vodafone has often focused on bringing the Web to the mobile – the w3c Mobile Web Initiative and dotMobi were early examples: making it easier for Web developers to engage with users across a range of mobile devices.
But now it’s time to move on to a different set of challenges – to look at things from a different angle: how can we bring the mobile to the Web? How can we make mobile networks more transparent and more useful for Web and app developers – to enable new kinds of experiences that are uniquely mobile.
People have asked me a lot of questions about the move so I though a short FAQ might be in order:
What about your W3C activities? I’m not going to be playing an active role in W3C in my new role. However, Web standards and advocacy thereof are are part of my DNA. Telefónica are a W3C member and I will continue to play a role from the sidelines.
What about your role on the W3C TAG? Will you run again? As I’ve told the W3C community already, I’m not going to be putting myself forward for another term on the TAG. However, with agreement of all parties, I will be serving out my current term until the end of January.
Are you moving to Madrid? No. I’m staying in London. The role is based in London at Telefónica Digital’s offices (once they find suitable offices). In the mean time, I’m going to be working out of places like TechHub and Adam Street where I will be more than happy to chat in person about what’s happening with BlueVia.
What’s going to happen to Over the Air and Mobile 2.0? These were always side projects for me (though thankfully projects that were allowed by my employer). I’m going to continue to be involved with putting these together at my new role.
What about MobileMonday London? I had already stepped back from direct involvement in MobileMonday London at the end of last year. Since then, I’ve played an advisory role to MoMo London and I will continue to do so.
BlueVia looks like it’s about Apps – I thought you were the Mobile Web guy? BlueVia is about helping developers do cool stuff using network APIs (apologies to James Parton if I am mangling the marketing message right there but you get the idea). This includes Web and App developers. One of the things I’m going to be working on is making BlueVia more friendly for Web developers so if you have any suggestions along those lines, please send them my way.
I noticed a mistake on the BlueVia web site. Can you fix it? Er. Give me a minute to get settled in… :)
I have a suggestion about BlueVia. Interested? Absolutely.
It’s time to have a serious talk about #!.
If you’re a sharp-eyed Web user, it will not have escaped your attention that, for many Web sites (Twitter among them), the characters #! have started to appear in the address bar when visiting certain pages. Try it now. Go to my page on Twitter but check the URL I’m sending you to first – it should be “http://twitter.com/torgo”. Now – when you visit that link, check the address bar at the top of the page. Abracadabra, a mysterious #! (pronounced “hash bang” in geek-parlance, and we are firmly in geek territory here) has interposed itself between the twitter.com and the torgo bits of the URL. The appearance of #! is an artefact of a certain approach to Web application architecture. Many in the Web community have decried this approach (see more detail in Jeni Tennison’s blog entry), but to cut a long story short, the argument against using #! has been painted as largely academic by many Web application developers.
This morning, I woke up and found my (very) local paper, the Archer, had been slipped through my mail slot. Something drew my eye to a box at the bottom of the page. “The Archer is now on twitter,” it pronounces. “Follow us on http://twitter.com/#!/TheArcherN2.”
Ok, #!. Now, it’s personal.
I’m not pointing fingers at the good folks at the Archer, by the way. They just did what Twitter told them to do. In good faith, they copied and pasted the URL that appeared at the top of the page. But surely this result could not be what the people at Twitter intended. So, now everyone who sees this URL and types it in will be forced to type in three more characters than is strictly necessary. And can you imagine someone trying to tell that URL to someone else down a phone line or over the radio? It’s like “H, T, T, P, colon, slash, slash” all over again, except worse! (For one, “exclamation point” has 5 syllables.)
And by the way if the person trying to type in that URL happens to be a Mac user in the UK then they are going to be doubly confused because there is no # on the Mac UK-English keyboard layout:
From a Web architecture perspective: Jeni’s blog entry goes into great detail on the pros and cons of this approach to keeping application state. In the TAG, Ashok Malhotra is working on a document on Identifying Application State which discusses this issue in detail, discusses and some alternatives to #! and some approaches that Web site developers can employ if they want to use #! and not confuse Web users. If you’re a Web site developer, I urge you to read these.
But thinking of the bigger picture: when you build a Web site or application, you are not building it in a vacuum. Stuff you do, including what appears in the address bar, will have unintended consequences. People doing stuff like passing around URLs out-of-band is part of the Web. So think of the children already and get with the program!
(And to my good friends at the Archer: I love you, and you have done absolutely nothing wrong, but please the next time you print this blurb, print it as “http://twitter.com/TheArcherN2”. For me. OK? Thanks.)
If you’ve ever seen one of those NASA simulations of galaxies colliding, you’ll know it’s a messy business. Symmetric spirals, serenely evolving and progressing through the universe on their own, suddenly encounter each other. The result is a violent conflagration. Plumes of previously well-ordered stars go shooting off into space, only to be drawn back in and shot out again in another directions; seeming child galaxies form, only to be absorbed again in more churning cataclysms. The time-scales over which this occurs are, of course, astronomical. At human-scale time, all we can ever perceive is a moment, frozen in time.
We are in the middle of such an event right now in both the Web and mobile industries. Our galaxies are colliding; they have been colliding for a number of years; and they will continue to collide for years to come. The result will be a new landscape, a new ecosystem, a new industry. What that industry will look like is not clear, but we can guess at its shape. At this year’s mobile 2.0 conference in San Francisco, we are once again going to take a stab at doing just this.
In 2006, before our first Mobile 2.0 event, when I first sensed the colliding of these two galaxies, I wrote a post about what I thought that future might look like. I stole a page out of the book of Tim O’Reilly in trying to define Mobile 2.0, attempting to use the same approach he used for the (then newly-minted) term “Web 2.0” to get a hold of what I saw happening in the convergence between the Internet/Web and Mobile worlds. One of the key ideas in this post was that the future of mobile was both the Web and connected applications. That view of the world was driven by what I saw happening with the fledgling app ecosystem on (then primarily Nokia / Symbian) connected smartphones and the fledgling mobile Web ecosystem, especially what was going on with webkit-based mobile browsers (also pioneered by Nokia). In my 2006 view of the future, the Web and connected applications would co-exist and (importantly) the Web would be the vector whereby these applications would be discovered, downloaded and installed.
Well, I almost got it right. What I didn’t anticipate was the rise of paid app stores. The bundled app stores (which are apps themselves) has created a gravity around downloadable, installable apps. So – while it has now become possible, on modern smartphones, to find and download apps from a universe of choices, that universe is actually constrained in some very important ways. What you can discover is constrained. How you can pay is constrained. And importantly for the developer, the tools they can use, types of applications they can build, and ways they can make money are, to a greater or lesser degree, constrained.
HTML5 is being touted by many as alternative approach to building apps – apps that would live in the browser in the same away that browser-based apps have started to appear on the PC Web. In some ways, this is true. Some in the mobile industry have jumped on HTML5 as a panacea, finally delivering “write once, run anywhere” apps. It also is being seen as a way around the vertically controlled app ecosystem promoted and maintained by the platform providers.
HTML5 is not primarily about mobile. It is about the evolution of the Web. It is about the consolidation of the Web platform. The Web has been on an evolution path since the first browsers, roughly speaking from a Web of documents to a Web of applications; from the Web as a document sharing system to the web as an application development and deployment platform. HTML5, and the related APIs, protocols and formats that are often lumped together with it, is simply the latest sign-post on that evolutionary path. The Web has had a profound impact, not only on commerce and industry but on humanity, on the way we now expect to consume information, interact and communicate with others. The Web by its nature is open. It is built primarily on royalty-free standards, it is closely (though not exclusively) tied to open source projects and software, it is diffuse and does not allow for a single point of control. This open Web platform of technologies includes new features that start to bring the Web on a par with native approaches to application development – specifically, off-line use (launching and using a Web application even when not connected to the network), access to device features (geolocation now with more APIs quickly following behind) and fluid UI (smooth animations, touch events, 2d graphics and other technologies needed to provide compelling user experiences). Building Web applications with HTML5 is still software engineering and it is still hard work, but it may make it possible to leverage the abilities of an engineering team already skilled up in the ways of the Web to build (and more importantly revise and maintain) mobile services more easily and at lower cost than maintaing separate teams (or outsourced teams) to build apps on different architectures.
What’s more, the same parties, the same companies, in many cases the same people who promote the “closed” app ecosystems are also pouring resource and money into this open Web ecosystem, a parallel ecosystem. This can make companies like Google and Apple seem schizophrenic at times. But look at the bigger picture. The apps world looms large in mobile, partially because it is the fulfilment of an idea that many people evangelized for many years, but which stubbornly refused to come true. Yes – finally people are using the mobiles for something else other then voice and text. And this use has become mainstream. That’s one way to look at it. But look at it from the Web industry point of view. The developer of a service or application on the Web wants reach – reach to as many platforms as possible for as cheaply as possible. They see mobile as a channel to customers and to more usage of their application. Mobile is only one piece of the puzzle to them – and mobile apps and app stores are only one channel to market.
So what does HTML5 really mean for mobile? If we are to glimpse an answer to that question then we have to move beyond the “web vs. apps” mentality. Application developers need to consider the Web platform along side of the various “native” application development platforms out there as one approach, one potential set of tools, one possible way to reach users, with its unique set of plusses and minuses.
In the end, it is clear that HTML5 will play an important part in this cosmic collision between Web and mobile of which we currently find ourselves a part. The lasting legacy of HTML5 in mobile, however, may be the linking of the evolution of the Web to the evolution of mobile apps. And while the Web may be evolving to be a better platform for mobile apps, and this is a positive step for the Web and for mobile, the more exciting development will be how the Web disrupts app stores by providing a compelling alternative to app stores for service and application discovery.
At Mobile 2.0 this year, I’m glad to say we’ll be exploring some of these issues with a galaxy of stars – people who have been working at the sharp end of the convergence between the mobile and Web and at the sharp end of disruptive innovation in mobile. At one of our afternoon workshops (“Mobile Web Present and Future”) we will be delving deep into the issues of the impact of HTML5 on mobile. We’ll be looking at current best practices for building great mobile applications using HTML5 and related technologies (with James Pearce from Sencha and Mat Womer from W3C – the standards body responsible for HTML5). Then we’ll switch to thinking about the (mobile) Web platform of the future. What’s missing from from the Web platform from a mobile perspective? Scott Jenson, who wrote a compelling piece on this topic earlier this year, will lead this part of the workshop. The intention of this workshop is to “move the needle” – to create help to create a community of practice around these technologies that will last beyond the event itself. I hope you’ll join us.
I’m fed up with the state of online (and offline) “sharing.” I’m talking about the experience of seeing something you like and sharing that sentiment (and a suitable URI*) with a community you care about (your Twitter followers, for example). I had three sharing experiences over the long weekend, none of which were very satisfying.
Example 1: The TechCrunch Europe article on start-up frustrations with BT’s Fibre roll-out. I was trying out an App, Pulse, and ended up reading the original article through this. Pulse is essentially a smart feed reader that downloads and caches articles – one advantage being that you can read them while off-line. (NB: when will someone write an HTML5 “app” that uses local storage to do the same thing?) Anyway, I wanted to share the article using the app’s built in Twitter button. That brought up a pop-up int he app which gave me a link shortened with Pule’s own link shortener (pulsene.ws). I wasn’t too comfortable with this because while I’m happy for the company behind Pulse to know that I’m using their app to send the tweet, I’m not so happy for them to be able to collect information on who’s reading my tweet. Plus I don’t know what that user experience will be when any other random person pulls up that URI. And I have no other option to use a third party shortener.
Example 2: The David Mitchell column in the Observer. This was the most dysfunctional. First of all, I had been reading the article itself in the paper version. I, like many other people in the world, read actual newspapers sometimes printed on real paper. But I find myself increasingly frustrated that there is no easy way to share directly from this medium. In this case, I read the article and I wanted to share it so I got out my phone then went to observer.co.uk (which thankfully does browser sniffing so automatically redirected me to a mobile-friendly home page). Then I had to find the article I had just been reading. I wanted to share right from the article page but no dice. I spent a few minutes looking around for “share me” buttons or menus – nothing (why?). Ok – so I shared directly from the browser menu. That brings up a contextual menu of all the ways you can share something (confusing!) – I chose Tweetdeck. I then had to ask Tweetdeck to shorten the URI (which it did using Bit.ly) so that it would fit (why?). Then I sent out my Tweet, which now had a bit.ly version of a URI to pointing to a mobile-friendly page (which itself does not do browser sniffing). So when another person on a Web browser on a regular PC views that link it shows up as one long column in the middle of their page. Yes – it worked, but totally unsatisfactory. And what about the link to print? Shouldn’t print newspapers start publishing a shortcut, QR code or short link in their print editions to close the gap between print and online? I’m just sayin’.
Example 3: Today, I shared a link from Plancast about the upcoming Federated Social Web Europe event. When I shared from plancast it send me over to Twitter.com which automatically re-shortened the already shortened link with Twitter’s own link shortener. http://planca.st/VRG became http://t.co/RPJrPTN. Well – I didn’t want to use t.co, I wanted to use planca.st. Why? I have this idea that using link shorteners that are controlled by the same organization that produced the original link is slightly less brittle than using third party link shortners. That’s fine – I re-pasted the planca.st link over the t.co link and sent my Tweet. Except, wait! Go to the tweet in question and use the contextual menu (right click) to copy the link and then paste it somewhere else for inspection. Oops! http://planca.st/VRG becomes http://t.co/RPJrPTN again! Thanks, Twitter! Then, to add insult to injury I get the following reply from my friend Ajit (presumably because his Blackberry browser balked at whatever t.co or planca.st or plancast.com decided to sling at him – but who knows at this point?
One more note of frustration: even in putting together this post, I had to manually edit the URIs that Twitter gave me as the canonical pointers to my Twitter posts. Why? Because Twitter insists on using the #! convention and I know that doesn’t work very well in some (especially mobile) browsers whereas if you use the same URI without the #! it works universally. (See Jeni Tennison’s blog for a great post on #! URIs.) Also, I have the “always use secure http” flag set to “on” in my Twitter preferences, meaning that if I copy and paste the URI, that will be the “https” URI – which is also probably not the best one to use in a post.
It’s clear that in this burgeoning era of the Social Web, people are sharing more, and in more ways, than ever before. This is a good thing. But we’ve got to get the user experience right and we’ve got to do it in a way that stands the test of time. The current maze of link shorteners, apps, interfaces, etc… has been great for innovation but it’s not sustainable or scalable. I hope that 2011 brings us some innovation that makes it easier to share (and to understand what’s being shared), in a way that is more in line with how the Web works (open, transparent, scaleable, traceable).
* For those confused by my use of the term URI, this is what Web standards wonks call URLs. Now that I’m a member of the TAG, I am legally obligated to say URI instead of URL. So be it.
Late last year, I was asked to write an article for a “digital parenting” magazine produced by my employer, Vodafone. I was asked to write about (positive) trends I see in the future – I chose to focus on the future of social networking, the future of human-computer interaction and the future of open data – three key trends that I see having a major impact on how we live, and have major implications for how we need to think about digital privacy. Besides my musings, though, the magazine is actually packed with great information for parents of young children who are just starting to explore the Web, social networks, texting and other forms of digital media. As a parent, I really recommend reading it. To read the full article, you have to go to parents.vodafone.com and “click on” the “Digital Parenting Magazine.” It is also downloadable as a PDF.
In 2006, I wrote a blog post in an attempt to define “mobile 2.0.” Looking back at that post, I can see that many of my predictions have come to pass. We have indeed moved into a new area, where apps and the mobile Web are bringing a new class of services to mobile users. And we are continuing to see the mobile and Web/Internet industries converge.
But what relevance does the “Mobile 2.0” conference have in 2010?
Hard to believe that this will be the fifth Mobile 2.0 event running in Silicon Valley. In 2006, after discussing with Mike Rowehl and Gregory Gorman the fact that the Web 2.0 Summit (and many other industry events focusing on disruptive innovation) had no mobile-related content to speak of, we decided to create Mobile 2.0 – a day-long event that would take the format we had helped develop with MobileMonday and expand it to a day-long event. The result was Mobile 2.0 – ok, not the most original name, I grant you. But behind the name, there was and continues to be an ethos that is different from other industry events. We are informal. We are emphatically not pay-for-play. We are people who work and live in this industry. We value people with knowledge they are willing and excited to share with others. We are passionate (and I don’t use the word lightly) about innovation in mobile and we have borne witness to a great era of change in that industry. We strongly believe in the importance of holistic thinking – bringing together entrepreneurs, developers, strategists, VCs, designers and marketers to talk to and learn from each-other. We understand that we live on a planet and that innovation is happening around the globe. We shy away from hype and try to expose the realities of what’s going on. We agree that the convergence between the Internet and the mobile platforms is creating a new medium with aspects of both. We are trying to move the needle.
I was amused to see that Nokia’s new CEO closed his talk at Nokia World in London by reprising Balmer’s famous “developers, developers, developers” speech. I’ve been talking to a lot of developers lately. I just got through co-organizing and co-presenting Over the Air and I’ll shortly be heading to San Francisco to help put on another event – Mobile 2.0, which includes a developer day and a “business” day. I’ll also be heading over to SuperHappyDevHouse to talk with yet mote developers. I want to talk to developers about what’s going on with HTML5, the social Web (and especially OneSocialWeb), the WAC, the Mobile Web Application Best Practices, and the re-launch of Vodafone Developer. I’m also very excited to hear from our line-up of speakers at the Mobile 2.0 Developer Day about what they think are the key issues facing developers today. And I hope to hear from many developers about what their issues are – what they think we as an industry should be focusing on.
I’m an early adopter, or possibly a serial alpha tester. I’m always willing to give something new a go, especially when it comes to new ways to get around my city, London. I was first off the block to get an Oyster card – a fantastic innovation that has transformed Tube and Bus travel, in my opinion. I was an early customer of the “OnePulse” combined Oyster-Visa-contactless payment card – less than fantastic, but that’s the subject of another post. So it should come as no surprise that I was one of the first to sign up for the new “Cycle Hire” scheme in London – cheerily called “Boris’s Bikes” by the press. (Us Londoners know they’re really Ken’s bikes but “Ken’s Bikes” suffers from a lack of aliteration so “Boris’s Bikes” it is.)
They probably had enough work to do just launching the service and getting basic e-commerce systems up and running to worry about mobile app development and I’m aso guessing they didn’t have the expertise in house (though that’s just a guess). Many companies and organizations launching new services, particularly in government, might be in similar situations. They could have decided to bag mobile all together, but that would have been shortsighted. Clearly, this is a service that needed a mobile component. So, as reported in the Guardian, TFL decided not to roll their own mobile app associated with the service but rather opened the field up budding mobile developers. They did so by releasing their data as an API to the developer community and seeing what emerged. And what emerged was a host of mobile applications, some of which have been reported on in the Londonist and CNet UK.
To guide me on my (so-far) three cycle hire journeys, I’ve used the Android Cycle Hire Widget by Little Fluffy Toys. It gives you instant feedback on your home screen on the location, direction and status of the 3 nearest docking stations: invaluable information at the beginning and end of your journey. (I’m also glad to report that we will be featuring a session from Little Fluffy Toys at this year’s Over the Air on how they built that app.)
The main take-away here is that by opening up their data through an API, TFL enabled a market to develop around how to best visualize and package that data for mobile use. And what we’ve seen emerge so far is only the tip of the iceberg. I fully expect to see mashups and other creative uses of that data in the near future.