Love the Fear

Lies, Damned Lies & Mobile Statistics

2010-09-16T05:25:00.000-07:00

The mobile industry is one of many which seems utterly obsessed with statistics. It doesn't matter what they are about, someone will horribly abuse them to make a point. There are plenty of statistics which show that Apple has an absolutely unassailable market position, just as there are plenty which show that Apple has a relative low market penetration. You can use these however you want to justify any position you wish to take. The problem is that it can be very difficult to see through ill-conceived headlines and soundbites.

In the past week, I've been confronted with statistics which just didn't seem to add up. Firstly on Twitter, Ewan MacLeod retweeted (original Tweet by Ken Shimada) this message:
http://twitter.com/kei_shimada/status/24344277211

on iPhone: BCN reports that 22.6% of July mobile handset sales were Smartphones. 80% of them were iOS based, and the remaining were Android.

I was surprised by this. We all know that iPhone and Android sell well, but they're not the only players, and frankly I don't believe that RIM and Nokia each only sell such a small amount as to be negligible in the stats. I replied with:

http://twitter.com/rival/status/24361145816

@kei_shimada @ew4n There were no BlackBerry sales? My Mobile magazine keeps telling me that BB Bold and Curve top contract lists

This is true. I get Mobile Magazine through the post every fortnight. Each issue contains a breakdown of UK retails sales for the previous week, both prepay and postpay. Postpay top ten is always dominated by RIM, and they often feature in Prepay. Prepay is dominated by cheap Nokias. I've never seen Apple on this list, not once. Actually, I don't necessarily read every issue, but I have still never seen Apple in the UK top ten retailing handsets, and it isn't even as if their sales are divided across a wide range of phones. I know that this is UK only data, but what I've heard anecdotally is that Apple sells lots of phones, but they're still not on the list. There is some back and forth between Ewan and myself, and then I get a reply from Ken.

http://twitter.com/kei_shimada/status/24362041581

@rival @ew4n these are Japanese stats.

OK, so now we're getting somewhere. There are two problems becoming clearer to me. Firstly, that Twitter encourages us to just write down the bare bones of what we want to say. We don't have the space to write a lot of qualification for statistics. Secondly that people will easily bend stats without explanation. Ken followed this up with:

http://twitter.com/kei_shimada/status/24362075883

@rival @ew4n read carefully, nobody said market share.

No, nobody did say market share, but the did start talking about shipping numbers. Now that I know I'm not comparing worldwide sales and UK sales, it starts to make more sense.

Ken then sent this absolute classic:

http://twitter.com/kei_shimada/status/24362303718

@rival @ew4n not all stats are bullshit if you understand what they mean :-)

That is my point. Stats are obviously not bullshit if we understand what they mean, the problem is that stats are being banded about without any qualification. Without even mentioning which market the stats we're for. Without any visibility of the underlying data allowing independent analysis. Stats like this are bullshit. They don't aid anyone in understanding a market, they are distortions of the truth.

Anyway, yesterday I found this blog on TechCrunch (yeah, I know, its my own fault).

http://techcrunch.com/2010/09/15/will-microsoft-and-nokia-team-up-to-take-on-apple-google/

Apart from the immediate nonsense of it, it has this to say.

Nokia’s stock has been hammered by its failure to gain real traction in the high-end segment. Its US listed shares have tumbled to just under $10 a share as of Wednesday morning trading— from an all-time high of more than $60 back in June 2000. Furthermore, although Nokia proudly waves the number “260,000,” the number of Nokia smartphones sold per day according to the company, the figure distorts reality.
Nokia is scrambling to defend its market share. On the high-end it’s dwarfed by RIM, Google and Apple in the United States— Symbian only captured 2% of the smartphone market in the first quarter, according to Nielsen.

The figure only distorts reality if your reality only exists in the United States. What Evelyn Rusli is saying here is that it doesn't matter that Nokia shifts 260,000 smartphones (not feature phones) each day, but that they only have 2% market share in the United States. Yeah Evelyn, the rest of the world are just wrong and will come around to the American way of thinking.

Gartner has a more complete view of the worldwide smartphone market. See Table 2 here http://www.gartner.com/it/page.jsp?id=1372013

Table 2
Worldwide Smartphone Sales to End Users by Operating System in 1Q10 (Thousands of Units)

Company	1Q10 Units	1Q10 Market Share (%)	1Q09 Units	1Q09 Market Share (%)
Symbian	24,069.8	44.3	17,825.3	48.8
Research In Motion	10,552.6	19.4	7,533.6	20.6
iPhone OS	8,359.7	15.4	3,848.1	10.5
Android	5,214.7	9.6	575.3	1.6
Microsoft Windows Mobile	3,706.0	6.8	3,738.7	10.2
Linux	1,993.9	3.7	2,540.5	7.0
Other OSs	404.8	0.7	445.9	1.2
Total	54,301.4	100.0	36,507.4	100.0

So, now we can see a much better picture. We have actual data, not stupid headlines, not misleading quotes. Worldwide, Nokia is in decline, but it still is by far the largest supplier of smartphones, selling just about as many handsets as iOS, Android and RIM put together.

Now, compare and contrast these three statements:

on iPhone: BCN reports that 22.6% of July mobile handset sales were Smartphones. 80% of them were iOS based, and the remaining were Android

Furthermore, although Nokia proudly waves the number “260,000,” the number of Nokia smartphones sold per day according to the company, the figure distorts reality.

Nokia is scrambling to defend its market share. On the high-end it’s dwarfed by RIM, Google and Apple in the United States— Symbian only captured 2% of the smartphone market in the first quarter, according to Nielsen.

Nokia is with world's leading manufacturer, selling 260,000 smartphones worldwide each day.

Lies, damned lies and statistics. I once had an argument with someone who responded with "Facts? Don't give me facts. You can prove anything with facts." That stopped me in my tracks, but I now think it may be a quote from something. At the time I thought that the person was an irrational fool, but every day I'm coming round more and more to that point of view.

Reasons why 2010 is the year of mobile in travel

2010-04-23T06:27:00.001-07:00

I've just read Timothy O'Neil-Dunne's essay on why 2010 is not the year of mobile in travel. He has made several well reasoned arguments, most of which we've already thought of and addressed with the Datilo for Travel software. Disclosure: I work for Datilo Limited.

Let's run down his arguments, with my personal response to each issue.

"1. Platforms – the splintering of the platforms is far greater than in the PC based world and even within application platform there are so many splinter forms that the consistency of the user experience is FAR less. There are also radical differences between platform types. For example, the iPhone and the Blackberry have really different UI/UE. Good news is that 80% is concentrated onto three platforms Android, iPhone and Blackberry."

Wow - well obviously I agree with him. This is why Datilo was developed with MoSync - a cross-platform tool for mobile applications. This is why Datilo supports Symbian S60, Windows Mobile, Android, J2ME and Moblin. We'll have Blackberry very soon, and possibly iPhone if we can get through Apple's processes.

"2. 234 million people in the USA used a mobile device in December 2009, according to Comscore. However, only 47 million smart phones were shipped, with the number of Smartphones in actual operation estimated at 65 million vs 308 million people in the USA."

Yeah, and add on the same again just in India alone. Datilo for Travel isn't just for Smartphones. This is part of what we do - championing the 'feature phone', and demonstrating the 90% of Smartphone apps work just as well on much cheaper hardware.

"3. The variations in performance mean that for the vast majority of time (and this will not change in the near future) the performance of the UI due to vagaries in the network performance mean that the impatient user will often have to wait minutes for a response – similar to comparing dial up with broadband. These are theoretical speeds – I am talking about real world experience when trying to access information."

Yeah, again I agree. This is why Datilo for Travel (and all Datilo apps) are made to run primarily offline. The app downloads the small packet of data (often less than 100k) which is required for that user. They can then access this when they need to and only connect when required. More on this later.

"4. Connection breaks – you have to recover the connection and start over…. You know what I mean."

I do know what you mean Timothy, and as I've written above it is something we've directly addressed.

"5. Consistent mobile broadband speeds mean that the amount of time when a smart phone is able to actually obtain acceptable signal/performance to operate will come down significantly – we estimate that this number exceeds 40% of the time – this is based on my own experience."

Hmm, I find it better than this - maybe this is just a North American experience. I think that we've got better connections in Europe. I've just come back from the Pyrenees, and even up a mountain in France I got an HSPDA connection. Still, if you're app runs offline...

"6. Physical window aperture on the device – i.e. the ability to view the application on the screen."

So this is a UI question, and possibly in to make up the numbers. Mobile phones have small screens, and always will do by definition. If you just want the number of your hotel though, a small screen works well.

"7. Vision impairment – yes, this is a big deal. According to the Vision Council of America, approximately 75% of adults use some sort of vision correction. About 64% of them wear eyeglasses, and about 11% wear contact lenses, either exclusively, or with glasses. Over half of all women and about 42% of men wear glasses. Similarly, more women than men, 18% and 14% respectively, wear contacts. Of those who use both contacts and eyeglasses, 62% wear contact lenses more often."

OK - Got me there. I've not thought about this enough. Expect changes in the next version. I wear glasses myself, but for those users with very bad vision, we can improve our app.

"8. Dexterity impairment, juggling impairment."

I'm not too clear what you mean here. If you mean that touchscreen smartphones aren't as easy to use and some people make out, then I completely agree with you. However, we leave the choice of device to the customers.

"9. And last, by no means least, THE HIGH COST OF ROAMING. At the recent Tnooz #tcamp3 event in Berlin, I described the iPhone as the devil incarnate. For the next few years – until our favorite EU commissioner Nelly Kroes gets her way AND such moves to reduce charges are adopted by other countries – this will be the biggest impediment to adoption of travel apps."

Yep - its extortionate isn't it? What you need is an app where you can download your data on your home network, and take it abroad with you. If you need to update it, you can do so on your terms, and download a compressed packet with all your data in it, not surf until you get what you're looking for, and paying for all the data you don't want.

Finally, we get to

"So fighting through the clutter is not easy.
What now becomes a characteristic is that there is no clear portal for mobile apps. The major portals of the web, going back to the early days, were the search engines and early value-added apps – eBay, Expedia et al."

This is why we produce apps for businesses. Our customers can distribute their app to their customers. No looking around or finding misleading software.

Timothy, we'd love to have a more detailed conversation with you about this 8-).

Great use of social mobile media

2010-04-21T03:18:00.000-07:00

So I'm trapped, trapped I tell you, in the south of France. I'm having to put up with 25c of brilliant sunshine, blue skies, cheap wine and Golden Virginia at €7 for 40g. Ahh.

We were hoping to fly back today. When I got up everything looked right. The UK and France have reopened airspace and airports, my flight was after 1pm, and the BA website said it was on. By the time my wife got up, the flight was cancelled, and it looked like we were going to have to drive back with a three year old after all.

I got onto the phone to BA, but I kept getting cut off. The queue was absolutely full. So whilst I'm redialling on the landline, I get my mobe out. This is the twitter message I sent

Ahhhgghh. Flight has just been cancelled. Just get engaged tone from BA I can't even get in the queue.

About ten minutes later I read this

@rival It will take a while to update on ba.com but you'll be able 2 make your changes on Manage My Booking (if you booked directly with us)

Nice! Even though I can't speak to them, I'm getting some response. Even if it isn't very helpful.

@British_Airways The update booking option is greyed out for me.

Less than one minute later comes the reply

@rival If you booked through a travel agent, they will have to make the changes otherwise, you'll need to call us UK - 0800 727 800

Hmm, that's actually a different number. I try it, and I'm able to join the queue. So while I'm waiting, I read this:

We expect to run flights to all of our longhaul destinations today from Heathrow & Gatwick and our shorthaul services will resume after 1pm

"So why is my flight cancelled?" I think.

@British_Airways So why is my 18:05 flight cancelled?

We still have a large no. of aircraft, pilots & cabin crew out of position,we're working around the clock to minimise any further disruption

Good answer

@British_Airways Yeah, I understand. Thanks.

Jack comes to find out what is going on, so I tell him that I'm talking to the pilot on Twitter. He wants to talk to him as well.

@British_Airways Jack (aged 3) asks "is it because of the voocano?"

Now the thing is, that this is a typo, not Jack having difficulty saying 'volcano'. Anyway.

@rival :) Thank you for sharing Jack's new word.

Wow, they're really putting a human face on a big corporation. Finally get through, only 45 minutes. I genuinely think that is alright, considering.

@British_Airways Wonderful talking to Kelly now. Rebooked for tomorrow. Well done BA! Very relieved I didn't book Ryanair

I even get a retweet along the way from @JamesMerrimanUK along the way.

I think that really highlights some of the ways that mobile social networking has evolved. Its really helped me understand BA's problems and to understand that they're just people too. Thanks BA,

o2Litmus Live Roadmapping

2009-04-29T14:28:00.000-07:00

So I was at the o2litmus live roadmapping session yesterday. Kind of interesting - some good ideas, but a lot of people there not really interacting.

Anyway, there were a couple of points I've developed in esprit de l'escalier.

Firstly, there was a lot of questions from o2 about the kinds of device APIs that developers want o2 to develop. I completely understand the wholly underwhelming response the question got. Being a mobile developer is hard - you've got a lot of different platforms, operating systems and devices your trying to support. Coding for operator APIs is not a priority (even if they are trying to standardise).

With the current challenges, all the problems are in division. I've got my target set of handsets. I divide these up by software platform/os/manufacturer/whatever. This is a really big challenge, but one we're just about able to meet. I take my 500 or so target handsets, and divide them up by these criteria.

Operator APIs are problems of mulitplication. I'm no longer breaking down these 500, but mulitplying it by each operator I'm going to support. My problem is not 'how do I get my code to run under J2ME on a Sony Ericsson W890i?' but 'how do I get my code to run under J2ME on a Sony Ericsson W890i on 02, er and on Orange, and Vodafone while were at it. Oh, and I need in German supporting T-Mobile APIs'. Its too big a problem, so I'll engineer an operator agnostic solution.

The second interesting point (I thought at least) was around questions of security. Again, not a warm response until we started to discuss application signing. I made a point that I'm building 500 different versions of my code, I'm not going to pay for signing as it will completely destroy any economic model I can come up with. Neil seemed to be taken aback by the responses he got.

Application signing is the biggest single business problem in mobile development, and we need to formulate an appropriate response. I understand that o2litmus doesn't require applications to be signed, but to get onto o2active, then they need to protect themselves. This impasse is holding back a lot of innovation and bedroom developers getting their apps to the public. Apple fixed this by having a manual screening process. A real person at Apple looks at each application and checks it for suitable content and malware. If it is OK, then it goes on the app store - no waiting weeks for signing or spending thousands of pounds. We suggested that this would be a great way for o2 to go. I even (rather cruelly) suggested that if they don't do this, then it is just because they can't bothered, which in retrospect was too strong.

What I propose is that I get signed. Approve me, trust me and give me a certificate. I'll sign my apps myself with my certificate, and this will be o2's guarantee of quality. I'm going through the o2litmus program - this means that if my application makes it onto o2active, then hundreds of users have downloaded my application, tested it, and will have reported problems with unsuitable content or function. I don't need to get it signed externally to prove this anymore, the o2litmus community has done this testing already.

The alternative to this is that I produce applications for Symbian S60 only. Nokia have a very large chunk of the handset market, and S60 makes a large proportion of that. I can produce a couple of versions for different screen sizes (maybe just 176x220 and 240x320), get them Symbian signed and onto the Ovi store for 400 million users by the end of next year. This is going to be a much more attractive proposition to me than messing around on a per operator basis.

Twitter is the new messaging bus - very cool

2009-03-31T04:54:00.000-07:00

In a recent blog post I said that I thought that Twitter was the new TCP/IP. What I meant by this is that Twitter is the messaging protocol which provides value to others, making it almost impossible to monetise in its own right.

To back this up, I've spent a few hours knocking up an example. I've built a new bot service which uses Twitter for its inputs and outputs.

GSearch lets you use Twitter to search the Guardian newspaper's archive. To use it, you need to follow 'gsearch'. A few seconds later, it will follow you back (and increase your twitter stock, if nothing else).

To perform a search, simply send a tweet with the hashtag #gsearch and the search terms you want to look for. The bot will read your tweet, take the search terms, search the Guardian's archive, compress the url of the first hit with Bit.ly, and send you a direct message in return. It checks for new messages once a minute, so you should get your message back quite quickly.

The point of this is to demonstate that Twitter is at the same time, enormously valuable yet impossible to monetise. At no point during this service do you have to visit Twitter's site.

This isn't a managed or supported service though - its just running on my PC. If it is off, then its off, but if its on, then I think that it is quite a nice demo of mashing up applications using Twitter as the messaging bus.

The upshot? Perhaps the easist, most compatible mobile interface to the Guardian's web site. Simply use your mobile twitter client of choice, and wait for your search result to come to you.

Let me know what you think

Lies, damned lies and statistics

2009-03-30T06:48:00.000-07:00

Right, I'm not a great fan of the iPhone. This probably stems from my deep hatred of Apple. This posting isn't an anti-iPhone rant - I just wanted to disclose my preference in advance.

About 20 minutes ago, this post went up. It states that the iPhone is only the 24th most popular phone for mobile web browsing, with Nokia taking the bulk of the honours. The problem is that this data is enormously skewed.

The source in from Bango, the mobile payment processing folk. They've collected their statistics by phone model for February 2009 and they've reached this conclusion.

Except this isn't the correct conclusion. The conculsion is that iPhone users don't use Bango very much. Well, this isn't a shock, iPhone users only buy apps from the Apple App Store, they don't go hunting around. They aren't being lead by operator portals for instance.

Why am I angry about this? I don't know, other than bad maths from other bloggers I suppose.

Who should buy Twitter?

2009-03-29T03:24:00.001-07:00

Much has been said about potential buyers for Twitter over the last quarter. Names have been dropped online as dead certs, and many different blogs give different reason as to why Corporation X should empty their wallets.

The Motley Fool recently published their take on why Google should buy Twitter. They've even predicted that it'll happen before the end of March 2009. Waaayy back in October 2007, SmoothSpan blog was urging RIM to get in and buy it before it got too expensive.

So, which player do I think has been discounted in all the predictions? Is it the same player to whom Twitter would represent the most value? I think so, and I think it is Microsoft.

Microsoft have poured billions into their online services, and are still a bit player. Almost all of their services have a more popular version elsewhere. The latest incarnation of Microsoft's online services, Microsoft Live is actually quite good, but its usage seems to lag behind competitors (notably Google) in almost every respect (figures are hard to obtain, but Hotmail might still outstrip GMail in numbers of accounts).

Twitter has a problem. No, not that one. Twitters problem isn't that it is overcrowded and the servers keep running out of capacity. Twitters problem isn't actually that it isn't making any money. Twitters problem is that it lies at the bottom of the food chain.

Look at the number of services which have launched since Twitter started, based off Twitter. And not just the client applications or search engines. Applications like twanswers are able to sit higher up in the food chain, and have a great opportunity to make money, but it is Twitter which is spending the money creating the enviroment/platform/ecosystem (delete according to preference) which makes the twanswers service work.

The same goes for Blellow. It provides a useful and simple function - Twitter Groups - helping you sort out the million tweets in your feed. Again, there is great potential for making money, without the expense of running the infrastructure (technical and social) behind it.

So look again at Microsoft. What Microsoft is lacking is critical mass. The apps are fine, the brand is well known, the uptake is rubbish. When was the last time you logged into Live, if ever? If Microsoft buy Twitter, then they are buying millions of Twitter users, and getting them to stick their noses into Microsoft online portfolio.

The traditional argument against Microsoft as a purchaser of Twitter is that Microsoft won't buy it without a plan for profitability. My argument is the complete reverse. Microsoft are the only people who will buy it without a plan for profitability. Twitter is the loss-leader which could kick-start Microsoft's portfolio back into life. Google won't buy it, despite what anyone else says* because they have got a plan for profitability for Twitter. There is only one way to actually monetise Twitter, and that is to inject adverts into your feeds. Google could do that day one. Twitter could do that today as well. The reason that Twitter haven't done that is because that signals the instant death of Twitter. Twitter isn't technically sophisticated. Actually, more or less any script kiddy could put together a Twitter clone in a few hours. If Twitter starts serving up ads in your feeds, someone else will do a better, cooler Twitter and everyone will jump ship in an instant.

Twitter needs to find a buyer, we can all see that. Microsoft are the only player with the financial clout, the need to buy the user-base, and are the only ones who will not destroy the service, but see it for what it is - the new TCP/IP. Twitter is the protocol which transfers data between applications. Ok - so susbsitute 'applications' for 'users', and 'data' for 'ideas' and this makes sense. Twitters future isn't necessarily sending stupid messages to your mates, it is a general communication process, like enterprise busses for the majority. But that is another blog for another day.

* I could look really stupid if you're reading this in the future, and Google have just announced that they've bought Twitter for $100 billion. If they have, stop using Twitter because it is about to become rubbish.

Building super fast, super portable mobile maps - Part Three - Making it super fast!

2009-03-20T05:34:00.000-07:00

So, my maps are scrolling around my mobile screen really nicely. I'm jealous of how fast GMM is, and I can't see how they've got it so fast.

Jaak Leineste again had the solution, in this post

" We have solved it with the Mgmaps lib SDK and CloudMade tiles this way, that we set up own "tile streaming" server to AWS EC2, so it has superfast connection to CM tile server, and I am doing the tile proxying there just like you describe. I must admit that I got also some inspiration from the google's mobile maps app :). You can compare different map reading options, direct 64x64 tiles or the multi-tile requests (we call it "streamed") with on-line web runner demo at http://www.nutiteq.com/libsamples.html#BasicMapperapplication . Start the app from web (it starts microemulator automatically), you see performance with default map, which is CM 64-pixel individual tiles. Select Menu > Change map > select CloudMade streaming (via Nutiteq) and see speed then. Difference is quite big, to say the least. Not worse than with google maps mobile."

So this is the secret to super-fast mapping - you have a webservice which fetches tiles for you and concatenates them into a single download. You then pull them out of the stream. The reason the old method is slow isn't because of the speed of my connection on my mobile, its the latency in setting up the http request. If I've got fewer requests, then I've got a faster map.

My problem was that the MoSync image downloader doesn't provide me access to the stream. It just gives me a formatted PNG image I can display. I needed to write my own downloader.

MoSync does provide access to their connection object however. With this, I can have direct access to the download screen. So with the help of Niklas and Fredrik at Mobile Sorcery, I wrote my own downloader which would retrieve tiles out of a stream.

I wrote my own streaming service in C#. This takes my API key and the details of the tiles I want from CloudMade. It fetches them in order from the CloudMade server, and returns them back to the requestor, flushing the response stream after each tile so that the client application isn't waiting needlessly.

This has made a massive impact on my mapping component. Previously it would take 30-60 seconds to get all 36 tiles. Now I get all the tiles I need on the screen in < 10 seconds, and all 36 tiles in < 20 seconds. Personally, I think that my component is at least as fast as GMM.

Building super fast, super portable mobile maps - Part Two - Getting Maps onto the Screen

2009-03-20T05:05:00.000-07:00

So, I've got a client who wants mobile maps, and I've got a supplier of map tiles. I've signed up as a developer on CloudMade, got my API key and I can see tiles. Now I've got to get them on screen.

About a 40 years ago (ok, about 25 years ago maybe) I was working out how to get my Acorn Electron to play Chess. I was just hacking around more or less directionlessly, and I fell into a classic programming trap.

My thought process was: "A chessboard. That's an 8x8 grid. So I'll represent the board in memory with a two-dimentional array. 10 DIM BOARD[8,8]". This seems obvious, but it is not the easiest way to implement a grid where you want things to move from one place to another place, and it isn't too quick in implementation. For example, to calculate valid knight's moves becomes fairly complex. If I've got a knight at [2,0] then I need to try permuations of where it can go in both dimensions. If I created a board as a single dimension array (10 DIM BOARD[64]), then I know that valid moves are:

currentLocation + 6, currentLocation + 10, currentLocation + 15, currentLocation + 17 currentLocation - 6, currentLocation -10, currentLocation - 15, currentLocation - 17

provided that the result is between 0 and 64.

Similar decisions are needed when you create a map grid on a mobile phone. So, again I started with an assumption of having a 240x320 screen. If I imagined a grid of 6x6 squares for the map tiles, then that will give me a total grid size of 384x384 - enough to cover the whole screen, plus a margin all around so that when the user scrolls, the tiles are ready. If I create this grid as a single object array[36] then it makes life really easy when it comes to scrolling. More on this later.

So I created a class to represent a MapTile, a marshaller to handle the downloads, and a Widget to put the map on screen. The widget converted the location from the GPS (or location API) into a CloudMade tile reference, and then took this as a basis for calculating the references for all the other tiles.

Each MapTile is responsible for formatting a URL which will get the image from the CloudMade server. It requests a download from the marshaller, and in turn gets its image.

The widget then puts each image on screen as they are downloaded, building the map. It also handles the scrolling, where the smart decision about an array MapTile[36] pay dividends.

To put the map on screen, I need to know which tile is going into the top-left corner. I call this the 'origin tile'. When my map starts this is the tile at MapTileArray[0]. The tile with the actual location I want to see is MapTileArray[14], which is about the middle of the screen. I start by displaying MapTileArray[originTile] top left, and then rip through the array in order, adding 1 MOD 36 to get to the next tile. This means when I get to MapTileArray[35] and want the next tile, I know that the next tile is MapTileArray[0].

I also wanted it to prioritise which tiles to get first. I don't want it to start with the top left tile and work sequentially though. I wanted it to start with the tile which shows the relevant location and spiral out. Initially, I worked on an overly complex algorithm which will calculate the order that the tiles should be downloaded in at runtime. In the end, I got some common-sense together, and just set up the order in code. I add each of these values to the value of the origin tile, MOD 36, and that is the order of the tiles that I want.

If I'd gone with a two dimensional array, then I've got an array I want to reflect on screen. This means that a scrolling operation doesn't mean adding to subtracting either 1 or 6 (depending on the direction of the scroll), but I've got to switch all the tiles into different locations into the array to maintain its reflection of the screen. Massive pain.

So I can scroll my map around nicely, my array is working quickly and easily. Its a lot slower than Google Maps though, and I start to wonder why.

Part Three >>

Building super fast, super portable mobile maps - Part One

2009-03-20T04:20:00.001-07:00

I've spend the last couple of weeks building mapping into one of my projects. It is something I've resisted in the past as being too complicated, too difficult and not offering a lot of value. However, my client wants a location based messaging solution, so maps we're a must have.

My client (who shall remain nameless for now) said that it was easy. His previous partners had done it really quickly; just mash-up Google Maps. The problem is that this is a very web-oriented view of development. Whilst GM are easy to mash-up in a web environment, they aren't licenced for mobile application development. Their API is also Javascript-based, so I wasn't going to be able to use that either.

So the next stop is just to hack it. I found that many people have done this in the past. You just need to know how Google Maps for Mobile (GMM) converts co-ordinates into map tiles, and you can build URLs to get the correct tiles. I also discovered that everyone who had done this had quickly received 'cease-and-desist' letters from Google's lawyers.

So what are the alternatives? Yahoo! Maps are as rigidly licenced as Googles. Microsoft are much more relaxed about accessing their geodata, but they only make tiles for the web.

The issue here is the size of the tile. Let's assume for the sake of argument that the normal size of a mobile screen is 240x320 pixels. The tiles used on the websites are 256x256 pixels, which means that one tile will cover almost the whole screen. If you've only got a 128x128 screen, then you've got something which is way to big, giving the developer the additional headache of working out which bit of this tile needs to be on screen. The main problem here is that this is one download which means a big delay between hitting the button on the phone and seeing the map. GMM has mobile-friendly map tiles sized at 64x64 pixels. This means that I can convert my location to a single 64x64 tile, and centre my screen around this.

So a quick bit of research later brought me to the OpenStreetMaps initiative. This is crowd-sourced geo-data. You go out with your GPS and send data about all the streets in your neighbourhood. This becomes 'open sourced' data. Digging a bit more lead me to CloudMade, the extension of OSM to convert their raw data into useable map tiles.

CloudMade have fantastic support for mobile. Not only do they do their tiles in 256x256 and 64x64 pixel tiles, but they also do their mobile tiles with high-contrast colour schemes. Now they are extending this, so anyone can create custom cartography with their style editor.

Better news seemed to be that Jaak Laineste has developed a J2ME component from his compay Nutiteq. This wraps up all the functionality you need to make your own GMM-clone with maps from CloudMade. This would be a massive short-cut, except that I'm not writing in J2ME; I developing in MoSync.

<digression>

The number one problem with mobile development is that every damn phone is a little bit different. The purpose of Java is that you write your code once, and it will run in an identical fashion on a different platform. The problem with this is that it has never quite been true, and for the Java you've got on your phone, this problem is magnified by a thousand times.

The problem is that you've got one body specifiying the language, and dozens of bodies implementing it. Just as no two people will interpret a book in the same way, no two implementers make J2ME work in exactly the same way.

The upshot of this is that even when you've got your J2ME application working on your phone, there is no guarantee that it will run on anyone else's. Or a Windows Mobile device, or in an S60 environment.

The guys at Mobile Sorcery have taken this pain away. They've written their own API which they've tested on the handsets. The difference with this approach is that it is one body who is managing implementation, massively improving compatibility. You write (or port) your code in C/C++ against their API, and it will build your application for hundreds of phones. Each of your target handsets gets a build specifically for it. On J2ME phones, it builds a J2ME application. On Windows Mobile devices, it builds a Windows application. On S60 devices it builds a Symbian application.

</digression>

Still, even without being able to use Nutiteq's mapping component, I've got a supplier of map tiles.

Part Two >>>

The Three Roadblocks to Mobile Web

2009-03-19T09:10:00.000-07:00

I seem to be giving this talk a lot lately, so I thought I'd pull my finger out and blog something.

Many handsets have had web connections (and actual http/html connections, not just wap) for many years. On some devices its even quite good. But it has never made the penetration into normob psyche that many people predicted. I'm often asked why this is, and why I continue to evangelise on-device portals and applications over mobile web given in availablity of all-you-can-eat data plans.

To illustrate my point, I distilled my thoughts down into what I call 'The Three Roadblocks to Mobile Web'.

So you've built a brilliant mobile web site. Perhaps you've used one of the automated tools to rebuild your main site and represent it to a mobile user. The problem is, you're not getting any hits. What is the problem? Does your content suck? You are getting loads of traffic through traditional routes, but not through mobile. How can you get more people to your site?

1. Having the idea

The number 1 problem with mobile websites, is to get people to have the idea to use their phone to do some web surfer at a convenient moment. I used to use the example of someone waiting on the platform for their train, but Paul Golding recently pointed out to me that the peak time for mobile web use is between 23:00 and 00:00 - when people are in bed. Anyway, you can imagine your ideal user who is idling for a few minutes - now is the perfect time for them to visit your website. The problem here is that even when people are in this situation, even when they're playing with their phone, you've still got to get them to press that Internet button.

There are a lot of people who are scared of this button. There persists an idea that connecting to the web is expensive and unpredictable. Even my wife, who I consider do be reasonably technical, occasionally asks me how long I've been reading that article, like it billed on connection time.

Having an on-device application puts your content in view. If your content has been downloaded and cached to be read offline, then people are much more confortable about starting the app. The fear that you don't know how much it is going to cost to click the next link disappears, and your content icon is one of maybe a dozen application icons on most phones, and not one of a million billion sites.

2. Knowing you exist

So, even if you've got someone in bed doing a bit of late night surfing. How do you get them to browse to your site? Mobile traffic isn't driven in the same way as desktop traffic. You can have all the SEO and tagging and cool tricks in the world, but the fact remains that typing a couple of keywords into that Google box you've got at the top of your browser is very quick and easy, and typing even one keyword into the Google box on your phone is more trouble than you can be bothered with, even if your really interested in the result.

3. Getting to your site

Traffic is driven from operator portals. Your late night surfer is going to see a couple of things on their home screen that catch their eye and click through on those. They're unlikely to go off that. If they can't be bother to search Google from their phone, they're definately not going to type your URL in.

So you spend some money, and you get a keyword on a shortcode. You advertise it, and the auto-responder sends your URL back. And some people even save it. In the list of bookmarks in their browser. Out of sight, out of mind.

So this is why I back on-device applications.

1. It is visible - you've put your icon and your brand literally into the pockets of your readers/customers
2. It is memorable - you're application is now in direct competition for eye-time with your user's browser. You're way up the decision making tree now.
3. It is comfortable. I build ODPs to download and cache data in a controlled way. This isn't necessarily any less data, but it is more predictable for the user. They feel in control, and with off-line browsing there is no fear in pressing the next link.

And if you're thinking of building an app store, then why are you thinking of building it as a website? Put your icon on your customers phone.

I buy a lot of games from GameMobile, but I wish that they'd build their own app so I can browse the latest games comfortably from my phone, rather than on line. I promise you that I for one will be hitting that 'Buy Now' button far more often.

What I've got against NHibernate

2008-10-10T07:49:00.000-07:00

Apart from being another example of too much configuration in XML? Well Billy McCafferty has summed it up for me in his article on CodeProject

Your database should be an "implementation detail" that is defined to support your domain model, not the other way around.

No it shouldn't. This is backwards for all but the largest businesses with lots of DBAs and data warehouses. This is a very arrogant developer argument to make.

It is more important to the business to be able to quickly and accuratly report about the business than to sell one more widget. Getting timely and accurate information about the widgets you've sold is more important. I know of lots of businesses who sold lots of their product and still went bust, owing to poor finanical management. Every business has to be able to manage their cash-flow at least as well as they can sell, and the database should represent this. Programmers can make the program more flexible to fit in with the best design for the business, but database design should be driven by business requirements, not programmers' whimsey.

In many, many cases both of these requirements will be in alignment, but not always. Some of your objects may need to populate and be populated from multiple tables, and whilst NHibernate can support this, it does drive developers to generate a 1-1 database model matching their entities.

And another thing, Billy doesn't hint at this, but says it explictly.

it is commonly accepted by many that ORM technologies, when used correctly, are, in fact, a silver bullet for software development

No they're not - don't be stupid. ORM technologies are a useful shortcut for developers to do less boring code, but they are not a silver bullet. They do not replace data abstraction layers, mearly form part of it. ORM is about being able to maintain the state of your objects in a database. Databases do more than just store developer's objects - how arrogant is this man?

Databases and DAL often perform complex data manipulation required by the business. Sometimes you need a process which will derive data from inputs, and you need a manageable, maintainable design pattern to implement these processes with data decorators and transformation objects. Whether you choose to put this code in NHibernate or elsewhere, then it still needs to be done. Using NHibernate doesn't remove business requirements.

Dependency Injection Frameworks

2008-10-10T06:23:00.000-07:00

Call me crazy, but I don't get why the world has gone mad, and experienced developers are in love with DI frameworks.

Don't get me wrong - I get IoC. I can see how it helps with flexibility even if I'm not completely convinced that it reduces coupling. You're, at best, no better off in terms of coupling, but objects can be used in new abstracted ways.

I even get understand how dependency injection could potentially help this, adding another layer of abstraction on how your objects relate to each other.

What gives me the fear is that you're putting your application configuration into an XML document. That's an XML document everyone, which is going to control how your objects relate to each other; which types to create; which objects should be cast with which interfaces. In an XML document.

A document that maybe dozens of developers will be working on. A document that is very, very unlikely to contain any comments. A document which is not validated at design time, or build time, only at run-time. A document which in twelve months will be unmaintainable garbage. A document that contractors will dick with for a few weeks and then leave. Your entire application in the hands of one XML document. No.

Lots of things DI framework providers write really scare me, and I don't scare easily. Here's something from Winter4Net

Fast - handles more than 20mb configurations

Aarrrghhh! I'm a big tough man, but even I tremble when I think that my enterprise-scale application maybe in the hands of a 20mb XML document that no-one will be able to follow.

And actually, its not just mentally-large config documents. Here's what the ubiquitous Nate has to say about Ninject.

To define a conditional binding, the two fluent interfaces (binding and condition) work together. Here's an example:
Bind().To();
Bind().To().Only(When.Context.Target.HasAttribute());

What? So now I'm putting business logic into configuration? I admit that if I had to use a DI framework, then I'm attracted to Ninject if only because of the whole 'it's not an XML document'

How can we take this idea further? I know! What I'm going to invent is a really flexible configuration system which I'll process and turn into commands my CPU understands, and I'll call it F*CKING CODE!