It was great fun, we spent a few hours in Covent Garden putting it together, and generally being geeks in public. Which in this case was great fun :)
I got to talk about the start of the upcoming Brighton Tuttle Club (Social Media Cafe), and a little about the future of tracking offline to mobile conversions and location specific behavioral patterns. Something that I’m really interested in at the moment, and will happily talk about, come find me at the weekly Tuttle!
What you see above you on the left is a feature listing for the “Dolphin” set of tariffs from Orange. On the right is the “detail” of those tariffs. Do you see the problem?
I want:
unlimited mobile internet
unlimited anytime, any network texts
600 anytime, any network minutes
Is that £30 or £35?
Not to mention that the tagline at the top reads “..weekend..” texts. Gah!? (Oh, and the typo on the left-hand £25 too, “unlimited anytime text”, not “texts”, oh no). And why do they repeat themselves directly under the same copy?
I lack any confidence in these people. And I haven’t even touched on bloody “fair use” clauses.
Now I suspect that the confusion may be because I’m an existing customer, I’m logged in, and it’s showing me the relevant content. That’s no excuse for contradictions. I also suspect that these prices may reflect different contract lengths. However, there is no mention of that. Plus I already have a contract, and do not need to extend it to change my tariff.
Send them (and all the others (and all the banks)) to the School of WTF, and get them to make sense. This reinforces my theory that most businesses make their money by confusing the customer or taking advantage of ignorance or stupidity. This is why we don’t like you. Are you listening?
For those that don’t know, a QR Code is essentially a 2 dimensional barcode, in that it stores it’s data in two directions on a grid instead of in one direction as lines. (see the example at the bottom of this post)
Using various tools to create these codes (on a RESTful URL) it’s possible to embed or encode many types of information, such as plain alphanumeric text, phone numbers or whole vcards, or urls. You can also denote a protocol for the information to help the device reading the code to know what to do with it, i.e. http://, smsto:, tel: etc..
For example, encoding “tel:+44207000000″ will produce a QR Code that when scanned by a mobile will ask the user if they would like to call that phone number. Lots of possibilities! Yes, the things you’re thinking right now are possible ;)
(Brian and I went further with this and have started to create a wiki that documents all the different scenarios and protocols and tests them to understand how best to use QR Codes in the everyday application. More on that at a later date!)
So I then decided to see what else could be done. Others have done lots of examples, and I’m in no way suggesting that this is groundbreaking, but this is an example that interests me greatly, and also shows very simply the power of this technology.
Not being a coder I spent some time trawling the internet for some javascript help, I was about to write my first Greasemonkey script, so needed some basic help. I wanted to be able to find a particular element in an html page, in this case an image, and identify it’s URL. This URL is then turned into a QR Code and displayed conveniently on the page. So that while a user (with the Greasemonkey script installed) was viewing a Flickr photo page they could easily then visit the image URL on their mobile phone, and possibly choose to save it.
So here’s what it looks like: - Original photo by cgandolfo, thanks!
Interesting? Yes. This is *the* simplest and quickest way I’ve ever seen to transfer data from one device to another, without and sort of direct connection between the two (Bluetooth, USB) or without any network or contact details (email address, fileserver). The user doesn’t even need to know the URL, type it in, or send it to themselves. Within seconds the photo just appears on the phone.
So if you want to do this, go install Greasemonkey for FireFox and then click on the QRFlickr script from the link below to install:
We have a version [of Flash] that’s working on the emulation. This is still on the computer and you know, we have to continue to move it from a test environment onto the device and continue to make it work. So we are pleased with the internal progress that we’ve made to date.
Well, Flash so far in emulation only. Implications?
(note that there is nothing in that quote that implies it will be Flash or Flash Lite)
I don’t know about you, but i’m loving the iPhone, as soon as ActiveSync is on there that’s me done, no more phones.
Will flash *work* on the iPhone conceptually is the real question, flash (as it is) works on the web, but similar ui/ux/interface paradigms have to exist/be created as have to be for other iPhone/mobile apps and sites. Just having flash on the iPhone (presumably in-browser) is not enough. Even though that will enable users to see the flash, does that mean that the flash will be usable on this platform in the same way it is in a desktop browser. I think that the very fact that there are iPhone specific web sites proves that it won’t just *work* in terms of ui/ux in the way that current flash sites do in a desktop browser. This will require developers and designers to do similar interface rethinks and detection as they’re already doing for html sites.
Not to mention touch, multitouch, scaling, frame rates (timeline based actions and animation), performance, player version, webcam/microphone access, uploads/downloads, video codecs available.
So if we can assume that (mobile) bandwidth will increase, handsets will get more powerful, have more storage and screen real-estate, does this mean we can expect better experiences as a result?
Website owners (or designers/developers, whatever..) are very quick to consume a users bandwidth. By that i mean the thinking that if there is more bandwidth then it can be used. Surely if there is more bandwidth then it means current things can be quicker! Downloaded faster! Download sizes of sites and their elements should still be efficient, video streamed should be realistic. Why not enhance the experience through performance rather than what is effectively just more data transfer in the form of more graphics, higher quality video, or even just more code. The best mobile apps and sites are the ones that let you use them quickly for the function that you need right there and then. And are designed with the end medium (essentially the small screen form-factor) in mind. And not forgetting, right now, also at a good data cost. For most users there is still a cost per kb, let’s not use data size as a barrier to use at all.
Luckily the iPhone has inspired people do make websites that take advantage of the form factor, and so far to not just push the limits of every aspect of it, making it unusable. The experiences are mostly good, because they are fast, low-fat, and have familiar interfaces instantly taking cues from the basic native apps.
Let’s go about this in the right way, help the users to take the leap to the mobile web by creating things that are genuinely useful and that work. Let’s not go back to the frustrating early days of pretty much every new step forward of the web, mobile or otherwise. Don’t make me compare this to WAP, please! We were young, ignorant, but excited and creative, and we learned a lot.
“Rich” experiences on the mobile web
Flash might be coming to the iPhone, Silverlight is coming to the mobile (and Java’s already here).
Shantanu Narayen:
read the article..
Well, Flash so far in emulation only. Implications?
(note that there is nothing in that quote that implies it will be Flash or Flash Lite)
I don’t know about you, but i’m loving the iPhone, as soon as ActiveSync is on there that’s me done, no more phones.
Will flash *work* on the iPhone conceptually is the real question, flash (as it is) works on the web, but similar ui/ux/interface paradigms have to exist/be created as have to be for other iPhone/mobile apps and sites. Just having flash on the iPhone (presumably in-browser) is not enough. Even though that will enable users to see the flash, does that mean that the flash will be usable on this platform in the same way it is in a desktop browser. I think that the very fact that there are iPhone specific web sites proves that it won’t just *work* in terms of ui/ux in the way that current flash sites do in a desktop browser. This will require developers and designers to do similar interface rethinks and detection as they’re already doing for html sites.
Not to mention touch, multitouch, scaling, frame rates (timeline based actions and animation), performance, player version, webcam/microphone access, uploads/downloads, video codecs available.
So if we can assume that (mobile) bandwidth will increase, handsets will get more powerful, have more storage and screen real-estate, does this mean we can expect better experiences as a result?
Website owners (or designers/developers, whatever..) are very quick to consume a users bandwidth. By that i mean the thinking that if there is more bandwidth then it can be used. Surely if there is more bandwidth then it means current things can be quicker! Downloaded faster! Download sizes of sites and their elements should still be efficient, video streamed should be realistic. Why not enhance the experience through performance rather than what is effectively just more data transfer in the form of more graphics, higher quality video, or even just more code. The best mobile apps and sites are the ones that let you use them quickly for the function that you need right there and then. And are designed with the end medium (essentially the small screen form-factor) in mind. And not forgetting, right now, also at a good data cost. For most users there is still a cost per kb, let’s not use data size as a barrier to use at all.
Brian sums a lot of this up very well for the Mobile Web 2.0 Summit blog.
Luckily the iPhone has inspired people do make websites that take advantage of the form factor, and so far to not just push the limits of every aspect of it, making it unusable. The experiences are mostly good, because they are fast, low-fat, and have familiar interfaces instantly taking cues from the basic native apps.
Let’s go about this in the right way, help the users to take the leap to the mobile web by creating things that are genuinely useful and that work. Let’s not go back to the frustrating early days of pretty much every new step forward of the web, mobile or otherwise. Don’t make me compare this to WAP, please! We were young, ignorant, but excited and creative, and we learned a lot.
[This article has been reposted on the Mobile Web 2.0 Summit blog]