Things what I writ

I sometimes write nonsense about things to try and sound clever

Have phone, will travel

This is a blog on a plane. It is the story of a number of systems I’m using to make the overall travel experience simpler, more efficient, and less painful. It will include this plane. It will include a few trains. It might also include a taxi or two. And hotels. And maybe some government systems that will allow me to enter the country without all those questions they felt necessary to ask me back in 1984 because I had a bit of a beard and looked like I maybe hadn’t slept much.

It will definitely include online booking systems.

All of today’s journey was researched online. Of course it was. How else do you do it these days? Nearly all of it was booked online, apart from the taxi. The taxi company we use for work does have some kind of online booking system I think, but it works rather better to phone the night before and tell them in person, because I’m not entirely convinced the online system is anything more than a copy of wordstar sending faxes to a pigeon.

And everything has been tracked online. Confirmation of booking, booking reference, whether the train is on time, what platform it will be on, checking into my fight, getting my boarding pass, checking the plane will be on time, what departure gate it will be at, right up to me sitting here in 27k somewhere over a cloud the size of Greenland, having taken a photo of my feet and a highlife magazine and bored 1044 to death with it on twitter.

When I say online, of course, I mean, on my phone. Everything I’ve mentioned here has been done using my phone. That’s to say the train company, the airline, the hotel chain (not the taxi company) make it possible for me to arrange and book and track an entire travel itinerary just using my phone. I mean, I could have used a desktop computer or a laptop, but, you know, that’s not the first thing we do these days. I fill the gaps between whatever I do either side of gaps by fiddling with my phone. It might as well be productive fiddling. Those companies might as well make it easy to use their service over someone else’s, because, increasingly, if I can’t do it on my phone, I won’t do it at all.

There are of course, some drawbacks to a wholly phone-based travel experience. When I want to print out the hotel details to leave at home, I’m a bit stuck. It’s almost an affront to have to turn on the poor neglected desktop just to connect to a printer. But really, that’s about it. For me, this is an entirely paperless trip. So paperless, in fact, that I forgot to take the most important piece of paper of all. My passport.

Ok, so I didn’t really forget it, BUT I NEARLY DID. That’s a good enough anecdote for me to describe the modern travel experience and how it’s changed our expectations of what is possible. The ubiquity of mobile and its effect on some of our largest ecosystems continues to change the way we manage our lives, mostly, I think, for the better.

I should probably point out the some of the apps and mobile sites I had to use to make this happen were fucking awful, but that might take the edge off my nicely upbeat story, so I won’t.

Global, local, desktop, mobile

About a million years ago I wrote the web globalisation strategy for a large corporation that included, variously, authoring and production strategy, globalisation, localisation and internationalisation requirements, data architecture, content management platform definition, functional specifications, business requirements, lots of pictures of concentric circles, some arrows, some double-byte character sets, search integration, all sorts of stuff. I mean, I didn’t write all of it. No, actually, I did write all of it. And it was pretty good. But it never happened.

It never happened because the content strategy that supported a ‘write once, publish everywhere’ model was simply too inflexible for stakeholders to sign up to. The idea is perfectly simple. The execution is pretty doable. We could build the platform, we could integrate localisation workflows, we could support content authors with different levels of scope and authority, we could distribute that authoring, we could centralise that authoring, we could mash everything together into a globalised online presence, and Bob would indeed be your uncle.

However, different stakeholders want different things. Different customers want different things. Different users want different things. So, what’s good for the North American goose isn’t necessarily good for the Korean gander. What’s good for the North American buck isn’t necessarily good for the French doe. What’s good for the North American seahorse isn’t necessarily good for the Australian, well, seahorse. And the subtleties of those differences are what led the program to dribble to an apologetic unconclusion. We simply couldn’t define a content strategy that was flexible enough to assemble and distribute a globalised site, based on the centralised, corporate brand and product requirements and the business needs of the content experts and marketeers in the countries. It was easier for the countries to roll their own. So that’s what they did. Using the platform we built to support the central content model. They just created their own instances and copy and pasted the bits they needed from .com, creating silos and duplicates all over the place thankyouverymuch.

It’s that difficulty I witnessed in the global vs. local model that appears to be a central (pun intended) issue with desktop vs. mobile. Well, ok, it’s one of the central issues. I mean, it’s a bit of an issue. IT’S AN ISSUE.

There’s no reason why technically we can’t support the authoring, publishing and distribution of content and services that can provide a coherent experience across all kinds of screens and devices. Responsive design is a method. Having less stuff is a method. Having smaller stuff is probably a method. But for a properly scalable, flexible and efficient operation, it’s just not going to happen unless all stakeholders are in agreement about the content strategy. And when I say stakeholders, I mean anyone who owns, manages, authors or consumes that content. As a content owner, you might not care about comments disappearing from an article when you read it on a smaller viewport. As a commenter, you’ve just been slapped with the wet fish of ‘fuck you’ simply because you’re reading the article on something that fits in your palm. And that’s why content strategy is hard and why rendering isn’t the whole answer.

I’m not proposing a solution, I just see parallels with the globalisation efforts I went through years ago. I don’t think anyone has ever really got globalisation right. I’m not sure anyone will ever really get content strategy for the wider web right. But it is fascinating seeing the component parts evolve that might make it happen.

Jennifer might enjoy this Global Web Programs presentation (PDF 5mb) that talks about the common web platform. Fun times.

listening post: pg.lost – jonathan

Ride the lightning

Notwithstanding a pithy reference to a metal experience that reminds me of the second half of the vinyl rack at the record shop where I used to work, tonight I rode the lightning at the event that uses the name but in no way conjures up images of axes and diminished 3rds because it’s got UX at the end and so rather suggests there might be crumpers and iphones and projectors and bottles of water and stuff which there was, for tonight was lightning UX and I spake of random percentages, gears of fear and communicating only through michael jackson thriller dance moves. There may have also been occasional references to mobile wallet design challenges amongst which and of I mused upon that included cognition of conceptual architectures, complicated contexts of use, and user confidences in and around the whole bloody wallet thing what they don’t even get ffs. Grrr.

I was, however, merely one of the peas in a UX pentapod that had been popped forth to live and breathe the warm air of a university basement and deliver a missive so sweet that it must just be our very last thing we do in a 10 minute burst looked upon by the sparkling eyes of the eversokeen. Within the delicate constraints of the framework – like rolling down the grassy hill of a summer’s day, passing the baton of freshly plucked UX grass between us like it might be the day all summery rolling down hill baton-passing days might be like – the five of us took that which was close to our hearts and set it into the ether upon the wings of hope where, in my case, it kind of crashed about a bit in a series of profane outbursts vaguely resembling a topic whereupon it flew too close to the flame of relevance and singed it’s little wings a bit.

In other words, I talked some stuff about designing mobile wallets and I made a lot of numbers up and the four others speakers on the bill were very good and actually when we opened it up to questions that got quite interesting and if anybody wants to ask me about the perception of flawed security models in the deployment of mobile payment frameworks or how you draw a thing which says PAY NOW then I’m more than happy to follow up with you. Point your stick toward @timcaynes. Come see me at the IA summit. I am UX.

Hacking NFC

Not strictly speaking hacking the protocol or platform or whatever you want to call it, because that might require rather more technical knowledge than I have left and implies something that is probably illegal, but hacking, in terms of using the near field communication infrastructure to muck about and produce something akin to a chocolate fireguard that you can show other people and say ‘look! I did a chocolate fireguard!’, as they add the finishing touches to their ‘tap-to-space travel’ demo.
 
Last week, the UK’s first NFC hack event was launched in Norwich. It’s a pretty ad hoc affair, under the Hot Source banner, that Proxamaare supporting by making their NFC technology platform available to anybody who wanted to enter a team. All you have to bring to the party is your creative minds and a willingness to stand in front of the other 17 teams at the end of the month and show them what you’ve managed to build. And show them you can. With an NFC-enabled phone, access to Proxama’s hardware and software, tags and tech, you really can build an NFC-enabled technology solution. You just write that HTML5 stuff that displays a monkey, loyalty card, free gift or whatever, when your programmed NFC tag is tapped with your phone. Of course, since your team defines the experience, owns the code, has the idea in the first place, you can do much more than monkeys. If you want to write a bunch of HTML that’s loaded in webkit, or the Proxama app, and then have that web content do something else, like, say, integrate with your ecommerce platform, turn on the lights, leverage location services on your device and send a message to the queen specifying exactly where the bloody cake is to be delivered already, then you can do that, just with a tap of your phone on the programmable tag.
 
You see what’s possible here? It’s not just about using your phone to pay for a banana. I mean, the platform could support that if you wanted to do that, but, like, you can already do that. The idea of the hack event is that armed with the technology platform, you create something new, innovative, quite possibly ridiculous, but definitely original and potentially commercially viable. And, if it is, all well and good. Take that idea away with you and make it commercially viable. Proxama aren’t going to steal it, it’s your IP. Do with it what you will. What the event is about is demonstrating what you can do with the NFC platform. And I’m leading the Flow team. There’s also a Foolproof team, but, you know, I don’t give them much hope for winning the competition. I mean, I can’t see how anyone is going to top my shark tank escape game. It’s simple – you get dropped in a shark tank with your NFC phone and have to tap on the hidden tags to open the escape hatch. You either tap all the tags, in the right order, within the time, or, well, the demo gets really interesting. I haven’t decided which team member is going to demo it yet, mind.
 

android user experience

see what I did there? no? it doesn’t matter, you’re not even reading this.

since I’ve recently twisted my own arm into spending more than 2 quid a week on my mobile phone, which was actually 2 quid a week on a sim card which was hoofed into a handset from 1999 running symbian s60 which I didn’t like when I was using it and like even less now that I’m not, I’ve been wondering how I might somehow get into experience design for mobile platforms. I’ve been designing for web and web-based channels for donkey’s years and more recently working on complex applications for trading platforms, but I’ve not really delved deeply into mobile as yet, other than the wap sites we pushed out for Sun Microsystems many years ago which amounted to 17 links in 5 languages that didn’t really go anywhere, but we did make the logo really much smaller than we were supposed to, which, in itself, was a triumph of vectors and transparency.

a few weeks ago, I was interviewing for a user experience design position with Qualcomm, which was to be working on their next-generation mobile platforms alongside and incorporating brew, plaza and lots of other nice things that you rarely see in carphone warehouse, but that position went the way of many other full-time permanent user experience positions. that’s to say it didn’t go anywhere at all. I was phoned before the second interview to say that the position had somehow vapourised internally by law of the corporation and that they were very sorry but it just doesn’t exist now so you can’t do it. despite it not coming to anything it did at least pique my interest, since I did my usual copious research on the subject in order to perform well at the interview I didn’t end up doing.

what has piqued me even more, if there are levels of pique, is that when I started my current position at Tobias and Tobias, working for financial services clients in the city, was the fact that not only does almost every single person on the train, on the tube, walking down old broad street or sat in bishopsgate, own, and is permanently conjoined with a smartphone of some descrption, they own, and are often conjoined with a smartphone of some other description. at the same time. and three on the go is not as uncommon as you might imagine, or at least I imagined. for at least 70% of these people, bleating into an iphone is their preferred interaction, for which the pied piper of hand things is undoubtedly most pleased, but other smartphones are available. you know that. right? and with all these smartphone appendages dangling in front of me, I feel like I’m missing a trick if I don’t get some kind of experience designing for those platforms.

now I’m one of those people doing the train, tube, hammersmith, broad street, bishopsgate, liverpool street, tesco thing, I thought I really should get some kind of proper phone which lets me monitor trades on an AMOLED screen or something. or at least doesn’t hang for a full minute when I send a text. since I also have a tendency to avoid technology trends (meaning, usually, I can’t afford to be an early adopter), I had, a long time ago, discounted an iphone. actually, I like iphones, but anything that requires me to use bloody itunes just doesn’t make it onto any list I have. apart from the list of things I won’t buy that I have. and, since I’m already a google person, I was already looking for a phone built around a mobile platform that integrates all my googlist activities which of course is the moble platform that google make. it was really just a question of handsets and platform versions. which, granted, isn’t an insignificant consideration. suffice to say, after I’d bought a pile of ‘what mobile’ magazines the size of a small child and reviewed acres of adverts with the occasional technology blog in the middle, I’d determined that the HTC Desire with Android 2.1 was the very thing. which it is.

I really rather like Android. I really rather like HTC’s Sense UI, although it really doesn’t do an awful lot after you’ve worked out you don’t need to flip between 7 home screens that often. and I really rather like the Desire, even though its a bit, well, brown. all three together, notwithstanding the usual caveats around battery life, seem to support an all-round user experience that suits the way I want and need to use my smartphone to do the things I bought it for. my most basic requirement was for excellent support for multiple email accounts that exist on multiple servers. I was also looking for excellent social network integration. I was also looking for excellent clocks. truth is, limited as the Android apps store is, there’s just enough there to enhance the user experience by one or two degrees. mind you, the apps bundled in 2.1 and the google support built-in, means that I’m pretty well set up without needing to go anywhere near the app store. unless I want better clocks. for which there is probably an app. called ‘better clocks’.

in a nutshell, which is kind of what my new phone reminds me of, first impressions of the Android user experience on the HTC Desire are very favourable. I’ve had a week to do the thing where you turn everything on and then turn everything off again. I’ve tried all combinations of widgets, programs and shortcuts. and turned them all off again. I been through every single setting screen and religiously observed the state and behavioural changes that occur as a result and determined whether I like those changes. I’ve settled on a default configuration for everything. I’ve installed the advanced task manager to kill everything I’ve left running, because, excellent as multitasking is and nice as it is to have updates and notifications going of all over the place all the time, is does rather reduce the usable uptime.

next step is to work out how I might begin to design and build something that runs on my own phone, just to go through the development process. with all that spare time I have. I’m writing this on the train you know. and my tea’s gone cold.

Archives
Categories

Share