Read this great article in The Verge today on the voice behind Siri. I’m finding myself using #Siri more and more these days, especially for quick tasks that would otherwise take multiple steps and involve unlocking the phone. For example, checking the weather (or checking the weather in another city), setting alarms, changing settings (“set do not disturb”) or location-based alerts (“remind me to check the gas meter when I get home”) which are pretty magical. I’ve even used Siri for dictating texts, but only short messages. IOS 7 Siri is definitely better (though still not perfect) at understanding you even with background noise present. All in all, it’s pretty impressive. She still can’t do “Tea, Earl Gray, Hot” though.
Update: Some further thoughts: Although Siri is great, does it represent another form of walled garden? I will note that I can ask Siri to make a restaurant reservation for me (though not in the UK) but it will only do so through OpenTable. I can get Weather info but I can’t configure it to get weather info from BBC. The lack of an open API for Siri is a bit troublesome. Shouldn’t I be able to plug in to Siri as an app (or a Web App for that matter) and as a data source in a more straightforward way?
This strikes me as a good example of “good patents” but where the patent system none-the-less is failing to protect innovators – i.e. here is a company, Dyson, that has come up with some revolutionary new technologies, which they have patented, and which are incorporated into their products which they bring to market. However, they are a small company so when a big company (Samsung) with lots of lawyers copies their design, they have limited recourse. Contrast to some of the press on patent trolls who buy patents, produce nothing themselves, and then use them to quash innovation in by companies.
I’m proud to be a part of an activity called “The Open Agenda” as part of my work at https://twitter.com/tefdigital/status/374912105012809728) which will be followed up with content at http://theopenagenda.com and other events and activities in the coming months. Have a look at my blog on the official Open Agenda site and get involved in the discussion by using hashtag #TheOpenAgenda.
Hello Google+ peeps! It's shameless self-promotion time, I'm afraid. I've put a panel submission into next year's South by Southwest #sxsw panel picker and I would really appreciate your support in voting it up. Personally I think this panel is going to kick ass – and I don't use language like that lightly. We've got (of CSS Zen Garden fame), (of FT labs) and (from W3C) lined up to explore the latest on the Web on mobile – responsive design, APIs, off-line operation and more. How is the Web closing the gap with native apps – what's the state of the art and where is it going? If you have a second, please log into the panel picker at the link below, register if you are not already registered, and vote my panel up. You will be doing me a favor, but more importantly you will be doing a favor for the future of the Web. Thanks! #blogthis #mobileweb
Another instalment of the video series I recorded with #FirefoxOS – this time touching on developer tools, responsive design and some of the elements that developers need to worry about on mobile – e.g. touch events. (Also see ‘s wonderful presentation on touch events from this year’s #Mobilism conference. In fact, anyone interested in responsive design topics would do well to watch all the presentations from Mobilism – http://mobilism.nl/2013/coverage, especially the “Mobile Web Design Anti-Paterns” talk by ) #blogthison
So I read with some interest a tech note from Google on the impeding use of a transforming proxy server for Chrome for IOS & Android. The idea is to speed up the Web on mobile devices where network bandwidth is constrained. If I understand correctly, the proxy will first of all route all http traffic over a single #SPDY connection. It will compress images to WebP on the fly, minify code and move DNS resolution to the proxy. All of this holds the possibility to greatly increase browsing performance – essentially giving you Opera-Mini like performance but with a “full web” experience. I’m excited about that. I’m also glad that they’ve explicitly excluded https traffic from the proxy – although increasingly more and more services are redirecting users to https versions of their pages by default (including, amusingly, the page on developers.google.com that describes the data compression proxy).
I do have a few questions that don’t seem to have been addressed in the brief. First of all, what options do I, as a content developer, have to deactivate the features such as image compression? One example of where I might want to do this is if I am trying to transfer a file (rather than display an image) or I want to make sure that an image is sent at its highest resolution and clarity – for example, if I am trying to enable a doctor to examine an X-Ray image).
A few years ago, the Mobile Web Best Practices working group developed a set of Guidelines for Web Content Transformation – http://www.w3.org/TR/ct-guidelines/ (with some input from Google as well as from other players in the compressing proxy landscape, such as Novarra, which has since been acquired by Nokia and incorporated into their Asha product). This document could best be described as an attempt to re-educate implementers about some of the already existing features of http that they should be using to be more transparent to Web developers when they develop software that gets into the middle of the http transaction, especially when it attempts to meddle with the contents of what is being delivered to the client, or what is being communicated back to the server. Unfortunately, this document never got beyond the Note stage, but I think it’s a none-the-less very instructive.
I wonder if the implementers of this new Google Data Compression Proxy for Chrome on IOS and Android have read it? If not, I suggest that they do. If there is one thing I learned back then, it was to tread lightly when attempting to “optimize” Web content in the network: http://techcrunch.com/2007/09/21/vodafone-in-mobile-web-storm/
Can We Stop the Tracking Already?
I cannot believe this nonsense is still going on. I had to check my watch – yes indeed, it's now 2013, and we still don't have a viable do-not-track specification. This should have been one of the simplest pieces of work that W3C has ever engaged in. Instead it has been drawn out into an ever-deepening vortex of conflicting interests, back-stabbing and bad-faith behavior from which there seemingly is no escape. Do-not-track preferences are now built into all major browsers so many consumers might thing this is a solved issue – it's not, because nobody can agree what "do not track means." I say "nobody" but what I mean is that advertisers don't agree. Pretty much everyone else agrees – it means "do not track." Advertisers seem to think it should mean "go ahead and track" but "don't show me targeted ads so I don't feel like I'm being tracked." Some advertisers who have joined W3C and joined the Tracking Protection working group have done so with the explicit, cynical goal of torpedoing do-no-track. The question advertisers need to ask themselves is: what are they so afraid of? Surely, if Web users find advertising-supported sites and targeted context-aware advertising so useful, then they will be happy to have their Web surfing tracked for the purposes of targeting this advertising and providing these services. If users feel they are getting a fair shake for the information they are providing to advertisers, they should not then object to being tracked. Or is it possible that the advertising community can only exist by tricking users into providing information that they would not knowingly provide and then reselling this information in ways which the user would not agree to?
I hope the working group chairs and W3C team members involved can provide some leadership and pull this group back from the brink of irrelevance. We need a do-not-track standard that stands up for user privacy on the Web.
This great article neatly skewers Apple’s claim that iMessages are encrypted “so no one but the sender and receiver can see ore read them.” This was claim I as immediately sceptical about when it was made so it’s nice to have some expert opinion backing up that scepticism.