Dissection of a user interface
For various reasons, the next Unmethodical Analysis blog post is on blogspot instead of here on posterous. Dissection of a User Interface
For various reasons, the next Unmethodical Analysis blog post is on blogspot instead of here on posterous. Dissection of a User Interface
On its own, BYO is an abbreviation for Bring Your Own. This was originally seen on student party invitations from young Americans in the phrase BYO Beer. More mature party-goers, with refined tastes, might themselves choose to bring their own beer, or wine. That’s BYO.
BYOD is an abbreviation for Bring Your Own Device. This doesn’t imply you’re invited to a party; Bring means bring to work. As to Device, that means a laptop, a mobile phone, or any other type of electronic equipment, including an iPad. (I could say “slate” but I’m not a manufacturer so I don’t need to pretend that the iPad is just another instance of a pre-existing type of device.)
BYOD is part of a blurring of the division between what is mine and what is my employer’s. That division does not only apply to hardware, but also to services, and even time. Here it is in a diagram:
Note the grey area shared by the Home and Work ellipses.
You enter the grey area when you do any of the following:
· Make a personal phone call at your desk
· Order pizza using your work mobile
· Write a personal letter on your work laptop
· Play your own CD in your work desktop, while you work
· Take a late work call at home
· Work from home using your own broadband
· Have stuff you bought on-line delivered to your office
I have done all of the above. Also, I don’t have a personal laptop and a work laptop, nor do I have a personal mobile phone. Beyond hardware and services, I don’t have separate work and home calendars, nor separate address books.
Well, as the song says, how did I get here?
How did I blur the thick black lines of the home-work distinction into a grey blur?
The answer lies in the psychology of the individual (Jeeves reference). There are a number of psychologies that can lead to the blurring of the division of home and work.
Only prostitutes do it for the money
The psychology of the job-lover is that of the motivational poster: Fascinated by your work? No? Then get different work. Don’t spend half your waking hours doing something you hate. If you despise your work, you despise yourself.
The job-lover doesn’t look forward to the end of the working day. They want to continue working after they leave the office, or lab. Hence they bring their work home and blur their work and home lives.
The crime is salary; the sentence is work
Guilt can be a motivator: You browsed the internet a lot today, so you agree to take a late call tomorrow. You took your laptop home so that your daughter could do her homework on it this evening. You shouldn’t do that because it’s a work resource, so you feel guilty. Tonight, to expiate your guilt, you respond to some e-mails that you would otherwise have processed tomorrow. You hate your job but it pays the rent and puts food on the table.
The psychology of the guilt worker is one of constant shame that they are not working hard enough, or that they are abusing the facilities that their employer provides. Since they used their work time to do personal stuff, they now must let work stuff intrude into their personal time.
A man’s best friend is his job
The guilt worker’s and job-lover’s relationships to their jobs are those of forced parasite and willing host, respectively. The relationship of the engaged independent takes the best of both; it is symbiotic. If you need a model, think of man and dog.
Humans and dogs have been living together for around 15,000 years. That’s a successful marriage by any standard. It worked because each brought something different to the relationship. Man needed a partner who could track by scent. Dog needed a partner who could shoot an arrow into prey at a distance. (These days, Dog needs its kidney medicine, and Man needs lessons in loyalty.)
There’s a deal going on. For example, suppose your employer pays your mobile phone bill. Their end of the deal is your colleagues calling you at any time. Your end is calling home to your dad when you’re on holiday abroad.
Engaged independents recognise that they bring some things to work, and also that work brings some things to them. When the two come together, there is a blurring like spinning cog wheels in an engine.
These are three possible psychologies of the individual. In analysing them, we are analysing the consumer in the market, which is essential for product design. But the BYOD market is not pure consumer.
Whatever their psychological compulsions, individual consumers could not have created the BYOD market on their own. Their employers, the enterprises, participated too.
Most products are sold to the consumer, or to the enterprise, but not to both. Even products that are sold to both have a different proposition in consumer and enterprise markets. But, in the BYOD market, both consumers and enterprise are represented. Either may buy your products, although in different ways, and for different reasons.
Consumers make decisions quicker than enterprises, and that includes purchasing decisions.
Individual consumers are already buying the latest iOS and Android devices. They are increasing their productivity by investing in superior tools to those provided by their employers, the enterprises.
As any salesperson will tell you, it’s been shown by science that people make decisions emotionally and then reinforce with rational arguments a few seconds later.
A consumer sees an iPad and wants it, because it’s cool. They decide to buy it, then rationalise “I can use it for work.”
(An enterprise would never do that. An enterprise would survey the market and consider all options and costs. By the time they decide that WiFi iPads meet their requirements, all the users that would be getting a company unit have already bought their own 3G ones. Consumers move faster than enterprises, see above.)
The consumer’s impulsiveness is compounded by their need to justify their purchases to, at most, their spouse. An enterprise’s I.T. buyer will have a whole financial department dedicated to doubting their purchases.
Consumers don’t consider the total cost of ownership (TCO) of a purchase, and don’t worry about the complexity of cash-flow.
For many years, enterprises bought IBM PCs because of IBM’s leasing arrangements, not because of any technical benefit. At face value, they were paying more than a consumer buying equivalent hardware from another supplier. But all the consumer had to do was pay cash and take their computer home. The enterprise had to pay out of their revenue, had to support thousands of users, and didn’t want to end up with a worthless asset at the end of the computer’s shorter corporate life.
What’s that you say? Not all consumers are poor? Think about Bill Gates? OK, let’s do that.
For $50 billion I could apparently buy all the equity in Microsoft Corporation. The net worth of Bill Gates is apparently in excess of $50 billion, so he is less poor than Microsoft. But ask yourself: Whose phone bill is higher? Who bought more computers this year? Who spent more on software licenses? You get the point.
So consumers spend money now, perhaps unwisely, on stuff that they will simply own. Enterprises spend a lot more money, but only after a lot of consideration, and they may not be looking for simple ownership when they have spent their money.
This is how consumers and enterprises spend in the BYOD market. Next question is: What will they buy? Why, the winning products that my employer is launching.
Just kidding. Obviously I can’t share my winning product designs, since they’re super-secret company property and worth millions, probably. But I can share some guidelines and notes.
Suppose the user is going to have a single device with them at work and at home. Couldn’t they use that device to track how they divide their time between those activities? A time-tracker could ping to notify the user that they have completed 7.5 hours of work and should rest or eat now. It seems appealing to attempt to resolve the blurriness but I think it does not work to any of the user psychologies.
The job-lover doesn’t care about their home life. They also don’t recognise that spending more time at work is a bad thing.
The guilt worker doesn’t want to find out that they actually didn’t earn their salary this month. They will also disappear down a rabbit hole trying to classify their time correctly. What about that one-hour conference call that I took in the office? I didn’t say anything during the call and I spent half of it surfing the web for a film to see, and the other half IMing my buddies to organise the cinema trip.
The engaged independent is already comfortable with their work-life split. If their employer foists this kind of time-recording on them, they will put in whatever values are needed to get the foister out of their hair so that they can get on with their job and life.
(But couldn’t a time-tracker change the guilt worker into an engaged independent? No, changes like that take therapy.)
Consumer and enterprise users have different goals. But that doesn’t mean they want entirely different product features.
Consumers want Gmail and MSN hotmail on their phones. Enterprise users want Outlook-Exchange or Lotus-Domino. They both want mobile e-mail.
The consumer wants to receive a photo of his niece’s birthday party. The enterprise user wants to receive the new rates spreadsheet. They both want e-mail attachments.
The consumer has to remember to buy his girlfriend a birthday card. The enterprise user has to make the weekly sales call, wherever she happens to be. They both want a synchronised calendar on their phone.
The consumer wants to find out where all that money that was in their wallet went. The enterprise user wants to claim expenses. They both need to track where they were and what they spent.
I believe BYO Phone users will stop thinking in terms of “personal contacts” and “work contacts”. Instead they will only think of “my contacts”.
Suppose the user wants to call somebody. It could be a colleague or a personal contact. The user does not want to have to look up the name in several places. The number could be in their phone contacts, their synchronised contacts, or even in their enterprise’s global address list (GAL). What the user wants is to key in part of the name of the person, and have all the look-ups executed.
Similarly, BYO Phone users will stop thinking in terms of “work calendar” and “home calendar” and instead have a single calendar.
The single calendar is compelling because of a simple fact: you can only be in one place at a time*. You don’t want to book lunch with your nephew at the same time as you’re interviewing your next head engineer. But if you have separate personal and work calendars, it’s quite easy to make that mistake.
(*This doesn’t apply to Dr Manhattan from the Watchmen, since he actually can be in two places at one time. If you are Dr Manhattan then a: I’m pretty stoked that you read my blog, and b: sorry but you’re a user base of one, and a fictional one at that, so your needs are custom not productised.)
The BYOD user’s to-do list goes the same way: not split between tasks that work wants me to do, and tasks that my family and friends want me to do. Instead, it is all the tasks that I have to do.
BYO Phone users will have a single set of contacts, calendar and tasks. Or, more generally stated, they will have a single set of Personal Information Management data (PIM data). But where will users store their PIM data?
Will they choose Gmail? Will they choose MSN hotmail? Will they choose their corporate Outlook account? Will they choose their PC’s local thunderbird (or icedove)? The answer eventually is yes, yes, yes, yes. Users will eventually have all their PIM everywhere. (It might not be so much by choice as by default though.)
Here’s a real service I heard about quite a while ago, when I worked at a mobile phone operator.
There was a long-distance haulier company; I believe it may even have been the famous Eddie Stobbart. The enterprise wanted mobile phones, so that their truck drivers could be contacted wherever they were. The enterprise also recognised that giving every member of staff access to a mobile that was paid for by the company could lead to a very large phone bill.
Their solution was for the company to buy the handset and the contract, but allow prepaid top-ups to be purchased by the drivers themselves. (That’s the inverse of BYO Phone.)
Following is another example of both parties paying, although this one is not a product as such. I worked at a company that had a fairly standard book-buying process. You wanted the company to buy a book, you raised a request giving the reason you wanted it, the title, ISBN etc. (This is not the BYOD part BTW.) The result was that few books were ordered by anybody other than the chairman. Also, the company had one copy of each of Kernighan & Ritchie, Harbison & Steele and Plauger, which meant that you couldn’t keep a copy on your desk.
That company was bought by another company. Their process was different. You want a book, you buy it. Then the company pays you half the cost of the book. See how this cuts through any need to justify your purchase? You don’t argue for the book, you put your money where your mouth is. Also, the company doesn’t need to give somebody an admin task to buy the book. Instead, that task moves to the person who is actually motivated to do it, because they want the book.
(One caveat: since you would own the book afterwards, I guess there’s a tax implication.)
In the BYO Phone world, it’s already possible to have the enterprise’s chosen mobile e-mail service installed on the user’s own handheld. Ideally, you want the user to pay for the contract that includes the phone, then the enterprise to pay for the mobile data and the software license. That could challenge the operator’s billing system, and both user and enterprise would have to choose the same mobile network, but these are only I.T. hurdles, not legal or engineering barriers.
And if you’re BYO Phone, why not BYO laptop? The only thing stopping most enterprises from supporting this is that they downsized and outsourced their I.T. function so much that they are beyond arms-length, and in fact out-of-sight of the user.
JCB is a well-known manufacturer of excavators and other heavy plant used in the building and agricultural trades. Part of their success is due, no doubt, to making technical innovations in their area and to selling equipment at the right price. Another part is that JCB had elements of what software developers call user-focus.
A while back, JCB put the operator in an enclosed cab, with a heated seat and a radio. At that time, their competitors’ vehicles were still open to the elements. As a result, when an operator moved on from one building site to a new job, he would request a JCB digger.
Now, it’s not the individual builder (user) that buys or hires the excavator. That decision will be made by the building company (enterprise). But I suppose that, given similar prices and capabilities, the buyer will go with the user’s recommendation.
Similar analysis has always applied to software sold to enterprises, or to service operators. Developers are good at doing whatever is necessary to get the deal. It’s the excitement of the sale, when the buyer is in the driving seat. But one year later, or even earlier, the users will be in charge. If they haven’t had a good experience of the service, it’ll get dropped.
In the BYOD market, there is an even stronger mandate to service the user instead of the buyer. Why? Because the user has more control over what software is installed on their device.
Suppose the enterprise I.T. director has been sold your mobile e-mail product. Suppose further that he has mandated it as the only approved mobile e-mail software within the enterprise, because it encrypts the e-mail on the phone. Great sale, guys. But suppose the product doesn’t give the end user what they need. The end user has no motivation to soldier on with, say, your difficult UI or limited HTML support. They didn’t buy the software, they will uninstall it.
(Can’t they be blocked from uninstalling? Maybe they could have when the enterprise bought a BlackBerry, and tied the user’s sciatic nerve through the lanyard grommet. But not now that the user bought a Nexus One themselves, with their own money. The I.T. director may issue whatever diktats they like, the user owns the device and will not clutter it with software that doesn’t work for them. And as to blocking other e-mail services, good luck. Users are ingenious. They find ways to get the data that they need for their jobs. They might find a process loophole, or a technical hack, or even persuade their local helpdesk to leak an access code or two.)
Anyway, suppose it’s now one year later. The I.T. director, possibly a different person by now, is reviewing the license spend. They check the e-mail server and find that hardly anybody is using your mobile e-mail service. Why aren’t you using it? the I.T. director asks the employees. It does on-device encryption. We don’t care about on-device encryption, say the end users. That was your requirement, not ours. Oh well, thinks the I.T. director, I may as well cancel our enterprise license.
To prevent this scenario, bear all users’ requirements in mind when designing the product. To close the sale, you need only meet the enterprise buyer’s requirements. But to keep the customer, you must also meet the end users’ requirements.
(If you think it’s not important to keep customers, ask a salesperson about the relative cost of acquiring new customers compared to selling to existing customers. Then ask them about the different success rates of referral and non-referral prospecting, i.e. getting your happy customers to give you more happy customers, as opposed to cold calling.)
(TOTH the founder of flirtomatic for introducing me to this term, in a public talk recently.)
Remember the impulse-buying consumer in the above? They rationalised a gadget purchase by saying “I can use it for work.”
Later on, this same consumer may find themselves saying “Hey, I really can use it for work.”
For product designers, this means that rediscovery is important. Rediscovery also applies to the typical enterprise roll-out, as follows.
Suppose the enterprise purchases a mobilisation module for their corporate Instant Messaging (IM). They deploy it and announce the roll-out. Right at that moment, their users are busy doing their jobs and are not in immediate need of mobile IM.
Later, a user is alone with their phone in a situation that demands instant communication with a colleague. Rediscovery is the thing that happens in between now, and the user starting an IM conversation with that colleague. If the user fails to rediscover their enterprise’s mobile IM service, the service fails.
Rediscovery is important in all services, but especially where the end user did not install the software themselves.
The iPhones I’ve seen had a lot of whizzy animated transitions. A lot? Well, at least more than I would expect in serious enterprise software. But the iPhone is usable as an enterprise tool.
The presence of whizzy animations is something of a challenge to my inner stereotype of how business software looks. It would be unsettling in a pure enterprise application. But in a BYO Phone it’s OK, because a BYO Phone is not purely for work.
Badges are a feature of some social networks. For example, users of plurk.com and blip.fm can earn badges by having a large number of friends on the site, or by being very active users. We don’t see badges on enterprise software, but maybe we should. How about a badge for somebody that has made over 100 edits on the corporate wiki? How about adding long-service badges to employees’ IM avatars, or GAL entries?
It’s kind of frivolous, sure, but there’s no reason product designers shouldn’t allow look & feel, and even features, to bleed over when users are in the BYOD grey area.
I think I saw a while ago that a Microsoft staffer had made some kind of add-on that tracked the user’s work in MS Word and awarded them points. Users could then compete against other users. I think I’d quite like somebody to create the Game of Work service, on-line. To play the Game of Work, I would set myself work goals, and then earn points for achieving them. I might choose to battle with other players (workers) for more points and badges, especially badges.
That sounds more like a party than work, which means we are back where we started.
If you’re a student who wants to have a party, but you can’t buy beer for everybody, you ask them: Bring Your Own
If you’re a guest at a dinner party, and you don’t want to drink the cheap plonk that your hosts will serve: Bring Your Own
Transposed to the BYOD market:
The BYOD enterprise is a party in a student flat. It cannot buy everything its users need, for reasons of affordability and practicality, but it still owns the game as a whole.
The BYOD consumer is a snob from the suburbs. It has varying control over which products it uses, and pays a varying portion of the costs.
There are products out there that meet both their requirements, and there will be more in future.
Copyright © Jim Hawkins, 2010
DevMob 2010
On 03feb2010 I went to the DevMob 2010 event, whose ning is here http://devmob2010.ning.com/
I learned some things, I asked some things, I answered some things, I was even interviewed at one point.
I learned that LPIA stands for Low Power Intel Architecture
I didn't learn all that much about LPIA, but that's reasonable as I am not an hardware engineer.
One point I did retain is that LPIA divides processor functions across two “complexes”: the North complex, and the South complex. These complexes can be powered up or not separately. A recent change is to put the audio processor down in the South complex, which also houses the I/O controller. That way you only need to power up the South complex to play music. Clever.
The point of LPIA in market terms, seems to me to be that Intel are on the march towards the Smart Phone. This market is currently held by ARM processors. This reminded me of an occasion, many years ago, when I was visiting a computer manufacturer.
For various reasons, I was working in the same room as a man who was specifying a machine for a customer. The spec included forty or so 486 processors, or they may have been Pentiums. Why is LPIA a reminder for that? Because that specification in that room was Intel marching on the minicomputer. At the time, that market was held by the likes of DEC and Data General. Remember DEC and DG? Neither do I, really. (I did enjoy the book Soul of a New Machine though, which follows a DG project.)
Anyway, Intel must have gone about as far as they can upwards. Nobody’s going to swap out their IBM mainframe for a PC farm, right? So now Intel are going downwards instead. It’s like the mammals have wiped out the dinosaurs and are going toe-to-toe with insects. We’ll see how it plays out.
I asked: What is the Linux Foundation?
Not quite as stupid a question as it sounds actually; there are a number of foundation-style organisations associated with open source software. Well, organisations many be overstating the situation. Many are no more than projects or, less, pieces of code that happen to be on git-hub.
Anyway, it turns out that the Linux Foundation is the non-profit that employs The Man himself, Linus Torvalds. So now I know.
I learned that Intel is one of the top three contributors to Linux
Their Moblin (Mobile Linux) project is hosted at the Linux foundation, or it was at the time of DevMob 2010. A matter of weeks later, at Mobile World Congress, it seems that Intel-only Moblin was replaced by an Intel-Nokia joint venture: MeeGo.
Moblin was Open Source like Android, and MeeGo is too. But, like Android, any real installation on a device is not wholly Open Source because the phone part will be closed by the device manufacturer.
Moblin started in 2007. Originally, it was based on whatever goes into Ubuntu. Now it is based on whatever goes into Fedora, apparently so they can use .rpm packages instead of Debian packages.
I asked: To whom would I pay my Moblin SDK license fee?
Right now, if I was developing software for HTC devices, I'd expect to have a license with HTC. But Intel seemed to have their own free and non-free tools for Moblin. (Same for MeeGo, I expect.) Would I license those from Intel, instead of licensing the device manufacturer's tools? Or would I need both licenses?
The answer may be that I would only need to license the Intel tools if I was a device manufacturer. As an application developer, I can get by with the free tools. But this may not give me access to the heavy-lifting APIs like power optimisation. I guess I’ll have to leave that to the device-driver developers.
I learned about a UI piece that Intel purchased and is now Open Source
It’s called Clutter and much was made of it at DevMob 2010. They said that it enables an iPhone-like user interface because it has built-in animation. They also said that there is the Moblin User Experience, which is written in Clutter, sitting on top of the Moblin User Interface. Well, I suppose somebody who thinks that the key to the iPhone's success is animation in the UI, might also think that “user experience” means “user interface but better”. Tut.
Since DevMob 2010, a new diagram has been published (Here, for example http://meego.com/developers/meego-architecture). This shoves Clutter and GTK+ well over to one side, leaving Qt in the dominant position. That’s from Nokia’s maemo, I bet.
Heresy alert: Do customers really care about another user interface? I’m especially thinking about phone customers. I saw some research recently that suggested most people look at the phone, pick it up and feel the buttons, and they’ve decided. UI isn’t something that drives their buying decision; it’s something they complain about later.
(Here’s that research http://www.telecoms.com/18383/application-brands-sway-handset-decisions)
I asked if Intel met enterprise requirements in their Moblin store
Suppose I'm an I.T. director. I've decided that all team leaders will have tiny laptops, such as Asus. I pick out a productivity suite that is compatible with these laptops and the infrastructure and enterprise applications that I’m already running. Every Moblin computer has access to the Moblin store. Can I, as I.T. director, use this store to distribute the applications that I identified for the productivity suite? The enterprise would be licensing these applications, and hence paying for them. The laptops themselves would be in the hands of end users. No, the end users would not have company credit cards. Neither would they have secretaries, nor access to a typing pool.
The answer was no, the store would not support the above scenario.
Since the Joint venture, the Moblin store may go West in favour of Nokia's Ovi.
I'm wondering if manufacturers, like Asus, will be getting a slice of Application revenue due to users of their Moblin / MeeGo devices? If the store on Moblin devices is Ovi, does that mean Nokia get a slice too?
My questions about The Slices started when I heard that O2 had to pay Apple a slice of call revenues in order to get their UK exclusive iPhone deal. Of course, Apple also gets a slice of application revenue, which they share with the mobile operator that sends the bills.
Then again, there's Google Android. That's an OS supplier sharing a slice of application revenue with a mobile operator.
With Moblin / MeeGo, Intel would be providing the OS and the processor. I suppose that entitles them to at least as much of a slice as Google get for supplying Android.
Maybe the ingredients of the pie will turn out to be more important than with whom it is shared. There was a game developer at DevMob who complained that the iPhone appstore gives him no information about who purchases his game, nor does it offer any way for him to contact his customers, nor is there any built-in system for his customers to raise support issues. If Intel, and Nokia, make a pie that provides those functions, they could literally build the pie higher (Bush-ism) and with it their revenues.
I learned how the Netbook started its life
Turns out there was a big batch of old Celeron processors going cheap. Some smart individual thought, yeah I could put one of those in a Speak & Spell chassis and sell it as a PC.
There ought to be a word for turning old hardware into money. I once worked in the same building as a company whose business was buying old R.A.F. warehouses full of valves and selling them to the Third World. Then again there was the Ascom salesman who had a growing market for Telex machines: Eastern Europe. The old kit may not be sexy but it is still valuable in the right context. (Must remember that next time I’m looking for a job.)
I answered: Why apps, why not The Cloud?
People still want their apps on their computer, which they own. The P in PC stands for personal, something in-house helpdesks might do well to remember.
I’m also coming across a trend to diversity. People are using their own phones for work. People are bringing in their own laptops into the office and, shock horror, I.T. departments are actually supporting them. There is a blurring between work and personal hardware, and life.
Is this new, or quite old fashioned? Think about the princes of the industrial revolution. They had no work-personal boundary; why should you? If you are interested in what you do, you think about it out-of-hours. You might even write a blog post about it out-of-hours.
I learned that there is a four to ten inch niche
This is about screen size. There is a niche for handheld devices whose screens are between four and ten inches across the diagonal. It is quite ably filled by one Chippy Paine and the other contributors to the http://www.umpcportal.com/ site.
(By the way, that site is now on my weekly read list, along with the following:
http://www.readwriteweb.com/
http://www.Telecoms.com/
http://friendfeed.com/rooms/weloveapps
http://london-ia.ning.com/
No, I don’t do RSS.)
No brand owns this niche, hence there is a great deal of activity there. The technology is improving in all directions: energy consumption, screen quality, storage capacity, processing power and so on. (I maintain that convergence with the desktop is a misconception though, since the desktop is also improving just as fast.)
But these improvements do not fundamentally change what the user can do with the devices in this niche. These improvements do not make users’ hands bigger, so they still cannot hold a large tablet device in one hand and type with the other. Neither do they make users’ hands tinier, so they still cannot type fast on a “peck board” or “thumb board” keyboard. Neither do they give users’ tuneable microscopic eyesight, so they still cannot view quality photos on a two inch screen.
The use cases are summarised in a diagram here on the umpcportal site
Excellent, isn’t it?
To the left-most column I would add the following:
On-line social network messages and comments with zero content such as Facebook’s Poke, Like, and Unlike, or Twitter’s mark as Favourite
Barcode reading with the camera, which is already in use on some Android and iPhone applications
FM radio. Why not listen to internet radio? Because it takes wa-a-a-ay more data and battery. Same goes for DAB radio, at least w.r.t. battery
Breathalyser would require additional hardware, but would be valuable to some
Sound-level checking is something a semi-pro muso colleague of mine was able to do with one of his phones. I don’t know if that particular phone had a better microphone, or just happened to have built-in software.
As I see it, only some uses cases should extend to the right in the diagram. In other words, some use cases can only be done on the smaller, less powerful, platforms. Any in-pocket use case is in this category.
For example, I often listen to the music on my phone when I’m walking and the phone is in my pocket. Could I do that with a laptop? I’ve tried and the answer is no. First of all, I had to plug the headphones into the socket on my laptop, then put my still-powered-on laptop into my rucksack. That was OK kind of until I wanted to change the track. I had to get my laptop out, open it, and then click a button in the media player. That’s a much longer interaction than the phone equivalent.
For more on mobilised usage, see this earlier post of mine: http://post.ly/1Ssh
I learned that there is an approach called Hurry Up and Get Idle
The theory is that a higher-spec processor might consume less power than a lower-spec. This is because it does what it needs to do quickly then goes to sleep. Probably not applicable to telephony or music though.
I learned what they call the glass in a phone touch screen
Gorilla glass, and it isn’t cheap. It’s fun to look at phone BOM (Bill Of Materials) websites sometimes. The screen is often the most expensive component, even pricier than the chip.
In conclusion…
Mobile computing has come a long way since the Husky Hunter and the Zorba (try http://www.old-computers.com) but it still has a long way to go. Is it the passenger or the vehicle?
Copyright © Jim Hawkins, 2010
Funny video and picture classification tags
My mate Jeff is a great forwarder of amusing pictures, videos and slideshows. Whilst I do not wish this to reduce, and certainly not stop, I do wish he would use the following classification tags. These are emerging as a de facto standard, I feel, for the good reason that they enable easy and appropriate enjoyment of forwarded content.
Tags can be added in the subject line or body of the message to which the video or slideshow is attached.
No sound
Use this tag when the video or slideshow is silent. I’ll be happy to play it anywhere, but see NSFW, below.
Has sound
Avoid the deprecated tag “Has sound” in favour of one of the following.
Better with sound
or
Needs sound
Use the “Needs sound” tag to let me know that I must get my headphones out in order to enjoy your video, or wait until I'm somewhere that I can make sound. Either of those is a cost to me. As Ofcom and the OFT would probably say, the consumer must be made aware of costs prior to consumption.
Use the tag better with sound to let me know that I could mute my computer and watch now, but with lesser enjoyment. This tag also gives me the alternative to delay watching, for greater gratification later.
NSFW
This tag originally derives from an abbreviation of Not Safe For Work but now has a wider meaning. The jocular re-working Not Safe For Wife has of course no place on my politically correct personal computer.
What NSFW implies now is the following:
I believe that you will not be offended by this material, although you may be amused, aroused or disgusted. However, I believe that you may not wish to be seen enjoying this type of material. Also, I cannot vouch that others will not be offended. To be safe, watch when alone.
Personally, I am tending to use more detailed classifications such as now appear on video games. For example: Sweary, Adult themes, or Sexual content.
Work-safe
Use this tag on material that is not NSFW. I prefer not to have this tag assumed and implicit, thank you.
Copyright © Jim Hawkins, 2010
Opprobrium: They charge me far too much!
Self said that airline pilots ought to sound a lot more excited when they take off. They actually sound quite bored, something like “This is your captain speaking. We will be travelling at an altitude of blah blah.” What they should say, with an exhilarated tone, is: “Holy cow, we’re flying. We’re actually flying; all of us. Just now, we were in London; when we stop flying, we’ll be in New York. Wheee!”
Why am I reminded of that? Because, guys, where’s your sense of wonder? You switch your phone on and you can talk to anybody in the world, from wherever you are in the world. Isn’t that amazing?
Isn’t that a bit gushy? Well, yes. Also, it’s only half the picture.
In the full picture, price is determined by supply and demand. The above is the demand side, and demand is clearly less hungry than it was when the mobile phone first appeared. What about supply?
Supply here means a mobile operator. I used to be employed by a mobile operator, whom I won’t name, so I can outline some of their costs.
Physical network means cell sites, aerials, microwave dishes and all that Real Engineering hardware. When I started work at the operator, I had a round of induction presentations. In one of these, I was told that the company was spending £1,000,000 a day on improving their network. Yes, one million pounds, every day. By the time I left, I think they were up to £2,000,000 per day. The average cost of a cell site is around £250,000 apparently.
Core network means the switches, Base Station Controllers (BSC), Home Location Registers (HLR), Visitor Location Registers (VLR) and a lot more gubbins besides. It’s all necessary, if you want the physical radio network to actually route calls.
Here, it’s not so much the hardware itself that costs the money. It’s the support costs and licensing fees. The actual amounts are guarded pretty closely but I do have an interesting snippet.
As well as everything else, the HLR vendor of my ex-employer charged the operator a fee per customer, per month. A customer here means an allocated HLR entry. So the “customer” might not be active, but the operator still had to pay. Suppose the fee was £1. On a £20 per month contract, that’s an immediate 5% of revenue that the operator never even sees.
I.T. Infrastructure means network management, rating, billing, customer care, provisioning, and possibly prepaid platforms. This is in the same category as core network. It’s a necessary cost, if you want the physical radio network to be useable.
Another snippet: a database vendor was at one time rumoured to be suing my employer over what they reckoned to be a very large number of unlicensed end-users. The database vendor argument went something like this:
A prepay customer of yours can query their balance at any time. That results in a query on the database you buy from us. So every prepaid customer is an end user and requires a license.
I guess the operator had about one thousand times as many prepay customers as they had staff, so those license fees would have been quite a hit. The operator had to settle because the company was being sold.
On a side note, unlike the physical network, the core network and I.T. infrastructure are not assets. In two years, all those cell sites will still be worth something; they could be sold. But in two years, the core network components and the I.T. infrastructure will be a big pile of two-year old computers. We all know what those are worth.
License to operate a mobile network. Licenses to operate are issued by that paragon of efficiency: The State. Licenses are not cheap.
As I recall, one operator paid £5bn for their 3G license. Not long after, the company was sold for £10bn. In other words, they paid half the value of their company for a piece of paper.
That piece of paper didn’t magically give them a 3G network either. They still had to build that. Could they re-use their 2G physical network? To some extent yes, but the technology has significant differences. In particular, 3G cells’ coverage shrinks when they get busy. This means that more cell sites are required, and that cell planning has to be done all over again. See above under Physical network for an idea of what that costs.
I think I’ve now painted the supply half of the picture. It’s a portrait of the physical network, core network, I.T. infrastructure and operator license formed into a lumbering colossus of cost and debt.
Apart from that analysis, there is also evidence to consider. Are mobile phone operators actually making massive profits? T-Mobile and Orange aren’t. That’s why they’re merging their UK operations.
So next time you find yourself wondering why the operator sets contract rates so high, don’t look at the buttony candy bar that they’re pressing into your hand. Look over their shoulder at the lumbering colossus of costs and debt that stalks them.
Opprobrium: They charge me for early termination!
The first way to avoid any early termination fee is to buy an unsubsidised and unlocked phone. There, simple.
But wait, you say, they cost way more. No, they cost the same; it just seems like more because you’re paying it all at once.
You see, the price you pay for your phone is initially reduced by a handset subsidy. The operator pays the subsidy to the manufacturer, and then charges it to you over the course of your contract.
Handset subsidy is like the operator lending you the money to buy your phone. When you terminate early, you still owe them whatever is left to pay. The phone is at least yours by then; it’s not like when you default on your car payments and they take away your wheels.
In the early days, so I was told, the operators came up with a creative and in no way dishonest approach to accounting for handset subsidy. They told the auditor that a happy customer is an asset.
Happy customers, they said, spread goodwill and induce non-customers to take our service. By doing this, happy customers actually increase the value of our business. Ergo happy customers are an asset. Expending the subsidy money increases our customers’ happiness. It is therefore an investment in the happy-customer asset. They even got away with it for a few years.
Then the auditors realised that customers are not assets but, well, customers. You can sell your assets; you can’t sell your customers (not legally anyway, T-Mobile UK staff take note please). Ergo the handset subsidy is not an investment but money you threw away, unless you get it back from the customer.
The operators said that their business model didn’t work if they did that. The auditor said: yeah not our problem.
And so the handset subsidy became the customer’s problem.
The second way to avoid an early termination fee is to wait 12 months, probably. Back when I was employed by an operator, the legal advice was that early termination fees for contracts over 12 months could not be enforced, although that may have changed.
OK, it’s obvious that you can avoid early termination fees by not terminating early. The operator’s point of view may be less obvious, and is really where I’m going with the second way of avoidance and indeed with this whole piece.
Customers that have just signed a contract provide a guaranteed steady monthly income, with a possible bonus if they exceed their allowances. As soon as a customer’s contract expires, they are a line-of-business (LOB) that could stop at any moment. More precisely, they could give notice to stop at any moment, when customer subscriptions are charged in advance.
In that respect, the operator is at a disadvantage compared to the customer. But the operator has the upper hand in another respect. The value of this LOB is now known to them, with standard caveats about the past twelve months not necessarily being indicative of the next twelve.
Back to your point-of-view now.
Once the signed-up period of your phone contract has expired, you qualify as Out Of Contract (OOC). Up until that point the operator could menace you with the entirely fair early termination fee. But now they are disarmed. This means that you can take your time.
Find the best competing offer, then call to terminate. You’ll be put through to the retention team, or whatever your particular operator calls it. They have the authority to make better offers than are in the shops, and will do so. There’s a caveat…
Before offering, the retention team will make a calculation of your likely Customer Lifetime Contribution (CLC). That’s your value to the operator, as a LOB. If your CLC is low, well, don’t expect a free iPhone and unlimited texts. But even then, you might still be worth an accessory or two so try and don’t be shy.
If your CLC is high, then you’ll probably get a better deal than you could have by switching. You certainly won’t have to go through the pain of porting, and you certainly will have avoided the early termination fee.
The retention team will probably try to get you to accept a new phone. Why? At some point, and possibly currently, the law considered that a new deal without any new hardware was not considered an upgrade as such. The customer has not received anything substantial, so the customer cannot be tied into a new contract. By contrast, a new phone means a new handset subsidy. A new subsidy means a new loan to you, hence a new contract with an early termination fee. And now you’re back to being a guaranteed steady LOB.
The second method boils down to: be valuable. The first boils down to: don’t be cheap.
Instead of complaining about early termination, count yourself lucky that the operator lent you the money to buy the handset that you now own.
Next time: DevMob2010 report
I used to work at a mobile phone network. I was working there when MMS was launched, and I worked on a few MMS projects. In this piece, I’ll try to write down everything I know about MMS. This is partly to pass on the knowledge, and partly therapy, for me. Those MMS projects were Hell.
Mm, protocols
Use cases
Picture upload. Pretty easy, just needs a packet data connection, right? Not entirely...
(And the packet data bearer has to be set up in such a way that the packet data billing engine can recognise it as zero-rated.)
If the customer is roaming, the packet data would still be free but the message charge would have to be higher. Why? Because the network on which the customer is roaming will charge the customer’s “home” network for carrying the data. That charge gets passed on to the customer. So, when the picture upload takes place, the fact of the customer’s roaming status must be passed to the MMSC so that it can be included in the EDR. Now it’s getting a little difficult.
New picture notification to MMS phone. The recipient phone won’t have a constant packet data connection to the MMSC. This means that the phone has to be notified that a new picture has arrived so that it can establish a connection. That notification is typically WAP Push, which I think of as a special kind of SMS.
That’s pretty simple because I ignored the possibility that the receiving phone is not capable of MMS, for now. There is a non-protocol complexity that I will slip in here though. The device cannot necessarily go ahead and download the picture without user confirmation. There are a couple of reasons for this.
First, with the technology in its infancy, it’s not known if people would generally break the Don’t Be That Guy rule. Here, That Guy would reason: I know your phone number, now I can send you pictures of my genitals, yay.
Second, when the phone is being made, its manufacturer cannot guarantee that the eventual end user will not be charged to download a received picture. Like uploading, downloading requires a packet data bearer, and operators typically charge their customers for those. So the manufacturer has to make the phone display a warning, you may be charged, and offer the user the option.
The impact of the above complexity on the user experience is that the recipient has to accept the picture message, and must then wait until it has been downloaded before they can view it. The end user has to do two actions instead of a single action, which roughly equates to the user experience being half as good. Also, the end user has to wait, which roughly equates to another halving.
The engineers that designed MMS probably thought that would be an acceptable price to pay for staying in control. But every real user will set their phone to download every inbound message automatically, if they can.
Picture download on identical phone. Pretty easy, just needs a packet data connection. Although, see Picture upload, above.
So the simplest possible use case is Upload, Notify, Download. Now read on…
Picture download on a different phone. Meaning a different make or model of phone to that used to upload the picture. Meaning a phone with a different screen size. Or different screen resolution. Meaning a phone with different image format support because, no, it wasn’t all JPEG in those days. Meaning a phone with a different number of bits per pixel, or we may have called it palette or colour depth. Meaning a phone with a different maximum file size for image data. In summary, meaning a phone with different photo display capabilities.
One approach would be to say “tough” to the recipient; this service only works between identical phones. This also means saying “tough” to the sender, who is being charged because the upload, a separate event, was successful. I’ll discuss how wrong that approach is later in this piece. For now let’s just say that it doesn’t lay well with the operator’s responsibility to those whom it charges. This means that the differences between the sender’s and recipient’s phones must be reconciled. How?
How can a 40Kb image be displayed on a 20Kb maximum phone? How can a 24-bit colour depth image be displayed on a 16-bit deep phone? How can a 320 by 140 image be displayed on a 200 by 200 phone screen? The answer to all of these, and other combinations, is called: Transcoding. This means scaling, cropping and flattening an image to fit the display capabilities of the target phone. And since the target phone could be little more than a candy bar with buttons, the transcoding computation takes place in the MMSC.
One approach would be for the receiving phone to include its image display capabilities in its download request to the MMSC. Then the MMSC could transcode the image, whose characteristics it knows, so that it would be displayable on the receiving phone. Well, that’s not how it went down.
Instead of sending a list of capabilities, the phone sends only its make and model. The MMSC then looks this up in a database of phones and their display capabilities. Knowing the capabilities from the database, the MMSC can transcode the image, as above. But there is a problem with this approach.
The MMSC can only transcode for phones that are in its database. And the transcoding will only be correct when the database is correct. So the database has to be maintained, by the operator, with information about phone capabilities. This should not be restricted to the capabilities of phones that the operator sells, since their customers may pop their SIMs in any phone they like.
New picture notification to non-MMS phone. These were also known as legacy phones. In a way, this is in the same area as transcoding for different phone capability. Consider a phone that cannot display pictures (yes, we used to have those), or does not support those yummy mm-protocols. No MMS could be considered an image-display capability, in the same way that atheism could be considered a religion.
Unfortunately, this approach is impossible. The phone would need to contact the MMSC in order to inform it of its make and model. That contact would itself require MMS protocols, which the phone doesn’t have.
The say-tough approach also doesn’t work for this use case, for the same reasons as it doesn’t for the Picture download to a different phone use case. The upload was successful and that customer has been charged.
What kind of works is to use the account instead of the phone. The MMSC has the phone number (MSISDN) of the recipient. The MSISDN could be looked up in a list of customers that have subscribed to MMS. An assumption could then be made that only MMS subscribers have MMS phones. Therefore any MMS message to an MSISDN that is not on the MMS subscriber list will be received on a legacy device. This is close to the approach used at the operator at which I worked, although they added a robust twist.
Every time an MMS message was uploaded from a phone, the MMSC added the MSISDN of the phone* to a list. This list of uploaders was then used to identify which recipients were legacy. Messages to MSISDNs on the list of uploaders were delivered as MMS. Messages to MSISDNs not on the list were delivered as legacy, non-MMS.
(*OK, the MSISDN only strictly belongs to the phone on CDMA networks. For the rest of us, it strictly belongs to the HLR entry associated with the IMSI on the SIM card. Luckily very few people need to understand that, me included.)
Unfortunately, this allows the following scenario: Customer buys an MMS phone, expensive at the time; Customer subscribes to MMS; Customer is sent an MMS message by their pal; Customer receives it as legacy, even though they have the phone and the service. That’s a pretty poor user experience. It could be explained to the customer at point-of-sale that they must send an MMS message before they can receive. Well, it could be if the operator had invested in the point-of-sale staff.
Anecdotally, at one point after the service was live, a senior marketing man from the operator where I worked went into one of our own retail outlets to buy an MMS phone. The staff didn’t even know what MMS was and told him that our network didn’t offer the service.
Anecdotes aside, identifying the need for non-MMS delivery is all very well but this begs the question: How? How can an uploaded picture be made available to a non-MMS recipient?
The solution at the operator at which I worked was for the MMSC to host a website on which uploaded pictures could be displayed. Then the recipient was sent, by SMS, the URL of the picture’s page and a password. It’s a little cumbersome but it does fulfil the operator’s responsibility to make the picture available to the recipient, having charged the sender.
(Obliquely, I think few purist designers would countenance such a UI. This is because purist designers have lost sight of the fact that usability is not the only requirement. For example, in this case the operator has a requirement that they are not shut down by the regulator.)
New picture notification on other operator’s phone. Yes, all the above applies when both phones are on the same mobile network. What should happen when the recipient is on a different network to the sender?
Once again the say-tough approach needs to be kicked out, and quite hard. Several paragraphs hard, in fact.
In this case say-tough would mean only delivering MMS messages to other customers of the same network. This is called “on-net” in mobile parlance, the opposite being “off-net”. This is a gigantically wrong way to offer new services, which is to say that mobile operator marketing people think of doing it no more than twice a year.
This is wrong, firstly, because of mobile number portability (MNP). This is the process whereby you can take your phone number from one operator to another when you change provider. MNP is good for you overall, but has the side effect that you cannot instantly know which phone numbers are on the same network as you. (Operators buy ranges of mobile numbers from the regulator. Before MNP, that transaction was taken to mean that the operator then owned the number.)
Any new service, like MMS was, is naturally beset by uncertainty. If you don’t know whether somebody can receive the picture you just took, that increases the uncertainty. If the uncertainty of a service stacks up higher than the certainty that you will be charged for the service, the service fails.
Launching a service on-net piles layers in the uncertainty stack; but there’s more wrong with it than that. There is a whole wrong analysis that leads to launching on-net only services. The wrong analysis goes something like this, in the heads of marketing:
“The service is awesome. The service only works between our customers. Subscribers will want to use the service with their friends, because it’s awesome. But subscribers will be unable to use the service unless their friends are also our customers. The service’s subscribers will solve that problem by persuading their friends to become our customers. It’s like the service’s subscribers become unpaid sales people, churning their friends onto our network.”
The obvious error is that no service is so awesome that a person will go through the pain of signing to a new operator purely in order to use the service. At least, no service that can be provided legally and on a phone.
There is a less obvious error as well, in the first sentence. No service is awesome to a person until they’ve used it. So if they can’t use it because their friends aren’t on the same network, or if they don’t use it because they are uncertain whether their friends are on the same network, the service never becomes awesome. Even if a service is awesome between subscribers, the service fails if it does not provide enough utility between a subscriber and non-subscribers.
This would also apply to a service that required users to have identical phones.
So the service must work when the sender is on Network A, but the recipient is on Network B. Question is: Should it work like Network A’s service or like Network B’s service? Should Network A deliver the picture directly to the recipient, which is how SMS goes, or should they post the message via Network B?
Well, the specific solution described above for the New picture notification on non-MMS phone use case wouldn’t actually work for off-net phones, since they would never have sent a message through Network A’s MMSC. More generally, both networks will have made a number of decisions in implementing MMS, based on what they believe to be the best for their customers. Network B wants their customers to get the service implemented by Network B, not the service implemented by Network A. Which means that the answer to the original question is: MMS messages must be delivered via the recipient’s network, and not directly from the sender’s network. In mobile technology, this is called interworking or sometimes interconnect.
(I have the impression that the terms interworking and interconnect are not interchangeable but I don’t have a clear rule about when to use which. There’s been a lot of text under this sub-heading so I’m putting in a new one.)
Interworking. There are at least two MM protocols for Interworking. There is at least one for outbound connections, which is my customers sending to yours. There is at least one more for inbound, which is my customers receiving from yours. Standard protocols are needed because we might have purchased our MMSCs from different vendors.
The easy interworking case works as follows: Network A customer uploads a message for a Network B customer, the Network A MMSC passes the message to the Network B MMSC, which then causes the recipient’s phone to retrieve the message (or not, see above). After that, comes the interworking charge.
In the above case, Network B charges Network A. Why? Because Network B resources were consumed, in effect, by Network A’s customer. This is pretty standard stuff for phone operators, both mobile and landline. Here’s how they work it, at least outside the US.
The network from which the call was dialled is known as the originating network. The network where the call is answered is known as the terminating network. The terminating operator charges the originating operator for their use of the terminating network. The originating operator charges their customer.
(Obliquely, you can get into kind of a Strange Loop trying to make money on interconnect charges. If all consumers were equal, it would always be a zero-sum game: If you have a lot of customers, you expect to pay a lot of outbound off-net termination fees, but also to charge a lot of inbound off-net termination fees. To be in profit on interconnect then, your customers have to be net receivers of off-net calls. This means that you want them not to make calls. But to be in profit on non-interconnect activity, you want them to make lots of calls.)
I don’t know, but the US may be different. Why? Because over there, operators charge their customers to receive calls. Hence there is no need to charge the originating operator for use of the terminating network – the called customer pays for that instead.
Back to MMS, we have now added a couple of new reporting streams: Inbound off-net and Outbound off-net. At the end of the month, Network A totals MMS messages received from Network B, and deducts messages passed to Network B. If positive, the difference is the number of messages for which they will charge Network B. If negative, it is the number of messages for which they will pay Network B. Network B makes the same calculations and both hope they come up with the same numbers. The rate at which they will charge these messages is written in the interworking contract.
That’s right, not only must there be a physical arrangement to get the electronic data from one MMSC to another, there must also be a legal arrangement. And yes, that is between every different pair of operators. If there were four operators, there would be six contracts. (Work it out: 1&2, 1&3, 1&4, 2&3, 2&4, 3&4.) That’s not too bad until the larger and more customer-focussed Mobile Virtual Network Operators, such as Virgin Mobile, get their own MMSCs, even though they don’t have their own physical networks. Yes, you can do that. Some value-added service (VAS) providers did the same thing.
(Eventually, a kind of MMS interworking clearing house emerged, as I recall. That could have helped a great deal except the clearing house still charged different rates for termination on different networks. So all the same charge calculations had to be made. Great.)
In the UK at least, there was another level of complexity to MNP. Suppose an operator’s MMSC has a message to a recipient phone number (MSISDN). First, it checks if the MSISDN belongs to one of its own operator’s customers. If the MSISDN doesn’t belong to one of its own, the MMSC needs an authority that can tell it the operator to which the MSISDN does belong. The obvious candidate is the operator that originally purchased the number from the regulator. That operator could track the movement of the customer, and hence know which operator is current for the MSISDN. Then, that original operator could expose the information to all other operators.
I understand that in other European countries this is indeed the system that was in place. Also, this may now be in place in the UK, although it was not at the time MMS was being launched.
(For MMS, a solution might have been for the MMSCs to keep passing the message around until it landed with the operator of the customer. Might have, but the MM protocols didn’t support that.)
In the UK, there was a third party, in fact BT, that was the authority on which was the current operator for an MSISDN. Why? Either the operators didn’t trust each other to expose the data, or the regulator loved BT too much. Whatever the reason, as well as the interworking data connection, and the interworking commercials, a link to BT also had to be implemented.
That must be all the use cases? Well, no…
Additional use cases
Picture upload by grey-listed phone. Blacklisting is simple, if politically incorrect. If you are on the MMS blacklist, you can’t send or receive MMS messages. Grey-listing is different.
If you are grey-listed, you can use the service, but every message you send is also forwarded to the authorities. It’s for gathering evidence against paedophiles and other criminals. If you are an operator, your license requires that you offer this, and other police liaison capabilities.
Picture sent by e-mail. Yup, MMS allows messages to be sent to e-mail addresses, as well as phone numbers. At face value, that’s easily handled. The MMSC gets another MM protocol that is plumbed in to an e-mail gateway. The MMSC may or may not transcode messages towards the e-mail gateway; it has transcoding capability anyway. There is a problem though.
What if an e-mail recipient replies? Now, if a phone number recipient replies, the operator will charge them at their phone number (or charge their operator an interworking fee). But since e-mail is free, there is nobody to charge.
Here it seems the operator finally can justify saying “tough” to the customer. The sender cannot be charged, so the sender cannot pay, and the sender therefore cannot use my resources to deliver their message. This is Engineering logic.
Marketing logic says, if the recipient cannot reply then the conversation ends after one message. That means we only billed for one message. If the recipient was allowed to reply for free, then the original sender (whom we can charge) may continue the conversation.
Once again, marketing and user experience argues against saying “tough” to the customer. Well, one of the competitors of my then employer didn’t say “tough”, they said “one”. In full: they would deliver one reply from an e-mail address to a phone number. My employer followed suit, I believe.
Video messaging. There is no such thing as video messaging. There is no such thing as Picture Messaging either, even though the service was called that, by me for example.
Multimedia Messaging supports the inclusion of a number of message parts. Each message part has something like a MIME type. They can be pretty much anything, even plain text.
Of course this means that all the above descriptions about phone capabilities and transcoding are simplified. The true sequence involves transcoding each part of a message. The parts could all be different types; some might not be supported by the recipient phone.
(One manufacturer made a phone that supported slide shows of images. Presumably they thought it would be so awesome that everybody else would buy the same phone, just so they could get the slide shows.)
So video messaging is in principle the same thing as picture messaging. But only in principle. Outside of principle, the problem is that there is no single dominant format for video. Furthermore, the technology seems to be shot through with proprietary technologies. Video messaging, specifically, is therefore a giant transcoding headache.
New user is an important use case to get right, and boy did the networks not. It’s all because of “Provisioning”. I suppose that is not a word in common usage outside the mobile phone industry.
Provisioning means allocating network resources to users; provisioning also means granting users access to network resources. Network resources include voicemail mailboxes, access point nodes (APNs), fancy types of bearer (for example: high-speed data), ordinary types of bearer (for example: voice), home location register (HLR) entries, and much more besides.
Using the approach described above in the New picture notification to non-MMS phone use case, provisioning seems unnecessary. When the phone contacts the MMSC, it is automatically provisioned. Yes, except the phone has to be able to contact the MMSC, which requires an APN, and packet data bearer. The APN and bearer do have to be provisioned.
How provisioning works: The customer subscribes to a package; The customer care and billing (CCB) system adds the package to the customer’s account; The CCB system triggers provisioning of whatever is need to support the package, onto the Network.
(You may ask why there is a division between CCB and Network. One reason is that the Network needs to have an uptime of 99.99% or even 99.999% for some platforms. CCB, and IT systems need only 99.7% or so, which represents 30 minutes downtime a week.)
How provisioning fails: Network systems process provisioning service orders very slowly. I was once told that an HLR can take eight minutes to process a service order. It doesn’t seem like a long time, until there are 3,000 to do because of a product launch. The HLR: Good at staying up, not good at changing fast.
The result is that provisioning often takes so long that it appears to have failed.
A breakfast television programme did a feature on MMS. It was when all the operators were launching their MMS services. In the programme, the presenters tried to use the MMS service of each of the operators. In all cases, they were unable to get past the set-up stage, so not a single MMS message was sent.
Could the operators have avoided the inevitable provisioning bottleneck?
Anti-provisioning might have been a solution. Anti-provisioning of a capability means that customers get access by default. Then a service order is only necessary in case access has to be blocked. This is a pretty radical solution, and technically not on the board, certainly at the operator where I worked.
A soft launch might also have worked. The operators could have switched on the service without plugging in the billing end. Then it would have been free, yes free, for an initial period. They could have provisioned new users at a rate that did not overpower the infrastructure or the MMSC. They could also have observed the system and spotted the problems and bottlenecks. The initial users might experience a pretty rough and ready level of service, but they ain’t paying so they ain’t complaining (this was before web 2.0). Prior to the hard launch, all the problems and bottlenecks would have to be cleared.
There are a number of factors that place soft launch off the board.
First, the regulator doesn’t like vagueness. In my experience, which I admit is limited, the regulator is staffed by civil servants, not software developers, not technologists. Back when I was working at an operator, Ofcom were still using triple-carbon paper to write reports and their staff did not have access to “external” e-mail. Could they have understood why it might be OK to give away a service that doesn’t work too well so that you can monitor it? No. Why can’t you just finish the service and then launch it and start charging for it? Because it’s not a toaster.
Second, our Marketing department wanted us to own MMS. In this context, owning means everybody associating the service with us as an operator. Head & Shoulders used to own anti-dandruff shampoo. When people saw an advert for another anti-dandruff shampoo, they thought they were watching an advert for Head & Shoulders. To own a service, you must launch first, and launch best. You must also be first and best by a wide margin.
But soft launch requires patience. Marketing have even less patience than they have honesty. They don’t just want to own MMS, they want to own it now. So the urge to own is incompatible with soft launch. Also, the first launched MMS service would be only marginally more useful than the first launched telephone, see above under awesome.
(By the way, soft launch was, at one time, an option for putting new SMSCs on line, especially those of a new architecture or vendor. The engineers would plug in the SMSC, then leak its number. Those users in the know would enter the number in their phone’s messaging settings. The users got free SMS for a limited period; the engineers got free testing. Once the SMSC had been proved, it would be plumbed into the billing infrastructure.)
OK, that really is all the use cases. Conclusions are overdue
Conclusions
Multimedia Messaging is a technology that challenged the mobile network operators. The challenge was fought on a number of fronts: commercial, organisational and technical. I think we can say that the operators were not equal to the challenge. MMS failed at launch.
But did it subsequently succeed? Well, MMS at least survived. I expect every operator still has an MMSC. The operators did eventually get the finer points right, like legacy support, transcoding and reply by e-mail. I know people who use MMS all the time. But I personally have never yet used MMS, which means I probably never will.
By the time I got into the concept of sending pictures from my phone, I already had mobile e-mail. I would bet that many more pictures are taken using camera phones than are sent using MMS. That for me is a measure of the operators’ failure.
And finally, an old maxim states: A picture is worth a thousand words. By my calculation, a thousand words is 31.25 text messages. Be thankful that the maxim was not adhered to when the MMS tariffs were set.
More operator opprobrium next time…
Copyright © Jim Hawkins, 2009
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
Original post here:
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
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
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
Conclusion
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