Future of mobile phones (part 2)

Previously we looked at the form factor, what shape phones could be in the future. But what will phones do?

Clearly phones are getting smarter and able to do more, so here are some thoughts on the changes that could occur.

Phones replace your laptop/PC

Sometime this year we should see phones with quad-core processors, making them as powerful as some PCs. Following Moore’s law, they will get more and more powerful. And the same goes for storage/memory, although as “cloud applications” improve you will need less on your device.

With this in mind, you could easily see a phone that slips into the back of a tablet which is only a screen. Already, the Motorola Atrix shows that you can have a dockable phone that could replace the need for a PC.

Phones replace your wallet

This one’s not really news at all. Already there are a whole lot of mobile cash/payment solutions, so I won’t go further into this just now. However with NFC (near field communication) expect to be able to pay for things simply by tapping your phone on a till or another phone (e.g. to give your friends money).

Phones replace your keys

Again, NFC could quite easily be used to allow your phones to open car doors, your front door at home and even replace security badges at work. It might be that phones will have multiple slots for NFC chips.

Phones replace your brain

Not literally, but they will save you having to remember things. Growth in memory capacity means that you could have chips that store everything: what you see, say, hear and do. Coupled with powerful search capability you’ll never forget people that you met, actions from meetings and the name of the little restaurant you loved on holiday.

Phones replace your doctor, mechanic…

Google has toyed with the concept of phones with monitoring capability, immediately alerting you of heart, blood pressure and maybe even sugar level issues. Ford have toyed with phones alerting you of servicing needs in a car and other advanced telemetry. Following on from this, there’s no reason why your phone won’t become your central processing unit for anything: your home security, your gas boiler servicing and more. Expect a future where there is a lot more device to device interaction than today (I will write more about this soon).

Phones replace your personal assistant

Already there are apps to help you with everything from planning your train journey to scheduling parties. In the future, your phone will also tell you when you’re close to shops you like or that have offers on things you might like based on your personal tastes.

You may be on holiday, and your phone will let you know where the nearest bathrooms are or how to navigate through a city to make sure you see all sites of interest with the most efficient route possible.

So with all these capabilities phones could be very important. How will be secure something that can so easily be lost? It could be that they move towards biometric security: voice, fingerprint or facial recognition. Or it could be that a secondary NFC chip that is in some jewellery or even embedded inside you grants you access.

This all sounds very futuristic, but some of the features discussed are either already here, or could be within the next five years. It seems phones are going to be part of an important and exciting future for us all.

Future of the mobile phone (part 1)

For a few months now I’ve been having conversations with colleagues, friends and family about the future of phones, sad I know but at heart I am still a geek ;o).

I see three possible futures for mobile form factors. Phablets, smartphones, phone jewellery (starting with watches and bracelets, then other jewellery).

The smartphone we all know and love. Multi-functional it is technologists answer to the swiss army knife. This is currently the most popular form and for many will continue for years to come. However, the downside to this is that screen estate is limited and the need to zoom and scroll detracts from any serious browsing.

This has brought an opportunity to try a new form factor, the “Phablet” (phone-tablet), a phone that is not as big as a tablet, but not as small as a phone. The Galaxy Note is a good example, with a 5.3 inch screen it’s a little big for a phone, and perhaps too small to be called a tablet.

What’s interesting though is that the screen resolution (1280×800) matches most current tablets, and is better than many of the earlier tablets, so what you get on the screen is the same amount of information as a tablet. This for some will solve the problem of having to carry a phone AND a tablet.

However for some people a phone needs to be a phone and nothing more. For my wife, for instance, ideally this would be not much bigger than the size of a lipstick and just as simple to use. Phone size and weight can place a burden in pockets so going smaller also makes sense. In addition to that there mobility makes them easier to lose, which can be a real issue for most people.

There are already phones in watches, and there are some great prototypes of bracelet style watches. As batteries improve I can see phones being embedded into other jewellery also such as pendants or earings. This is approach is great from a security perspective as people tend to lose more phones than their watch or bracelet, and with mobile payments this may become an important factor.

The smartphone itself may yet bite back, there have already been concepts of smartphones with projectors and ones with roll-out screens that solve the issue of screen estate. Other concepts include “flexible phones”, phones that are so thin that they can flex. In fact Nokia has taken this further so that the phone has “flex-gestures” for example bending the phone up or down scrolls pages.

Or will we become phones ourselves? Will we have bionic implants?

So what do you think? Will you wear you phone, carry it or will you be a phone?

HTML5 will be key to a MAD world

According to researchers, over 5 billion devices connect to the Internet today and by 2020 over 22 billion devices including 6 billion phones, 2 billion TVs will be connected. By 2014 sales of new internet connected devices excluding PC’s will be over 500 million units a year.

We’re moving into a connected world where people expect internet access any time, any place and on anything, and so many of us will have Multiple Access Devices (MAD).

Therefore it still amazes me to find large corporate with a separate Internet strategy and Mobile strategy. I won’t name and shame but you know who you are! What next, a strategy for tablets and a separate one for Internet TVs?

One of the key principles of HTML5 is that it aims to give you the tools to write once, deploy everywhere; that is, to create applications and content that can be developed to run appropriately for every device. Of course where it makes sense an application might need to take advantage of a specific devices capability (e.g. a camera or GPS), but even then conditional behaviour can be developed to provide such differentiation rather than develop a whole new application for a specific devices.

One of the key enablers here is adopting an approach whereby the content/application VIEW (look and feel) is fully controlled by CSS, and namely version 3. CSS3 has a number of features that allow you to control layout and look and feel according to screen dimensions/estate. The enabling technology is Media Queries, which allow you to create different VIEWS of an application based on screen dimensions. I’ll be writing more about this soon.

Creating a MAD (Multiple access devices) strategy is not all about technology though. Organisations will have to monitor and sometimes drive changes in customer behaviour, look at how much more time youth spend on smartphones than watching TV or in fact any other device. With each person having multiple access devices, different devices will likely to be used specifically for different parts of the customer buying cycle. If a purchase requires research and thought then most likely this will be done on PC’s/Laptops, for instant updates (news, stock prices, weather, scores and so on) smartphones for entertainment maybe tablets will prevail.

There are many more challenges to be discussed and I hope to cover these in more depth in follow up blogs, but for now small or large organisations need to create a single MAD strategy that encompasses customer/user needs, monitor behavioural changes and trends and investigate the capabilities of enabling technologies.

The change will be profound, as organisations realise the total impact to processes, skills and technologies to really master Customer Experience in a MAD world, a journey which the visionaries have already started.

HTML5: The right time right place for mobile?

Most people by now understand that main challenge for developing mobile applications is creating a solution that runs on as many platforms as possible. This challenge can range from supporting browsers that only support text, up to fully fledged smartphones.

For organisations that are targeting users in the developed world, many are simplifying this challenge to target smartphones only. However even here to create local native applications requires solutions that support Apple’s iOS, Windows, Android and Java (Blackberry).

There are many mobile development platforms available to assist with creating “write once deploy everywhere” apps. The main constrains here are that you end up with deployments to many different stores, and that quite often still write platform specific code to take advantage of platform specific features.

HTML5 has long been a strong candidate for mobile applications, but is it ready? Are mobile browsers upto date with HTML5?

The answer to this question can be a simple “No”, no mobile browser supports the full HTML5 specification. Or a “Maybe” depending on what features (camera, phone book and GPS) of the phone you require you may have support from HTML5.

Push that up to a resounding “Yes”, if you want to move an application that currently runs on the web to run on mobile. Of course, I should also caveat the above with ‘there are grey areas’ in between these responses, not very helpful I know.

For corporates looking to support mobile users with line of business applications I believe there are some great examples that prove HTML5 is ready for them. For a start Facebook is one such application taking full advantage of HTML5, and promoting its use for Facebook apps.

The key areas of HTML5 that are supported across mainstream mobile browsers are offline storage, geolocation, multimedia, graphics (canvas), touch events and large parts of CSS3. The mobile HTML5 site provides a list of mobile browser capabilities.

In the past marketers are argued that presence on App Stores adds value to “brand awareness”, and whilst this is true, there is nothing stopping an organisation having using both native apps and HTML. For example, take LloydsTSB. You can download their app, which effectively once downloaded then runs a “browser” version of their Internet banking service.

There are also some great libraries out there that make cross platform mobile development much easier and provide features that make your web applications feel much more like a native phone app. JQueryMobile is a great example.

So what are you waiting for?

The end of Apple?

We are clearly in the web age an era that has turned everyone into readers and publishers of free content. In this era we have seen the rise of open source, free software and the move to software and services freely available in the cloud.

Yet in the “free age”, Apple maintain a huge client base locked into its proprietary and closed hardware, operating systems and stores. When Steve Jobs returned to Apple, even the great Bill Gates proclaimed that the world had changed, and that Apple would not survive with Steve Jobs maintaining the company’s control over platforms from end to end.

Despite this Apple is a huge success. Is it likely to last?

As a techie, I’d hope not, because we do want to be able to upgrade our hardware, we want the option to use any suppliers’ parts and we want the same to be true of our software. Do we care what the hardware looks like as long as it’s fast and powerful, not really.

However as a consumer, too much choice is not necessarily a good thing. As a consumer, we are in a world where things get replaced rather than fixed or upgraded. For the majority style is every bit if not more important than features, and customer experience does matter.

How quickly and easily I can use my device has become more important than whether it has all the latest and best features. Going back to one store is easier than have to search several for apps and music.

Apple started with some engineering innovation, and when Steve Jobs was first ousted focused heavily on engineering; this was its downfall in the late eighties. However with the return of Steve Jobs, and his partnership with Jonathon Ives, a return to a focus on customer experience and design revived the ailing technology company.

So although it pains me to see Apple thrive in such a closed environment they really do highlight that style, ease of use and the overall customer experience really does matter to consumers. Hence I would not forecast the end of Apple for some time in the near future unless it loses its way again to “engineering”.

HTML 5 makes the browser smarter

The unsung hero of the web has always been Javascript, without which the standards-based web would be completely static. Javascript enables functionality to be executed in the browser, and has been used to create all sorts of effects otherwise not possible with HTML alone.

In the early days, Javascript implementations weren’t entirely standard, requiring developers to have to write variants for different browsers; this isn’t really an issue any more.

For applications, developers will either use libraries or develop their own validation routines. This Javascript code adds significantly to the amount of code downloaded.

With HTML5, developers will need to write less Javascript, as the browser provides features to do things for itself rather than rely extra scripting.

Validation is the main area of improvement. HTML5 now provides a number of new validation features such as mandatory checking, type checking, range and field length validation. The validation is done within the browser, and developers can opt to decide how to process errors.

Obviously validation has to be repeated on the server for security, to ensure that data hasn’t been hacked in the browser or in transmission. This then means that validation has to be maintained in two places and kept in sync.

HTML5 also provides a number of new input field types such as tel, email, color, datetime. This empowers the browser, by applying it to display a date picker, or a colour chooser for example. More importantly for mobile applications it would allow the browser to show an appropriate keyboard layout e.g. a numeric layout for tel, and an alphabetic keyboard for email type.

There are also a number of new attributes which previously required Javascript such as autocomplete, placeholder and pattern which will prove very useful.

There will be some organisations that will not want the browser to affect their carefully designed user experience; for these people the answer is simple, just don’t use the new features.

For the rest, you will enjoy having to write less Javascript for HTML5 browsers, but of course you will still need to have backwards compatibility for non-HTML5 browsers which will rely on Javascript.

HTML5 Gets pushy

In the past there have been a number of clever approaches to get around the limitations of web technologies inability to allow servers to broadcast messages/data to clients. One of the more popular libraries for such capability has been Comet.

Whilst providing a solution where the standard lacked functionality, Comet is quite inefficient – both in terms of network bandwidth and performance.

Comet effectively posts a message to the server and the server replies if there is data waiting to go, if there is not the call is left waiting and if subsequently it times out the client is notified which in turn then makes another call. So it’s inefficiency is that it is constantly making calls to the server regardless of whether there is data to be sent back or not. Also it is using HTTP, so the requests are relatively large in size.

In a previous blog, I mentioned how the WebSockets API allows you to have bi-directional messaging between a browser and server. The use of WebSockets requires a Socket server to facilitate messaging using the socket protocol (which is far more efficient in terms of request size than HTTP). The most popular example of a good use of WebSockets is online chat.

However there is another option: Server Sent Events (SSE).

The main advantage of SSE is that no additional software is required, a standard web server can be used as it only relies on the HTTP protocol. However, the main downsides therefore are that SSE is uni-directional, server to client broadcast only and, because they use the HTTP protocol, the message requests are much larger than socket calls.

SSE also allows arbitrary events which even allows messages to be sent to different domains. Care needs to be taken as this can be open to abuse, so developers should check the domain from which the event has been generated is one that they are expecting.

This is a powerful capability, and for anyone looking at “lean portal” implementations, could be a way of creating functionality like “inter-portlet communication” without requiring a portal server to facilitate the sharing of data.

They are also relatively simple to implement which again gives them an advantage over WebSockets.

SSE will be most useful to applications like stock ticker’s, live news, weather updates, sports scores and any other applications where the server needs to push data to a client. So does this mean the end of Comet? No because to provide backwards compatibility with non-HTML5 browsers, Comet could be used as a polyfill.

Using Polyfill to cover up the cracks in HTML5

Long gone are the days when Internet Explorer had 95% of the browser market. We have lived in multi-browser world since the start of the web. Whilst this has its plus point, it also has its downsides – none more so than ensuring backwards compatibility. Using HTML5 today is not simply a case of does the browser support it or not, but what aspects of the huge specification does it support and to what extent. A good site for seeing the various levels of support across browser releases, against different areas of the HTML5 specification can be found at CanIUse.com.

The W3C’s answer to developers creating solutions with HTML5 is that the new features of the spec should “gracefully degrade” when used in older browsers. Essentially this means the new markup or API is ignored and doesn’t cause the page to crash. Developers should test and develop backwards compatibility. This can be an onerous task. However help is at hand with libraries like Modernizr you can detect what features of HTML5 the browser supports.

Once you know that the browser doesn’t support a HTML5 feature you have used you can write or use a 3rd party “polyfill”. In HTML, a polyfill is essentially code that is used to provide alternative behaviour to simulate HTML5 features in a browser that does not support that particular feature. There are lots of sites providing polyfills for different parts of the HTML5 spec, a pretty good one can be found here it lists lots of libraries covering almost all parts of the specification.

For me a big concern is that I’ve not yet been able to find a single provider that gives you polyfills for the whole of HTML5, or even the majority of the specification. This could mean that you have to use several different libraries, which may or may not be compatible with each other. Another big concern is that each polyfill will provide varying levels of browser backwards compatibility i.e. some will support back to IE 6 and some not.

With users moving more of their browsing towards smartphones and tablets which typically have the latest browser technology supporting HTML5, backwards compatibility may not be an issue. However it will be several years before the HTML5 spec is complete, and even then there are new spec’s being created all the time within the W3C. So far from being a temporary fix the use of polyfills will become a standard practice in web development, unless of course you take the brave stance of saying your application is only supported on HTML5 browsers.

However this does raise another question, if you can simulate HTML5 behaviour do you need to start using HTML5 at all to create richer applications? The answer is quite possibly not, but having one will certainly improve your user experience and make development of your rich internet applications simpler.

HTML5 The proprietary standard

The good thing about standards is that they are uniform across different vendor implementation. Well that is at least the primary goal. So how does a vendor make a standard proprietary?

Well it’s quite easy really you provide extensions to the standard for features that are not yet implemented in the standard. Vendors wouldn’t be that unscrupulous would they? For example would they create application servers following standards but add their own extensions to “hook you in”, sorry I mean to add value beyond what the standards provide ;o)

I’m sure Microsoft’s announcement at Build to allow developers to create Windows 8 Metro applications using HTML5 and Javascript took many Microsoft developers by surprise. What is Microsoft’s game plan with this?

Optimists will cry that it opens Metro development out to the wider base of web developers rather than just to the closed Microsoft community. Cynic’s will argue that it is an evil ploy for Microsoft to play the open card whilst actually hooking you into their proprietary OS. In the cynics corner a good example is Microsoft’s defiant stance of Direct3D versus the open standard alternative OpenGL. This has lead to Google developing Angle, effectively allowing OpenGL calls to be translated into Direct3D ones so that the same programmes can be run on Microsoft platforms.

Whatever it is developers aiming for cross platform conformance will need to stay sharp to ensure that proprietary extensions do not make the application incompatible in different environments.

Adobe’s recent donation of CSS Shaders shows a more charitable approach whereby extensions are donated back to the standards bodies to make the “value added” features available to every platform. This is largely the approach in which standards evolve, with independent committee’s validating vendor contributions.

So what is Microsoft’s game? It’s too early to really say whether there is an altruistic angle on their support for HTML5 and JS, but history has shown us that the empire is not afraid to strike back. Look at their collaboration with IBM on OS/2 leading them to leave IBM in lurch with their own launch of Windows NT. A similar approach occurred not long after with with Sybase and Sql Server.

I maybe a cynic, but having been a Windows developer from Windows 1.0 to Windows NT and following a road of promises and U turns has made me that way when it comes to Microsoft. It’s great to see increasing support for HTML5 but I am always a little concerned with the motivations of the Redmond camp. However perhaps I myself need to be “open” to a different Microsoft, one that is embracing standards even though it may cannibalize it’s own Silverlight technology.

The BBC does a U turn on HTML5

Rewind to August 13th 2010 and Erik Huggers Director of BBC Future and Technology blogged that the the BBC were committed to open standards but “HTML5 is starting to sail off course”.

At the time I thought this was a brave statement to make especially as the late Steve Jobs had already announced in April that year and despite a billion app downloads, that HTML5 negated the need for many proprietary browser plug-ins. It was clear at the time this was squared largely at Flash (and possibly Silverlight too).

For me this was a faux pas too far as Huggers continued his blog with statements about proprietary implementations of HTML5 by Apple and fractions of opinions within the W3C and WHAT-WG (who initiated the development of HTML5).

Now fast forward to almost exactly a year later, and Gideon Summerrfield, Executive Product Manager for BBC iPlayer announces the launch of a HTML5 version of iPlayer. Initially this is just aimed at PS3, but will roll out to other devices in the future.

If we take a slight diversion and look at the developer conferences for both Microsoft and Adobe in the last four weeks, both made big announcements about tools and support for HTML5. However committed developers with years of invested skills in SilverLight and Flash were left deflated with the lack of announcements on the future of these technologies.

So have the sleeping giants finally woke up? It seems like it to me.

However, in the case of the BBC, Summerfield’s blog states that they will also launch new versions of the iPlayer for Flash and Air. This may be a short term decision to wait for wider support for HTML5, but there is little clarity about what they see as the future for iPlayer.

To Hugger’s credit he did foresee the benefits of HTML5 could bring to the BBC in reducing development timescales and having a common skill set.

However I applaud those that have the courage and conviction to take bold steps forward and put their money where their mouth is. The FT is a shining example, ditching their AppStore versions for iDevices and completely moving to HTML5.

There is work to be done on HTML5 and it will evolve for some time yet, but the bandwagon has started to roll and as a good friend of mine said to me at the start of the .com era, “When you see the bandwagon starting to move, you have a choice to jump on, or stand in the way of a tonne of metal !”.

For me it is clear. I’m not standing in the middle of the road, I’m jumping squarely onto the HTML 5 bandwagon. The question is, are you?