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 +Dave Shea (of CSS Zen Garden fame), +Andrew Betts (of FT labs) and +Dominique Hazael-Massieux (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 +Christian Heilmann on #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 +Peter Paul Koch‘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 +Dave Shea) #blogthis
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.
#donottrack #privacy #w3c #blogthis
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.
Overall a very good program of talks this morning at +LeWeb London focusing on the "Sharing Economy." I think the idea of the sharing economy aligns well with the core values of the Web. But one thing no speaker has addressed yet is how to deal with "bad actors" in the context of the sharing economy. How can I participate in this sharing economy and avoid being phished, or spammed, or pwned? How can I participate in the sharing economy and also maintain my privacy? How can we stop airbnb becoming a micro-culture like eBay that is impenetrable and hostile to newcomers? How can we use the transparency of the Web to combat our own darker natures? #LeWeb #SharingEconomy #blogthis
One take-away from last week's Mobilism conference that I did not get to ruminate on during +Jeremy Keith's fine panel was just the bare fact that responsive design has arrived. Last year's Mobilism was full of pitches for responsive design and explanations of why responsive design was a good idea. This year's conference speakers mostly started from a base assumption: we are designing responsively. Now what? How do we do it? What best practices should we use? What anti-paterns exist? How does it apply to images, to animation, to touch, etc…? For those in the Web design community this may be old news, but I think it's notable that we've had that shift, from justification to implementation of responsive, in the last year.
I think this is more evidence for what I've been saying for the past few months: the "Mobile Web" is no longer a thing. That might sound strange coming from someone who helped to develop the W3C Mobile Web Best Practices, but where we once said "mobile Web" we now need to be saying "responsive design" and we need to be thinking about a much wider range of devices and input / output modalities than simply mobile phones. (For example, gaming consoles, as +Anna Debenham pointed out in her Mobilism presentation.) Simultaneously we need to realize that the Web is a mobile medium – by some counts, a majority if Web usage is now happening from devices we are counting as "mobile."
I don't get how so many people can be so vehemently opposed to the QR code, and not only that, but that people somehow view the QR code as being a weapon of "marketing." In my mind, the QR code is about openness. You may not like the looks of it, but it is a "democratizing" technology. It's open – anyone can create one – and it can point to a URL, which is itself an open pointer to anywhere on the Web. In contrast, other similar mechanisms (e.g. NFC) are usually closed and proprietary in nature. It actually reminds me of the equally misguided negative reaction to the URL itself in the early days of the Web.
Paging +Terence Eden.
Glad to see that this document I had worked on during my elected term on the TAG (with +Jeni Tennison, +Ashok Malhotra and +Larry Masinter) has been published. This document is trying to clarify some issues around Web publishing and linking that seem to keep cropping up in legal and policy discussions. In the process, it offers up some (hopefully) easy-to-understand definitions of pieces of Web technology. Although my proposed language on enshrining a "right to link" doesn't seem to have made it into the final draft, I think it's still a good piece of work. #blogthis
This weekend I built a simple temperature sensor with #arduino and got it sending information to #cosm via the #gsm shield, using the #bluevia SIM for data. Even after a year working on this project, this was actually the first time I was able to test the whole thing end to end myself, as a user would do (including purchasing the shield and the Arduino kit itself through online store, activating the SIM and adding balance to it, etc…). The results can be seen below and here: https://cosm.com/feeds/121725 where you can get an updated feed and graph of the temperature in my living room. It’s a pretty simple project but especially since I have been swanning around London telling people how easy it would be to build a connected temperature sensor with this shield, it was gratifying to see that I was right. :) The project uses the Cosm libraries and is built on top of the Cosm example code, but uses the GSM libraries instead of the Ethernet shield ones. In putting it together I realized one of the differences between writing an IoT application for the GSM shield (as opposed to Ethernet or Wifi) will be keeping data volume to a minimum. Also the Cosm example code just activates the network and keeps it active even when the Arduino is just sitting idle, whereas on GSM you’d want to connect and disconnect, especially if you are on battery power.