Intelli-J makes Android Easy

On paper Android should have been a good fit for my previous experience in java and C#. I’m quite used to using the Eclipse development environment and, despite some of its more quirky configuration aspects, it has generally proven relatively painless. However, for much of the last couple of years, any involvement in Android has proven to be a bit of a heart-sink moment. Write the code…wait for the emulator…wait for the debugging to commence…wait…wait…wait. 

There is much to like about Android, as a developer, but somehow, compared to the slickness and immediacy of the iPhone emulator and debugging experience in Xcode, and the depth and sophistication of Microsoft’s Visual Studio, Eclipse has been the source of much heartache, cursing and premature ageing. Recently, however, I have moved from Eclipse to Intelli-J (IDEA 12 CE) – a free IDE from JetBrains that can be used for Android. This has revolutionised my Android experience – now I feel  like I can focus on the job at hand, and on the well-thought-out Android Framework – in short, I feel like a developer rather than a software trouble-shooter. Moreover, with sophisticated code-completion and all the other whistles and bells you’d expect from JetBrains, coding productivity shoots up.

Now we have the three major platforms with very pleasant and capable development environments, I am more convinced than ever that the advantages of quick-adoption offered by PhoneGap and other HTML-based cross-over frameworks are more than outweighed by the power of having direct access to the underlying frameworks and better performance. Indeed, my current experience of porting over a complex application framework from iOS to Android suggests to me that whilst code might not be shared directly, the platforms have enough in common to make the translation reasonably painless.

As the mobile development market matures further, we will no doubt continue to see steady advances in the ease and productivity of native code development – something no developer is going to be sorry about.

With XCode 4, Apple Start to Love Their Developers!

As I mentioned on a previous blog, compared with Microsoft’s Visual Studio and the vast array of good quality reference material and samples available, the Apple development experience could easily be found wanting. With the latest version of their Development Environment – XCode, Apple is beginning to show the kind of love that developers, and in particular new developers, need.

For developers from a non-Apple development background, with a lot of experience in Java and .Net, one of the most awkward things about the older version of XCode and Apple’s Objective-C programming language, was the need to basically tell the computer when it should remember or forget things. In other languages, this is usually taken care of automatically, although sometimes you would choose to interfere in order to keep system resource usage down. The upshot was that a whole extra pointless layer of testing was added for something that provided no benefit to the end user.

Now Apple have introduced something called Automatic Reference Counting (ARC), which does the job of working out when to remember and when to forget about things. This does not sound revolutionary, but it has gotten rid of one of the more dangerous and common pitfalls of developing for iOS. Now, instead of worrying about the internals of the platform infrastructure, developers can just focus on giving the end user a great experience.

Having used XCode 4 for a while now, I can say this is probably the biggest single time saver, but Apple have put other things in too – including a helper that will suggest fixes for small problems on the fly. There is also a storyboard that allows developers to layout transitions between views visually. Overall, the improvements make the whole development experience more slick and less painful.

Why does this matter for people who aren’t developers? I think one of the upshots of this is that it makes native app development faster, easier and hence more cost-effective. Despite having spent time going down the PhoneGap route, these new development enhancements have persuaded me, at least, that native iPhone development is now actually faster and more convenient than HTML5 based frameworks. Indeed, even if you want to combine web content with your app, it is still, I would suggest, easier to hybridise properly by going native.

Whilst XCode is still not up to the level of Microsoft’s Visual Studio, it is getting very much better, which can only be to the advantage of developers and end-users alike. I look forward to more of the love in their next release!

For an Effective Mobile Content Strategy, First Understand Your Users

Any good CMS system worth its salt should be able to support proper mobile devices through the platform specific targeting of content and style elements. However, simply making your page layouts and stylesheets mobile friendly may not be enough to satisfy your users.

Different Ways of Providing Mobile Content

There are different ways of supporting your users on the move, including*:

• RSS News feeds
• Mobile friendly web pages – navigation as per your current site structure
• Downloadable eBook/pdf – for Kindle/Tablet users
• Mobile friendly site – both pages and content structure optimised for mobile
• Mobile friendly site in an app – installed like a mobile app, works like a website (normally HTML5)
• Framework based mobile app – e.g. PhoneGap – makes native phone/tablet functionality (e.g. GeoLocation, local storage) available to mobile web app (normally HTML5)
• Native mobile app – implemented in native language for each device – e.g. iOS, Android

* (you can find out more from my previous post Mobile Apps for the Uninitiated)

Broadly speaking, this list gets more expensive as you go down it, but with a potentially much richer and deeper ongoing engagement with your users.

None of these approaches covers all eventualities – there is a cost/benefit for each. For example, RSS feeds provide users with easy access to news items from your web presence, typically with very little extra setup cost. At the other end, native apps provide the smoothest experience, and the possibility of an excellent push content channel. However, you can’t push content to users unless they download the app, and they will only download an app if it supports an activity they want or need to do.

Different Users, Different Uses

Users may fill their time with research type activities when commuting to and from work on the train, using their smart phone or tablet. They may wish to get access to material relevant to their job at their desktop, to your contact details on the move, check their user account, or outstanding orders at lunchtime at their desktop…and so on. If you hope to have a clear idea of how to service their requirements, then you need to clearly model the key user journeys you want to support, otherwise you are not making their lives easier. Different kinds of users engage with different kinds of content, on different platforms, for different reasons, in different situations.

There is no one size fits all approach to reusing content on mobile platforms, beyond the basic exercise of providing content. Whilst this basic exercise is better than nothing, this is unlikely to make all, or even any, of your groups of users engage more deeply with your content.

The Right Approach for Your Users

It may be that you have something to offer your users that means they are keen to engage on an ongoing basis – for example, if they order your goods regularly, or if they use real-time information, or if there is a professional or interest based reason for frequent two way communication. In such cases, you will most likely have a strong case for developing a mobile app.

If you find that your users just want your news on an occasional basis – in which case, a mobile friendly news page, or an RSS feed may well suffice. If your users tend to check you out on the move, then your entire site navigation, along with the page content, will need reconsidering in light of issues such as:

• how do and should people access your content
• how should you signpost the most important activities in the limited screen space of a mobile device
• how should you keep the sequence of activities short and easy to manage on a mobile keypad

Reuse of Content

Only when you understand the likely patterns of engagement of your users will you be in a position to judge how you may be able to reuse your content. Although the challenge of how you will push that content out technically is not to be underestimated, that is just a side issue compared to the organisational and human complexity of establishing and appropriate authoring process.

Reuse may require Rewriting

You cannot expect content designed for the written page to be a good fit for mobile devices and vice-versa. You may be able to give much more concise, interactive and context-sensitive content on a mobile device, which can be made aware of its environment to some degree, as compared with a desktop browser. If you are considering reuse, then you need to set up an appropriate workflow that will segment your content into elements that are appropriate for each platform. In your CMS, this may mean that you have separate précis, body and imagery for each distinct platform. You will no doubt wish to flag which content may be permitted for use, or blocked from use for each platform as well. You may want the structure as well as the content to be pushed into the mobile device.

Mobile Apps as a Content Delivery Platform

If you are in the fortunate position of having a compelling reason for deep two-way engagement with your users – perhaps as a membership or professional body, or as a charity – then it may make sense to consider developing a mobile app as a content delivery platform. The advantage of this is that you can give a bespoke engagement with content which can, if implemented correctly, be updated regularly without distributing a new app. Users can then engage with content on the move and then access it subsequently without having an internet application. In effect, you can have a targeted push channel into your user base, as well as an effective platform for two way communication.

Creating an effective mobile content strategy is complex, though it offers great opportunities. Only by understanding the needs and behaviour of your users can you hope to succeed in achieving your organisational aims.

Why Google and Apple still have a lot to Learn from Microsoft

The Apple and Google brands dominate the modern digital communications landscape, between them seemingly shaping the future of mobile. Whilst they have shared a breathtaking run of success and growth, the two brands embody very different aspirations.  Despite their success, they still have a lot to learn from Microsoft.

Apple – Supporting Safe Early Adopting through Corporate Paranoia
For the would-be early adopters of technology who want to be sure that their early adoption will be a smooth experience that will signal both a forward-looking attitude, and a personal commitment to uncompromising design values, the latest and greatest gadgets from Apple are a perennial must-have. For the technologically savvy, not afraid to experiment, get their hands dirty, look under the bonnet and get fully involved in their technology, whilst seeing the latest developments even before they have been polished, the restless and even reckless genius of Google is source of ultimate satisfaction.

In order to make the end-to-end user-experience safe for consumers who want to be isolated from what’s under the bonnet, Apple have sought to control every aspect of their eco-system. There is the Apple way and no other if you want to get on board their band wagon – at no point can the experience of a user be allowed to bring the design judgements of Apple into question. At times this attitude of safeguarding the user from themselves has backfired – I challenge anyone to tell me honestly that moving files to your iPhone using iTunes is not a nightmarish process when you switch computers or just want to put a track on from a computer other than the one you are paired with. I know that Apple will be addressing this soon, but it is a clear example of where Apple’s paranoia about controlling user behaviour is made tangible.

Google – Trust the Users, Accept Rough Edge
At the other end of the spectrum, Google’s app market place trusts to user feedback and ratings – no review process except by users. It is undeniable that the overall quality of apps on iTunes is well above that on the Android Market. From Google’s perspective, everything should be driven by users, informed by users, open to users to use or not use, ignore or engage with. You have to be a bit braver to engage, but you can keep on digging with Android, or indeed any of Google’s web services, and finding new joys, excitements and, sometimes, rough edges. Google trusts its users more, and puts faith in the increasing technological savvy of younger generations, along with their cost consciousness, to gain long-term advantage over Apple.

Releasing Apps – Apple’s Big Brother v. Google’s Wild West
These divergent brand aspirations extend beyond the end-user facing aspects of their respective offerings and are even clearer when releasing an app. Want to put out an iPhone app – you won’t be able to guess exactly when your app will come out of the review process, or even exactly happens whilst its being inspected. If a major marketing campaign is slated to coincide with the launch of your company’s new app, then you better leave plenty of time for review, and don’t give a firm date for your campaign until your app is approved – you may even find that it isn’t permitted at all. By contrast, releasing an Android app is instant – no questions asked. At the same time, it’s a good bet that most of the users you really want – high spending, early adopters – will have an iPhone or iPad, so this is not even a choice.

Developing with Apple – Apple’s Way or the Highway
When developing code for these respective platforms, the divergence is even clearer. Apple’s XCode development tool is idiosyncratically Apple, using a language that only Apple cult members could really love – Objective C. At the same time, once you’ve paid for your Apple developer account, which you need to release apps, the development tools are free, and cover every aspect you need covering for developing and testing – even if the process is a little painful.

Want to use Apple’s standard design patterns – that’s fine, you will find more than adequate support, though it involves some fairly logic-defying steps to get things done. Want to do things your own way, or even in a way that is commonly established for lots of other platforms – well, you can do it, but you will find yourself on your own, fighting their tool all the way. Want to use another tool – well, there are permissible alternatives, but none deliver the same access to underlying behaviours and performance compared with Apple’s own tool – in part because Apple doesn’t want to open the development of its ecosystem up to interlopers.

Whatever the problems with developing apps for the iPhone or iPad, there is one thing that makes the idiosyncrasies of Apple easy to swallow – you know what kind of device your developing for, what it’s capabilities are and how you are going to test  your app to make sure it works properly on anything it’s going to be used on.

Developing with Android – Endless Possibilities, Endless Fragmentation
If you want to create apps for Android, there are a number of ways you can go, though the most standard is using the Eclipse IDE, which has been around quite a while as a java development tool. Unlike Apple’s XCode, in order to install the Android development tools, you require a number of downloads and a more involved set up. The fact that you create code for Android using a plugin for a tool not made by them speaks volumes about Google’s general approach – try to reuse the best of what’s already out there, add extra bits to make things easier, provide documentation and starting points and let everyone get on with it. Thankfully, Android is java based, which makes it easy for the majority of programmers – familiar with java or the very similar C# – to get stuck in.

The possibilities with Android are seemingly endless, there are no complete answers, but lots of starting points. The satisfaction of engaging in truly novel development is, however, tempered by the fact that you cannot be sure what kind of device you will be dealing with – screen resolution, memory, capabilities – vary massively. As has been acknowledged by many commentators, Android’s major problem is the fragmentation of the platform – so, you may test your app with a good many devices, but there is still the overarching, and realistic, worry that it won’t work on some device that is key to your target user market.

Indeed, fragmentation is the key phrase one would probably use for the whole Android experience – lots of different ways of doing things, lots of potential tools, lots of downloads to get you going, lots of reference sites and forums, lots of devices, formats and capabilities. No app can hope to work properly on every “Android” platform – and you may easily get caught out by phone features such as physical slide-out keyboards that require the phone to be used one way up rather than another.

Pining for Microsoft
In all honesty, I have no particular axe to grind here – there are many things that I like about developing for the iPhone / iPad, and there are many other things that I like about developing for Android. They are very distinct experiences with their own very well defined pro’s and con’s. However, the very fact that both have their clear drawbacks means that they have a long way to go in fully supporting their developer communities – regardless of what their fanatical partisan adherents would have you believe. Here, I think that both Apple and Google have a lot to learn from Microsoft, a company whose current, though likely temporary, absence as a significant figure in the mobile space is sorely missed by many developers.

Over the years, particularly while it’s dominance as the leader in software and technology was largely undisputed,  Microsoft received much criticism over its behaviour. Over the course of court cases on the bundling of Internet Explorer on Windows, amongst many others, it demonstrated a certain ruthlessness in pursuit of corporate advantage. Nevertheless, Microsoft’s heartland was always its development community – which it looked after in a way that no other company has been able to.

Take, for example, the current version of Visual Studio, and in particular its new scripting language for the web – RAZOR. It is, quite simply, a breathtakingly elegant and simple approach to creating highly interactive web applications, one that keeps coding and obscure development processes to a minimum. Microsoft really know how to make a developer’s life simple – and C#, in my opinion, is probably the best general purpose programming language, or certainly the most carefully elaborated – with well-structure libraries and tools, as well as a very active open-source community.

Over the course of a bumpy track record, Microsoft have got their development tools and frameworks just right – which is why it is such a shame that Microsoft largely missed the boat in mobile, at least until their Nokia deal pays dividends. Moreover, when developing for the B2B market, where the expertise and experience of corporate ICT, security and compliance departments is key, I sense that a lot of mobile and tablet developments are being held back for fear of using anything other than the familiar Microsoft platforms.

Apple, Google and Microsoft – a lot to learn from each other
This does not mean that I want Microsoft to suddenly steal a march on Apple and Google, to become dominant in mobile as they once were, and still largely are, in the desktop market. Far from it – but I think some healthy competition from Microsoft will not only free up forward-looking technological development in the corporate market – but it will also make Apple and Google alike up their game in supporting their developers.

I live in the vain hope that Apple will take a leaf out of Microsoft’s book and start loving their developers a little bit more, that Google will take a bit more care over polishing and integrating their disparate services and support, and that Microsoft learn what makes mobile devices tick. All three have massive amounts to offer by way of advancing mobile and other technology for corporates and consumers alike. All three have their distinct style and flavour – personally, I don’t think any one is better, at least in a general sense, than any of the others – but all of them are needed.

Mobile Apps for the Uninitiated

Last week I gave a presentation at the Web Managers group in London, giving a general overview of what is involved in getting into mobile apps, and some of the key considerations involved. I was a little surprised that of those who were not agency-side, none had yet created an app. Whilst this might be interpreted as a lack of appreciation of the importance of mobile, talking to the web managers it was also clear that this could be seen as a sensible caution over getting into a new platform just for the sake of it.

You can get the content of my presentation from here.

How mobile fits into a broader content strategy is a difficult question to answer – it depends on  the nature of the content that an organisation is providing. In order to have any kind of ongoing usefulness, a mobile app needs to be focussed on making commonly undertaken tasks more convenient to complete or on providing rich and entertaining interaction that has some possibility for progression. Given the propensity of users to offer feedback freely, creating an app with a contrived need runs the risk of negative reviews and damage to the corporate brand.

• If your audience have a frequent engagement with your services, such as maintaining an account, ordering, obtaining guidelines or updated materials, or engaging in communication, then there is probably a case for creating an app.
• If you provide regular content updates to your audience, but only in small volumes, then an RSS feed, or a mobile friendly site is more likely to be a good means of engaging your mobile users.
• If you do not have regularly updated content, or news about your services or events, then a mobile friendly site is probably the answer.

Depending on the precise needs of your audience and your business, there are a whole range of options available for reaching out into the mobile space:

• RSS feed
  not mobile specific, but can be consumed easily by smart phone users
  
• Mobile friendly site
  a good starting place, but remember, just creating a mobile-skin for your site is not enough – your content and navigation must reflect the specific needs of mobile consumption – your content must be bite-sized and succinct
  
• Site in an app
  brochure ware for the mobile – effectively a website wrapped up as an app – quick to produce, you can say it’s an app, but if you don’t do it well, your audience will be disappointed
  
• Cross-platform HTML5 hybrid app
  implemented using a cross-mobile framework such as PhoneGap, AppCelerator, RhoMobile, AppMobi (and many more) – good for multi-platform, provides access to some of the phone’s underlying functionality, allows reuse of code – these frameworks keep getting better, but they are still not as slick as a native app
• Native app
  created separately in the native language for each platform – provides the slickest experience, but at a price

There is no one-size fits all approach to success in mobile. The mobile space is fast changing, and there are lots of options for getting involved – mobile apps being only one form of engagement. The important thing is to be clear about your aims and your audience – reach out to them early, get user groups involved in appraising prototypes and get plenty of feedback before launching.