Unmethodical Analysis

Where are you? Analysis of requirements for location
Because of a super secret project at work, I have been analysing requirements for location. Specifically, how do people answer the question: Where are you?

I expect Plato had something to say about the difference between taxonomy and understanding. I choose to ignore whatever it was and have analysed by classifying the types of location description we can give.

First off, and a warmish topic of the moment, co-ordinates.
Co-ordinates
Co-ordinates, also known as longitude and latitude, can be obtained by geo-location or in some other way. Chomsky should love them because co-ordinates require no context to be understood. Also, they are precise and unambiguous. So this seems like it should be the best way to state your location. Predictably though, there are issues with co-ordinates.

First, co-ordinates only address the physical aspect of location. More on that story later.
Second, because a co-ordinate location requires no context, and no familiarity with the located individual, there is a privacy risk. Anybody who can get hold of your co-ordinates can also get hold of you.

Third, and this might just be my experience, co-ordinates are not supported where they need to be. Some scenarios…
Scenario one
We’re trying to meet up right now and are both outside on the street.
So far as I can tell, unless we have both already signed up to a service like Latitude, and agreed that we want to share our locations with each other for ever, we cannot find out where we both are at this moment. Hardly a “set-up lite” solution is it? And it could be so much easier:

Step one: Your mobile device enables you to send your current location by SMS
Step two: My device receives the location SMS, and displays the received location, and its own location, on a map that is zoomed to the rectangle defined by the two points.

Step three. There is no step three. There was no set-up either, other than exchanging our mobile phone numbers.
Scenario two
I’m at my desk, planning how to get to your office. I have your postal address, and I know where I am.
Hmm, the address book in which I store contact details can handle postal addresses, but cannot store longitude and latitude co-ordinates.

Ah, my mobile device can only get my location when I’m outdoors.
Oh dear, I’m stymied. I have to copy and paste postal locations into a mapping utility like Google Maps.
Scenario three, counter example
On a recent holiday in Umbria, I noticed a tendency for tourist brochures to include the co-ordinates for the attraction that they promote. Given the local infrastructure, it would be pretty hopeless trying to give directions in prose, which would also require translation. So they enable you to use your car’s GPS. (I’m assuming you can punch co-ordinates into a GPS; a usability guru might have decided that would be “far too technical” for users to understand.)

That’s co-ordinates, the ultimate low-context statement of location. At the high-context end of the scale are locations like “at home”, “at the gym”, or “on holiday”. I call these evocative locations.

Evocative location
This type of location is not useful to me, the located individual, but it might be useful to you, the person who is trying to locate me. If I’m on holiday, you wouldn’t call me about a routine work matter. If I’m at the pub you might call me to see if you can come too.

Now, knowing my co-ordinates might enable you to work out something like an evocative location. For example, if you map my last known co-ordinates and find that they were within 5 metres of a pub door, you know I’m probably “at the pub”. Similarly, if you know where I live, and my current co-ordinates are within 10 metres of it, you might conclude that I am “at home” although I might be “on holiday” and getting on with some DIY.

That mobile classic “I’m on the bus”, generally shouted from the upper deck, fits here. At only four words, this is an economical way to convey location. The other party knows what kind of communication can now take place; they have an idea of where you are and where you will be in the immediate future, and they have a mental picture of your environment.

Back at the low-context end of the scale, nearer to co-ordinates than evocation, is postal address.
Postal address
Exchange of postal addresses is widely supported; they can be included in a contact record and sent by Bluetooth, SMS, e-mail etc.

They can be used in that hardcopy delivery service the old folks call “letters”. It’s also where Royal Mail will drop the slip that tells you to go to the sorting office so you can collect the stuff you bought on-line.

Postal addresses have stood the test of time, so far.
I’m trying to think of a non-postal scenario where I would prefer a postal address to co-ordinates and I can’t. But until co-ordinates are supported everywhere that I need them to be, postal address remains the best context-free location.

On the high-low context scale next to postal addresses are locations like: Edinburgh, Bermuda, Africa, Old Street. These are descriptive without being evocative.

Descriptive location
Like an evocative location, a descriptive location is more useful for you than for me. If I’m in Africa all week, there’s no point inviting me to a meeting in Bermuda this evening. Note that, for the purposes of the query “can you attend a meeting in Bermuda this evening” there is no need for a more specific location than Africa in the answer.

If you know the location of my London office, i.e. if you have a particular context, then when I give my location as London, you probably know exactly where I am. Somebody without that background, who gained access to my location as “London”, would not be able to locate me.

So this is a more private way to give location than postal address, but carrying a different kind of information than evocative location.

Conclusion
I thought of four types of location and ranked them as follows:

On to the question of requirements, which is my job…
Support for co-ordinates is generally required. I’d like to see them in a lot more applications, please.
Postal addresses must remain supported until user interfaces develop proper handling of co-ordinates.
Descriptive locations will give way to co-ordinates, I believe. In user interface terms, the choice will be between typing “Hackney” and clicking Send my geo-location now. People will pick to click, not type.

Evocative locations will, I hope, always be required. Where am I? I’m at my desk.
Would you have got more information out of my co-ordinates or postal address?

Copyright © Jim Hawkins, 2009

Loading mentions Retweet

Original post here:

http://danwtmoon.posterous.com/context-not-content-is-king

Click here to download:

Unmethodical 02 mpg.mpg (23880 KB)

Loading mentions Retweet

UX Camp London 22aug2009
A most stimulating day sponsored by Vodafone, Gum Tree, Addlestones Cider and some others, and organised by Dees and some others

Here follows an encouraging miscellany of personal stimulata…
Talk: Accessible Mobile Web
The presenter is about to kick-off a research project on mobile web for users with disabilities.
My main encouraging moment came in the questions. One of the attendees started talking about how flash might or might not work on some phones, how javascript was imperfectly implemented, like that. The presenter said he was going to start his research by discovering what users with disabilities actually want to do with the mobile web. Outstanding, I thought.

It seems obvious, yet most mobile websites that I see appear to have begun their design by asking: How will our website look in a mobile browser? What technologies can we use to present our desktop website on the phone?

The first question should be: What features of our service do users want to access when mobile?
Talk: The Big Picture
The presenter is a UX designer working in an Agile Development regime. They talked about how to present information internally.

My main encouraging moment in this talk was quite near the start. The speaker related that, when they had joined their current employer, they had been labelled a “user champion”. Oh dear. The speaker soon shifted away from this ridiculous buzz-wordy title, and instead found themselves “talking in user terms”.

I’m very encouraged to meet other people who reject the buzzwords of the day, but still follow up-to-date best practise.

Talk: Emotion in design
The presenter is a UX designer at Motorola, the phone manufacturer.
Yes, it’s an American company, and yes, he was from America. So he’d come a long way to give his presentation. With that in mind and not wishing to be inhospitable, it seemed churlish that I should insist on telling him what I think of his employer’s product.

Then again, I knew that I would never be able to look at myself in the mirror, nor my interaction designer in the eye, if I did not tell him. What to do? I mean, I need to look at myself in the mirror once a week in order to shave.

Luckily for me the discussion after the talk pretty soon descended into Apple-bashing. Hence I was able to execute what I believe is termed a segue in the name of getting back on topic. From a point about the quality of what you see and hold in your hand before you switch on a device, I slipped in that Motorola phones are pretty poor when you actually start using them.

My interaction designer will be proud.
How did the presenter take it? He gave a wry smile. Yeah, he knew already. Later he mentioned that he works “mostly on the design side” which I guess means the superficial* part.

(I mean superficial* in the medical sense: on or near the surface.)
Talk: Agile moaning and wailing
Yes, that was the title. There was no presentation, as such; this was more of an open chat session.
People talked about the problems they face as UX designers while working with or in Agile teams. Here’s a few that were memorable, to me at least.

“When you’re a freelance UX designer, the project manager doesn’t give you the chance to sit with the developers, which is key if they are Agile.”

I can’t help thinking that this is bound to happen when you’re being paid by the hour. I’m not saying it’s your fault, mind. I’m sure you ended up doing hit-and-run UX design because your last permanent employer finally succeeded in persuading you that you don’t own the thing you make. (OK, hit-and-run isn’t quite right because in a hit-and-run there’s only one guilty party. It’s more like wham-bam-thank-you-ma’am.)

Anyway, point is that a UX designer isn’t carpet. You can’t buy it by the metre, and then walk all over it. You need your UX designers to be stakeholders in the software that is being produced, which means them being permanent team members.

“Developers focus on the minimal function, as defined by the user story, not on delivering an excellent user experience.”

It’s easy to see how this could happen in an organisation that has gone Agile in name only. Hey Project Manager, you’re now a Scrum Master. Hey Requirements Analyst, you’re now a Product Owner. Hey the Functional Specification is now the User Stories. Hey, we’re Agile, mission accomplished.

See what’s happened? The developers have been told to implement the User Stories instead of the Functional Specification. That doesn’t work because the Functional Specification is not replaced by the User Stories alone, but by the User Stories plus all the conversations the team has about the User Stories.

So, what’s the solution? If I were of a religious inclination I suppose I would insist on strict adherence to Agile methodologies. But I’m not, so I blame the person responsible, in this case the Product Owner.

“The Product Owner should block the Done state of a User Story if the user experience is not good enough.”
That was my quote and I think on the day I said “… if the interaction designer is not happy with it.” I’m backing off from that because always saying yes to your UX designer is like always saying yes to your coders, your testers, your sales people or your customers.

And on that note of compromise, I move on as did the participants in the discussion. That happens at barcamps sometimes; time runs out and you go to the next talk. No bad thing, and fairly Agile when you think about it.

Talk: Search UX
Not much to say about this, except that it was an excellent talk. I never really think about how many search user interfaces there are out there.

I was reminded of a course that was part of the final year of my degree. The title of the course was Software Engineering. The point of the course was to draw a distinction between programming “in the small” and “in the large”. The Search UX talk was squarely about design “in the small” which I found encouraging.

UX Camp London had a number of “in the large” talks about the role of UX in the corporation and such. All very well, but some people still care about the basics. Some people are still pondering what is the best interface, even for a task that is now very common. And evidently, they are still coming up with new and better approaches.

The presenter didn’t actually use the phrase but his thesis was “we can do better than Google.” I approve.
Talk: Textual interfaces
Another good talk that provoked plenty of discussion, in part about what actually counts as a textual interface.
Turns out the command line is alive and well and residing in Google search. I’ll probably stick to goosh.org myself, mostly because it maintains the fine tradition of Unix humour.

Talk: Addressed to me, Visible to me
Erm, my presentation. Only two people attended but we had a nice enough chat that lasted for the allotted time. Afterwards, I wandered about looking to fill the last talk-slot of the day. I found another talk attended by two people, and even a talk attended by only one person. So I didn’t feel bad getting an audience of two.

Conclusion
The event’s conclusion started over ciders in the kitchen, and continued at some pub or other where a free bar had been arranged. I wimped out and came home.

But I do feel encouraged to give a talk at a barcamp again. Next time, I’ll bag a slot earlier in the day, when everybody’s still there. I’ll also give my talk a better title; something more provocative and informative.

Until then, I’ll have to get my stimulation from elsewhere. I could always get it from my job, I suppose…

Copyright © Jim Hawkins, 2009

Loading mentions Retweet

Three scenarios for mobilising on-line social networks
I have three key scenarios for mobilisation of on-line social networks. Eh? OK, word by word:
Scenarios. Scenario analysis is a great way to approach user requirements. Formally, a scenario consists of some pre-conditions, a sequence of steps, and some post-conditions. Informally, a scenario is a situation and something that the user wants to do in that situation.

Mobilisation. Getting a service onto a mobile phone (US: cell phone) is called mobilisation. This implies that there is a process and therefore a difference between the “full” service and the “mobilised” service. I subscribe to that implication and suggest that it will always be the case. What some people see as convergence of the desktop and the mobile is in reality only improvement of the mobile.

On-line social networks. Like facebook, twitter, MySpace, flickr, and the Whole Sick Crew (Pynchon reference). I prefer that term to the superfluous -ing of “social networking sites” and a plain “social network” is simply a group of people that communicate in some way. If I need an abbreviation, I put SN. Yes, I have lumped media hosts, like flickr and photobucket, in with social networks.

So what I meant to say was: When specifying software requirements for getting data from facebook, twitter, MySpace, flickr, photobucket and the like to a mobile phone, I consider three situations and what the user wants to do in those situations.

Why now?
I have now related these scenarios so often that people have started repeating them back to me. So I thought I’d better document them to, as it were, stake a claim. Get on with it, you say? Very well…

Scenario: The Dave Gap
I’m out for a drink with my mate Dave
Dave goes to the lavatory
This is the start of The Dave Gap
Before his back has even receded from view, I become bored (yes, I’m part of the internet generation or the mobile generation or some other generation or other)

What do I do to relieve my boredom? I get out my phone of course. I check my e-mail. I check my twitter, my facebook, and my other on-line social networks.

Dave comes back from the lavatory after a short interval (didn’t wash hands)
This is the end of The Dave Gap
I put my phone away, polite chap that I am, and that’s the end of the scenario
Analysis: Notice that I had to check my e-mail and on-line social networks before Dave returned. That requirement pretty much mandates that the data had already been pushed to my device. No IMAP or POP3 client can establish and retrieve a connection in that time. Nor can any browser open an SN website quick enough.

I have time to write a sentence in The Dave Gap. Or I have time to set a number of “unary flags” like facebook Liked, or twitter Favourite. So these actions are good candidates for mobilisation.

Scenario: Mary Is Hot
Disclaimer: This is not based on any particular Mary
Mary is my friend on one or more SNs
Mary uploads a new picture of herself
I see the picture on my phone, somehow
“Mary is hot,” I think. “I should call her.” (Will & Grace reference)
I click once or twice and my phone places the call
Analysis: There has to be an identification of the Mary that is a user of the SN with the Mary whose phone number is in my mobile device.

The interaction has to be extremely simple. I don’t want to have to key in M, A, R, Y to my phone address book; by the time I’ve found her, I’ll be out of the moment. The point of a mobile device is that it is always with me.

Is it pretentious to say that it should be with me emotionally as well as physically? Yes it is. Nevertheless: When I’m in the moment, my mobile device should be in the moment with me.

Variant scenario…
I see something funny, like a road sign or some obscene graffiti
I take a picture of the funny thing
I share it with all my SN friends
Analysis: OK, Mary wasn’t involved in this but it was still about being in the moment.
An example of staying with the user in the moment is: Don’t force the user to enter a caption to their picture. Certainly don’t make me wait until I’m next to a computer to which I can connect my device. That’s not in the moment; that’s in a different continent from the moment.

But, the software could capture the moment. For example: if the photo cannot be uploaded now because I have no coverage, queue the photo and upload it later, when I do have coverage.

Scenario: Drunk On A Bus
This could take place after I’ve been drinking with Dave or my failed date with Mary and I’m on my way home
Let’s say it’s a journey of one hour
If I was bored after ten seconds in The Dave Gap, imagine how I feel when I’m Drunk On A Bus for one hour. Back then, I was evading. Now, I have more time and I’m going to take the fight to the enemy. It’s war.

To fight boredom, I crave stimulation (Cronenberg reference) and entertainment.
I could listen to music that I’ve downloaded to my phone earlier, but then I would have to make an intelligent choice. Right now, I’m drunk (see the scenario title) so intelligence is not my preferred option. I simply want entertainment to come to me without my choosing.

Fortunately, this is provided by the Web 2.0 internet. Entertainment from the internet, internetainment if you will.
I did make intelligent choices earlier, when I was sober and supposed to be working. I chose which SNs to join, chose who to follow and chose who would be my friend.

Now I capitalise on those choices. I find entertainment and stimulation from my on-line contacts.
I click around their witty tweets, amusing photos and pithy remarks
I respond, because I have time, with comments and tweets of my own. Or, I drunkenly flame them. (Drunks tend to think that they’re invincible and amusing.)

Analysis: Here, it’s OK to open a browser or similar application, so long as the software tolerates spotty coverage.
The user is not interacting with their “real” friends in this scenario. Instead they are interacting with their “on-line” friends. The difference between the two categories is in how they were chosen. How, or even if, people choose their real friends is complex topic that is beyond my powers and is in any case irrelevant to this scenario. How people choose their on-line friends is simple: On-line friends must be good allies in the War On Boredom.

Conclusion
My phone is not a desktop computer. My phone is not the tool I use to organise the hundred high quality pictures I took on my walking tour of the Massif Centrale. My phone is not where I group my contacts, real friends or on-line friends.

My phone is a weapon in the War on Boredom
My phone is with me when I am in the moment
My phone can fill The Dave Gap

Coming soon…
Operator opprobrium part two: Multimedia Messaging Service
(In which I once and for all write down everything I know about MMS)

Copyright © Jim Hawkins, 2009

Loading mentions Retweet

Stimulus: TJI OpenTech
@billt: The world is being run by people who do not understand what is possible with modern technology and science.
@edent: I may not understand technology, but I understand usability and psychology. Aren’t they just as important?
(TJI = Tweets Just In)
Now personally, I don’t want the world to be run by Technologists, Scientists, Usability experts, or Psychologists. I want the world to be run by me, or at least by my vote.

But seriously, this exchange takes me back to the old Market Led versus Technology Led debate of the Nineties.
Response: Market Led vs Technology Led
The central question of the debate was: Should products be designed by Marketing, or by Engineering?
The answer was, and is: By both. In other words, the Muppets and the Geeks must both lead; they must collaborate.
To take a personal aside, anybody familiar with people from Marketing and Engineering knows that they cannot collaborate directly. They do not share the same values, nor a common language. This is why people like me have the job of Product Design, previously called Requirements Analysis. We mediate in order to enable productive engagement. And engagement is key because both parties bring their own perspective.

Consider the laptop. What features will we have in the next generation of laptops?
What we want is for the next generation to be the same as the current generation except lighter, more powerful and easier to use. This is the market perspective; it’s what we want.

But what we can we have? Maybe tiny retro-rockets that would stop the laptop from hitting the ground hard when dropped. Maybe a lamp that can project an image of you typing at your laptop. These would be important innovations from a technology perspective. (I didn’t make these up, by the way. Try an internet search for the Lenovo tapes.)

Already-real examples of technology-led innovations are: Webcams, Memory cards, the USB port, fingerprint recognition.
The corresponding market-led innovations are: built-in webcams, built-in SD card readers, more USB ports, fingerprint login.

Conclusion
The Market knows what it wants, but not what it can have
Technology can innovate radically, but cannot place its innovations within easy reach
So neither Market-led, nor Technology-led, work when they are separate. But Market-led and Technology-led do work when they are together.

Copyright © Jim Hawkins, 2009

Loading mentions Retweet

Operator Opprobrium
Lately I’ve been hearing a lot of people knocking mobile network operators. I have a few things to say about that, to those knocking the operators and to the operators themselves.

(Originally, this was going to be titled The Network Knockers. But since the audience is going to read this, not hear it, it is preferable to have lexical alliteration, to oral alliteration. Also knockers is slang for boobs in British English.)

Why should you listen to me?
I spent seven years working at a mobile operator as a coder, team leader, tester and solution designer. Since then I’ve spent three years working in mobile phone software requirements analysis aka product design.

Opprobrium: They won't let me tether my iPhone!
Have a guess why; I have. To be allowed to offer the iPhone, an operator has to sign a revenue-sharing deal with Apple. Who do you think is getting the good end of that? Last I heard, in the U.K. Apple were even getting a share of the call revenue of all iPhone users on O2. That’s right, call revenue. It’s the meat and potatoes of all mobile operators and here is a manufacturer biting out a meal of their own.

The details are confidential of course but recent speculation is that O2 will lose their exclusivity on iPhone at the end of this contract because they are no longer willing (or able?) to pay what Apple is asking.

So if you’re using an iPhone on O2 you should be thanking them, not knocking them. They’re paying so you can have a beautiful mobile device.

Opprobrium: But unlimited should be unlimited!
The iPhone, and others, may be sold in a package that includes “unlimited” packet data. That has led some buyers to decide to assume that what they’re paying is a fair price for infinite packet data. The network is perhaps at fault in calling this an unlimited tariff.

Perhaps they should have stayed with the industry term, and called the deal an All-You-Can-Eat tariff. It’s a good way to think of these deals. The term All-You-Can-Eat originates in restaurants that charge you a fixed price, regardless of how much you eat, typically from a buffet.

Tethering your iPhone to your laptop is like going into Joe’s All-You-Can-Eat and stuffing your backpack full from the buffet. Joe doesn’t like it; would you?

More later…

Copyright © Jim Hawkins, 2009

Loading mentions Retweet