Mobile technology – what should we build for?
There is a lot of discussion happening in the industry at the moment surrounding mobile technology. Most of it seems to be centred around the iPhone, but it’s important to remember the other platforms as well that haven’t quite had the hype that the iPhone has.
The contenders run as follows: iPhone, Google Android, Symbian (Nokia smartphones among others), Windows Mobile, BlackBerry, and the “dumbphone” contingent that can run Java Mobile Edition applications. There are a couple of others, but they are found so rarely that they’re not important for the purposes of this article. Of course, if the majority of your userbase happens to use one of those rare platforms, then by all means build for it. It’s just that most don’t.
What this article will seek to empower you with is the knowledge necessary to make an informed decision as to whether a given platform is worth the time and effort to build an application for or whether it might be better to try a different one.
iPhone
The platform that has received more press inches than any other technology… in the World. The hype is there, almost everyone wants one, and we’ve just learnt that O2 is losing their exclusive contract with Apple in the UK. Orange will get the iPhone in November and Vodafone in early 2010. That grows the potential market considerably.
From a consumer perspective, the iPhone is brilliant. It does everything expected of it, and with relative ease – Apple have clearly spent a lot of time and effort on the user interface. There are over 85,000 applications on the iTunes App Store now that do all manner of things, ranging from silly games to full blown applications, and that’s not including any applications built for enterprise that are distributed internally and never see the light of Apple’s day. Couple that with over 2 billion downloads across the iPhone and iPod Touch and you have a force to be reckoned with. Dismiss the iPhone as a marketing tool, and you’re going to miss several tricks.
As for the developer angle, the iPhone SDK coupled with Objective C is no Ruby on Rails, but it’s certainly nice to work with. Apple, again, have spent a lot of time designing and building their development tools, and it shows. Since Apple released their non-disclosure agreement with developers, there are hordes of books and tutorials around the Internet, coupled with forums with developers supporting each other across the globe. It makes for a pretty handy development platform.
Miss this and miss out, as they say.
Google Android
Google decided it was time to play mobile, and built Android, an open operating system for mobiles. It’s been taken up by almost all of the big manufacturers and is proving successful to the point where Android will likely overtake the iPhone in terms of usage numbers in the coming few years.
As a consumer, it’s easy to use, does over the air updates, so you’re always running the latest software, and has a whole mass of integration with Google products. That just means talking to people is easy. There is one really nice thing with Google though: all apps are equal. So, if you want to, you can change the dialer to a different one, the keyboard, the mail application… anything you like really. Google’s own app store is also a little less policed than Apple’s, from the perspective that Apple will not allow an application that competes with one of their own. It is only with the FCC in America forcing AT&T’s hand that Skype will now work over 3G and not just over WiFi, for instance, and it took over 8 months for Spotify to appear on the iPhone. We all wonder why…
Again, the SDK available for Android is brilliant. It plugs in to open source products and lets almost any developer on any platform build for it. You also have a choice of app stores, and you don’t need to jailbreak to multi task, like you do with the iPhone. This is one of the iPhone’s major gripes – you can’t keep your application running if you want your user to send an email or send a tweet using TweetDeck. If you want it to do something, you have to do it yourself in your app. Not so with Android.
Again, like Apple, this is one to watch. There hasn’t been quite as much hype from Google about this platform, but it’s been allowed to grow and mature steadily, and this shows in the quality of the latest version available in the HTC Hero.
BlackBerry
RIM took the world by storm a few years ago when they brought us a mobile phone with a proper keyboard that would push emails to the device as soon as they arrived in your inbox. It integrated with all the major enterprise email platforms (Exchange and Lotus Domino are the key ones here), and it did everything very well. RIM have been pushed a bit recently by the likes of Apple and Google, but still they’re the ones that got there first, and as such have a vast share of the market. Our target demographic for most brands will definitely include the BlackBerry user.
It doesn’t have the development tools that Apple and Google have deployed for their developer bases, but it’s certainly not too shabby. Applications can multitask, and interact with hardware available. Because of the vast number of devices running BlackBerry’s operating system, this is one that should be considered in any marketing campaign. However, a point to note is that distribution of your application is a lot harder for BlackBerry than it is for the two platforms discussed above. That will probably change in the coming months, like Nokia has released Ovi.
Symbian
Symbian, once the pinnacle of British software engineering, and originating in the Psion series of palmtop computers of the 90’s as the EPOC OS, has rung its death knell. It used to be used by a number of manufacturers, including Sony Ericsson and Motorola, but in recent years it’s been Nokia sounding all the trumpets about this platform, most notably that they open sourced it. However, Nokia themselves have announced that they want Maemo, their Linux platform currently in use on their N range of Internet tablets, to take over in their smartphone range. It just isn’t worth developing for something that won’t last more than a couple of years, if that. Time to say goodbye. It’s a shame because it’s a nice platform, but the fact of the matter is that it’s a gonner.
Java Mobile Edition (J2ME)
J2ME is in use everywhere. Every non-smartphone on the planet, and most smartphones too supports J2ME applications. That means nothing though where advertising is concerned, because I don’t know anyone who has a dumbphone who has downloaded a single application for it, save for the techies who have added one or two. Games from the mobile provider’s WAP portals may have had a few downloads, but nothing in comparison to the vast array of useful applications available for iPhone and Android. That’s not to say they don’t exist… they’re everywhere, but no one knows about them. There isn’t yet a sensible distribution method for these phones either. You can’t buy an app and keep it as you upgrade your phones through the years; you need to buy it again each time you upgrade your phone. Worse, if you lose your phone or it gets stolen, you have to buy them all again too.
It just isn’t practical then to build for J2ME unless you are building for a particular market that you know will use it – simple games and ringtones spring to mind, with low income people as the main demographic. Other than that, don’t bother.
Windows Mobile
The lost soul of the party, Windows Mobile has been trying to gain traction in the mobile space for years now. It’s bloated, slow and above all, it keeps changing. Microsoft have laid their bed of nails, but they insist on lying in it. It’s a shame. It could be a good platform, and it’s certainly a nice one to develop for these days, with the .NET framework and languages available to you. Microsoft have also now launched a distribution platform for applications, but it’s not readily available on older phones. They’re some way off the technical abilities of the Android and iPhone platforms, and BlackBerry does everything better than Windows Mobile does.
As far as marketing opportunities go with Windows Mobile, the story doesn’t really improve. Mostly due to the current lack of devices available with a proper distribution mechanism, and the severely reducing market share at the hands of the men in Mountain View and Cupertino (Google and Apple, respectively, for those that aren’t “in the know”), this is another one that probably should be left by the wayside for the moment. We’ll see what the future brings, but it isn’t particularly rosy.
I guess the only other platform that needs some discussion is Palm’s WebOS. It’s the new thing from Palm, trying to regenerate interest in their brand of devices. Personally, I think it’s too little too late, and unless you’re Apple, a one-trick pony in a race amongst horses won’t be winning any prizes. That’s not to rule it out, but we will need to see where we are with it in a years time. Of course, it is easier to build for, because most web developers can build apps for it, being based on web technology.
Our view on the marketplace here at Initforthe suggests that the order in which applications should be considered currently is likely to be something like:
- Apple iPhone / iPod Touch
- Google Android
- BlackBerry
- Windows Mobile
- Palm WebOS
- J2ME
- Symbian
This of course assumes you’re in the marketing and advertising industries. Other industries are likely to vociferously disagree with me here, and that’s fine. I’d agree that in some places, J2ME will be top of the list, and in some enterprises, the only ones to touch will be Windows Mobile and/or BlackBerry. That’s a decision to be taken based on a known userbase. In an unknown world where you have to make judgement calls about what will return the most for your brand, it’s a different story. This is how to tell it.
Testing, testing, and more testing!
It is blindingly obvious that testing is utterly important. You can’t go live without at least some testing time. But what really is testing, and do we give it the space, time and money it deserves? That’s the question I’d like to ask of the whole industry, because I think the answer is a resounding NO! And that worries me.
First off, I’m going to look at what testing comprises of. What is testing? What are the options and their meanings in terms of time and value? I’ll look at what we’re prepared to pay for, and why this needs addressing, and I’ll ask why we’re not being more forceful about it.
Testing can mean many things, so I’ll keep it in the context of a web application in this instance. It’s a limited viewpoint I know, but it carries the same message across other disciplines.
In testing a website, we talk about functional testing, we talk about user acceptance testing, and we talk about User Interface testing. The latter two often work hand in hand, and are done prior to build, where functional testing traditionally happens after the build process and is about eliminating bugs in the system. Fine, but that only works to an extent. It’s the functional testing we’re talking about here. If the others haven’t been done prior to build, there are bigger issues that need dealing with first. Like why not?!
We’re given scopes to look through and quote for on a day to day basis. Sometimes they appear complete and other times they don’t and need some reworking. The complete ones almost certainly are not perfect, and have missed one or two bits of business logic somewhere along the line. These aren’t picked up until later in development, and only surface when an astute developer asks the question of his Project Manager. If they’re not picked up, they surface when a user of the site does something unexpected, at least something that the developers didn’t expect the user to do. And that’s usually where the bugs appear.
So what sort of testing can you employ and how does it help? Well there are two main options: manual testing, or automatic testing. You could put someone in front of a computer and ask them to run through every single possibility and flag bugs, then run through it again and again until there are no bugs, in each separate browser. You could alternatively automate the testing if you’re building the application in a framework that has the possibility of testing built into it.
The first of these two options, manual testing, is what is normally assumed. Unfortunately, it’s considered a case of going through the application or site after build and checking everything appears to work as expected. This is fine, but doesn’t really deal with the issue at hand – those pesky bugs that hide under bits of code you never thought to look under. If you choose to go down the route of manual testing, preparation is key – all scenarios must be thought through, written up into test cases and tested by a person, or people, independent of the project. Clearly, the people involved in the project need to be testing as well, but they can often be too close to the project to notice what are sometimes glaring issues. Sufficient testing means a full set of written tests, with results properly recorded step by step. This costs money; often half or more of the build cost. Doing any less than this can’t be considered to be sufficient.
If the framework of choice has a test suite, such as Ruby on Rails, there is a second option that costs significantly less, yet gives almost the same quality assessment of the project as does the manual process. Depending on the choice of test suites (many can be employed, each one testing a different facet of the application; e.g. separate front-end and back-end suites), they can be written to be readable by people not affiliated to the project, or those not on the project in a technical capacity. This means these tests can be peer reviewed and cross checked for completeness against the technical specification. Usually testing in this way happens during the build process, the tests being written before any code and then the code written to pass all the relevant tests. Two methods used here are Behaviour and Test driven development. The first tests that the behaviours expected by the user actually happen, and the latter is often used to test the business logic. Both can be used together. Automated testing costs on average approximately one third of the build cost. With it come guarantees that the application has been tested almost to destruction, with all kinds of possibilities tested out. If you want an extra layer of security, do some manual testing as well. Get people not involved in the project to run through the system and if anything is spotted, then it can be dealt with promptly. Again, tests must be written for these, and should detail behaviour that the user should experience. As long as the results are recorded, including steps taken, then this is well worth doing.
There is one further major benefit to automated testing. The tester doesn’t go away. If you update the application later down the line and you want to add some more functionality, you can quickly make sure that the changes you have made work, and more importantly, that all the previous tests still work. If you decide on the manual process because of a resourcing issue at the time for instance, remember that you’ll have to run through every single test again whenever you make any changes if you want to guarantee the same level of quality. This is the value in automated testing. Continuous, solid, quantitative tests that never go away.
If making sure your application is robust is this economical, why then is it perceived to be too expensive? I’ll make an analogy to motorcycling. I recently bought some new motorcycle gear that cost me nearly £900. I know I could have bought gear for less than £200, but I also know I’d be compromising my own life if I did so. Testing an application is the same, if a little less terminal. Usually though, it’s the first thing to be thrown out. You need to reduce the budget and the scope needs to stay the same, so the testing budget suffers. The issue is that the expectation is still that the application be fully tested. I think there is a certain belief too that the £200 gear will save your life. It may well do, but not before you’ve had a few skin grafts and organ transplants. Should we be prepared to pay more for this part of the build? Yes. If the budget does need to be reduced, it must reduce the scope, or the quality of the end product will be severely compromised, and for that there can be no guarantees provided.
I know this is something of a long post. It’s important that we understand the unequivocal requirement for proper testing, whether manual or automated, and that our clients are educated to that effect. They pay millions of pounds and dollars for software systems that run their organisation on the basis that the systems are tested and won’t break. Even so, they do sometimes break, if rarely. Even less often do they break badly. That’s testament to the amount of testing that they do. All software has bugs. It’s almost impossible to eliminate them all. Why can’t budget be put into testing these bespoke systems that are being built? Education. That’s all. The budget is there for testing, but if the knowledge and understanding of the whys and wherefores isn’t there, then the budget won’t be allowed to be spent on what appears to be a frivolous activity. This is why.
A great new viral for a new film: “Shifty”
Just today one of my colleagues received an email from the “Community Drugs Team”. She read it, re-read it. Then said “I’ve only just moved to Shepherds Bush. This isn’t right! I’ve not been involved in any of this.” She was referring to this:
Looking at the links, the code behind them, you’d never think it was a fake. Clicking on them, however, told a different story:
Well. It was definitely an interesting way to get the point across. The mark of a good advertising campaign is one that gets people talking about it, in my mind, and this one uses some of the most basic elements of digital technology to deliver that. A great example of KISS
Everyone in the office is talking about it. Oh, and stitching their mates up… Kudos to the team that did that.
Content distribution, now for the masses
We’ve known about Akamai, who’ve been long regarded as the leaders in CDN technology for some time now. As of a few weeks ago, there’s a new kid on the block.
Amazon released CloudFront on the 19th November, and it’s what I think has been lacking in their S3 storage solution that now makes Amazon a key competitor on the CDN front. That of what Amazon have termed “Edge Zones”. Nothing particularly complex in the definition: You upload your content, and you can have Edge Zones in the USA, Europe, Hong Kong and Japan. Amazon will automatically fetch the data from S3, cache it at the Edge Zone location, and from that point forward the transfer time for your users will be blistering!
I fully expect to see some really innovative uses coming out of this and we’ll keep tabs on it here and keep you abreast of the happenings. If you’ve got a project you’re working on that uses CloudFront, feel free to comment here. It would be really good to see the different uses people have for CDN tech.
For now, that is all. Back later with more fresh goss from the Tech world.
"It Doesn’t Work"
“The site doesn’t work.”
“What do you mean, the site doesn’t work?”
“It just doesn’t work.”
“So what is it doing that it shouldn’t be doing?”
“When I go to the site, I can’t do X.”
“But when I go to the site, I can do X.”
To a developer this is an all too common dialogue between someone looking over the site – usually someone non-technical, and definitely someone who hasn’t read up on Reporting bugs effectively.
After development comes testing, and during testing, bug reports are made. If the bug reports are unclear in any way, then it takes more time to fix them, because it takes more time to decipher their real meaning. So what this article is about is understanding the core elements of a good bug report, and why “It doesn’t work” is bad.
From the perspective of a developer, a good bug report consists of a specific set of things that must always be there in order to be able to replicate it. Without the ability to replicate a bug, the chances of it being fixed are very slim. The above article by Simon Tatham, a very well regarded developer, of PuTTy fame, is probably one of the best groundings I’ve seen for writing good bug reports for software, and it extends to web applications and sites too. The first of these things is a concise but clear summary of the bug. One line is enough – just something that describes the issue, eg. “Firefox 3.0.3 prevents upload of multiple files in new messages”. That’s a good summary that with some additional information as described below is the formative part of a good report.
The concept of “Show me how to show myself” is crucial here. What’s needed is a step by step set of directions by which you came to see the bug. The developer may well not have used the application in this way, and didn’t expect it to be, but users will always do the unexpected! If the issue is a display issue, take a screen shot, and include the whole window, not just a bit of it. If it’s a browser issue, and this happens a lot on the web, the developer needs to know which browser the issue happens in. If the same issue happens in every browser, one screen shot will do, but a comment to that effect is absolutely necessary. There are also some key facts that should be included with any and all bug reports: Operating System, Browser, Browser version, URL on which the error occurs. Some other useful pieces of information, depending on the bug report are: Flash version (or that it’s not installed), JavaScript status (on / off). If you think there are any more, there probably are, so feel free to comment on this article.
So, to conclude, we need a good summary (usually marked down in a subject field if you’re using a bug reporting system), a set of facts about the machine you’re seeing the issue on, a clear set of instructions on how to reproduce the bug, any additional information the developer might need to reproduce the bug, and if you can, a screen shot or set of screen shots to show the developer the problem you’re seeing.
Recent Comments