Category: Platforms

Categories
Platforms

The Rise of the Chat Bots?

Developers struggling to get noticed on the app stores, or hoping to capitalise on the growth of enterprise messaging, are looking to a new way to reach their users – via a chat interface. The logic of reaching users where they spend the most time seems sound, and that is clearly in messaging apps. Does the typical consumer or business user really want to be taken back to the days of the command line interface though? Is this the next big market, or will it just be a trendy niche? [tweetable]Natural Language Processing (NLP) technology seems to be the key to mass market adoption[/tweetable]. Can that interface scale across thousands or millions of apps, or will it be dominated by a few key players and use cases?

the_rise_of_the_chat_bots

An old idea

[tweetable]Chat bots – apps that communicate via a textual, conversational interface are nothing new[/tweetable]. A convincing conversational computer program has been a goal of artificial intelligence research since Alan Turing proposed his famous test in 1950. As long as there have been chat-rooms, including the bulletin board systems that dominated the Internet before the invention and adoption of the web, there have been chat bots. Even commercial scale and conversational access to internet services are far from recent developments. The SmarterChild bot on AOL Instant Messenger and MSN Messenger (now Windows Live Messenger) had 10 million active users and processed 1 billion messages per day. It provided access to news, weather, sports, a personal assistant, calculator etc.

New scale & changing habits

Why the renewed excitement in chat bots? Two reasons – mobile messaging scale and enterprise messaging growth. Third party mobile messaging apps are rapidly heading towards 2 billion active users globally. These apps are typically the most used on any mobile device. Following the model of Asian messaging apps WeChat and LINE, the owners of other messaging apps want to turn them into platforms. At the same time, Slack is attempting to create a platform out of their enterprise messaging product. [tweetable]The impressive growth of Slack in the enterprise, where people are actually happy to pay for software[/tweetable], means a lot of entrepreneurs would like to ride their coattails to success. There are two separate markets here, with a common interface and some common technology.

Better technology for smarter chat bots

It’s the improvement in that common technology, particularly for NLP, that leads many people to think it might be different this time. Conversational interfaces might finally be able to deliver a great experience. However, there are some tradeoffs here for developers. One appealing aspect of a textual interface is that it can be much less effort to develop than a mobile app UI. Unfortunately NLP research has been disproportionately focused on English so far – the technology isn’t as good in other languages, so these interfaces automatically have a more limited audience. The more sophisticated the NLP, the more work involved in developing the interface. Using a 3rd party NLP service can significantly reduce this effort but also removes a key source of differentiation if your product is only a chat bot. Without NLP a bot is either focused on a very specific task or only for power users – mass market consumers aren’t going to want to memorise a lot of specific command syntax. At the other end of the NLP sophistication spectrum, is it going to be viable trying to compete with the likes of Google and Facebook as the best way to access mass market services?

Will Facebook own the consumer market?

Telegram’s bot platform might seem interesting as it reduces the need for NLP (and typing) with dynamic custom keyboards but their reach is a tiny fraction of the likes of Facebook Messenger or WhatsApp. Unfortunately [tweetable]Facebook doesn’t have a good record as a developer platform provider[/tweetable], which they managed to prove again recently, if such a reminder were needed, by announcing they’re shutting down Parse after promising developers their backends were in safe hands. Indeed chat bots on the big consumer messaging platforms may have some success at first but it’s likely to be the platform owners that take the lion’s share of the revenue in the end. These platforms will probably be great for businesses to reduce marketing and customer support costs with chat bots and they’ll be paying Facebook (and possibly others) for the privilege of talking to their customers in this way. There are probably also good opportunities for smaller developers to help companies build these bots.

An opportunity to differentiate enterprise services

The enterprise opportunity is different. As a growing number of companies reduce their email usage and build workflows around chat in apps like Slack and HipChat, the most natural way to access some premium services will be through chat (at least for some use cases). For example, when discussing past sales, or future sales projections, it would be much more natural to ask an accounting, or forecasting SaaS tool to give you a chart for the relevant period than to switch away to another application to look that up. However, as with most of the obvious examples you could imagine, it’s unlikely that these services would operate entirely through a chat interface. It doesn’t make much sense to enter all of your accounting data via chat or build your sales forecasting model that way. As such, chat bots become just one of many interfaces to a cloud service. There are opportunities for new services to get discovered, or existing services to gain market share, by being early to support chat interfaces but 100% chat-based is unlikely to be a giant new market.

Evolution not revolution

In most cases, consumer or enterprise, conversational interfaces are just another channel. Much like mobile apps are just another channel for many services. They can be a channel that increases convenience or reduces friction for some key use cases. This also follows mobile but their increased convenience and usability lead to a massive increase in total use. The change messaging platforms will bring is nowhere near the same scale as the shift to mobile. The things that were really interesting on mobile were the ones that couldn’t be done, or were too inconvenient to bother with on desktop platforms. What new possibilities do conversational interfaces bring on mobile platforms? What mass market use cases haven’t already been tried (and widely under-used) by Apple with Siri? The most interesting areas are probably those that involve some element of discovery – when you don’t know which app to go to – or embrace the asynchronous nature of messaging. That said, how do you discover a new chat bot to help if you don’t know what you’re looking for? What business models would work for a purely conversational interface? The chat bots may be on the rise, but it’s likely this is more of an evolutionary step than a revolutionary one.

Categories
Languages Platforms

The Significance of AlphaGo: Has a golden age for artificial intelligence just dawned?

artificial intelligence

In recent years artificial intelligence (AI) has returned to the forefront of technological debate. That debate has moved on from when, and even whether, computers will ever display intelligent behaviour to how smart they will get, how quickly, and what the implications are for society. Although there are multiple approaches to creating AIs, the ones that involve machine learning from large datasets are generally outperforming all others. The results from such systems are often so impressive that large companies are rushing to hire data scientists, collect more data, and apply the latest machine learning techniques to inform their management decision making. Google’s DeepMind team recently demonstrated that without any human in the loop they can build a system that makes complex strategic decisions better than a human expert. Their approach suggests a way forward for building such systems in many diverse fields.

Machine_learning&artificial_intelligence

The game computers couldn’t beat

The announcement from the DeepMind team that their AlphaGo program had defeated the European champion at the game of Go was a highly significant landmark in AI. Not only did they accomplish a long-standing ‘grand challenge’ in AI and surpass rival Facebook’s efforts by an enormous distance, but the way the system works is in many ways very human-like. At first glance it’s easy to dismiss game-playing AI systems as not immediately applicable to real-world problems. The ‘world’ the AI operates in is incredibly simple compared to our physical world – in the case of Go, a 19×19 board where a black or white stone can be placed on each intersection. However, [tweetable]advances in AI from the pursuit of better Go playing programs are already being used[/tweetable] in real-world applications elsewhere. Also, the ‘deep convolutional neural networks’ that AlphaGo uses to ‘perceive’ the board are similar to those currently being employed to push forward the state-of-the-art in image and speech recognition, as well as natural language processing.

It’s different this time

Back in 1997, IBM’s Deep Blue beat the world Chess champion, Garry Kasparov. How is this different? First, Go is significantly more complex than Chess. There are nearly an order of magnitude more moves possible from every position and each move can have a bigger impact on the strength of a player’s position. Second, Deep Blue used a supercomputer and some hand-crafted heuristics to effectively do a brute force search of all reasonable future move combinations to pick the best move to make next. This was nothing like the way a human would play Chess and also not generalisable to other problems.

In contrast to Deep Blue, AlphaGo combines two deep convolutional neural networks with a Monte Carlo Tree Search algorithm to select moves in a way that’s quite similar to the way a human would play. The first neural network, called the policy network, picks a few promising positions for the next move. A human player doesn’t systematically evaluate all possible moves, rather through experience they develop an intuition for moves that should make their position stronger. They would struggle to explain why they selected a specific move over others in many cases. This suggests they’ve developed a model for how to play that exists below their conscious awareness. AlphaGo’s policy network is trained to predict the moves that expert players would make using a dataset of 30 million different positions from real games. The second neural network, called the value network, estimates how strong any given position is. It was trained, simplifying slightly, using the results of the policy network alone playing against itself from 30 million distinct positions. The Monte Carlo Tree Search is then used to look ahead from each move selected by the policy network at the opponent’s likely responses and AlphaGo’s subsequent moves. However, rather than search all the way to the end of the game, the value network is used to evaluate the end position after a sequence of moves. This is also similar to human play, looking a handful of moves ahead to assess the probability of gaining an advantage with each possible move. The lookahead searches are shallow (constrained by the processing power and time allowed for a move) and yet the results are better than existing leading systems that look much further ahead but with much less sophisticated move candidate selection and position evaluation capabilities.

Widely applicable artificial intelligence

This might all still sound a long way from a truly human style of thinking but if we abstract and generalise it slightly then it becomes more familiar. For any goal-oriented behaviour in a complex or changing environment we can assess our current situation versus our goal and generate some options for moving towards the goal. We can then simulate or predict the results of taking those actions and evaluate the new situations we could get into. We choose the option that moves us closest to our goal, or has the highest probability of moving us closer to that goal. This is just a description of iterative planning.

AlphaGo has shown that we can train a machine-learning system to emulate the options a human would select in a relatively-complex environment. If we simulate the immediate results of those selections we then just need to evaluate where we get to with each option. Again: machine learning comes to the rescue. If we can acquire or generate enough data we can train another machine learning system to perform the evaluation. None of this is really a new idea but now it has been demonstrated to be good enough to beat a professional at Go, it’s a fair bet it can be made to work for a huge range of other problems too. This is possibly why it’s such a landmark for AI research. It’s a challenge that until very recently was thought to require a completely new breakthrough in AI and probably another decade of research (and Moore’s Law) to get us there. It turns out the techniques we’ve already invented, when suitably combined, can achieve very intelligent behaviour.

Dawn of a golden age?

There’s an outside chance Go just happened to be a lot easier than we thought, or just unusually suited to these ‘deep learning’ techniques. However, given the progress that’s being made with deep learning on other longstanding AI problems it seems more probable that [tweetable]we’re about to enter a golden age for AI[/tweetable]. In this context it’s interesting to note that AlphaGo beat the European champion a month before Google opened the source code for their TensorFlow deep learning framework (which prompted Microsoft to follow suit with theirs). These open source moves can be seen as part of a land grab for talent and mindshare. The techniques are the subject of published research and efficient implementations are valuable but nowhere near as much as the data required for training and the talent to utilise it. Then of course, Google, Microsoft, Amazon and a bunch of startups will all offer managed solutions for training and running these kinds of framework on their clouds. As the significance of DeepMind’s accomplishment sinks in, more researchers and developers will rush to jump on the machine learning bandwagon and there will be no shortage of tech giants waiting to welcome them aboard.

Categories
Platforms

Facebook Messenger: All your numbers are belong to us

Facebook started 2016 with the bold claim that it intends to eradicate phone numbers and replace web browsing, but the Social Network has a mountain to climb before Facebook Messenger becomes the centre of our online world.

New-Report_Final

That’s the stated intention of the Zuckerberg empire – to replace all our myriad internet communication systems with one interface.

Facebook claims that its Messenger app has been installed 800 million times, but at VisionMobile our latest research shows that those installations are very much concentrated into the lower end of the market.

If Facebook is going to recruit the shops, taxi companies and airlines it needs to make Messenger a one-stop internet shop it will need to get the app installed across the demographics before Microsoft (with Skype) steps in to take the cream.

[tweetable]Facebook has long known that the days of pokes and personal walls are fast disappearing[/tweetable], and has quite a history in struggling to adapt to whatever the future might bring. Facebook Gifts/Credits/Deals/Questions/Beacon haven’t lit up the future, so now the company is betting on messaging, and value-added messaging platforms.

Such platforms are proliferating in business. The bots that proliferate across Slack and Yahoo Messenger have turned those platforms into much more than messaging, but taking that functionality into the consumer sphere is much harder.

The medium is the Messenger

With that in mind, Facebook Messenger was forked from the main Facebook mobile app back in 2011, but messaging remained possible in the main app until 2014. These days, the Facebook app will notify you that a message has been received, but if you want to read that message then you’ll have to download and install Facebook’s new Trojan Horse.

That analogy isn’t perfect: the horse of Troy was disguised while Facebook has made no secret of its plan to migrate key internet functionality into the Messaging client. If Facebook can’t own the interface to your phone (it tried that), then it will own the interface to the internet, which the company believes will be Facebook Messenger.

The inspiration behind this idea isn’t hard to see. In China, where Facebook/Google/Twitter fears to tread, the competitive market created in their absence has driven huge innovation as companies strive to differentiate themselves with new features and functionality. Every month, 600 million Chinese are using Weixen, Tencent’s WeChat client, to book taxis, check into flights, play games, buy cinema tickets, make doctors’ appointments, and even manage bank accounts, all without touching the web browser.

[tweetable]In China, messaging has become the platform of choice for accessing a wide variety of services[/tweetable], and Facebook plans to replicate that model in the rest of the world – with it owning the messaging platform, obviously.

This process has already started with Facebook integrating Uber into its messaging platform. It’s worth noting that Uber isn’t integrated into the Facebook website, or the mobile client, but into the Facebook Messenger app.

vision_mobile_2

And Uber is just the beginning. As David Marcus, Facebook’s vice president of messaging products, makes abundantly clear: “We can help you interact with businesses or services to buy items (and then buy more again), order rides, purchase airline tickets, and talk to customer service in truly frictionless and delightful ways” – and that’s before Facebook becomes your personal assistant, Facebook M.

“Facebook M” starts listening in to all your conversations to suggest ways it can make your life more, as they say in such circles, “delightful.”

The Facebook wall will be supplanted by the Custom Conversation, providing a personalised interface (colour, style, emojis) for every chat thread. The visual equivalent of a ring-back tone, customised for every caller, will enable you to decide how both sides of the conversation see their interface, unless the other side has other ideas.

Walled garden of Zuck

In Facebook’s brave new world, everything is done through Facebook Messenger, and Facebook takes control of the delivery channel, removing that irritating “Open in Web Browser” which takes so much control away from the Social Network.

But that brave new world is predicated on the idea that people will install Facebook Messenger, rather than relying on the website, and email notifications, to stay in touch. Our research, in partnership with Celltick, looked at the top 10 applications installed on different handsets, and shows that while many low-end handsets do have Facebook Messenger installed, the application is almost invisible in handsets costing more than $200.

In high-end phones, Skype consistently rates top – well above the main Facebook application – and Facebook Messenger isn’t even in the top 10. In handsets costing less than $200, Facebook Messenger rates around four or five – a couple of positions below the main Facebook application, and very close to Skype.

What this means is that those who can’t, or won’t, invest more than $200 in a handset are happily installing Facebook Messenger, while those with a bit more disposable income are refusing to commit.

What it makes abundantly clear is the opportunity this presents to Microsoft. If messaging really is the future of mobile interaction, as Facebook seems to think, then Skype is perfectly positioned to grab the most important demographic.

If Microsoft were half as willing as Facebook to launch into value-added messaging, then it could make Skype into the messaging platform of the future, if indeed users really want such a platform at all.

You can read more in our free report, here (email address required.) ®

Article first published on the Register

Categories
Platforms

Self-driving cars are about platforms, not about cars

Transportation platforms

There is growing consensus that fully autonomous cars will become a reality by 2020. Google self-driving cars have driven over 1.2 million miles. Elon Musk, Tesla CEO, predicted in September 2015 that Tesla cars will have fully autonomous capability in 3 years. Zvi Aviram, CEO of MobileEye, a supplier of self-driving systems to many car makers, expects their technology will support fully autonomous driving by 2019.

Most traditional car makers still see autonomous driving as a feature of the car, rather than a market shift that will open the path to the creation of a completely new winner-takes-all industry. It’s just like PC makers focusing on adding connectivity to their products and missing the transition to the Internet platforms (Google Search, Amazon, Facebook). Or telecom operators focusing on adding always-on fast data connectivity to their networks and missing the transition to the mobile platforms (Google Android, Apple iOS).

Is the same about to happen in the car industry? Are car makers about to miss the transition to transportation platforms in the same way as PC makers missed the transition to Internet platforms and telecom operators missed the transition to mobile platforms?

The future transportation value stack will be very different from the existing automotive industry. It quite remarkable that only two companies, Google and Uber, are present in all layers of the stack that are necessary for creating a dominant transportation-as-a-service platform.

car-platforms-blog-image

The car hardware (the body, the power train, the wheels) increasingly becomes a commodity. Modern cars are good-enough for typical everyday use offering little opportunity for differentiation. Car commoditisation will only accelerate with the transition to electric vehicles. Electric vehicles are much simpler mechanically and easier to make, which opens the gates for new players, including such electronics and Internet services players like Apple, Google, LeTV and even Acer. It’s also notable that Tesla ‘open-sourced” their electric vehicle patents in 2014 pledging not initiate patent lawsuits against anyone who, in good faith, uses Tesla’s technology.

Autonomous driving is about guiding the car along the road, following the rules while avoiding obstacles and crashes. It involves lots of sensors, computing power and sophisticated software, but the most important part here is the ‘data’. Self-driving systems are machine learning systems that are trained to evaluate the environment and make fast decisions on how to react.

The ‘data’ represents all the collective experience learned by multiple cars driving in test and real-world conditions. The more cars you have on the road and the more miles these cars have driven in all possible conditions, the more experienced, safe and precise the self-driving system becomes. Google is undisputed leader here having its fleet of test cars driven over 1 million miles. Tesla’s Autopilot feature introduced in October 2015 on Model S cars will allow Tesla to start training its self-driving system in real-life conditions on tens of thousands of cars.

Uber seem to be behind in terms of putting real self-driving cars on the roads. The company poached 40 researchers and engineers from the Carnegie Mellon’s robotics lab in March 2015 and partnered with University of Arizona on optics research for self-driving cars.

Navigation is about figuring out which roads and streets the car should drive on in order to get from point A to point B. Google is again is a clear leader here with Google Maps and Waze. A consortium of German carmakers (Audi, BMW and Daimler) is trying to uphold an alternative acquiring the Here Maps business from Nokia in August 2015 for $3.1 Billion. Uber also works to create a proprietary mapping platform winning independence from Google and Here Maps. The company acquired San Jose-based deCarta in March 2015, absorbed part of Microsoft Bing mapping assets in June 2015 and has partnered with TomTom in November 2015 to use its mapping and traffic data. (Is Microsoft about to miss the huge opportunity in the future automotive and transportation markets?)

Fleet routing this is where it gets much more interesting. Self-driving cars combined with Uber-style on-demand services make individual car ownership less and less attractive. Some people even claim that hardware-as-a-service is the end game for Tesla. The shared usage models will turn car market into something that looks like a public transport platform, where operators will match in real-time the demand for transportation with the location and the capacity of self-driving vehicles. In other words, fleet guidance is about deciding in real-time where every car needs to go. Which car needs go to a specific pick up point? Shall the car drive to where the demand is expected in the coming 15 minutes? What is the optimal time to recharge or refuel? When and where to go to do the service and maintenance? Where to park, and more.

This is a very complex computational problem to solve at the scale required to support fleets of thousands of self-driving cars. Bill Gurley, one of Uber’s early investors, gives a glimpse into how difficult it is in his blog explaining why UberPool is the new Uber’s “Big Hairy Audacious Goal.” (BHAG). UberPool helps the company to build capabilities that will be directly relevant for the optimal routing of large autonomous fleets.

I’m sure Google is not standing still here as well. Being a machine learning company, it has the scale and the technical depth to become the leader in this space. Add to that real-time bidding capabilities with extremely complex optimisations that Google has mastered for its online ad business. One can even argue that building such transportation platform is the reason for Google’s interest in self-driving cars.

It’s very difficult to see how traditional car makers will be able to compete with software-centric companies in this space.

Finally, the transportation platform is the most intriguing part of the value stack. Moving people around Uber-style is not the only use for self-driving cars. What else can we do with the fully autonomous fleet of robotic vehicles, given that they don’t not have to look as Uber or Google cars of today? These robotic vehicles can be specialized delivery vehicles (see this Domino’s Pizza car as a hint for how they may look like), small delivery drones like Transwheel or StarShip or even autonomous motorbikes, like Motobot by Yamaha.

The number of possibilities and applications for autonomous transportation is mind boggling. No single company, even as nimble and well-funded as Google or Uber, will be able to address all possible needs and use cases by themselves. The recipe for addressing these yet to be known needs and use cases is in plain sight. It is a platform connecting vehicle manufacturers, vehicle operators, service providers and application developers with users (much like Google did with Android).

The platform will harvest permissionless innovation by startups and developers to discover and deploy new services and applications we cannot even imagine today – in the same way that no one could predict Instagram, Snapchat or WeChat on smartphones. Uber already works with developers extending its service into a platform. Google also has a long history of relying on permissionless innovation by developers to win its competitive battles, from Google Maps to Android. It’s only natural that Google will use the same approach to dominate self-driving cars.

It’s still too early in the game to say which companies will dominate the future transportation market. One thing is a safe bet: The future transportation ecosystem will look very different from the existing automotive industry. It will resemble modern technology ecosystems with their platform business models, permissionless innovation by developers, and domination of software-centric companies.

Categories
Platforms

Developers: builders or explorers?

open source

What do you think about when you hear the word “software developer”? Most people probably imagine a duffy engineer, turning his boss’s requirements into code. A software builder, so to speak. But developers are so much more. They’re often more like adventurers and explorers, boldly going where no programmer has gone before. This was never more true than at the eve of the Internet of Things. The most important role of Internet of Things developers is to explore new possibilities. The technology is widely available; in no small part because of open source software and hardware projects. Now we need to learn where we can take it. We can build it, but should we?

Why are Explorers so important?

Explorers are critical to any developer ecosystem, including in the Internet of Things. First, because that’s where all the truly new, out-of-the-box ideas come from. It’s hard to be super-innovative when you have a project to deliver to your boss or client. Only by exploring seemingly crazy ideas can the Internet of Things reach its full potential. The open source ecosystem is often the area where these ideas bloom.

Secondly, while exploring, Explorers gain a tremendous amount of experience. This will help them build their careers (as builders or otherwise). It also helps the companies that pay the bill. And it is needed. In Q4 2014, VisionMobile surveyed 4,000+ IoT developers. The lack of hardware development skills was the top challenge among IoT developers. 48% of IoT open source enthusiasts (those who find it important to use an open source platform) listed it as a challenge.

Learning and open source

VisionMobile’s data also shows that exploring, learning and open source technology go very well together. Among Explorers (developers that are primarily interested in gaining experience to seize on future opportunities), 20% value open source platforms and technology. That’s the highest level of any group. Conversely, Explorers are the biggest group among open source enthusiasts (32%).

Furthermore, open source is popular among developers that are new to IoT and new to software. A second group who value open source are seasoned software developers who bring open source business models to the Internet of Things. Traditional IoT developers with lots of experience underuse open source. In a way, these “experienced in software, new to IoT” developers provide another kind of ecosystem-level learning.

More data

Here are some more key insights about IoT explorers and open source enthusiasts that we summarized in an infographic, co-created with Arduino:

  • Open source is not just useful for building skills. It is also used by developers that want to increase efficiency (we call them Optimizers) and by developers that work on commission (Guns for Hire). This indicates that open source tools get the job done quickly, efficiently and inexpensively. On the other hand, developers are cautious about using open source technology in commercial products.
  • Open hardware in particular helps IoT developers to address their 3 main challenges: a lack of hardware skills, immature tools and high production costs. Arduino is clearly a leader in this space.
  • “Open” seems to be a professional philosophy that is applied on hardware, software and protocols alike. 60% of open source enthusiasts feel that open standards are missing from IoT, compared to 44% of other IoT developers.
  • All this doesn’t mean that open source has won everywhere. Some verticals, e.g. wearables, seem more difficult to address with open source technology and are therefore less popular among open source enthusiasts. Sometimes open source platforms struggle in the face of strong closed-source competitor. Smart Home platform OpenHab is a good example.

In conclusion, developer-explorers are critical to any developer ecosystem, and open source technology is an important tool to make that happen. I for one can’t wait to see what these modern-day Marco Polo’s and David Livingstone’s discover next!

open-source-enthusiasts-iot

Categories
Business Languages Platforms

Who, What, How, and Why: software development laid bare

Every six months we ask developers around the world those four questions, to see how the industry is evolving. Now in its 9th edition the VisionMobile Developer Economics survey reached out to 13,000 developers, from 149 different countries, and the results are available in our biannual report: State of The Developer Nation Q3 2015.

Who

94% of our 13,000 developers are male, showing a gender imbalance which needs to be addressed if the industry is going to reflect society as a whole. North America is making some progress here, but even in the land of opportunity only a tenth of developers identify themselves as female, and the figures of the rest of the world are much worse.

It’s perhaps surprising that Africa is next best in terms of equality, while Europe is positively embarrassing with only 4% of developers ticking the box for the minority sex. South America offers the greatest imbalance, but nowhere do developers reflect the proportion of women in the general workforce.

What

Cloud is increasingly important for developers, and cloud developers the most likely to be generating revenue (67% of them are bringing in more than $500 a month). But there’s no rush to the public offerings such as AWS or the Google App Engine, despite all the media attention: 44% of cloud developers are creating apps in private, for use on private clouds.

The Internet of Things is also getting a lot of developer attention, though more a quarter of IoT developers (26%) don’t know who their eventual customer will be. Half of those developers are making applications, rather than hardware or firmware, reflecting the evolution of the IoT industry.

When it comes to mobile the two dominant players (Android and iOS) are squeezing out the competition and 37% of mobile developers are targeting both the leading platforms. Interest in creating apps for Windows Phone has dropped slightly since we last asked, from 30% to 27%, but developers are understandably nervous of Windows 10 and the uncertainty over Microsoft’s commitment to mobile.

How

Across the developer community the most-popular development language is now a combination of JavaScript and HTML5. The evolution of web languages has imbued them with functionality, while cross-compilers and packaging tools can make them indistinguishable from native applications. That’s been enough to attract 71% of developers in North America, though only 58% in Asia where old-school languages such as Java and C retain their presence.

Learning a new language is always a challenge, though the growth in Apple’s Swift shows that developers are willing to invest in their education. Swift is, perhaps unsurprisingly, attracting a good proportion of self-taught developers (27% of those primarily using Swift consider themselves self-taught), while Java, C#, and Objective C, all appeal to degree holders (around 60% have degrees) who prefer a more-formal learning environment (around 17% are self-taught).

Why

Not all developers are motivated by money, in fact many professional developers are hobbyists or amateurs in another field. More than half of our mobile developers, for example, are also mucking around with IoT – some professionally, but mostly just to see what it can do, and what they can do with it. Developers are predominantly young, with an average age of around 30, and have both the time and the motivation to explore new areas. Many are involved in open-source projects: 11% tell us that Linux is their primary desktop target platform, despite the fact that the open-source OS accounts for less than 2% of desktop installations.

In mobile the path to revenue, if not riches, is clearly selling products and services, in the manner of Uber or Just Eat, rather than downloads and booster packs, in the manner of Candy Crush and Minecraft. Only 10% of mobile developers are chasing e-commerce revenue, but almost a fifth (19%) are taking more than $100,000 a month – a figure that only 6% of those reliant on advertising can match.

The State of the Developer Nation

The whole report, complete with graphics and figures, is a free download, and packed with more insight and analysis from Vision Mobile.

Categories
Business Platforms

Business Model combines Magic and Algorithms in Mobile Gaming

app success

Two years ago, I stepped into the mobile games market when I joined Planeto in Malmö, Sweden. With more than 5 million downloads, Planeto is a leader in knowledge-based mobile gaming. The experience at Planeto has changed me as a product creator and marketer.

Like many of my Scandinavian tech colleagues, I come from the planet where they build mobile phones. One step up the software stack to apps did not seem like a huge leap, especially as Planeto develops games for smartphones. As it turns out, one of the most talented game designers in Southern Scandinavia took me to a planet that was significantly different.

This is the third and final blog of a three part series on battle insights by a mobile game CEO.

Mobile Gaming as a Business

[tweetable]Even today, game designers prefer the traditional model of being paid up-front for games[/tweetable]. This business model allows them to devote most time on what is important to them, namely the game and it’s magical game play loop. Our world of algorithms has, however, made Free-to-Play (F2P) the dominant business model for successful games. Free is very powerful as a digital marketing tool for skillful individuals who are able to combine great gameplay with algorithm-winning distribution and marketing.

Ad revenue and In-App Purchases (IAPs) are the two traditional revenue sources in F2P games. Developers mix the two in different quantities depending on the game genre and design. Let’s explore one by one, before we look at the next possible frontiers in the mobile games business.

Getting the User to Buy Everyday

In our first game, we had one item for sale, namely a premium upgrade. This is not a good business model when your game has strong retention. We still have customers today who played our games nearly three years ago… incredible! These users love our games and, in our original game, their maximum spend was $2.99. That was it for three years of entertainment. 🙂

By implementing lifelines, offering new question packs, and decoupling game boards from the premium upgrade, we have in subsequent games removed the limit on how much money you can spend. Our best customers now spend more and in return we offer more features and content. A much better relationship than the original fire and forget model.

Because of this ongoing relationship, we also have become much more generous. We provide the users with some in-game currency for free, so they can try the different lifelines and game boards. That drives up our conversion, as the users get familiar with our in-game currency early on. Contact to support also triggers free stuff!

Third, we actively work with conversion of users through campaigns where we make seasonable items available either free or at heavily discounted rates. We have had great success with our X-mas tree game board. 🙂

Finally, our lifelines are micro purchases offered at a time where the user is most willing to spend – very similar to the extra turns in Candy Crush Saga.

Good IAP design is hard, and it needs to be closely integrated with the core game play loop.

Advertising as an Ongoing Adjustment Process

As mentioned in “The Science of Mobile Game Marketing“, F2P games need an ad mediation layer to be successful in the advertising space.

First, you need a mix of different types of ads from incentivized video, over normal video, to static interstitials, and banner ads. The mix allows you to adjust the ad types over the lifecycle of the user. Advertising is not something users love, so you want to avoid intrusive ad formats, like forced video ads, early in the lifecycle of a user. Later they might make sense depending on your game.

It is also important to ensure you drive up your fill rate. You will not have sufficient video ad inventory from one network available at all times, and hence you should backfill with interstitials from other networks.

Finally, you need to be able to play the different ad networks against each other to ensure the best possible CPM. The ad intermediation layer allows the developer to switch between many different ad networks and adjust advertising volume by network. On top of the automated CPM-based adjustments made by the mediation layer, we adjust our volume by network each week to make sure we get the best CPM per country.

Each advertising network has its own logic when it comes to buying advertising space in games, but generally speaking we’ve also seen that ad networks take advantage of developers who are stale, i.e. developers who do not tweak the number of impressions per ad network. So if you leave your ad network distribution untouched for more than two weeks, expect your revenue to start declining.

Tweak and learn!

The Real World as a Revenue Opportunity

Game developers often use other brands for marketing. Whether it is Kim Kardashian, CR7, or FIFA, it is obvious that real world brands sell games. Integrating the real world into games does not necessarily need to be a royalty expense. In fact, this can be a great opportunity for business model innovation in the mobile games market.

Brands, people, and organizations are finding it increasingly difficult to engage with their stakeholders in a positive, meaningful way. Designed correctly, games can be one such path.

At Planeto, we have worked with brands to create question packs about a specific topic for TV stations. One TV station worked with us on a question pack on the Premier League – they wanted to engage their viewers on knowledge about the Premier League. Another TV station wanted 250 questions on fashion for the Copenhagen Fashion Week. Great fun for our users and excellent exposure for the brands.

Think about your game – how can the real world increase your revenue or extend the lifecycle of your game by bringing in brands, information, or other stuff that your users care about? Be creative – people care about more than just celebrities and TV shows – what about the city you live in? Nature? Politics?

Big Data as a Revenue Opportunity

As we live in a world of algorithms, game developers have more information about their users and their users’ behavior than any other industry out there. Where traditional industries are looking to build up data about their customers, it often feels like we have excessive amounts of data in the mobile games industry.

Taking advantage of user data requires a thorough understanding of privacy – both from a legal perspective, but also from a product perspective, i.e. what value do you bring to your users and when you decide to generate revenue from data? Privacy must have priority over any revenue considerations. There are, however, cases where the two can go hand in hand.

In the past, we have successfully offered our users a free upgrade in return of receiving an offer for a popular science magazine subscription. This is a reasonable trade-off for the user. They know an upgrade costs $2.99. They know they will be offered a magazine that aligns nicely with knowledge-oriented games that they are playing. For that, they are willing to provide an email or a phone number.

Aggregated knowledge about the users might also be valuable. If you have personal statistics, high score lists, or achievements, could other stakeholders get any value from them, if they were presented in a slightly different way?

I would love to throw a game designer and a big data entrepreneur in a room for a few days to build a truly innovative game where data is the core monetization source.

…and We Are Only Just Beginning

These are only two examples of frontier-type business models. There are many more.

Education: I am not a big fan of the 1st generation of brain training apps. They are generally not fun to use and need such a huge commitment that they are unlikely to have any effect for 99% of their users. In the end, I do believe we will become better at using games for education. We are just not there yet.

Media: The traditional media industry is going through a tough spell at the moment. Great games where entertainment is integrated at the core of the game could be the future for some magazines, newspapers, and TV stations. SMS voting is one step in the right direction, but there must be more revolutionary designs waiting to be discovered.

Social: Games are good at bringing people together around a common interest. “Play first, date later!” could be an interesting business proposition to pursue.

I believe the next generation of big mobile game innovators will find business models that integrated a magical gameplay loop in weird and wonderful ways with the world of algorithms. What other innovative gaming business models have you seen or would you love to see?

Categories
Platforms Tips

4 out of 10 sites unaware of the Google’s new Mobile Ranking Signal

mobile ranking signal

A variety of mobile devices have flooded the Web in the past years. To no one’s surprise, Google announced that starting April 21st, they’ll expand the use of mobile-friendliness as a mobile ranking signal, in fact penalizing all sites that don’t have a mobile strategy – dubbed “Mobilegeddon” in the recent press.

Furthermore, Google just paid $25 million for exclusive rights to the “.app” top-level domain. Although the company hasn’t yet announced any specific plans for .app, this could be the signal that the Mobile Web will evolve beyond Responsive Web Design (RWD) and lean more towards rich UX/UI and mimicking of the native environment.

Presumably, [tweetable]the update to their algorithm will have a significant impact on Google’s mobile search results[/tweetable]. If you’re like me, you’d want to go all the way and find out the specifics: what is the current distribution of mobile web strategies, how many websites will be impacted by this change and to what degree? If you already have a mobile web strategy in place or just started developing one, you’d probably also want to know how to optimize it: how “lengthy” should your pages be or how “heavy”? And what Google’s PageSpeed Insights has to says about it?

We have searched the answers to these questions by analyzing the top 10,000 Alexa sites, from 5 different categories: News, E-commerce, Tech, Business and Sports. What we discovered was no less surprising and we felt like this is something worth sharing with the community. Before diving into the data let me tell you a few words on the methodology.

As per Google’s guidelines, we have taken into consideration three types of configurations for building mobile sites:

google-table

Google recognizes three different configurations for building mobile sites. (Google Developers)

  • Responsive web design: serving the same HTML code on the same URL, regardless of the users’ device; render the display differently based on the screen size.
  • Dynamic serving (also known as adaptive): using the same URL regardless of device, but generating HTML code dynamically by detecting the browser’s User Agent
  • Separate URLs (also known as mobile friendly): serving different code to each device and a separate web address for the mobile version

To detect the strategy used by different websites, we have crawled them using an iPhone User Agent.

Mozilla/5.0 (iPhone; CPU iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3

On top of that, we also identified those sites that implemented a Smart App Banner meta tag in the head of their home page, to market their iOS app:

<meta name="apple-itunes-app" content="app-id=myAppStoreID">

For analyzing the performance, we have used the PageSpeed Insights API, which takes into consideration not only the size of a webpage, but also compression, server response time, browser caching and landing page redirects, among others.

We also wanted to see how long mobile pages have become. Since RWD relies heavily on scrolling, we asked ourselves if this is an effective way to display content and what can be considered an optimum page height. Throughout the rest of the article, you’ll see references to “X5” height rate, which means that a site’s main page height is 5 times the height of the viewport on iPhone 6 (375 x 667). This is an indication of how much scroll needs to be done in order to reach the last piece of content.

visionmobile-infographics

Overview of Mobile Strategies on the Web

It’s 2015 and if you think that RWD is winning over mobile friendly sites (separate URLs), you’re spot on. Nearly 28% of the sites we’ve researched are responsive, while 26% have opted for a separate mobile address. The gap is indeed there, but it’s not as wide as we might have assumed. The surprising fact is that 40% of the researched sites have no mobile web strategy whatsoever! To me, that’s HUGE! Since Google’s new algorithm update is just around the corner, we can easily imagine that ignoring mobile users will no longer be an option.

Deeply buried in the data, we’ve also found another interesting fact: approximately 4% considered that being adaptive (serving different content under the same web address) is the right strategy for their mobile web presence.

2% of the researched websites have chosen to target their mobile users through applications (iOS). The number may in fact be bigger, but the inconsistency in promoting their apps makes them difficult to track.

Let’s dig a little bit more and see the variations between different categories and the impact that each strategy has on the overall mobile experience.

Newspapers – resistive as always

Being “stuck in the past” seems to be rightly attributed to the publishing industry, especially to newspapers: 38% of the websites from this category are mobile-friendly (separate URLs) and only 25% responsive.

In the PageSpeed Insights (PSI) results, adaptive comes on top with 75% scoring between 40 and 60 (although only 15% are above 60). Interestingly enough, mobile-friendly sites score even better (19% with PSI > 60), while only 11% of responsive sites have a score higher than 60. In fact, most of the sites that score under 20 are responsive (10%).

Wait, what? I thought Google loves responsiveness, right? There are countless articles about how Google recommends RWD as the best way to target mobile users. Surely, something doesn’t add up!

Or maybe most of the responsive sites don’t comply with Google’s own recommendations. A plausible explanation might be that developers have mistaken Google’s love for good mobile experience with the love for responsiveness, thus taking Google’s guidelines for granted. Instead of taking advantage of RWD, they end up producing sites that score poorly on all aspects.

When looking at sites’ height distribution on mobile devices, we see that the average for mobile-friendly ones is X8, which is pretty close to the X7 average rate represented by adaptive sites. However, 54% of adaptive sites have a less than X5 height rate.

In all fairness, “old” doesn’t necessarily mean wrong for newspapers sites and this time it might be working in their favor: 47% of responsive sites have a X10 – X15 height rate and 14% even over X15, which means that mobile users have to do a lot of scrolling before reading a certain piece of content.

So why are mobile friendly pages shorter? Did they notice that not so “lengthy” pages are more suitable for reading content on mobile? Is that the reason behind choosing mobile friendly (separate URLs) over responsiveness? But if that’s the case, why not going all the way towards adaptive? They’re doing a better job in terms of producing closer to optimum mobile pages (averaged at 2.5MB for both mobile-friendly and adaptive, compared to 3.7 MB for responsive) so perhaps it’s the ease of managing a separate mobile site all together.

Looking at Alexa’s popularity ranks, we notice that as the rank decreases, the number of responsive websites grows. The majority of sites with a low popularity rank are in fact responsive (14%), while 53% of the analyzed adaptive sites place themselves among the top ranked ones.

Tech sites – leaning towards RWD

In contrast with the above findings, responsive sites predominate in the “Tech” category (33%), while only 12% are mobile friendly (separate URLs).

In addition to that, 58% have page sizes under 2MB and consequently – a higher score on PageSpeed Insights: 51% mark over 60 and only 1.5% under 20. A page size of 2MB might sound a bit too much, but in fact, caching and other factors are influencing the overall PSI score.

When comparing the results to the newspapers category, tech websites show a major improvement. Yes, responsive sites still have the biggest height ratio (X6), but the average is significantly lower than what we’ve found earlier (X8).

Unfortunately, the “Tech” category also has the biggest percentage of sites that have NO mobile strategy whatsoever: 51%. It would seem that we have either modern responsive sites or nothing at all.

Overall, adaptive sites are still the most efficient in terms of score, but responsive sites are stealing the 1st place when it comes to height ratio, with a slightly bigger percentage of websites having a height rate of X5.

E-commerce sites fare better than most

For the “Shopping” category, mobile-friendly (separate URLs) and responsive sites are at a tie: 26%. Surprisingly though, adaptive e-commerce sites scored the biggest percentage of all categories: 6%. What would cause e-commerce sites to lean towards adaptive?

One plausible reason can be their appetite for improving conversion rates, thus their attention to optimize everything related to the buying funnel, which is influencing their mobile strategy as well.

If we analyze the height distribution for all three configurations (separate mobile URLs, responsive and adaptive), we see a pattern emerging: e-commerce sites, regardless of their mobile strategy, have the biggest percentages for under an X5 height rate: 90%, 58% and respectively 81%.

One could speculate that the reason for keeping their pages shorter is related to the influence that a lower height ratio might have on conversion rates. On top of that, PageSpeed Insights offers the highest score for all three mobile strategies: ~90% of mobile friendly/adaptive sites and 75% of the responsive ones have scored at least 40 points.

[tweetable]Clearly, e-commerce sites are doing a great job at optimizing for mobile[/tweetable] and, regardless of their favorite strategy (adaptive sites seem to be leading by a low margin), they’re mastering it like no other.

Apps – still luxurious game to play

Among other categories, we’ve found that mobile applications are appealing too: close to 6% of sites from “Business” and “Sports” have created their own iOS application, even if most of these previously opted for mobile friendly sites: 9% respectively 15%.

As a general rule, regardless of the category, if a site doesn’t have a mobile web strategy, chances are it won’t go for an application either. You’d expect it to be the other way around, but if a site owner ignored all previous mobile web strategies at his disposal, would he really be open to a more laborious and expensive approach (apps)? Not really.

Optimum Height and Page Size on Mobile

Analyzing ~10,000 sites in various categories surfaced a couple of guidelines that you might want to take into consideration when implement your mobile web strategy. In essence, what’s the maximum height and page size that your mobile friendly, responsive or adaptive site should have to ensure a 50+ PageSpeed Score?

If we analyze page sizes less than 2M, we realize that mobile-friendly sites, particularly in the Sports category, come on top with little over 91%. We also notice that only 30% of responsive sites score over 50 on PageSpeed Insights. Again, just keeping the page size at this level isn’t enough to ensure a high PSI score since caching can be equally important, but it’s a good place to start.

Interestingly enough, the “News” category is the only one where the majority (52%) of the adaptive sites with scores over 50 has page sizes between 2MB – 4MB. Even if adaptive sites seem to be able to “carry” more weight, their height rate should be kept at the minimum (X5) to ensure a good score.

Applying the same logic to height rates, clearly X5 seem to be the optimum rate for scoring 50+ on PageSpeed Insights. Once more, responsive sites seem to have the least chances of scoring over 50, even if they aim for a lower height: 62%.

Is the Mobile Web Heading Towards “Appification”?

[tweetable]Today, mobile web consumption occurs mostly from in-app browsers[/tweetable]. Just look for example at the Facebook app, that used to open links by using an external browser. Now, they have embedded a browser directly in the app and it makes sense – they don’t want their users to have a broken experience.

With that in mind, shouldn’t mobile websites offer a more app-like experience? Isn’t the linear scrolling experience we see on responsive sites a bit outdated?

In all fairness, what we’ve concluded thus far doesn’t take into account various UI/UX aspects and doesn’t answer some critical questions: When scrolling becomes too much for a mobile site? What’s the impact of having a long scroll and is this the reason for poor mobile reading experience on the web? What else can we do to ensure that mobile users have a good experience on the web?

That’s why in the second phase of the study we’ll analyze how much scrolling is actually being done on a responsive page, on mobile devices. After gathering relevant information on how mobile users interact with responsive sites we’ll be able to complete the next phase of the study by answering some key questions:

  • What’s the mobile device and browser they’re using for accessing a site?
  • How much time they spend on a particular page?
  • What’s the maximum scroll height they reached on a site?

From “Nice To Have” To Mandatory

We’ve seen that 40% of the top 10,000 Alexa sites from 5 categories (News, Tech, E-commerce, Business, Sports) don’t do anything when it comes to their mobile users. However, we’re in the middle of a big shift: [tweetable]having a mobile strategy on the web is no longer just “nice to have”[/tweetable]. If we take into consideration the impending change of Google’s mobile ranking algorithm, we can conclude that at this point any mobile web strategy is a good strategy.

As far as this first part of our study is concerned, from a technical point of view, a page that fits within 2MB and has a height rate of X5 has a good chance to score 50+ on Google’s PageSpeed Insights. Although adaptive websites are overall the most efficient ones regarding these aspects, they are not very popular either. Even though the study clearly shows that RWD is far from being optimum, responsiveness is the leading strategy adopted when targeting mobile users.

If we add to the mix the “.app” top-level web domain bought by Google, the line between native apps and web apps is getting thinner and thinner. The Mobile Web is already evolving beyond responsiveness into something new and exciting where everything is an app instead of a site, where user interactions are more important than just page views and ultimately where all apps are interlinked into a Web of apps.

If you are interested in learning more about mobile app development read the third post of our series on Mobile App Marketing, on Business Models.

Categories
Languages Platforms Tools

Why JavaScript will win on mobile

javascript will win on mobile

JavaScript is not the world’s most elegant programming language. So much so that one of the world’s top experts on the language wrote a book about “The Good Parts”. The book carries the headline “Unearthing the Excellence in JavaScript” because that excellence is quite deeply buried. Even so, it has rapidly become one of the most popular languages in the world. That popularity is deserved, because despite the flaws in the language, JavaScript gives developers significant advantages that they can’t get with other languages. Some of those advantages were created when browser vendors agreed to standardise on JavaScript (OK, technically ECMAScript) as the language for the web. Others are inherent to the web app programming model and more yet have been created through tooling enhancements. However, despite the fact that native apps are dominating web apps on mobile devices, JavaScript’s advantages are steadily transferring to mobile. Will it eventually dominate there too?

why-javascript-will-win-on-mobile

Popularity not priority

The latest TIOBE Community Index has JavaScript in 6th place amongst all programming languages and rising. The TIOBE method of ranking tends to favour older, more established languages and is not so quick to pick up trends. By contrast, the Redmonk rankings have JavaScript in first place. The Redmonk method is somewhat biased towards languages with strong open source communities but more accurately reflects current interest and trends. Our own Developer Economics surveys have shown that [tweetable]HTML5/JavaScript combination is the second most popular language amongst mobile developers[/tweetable] with 55% using it, just narrowly behind Java (at 57%). However, even if we combine those who prioritise HTML5 and JavaScript (19%), they’re still a long way behind Java (29%) on this metric. It seems likely this is going to shift significantly over the next few years. [What do you think? We have a new survey out, so take the survey and let us know your thoughts]

JavaScript breaking free from the browser

This is not a standard “the web will win” argument. I don’t believe that browser or webview-based apps will eventually dominate on mobile devices. Use will grow but they won’t be the norm. If true open web standards are to dominate in the future then they need to move on from the Document Object Model (DOM). The DOM is a base for building documents, not apps. Of course you can build an app around a platform originally designed for documents but you’re starting from a position of handicap. Look at the modern frameworks that allow you to build fairly performant apps for mobile browsers/webviews: React.js, Famo.us and Ionic. All three share the common feature of touching the DOM as little as possible.

Yes, there’s WebGL (or HTML5 Canvas if you must) too but those are low level graphics APIs. You need large, probably multi-megabyte, frameworks on top to create a good platform for building most apps. That’s not a good fit for the web app programming model, where the latest application code lives on a remote server, particularly not in a mobile environment. It’s true that you could have a hybrid app with a large framework on top of WebGL stored locally and just fetch the application specific code from the server but then why use the browser at all? Why not just JavaScript on top of some other cross-platform framework built for hardware graphics acceleration (hint: Qt has a nice offering here). One with a higher level API so there’s not so much overhead bridging between languages. Perhaps also one that’s less restricted when it comes to accessing device specific functionality.

There are now a couple of really interesting new options that fit this description, React Native and NativeScript. These work in different ways but both build apps with a native UI using JavaScript. Appcelerator’s Ti.Next may also be interesting, although they’ve been talking about it for a couple of years without an actual release yet, so we’ll wait and see.

The JavaScript exception

Here is where Apple has restored JavaScript’s advantage on mobile. A key thing that has prevented most developers from adopting an agile, web-style continuous delivery model on mobile is Apple’s ban on code downloading. Without that iteration is significantly slowed and split testing is much harder to do. This effectively means developers, particularly startups, learn slower. Until very recently, the only ways to get more rapid iteration were to go Android first, or build a hybrid app, since Apple made JavaScript downloaded in a webview an exception to the code downloading rule. In the first case it means moving away from the platform with the most early adopters. Unfortunately in the second case the UX trade-offs are too great, with most developers that went that route for a consumer app failing or switching to native. But in iOS 7 Apple added the JavaScriptCore interface to their own JavaScript runtime and in the latest iOS Developer Program License Agreement they modified the exception to code downloading rules to include JavaScriptCore.

This makes sense from a security perspective. Apple can audit and update their own runtimes, whereas if they allow 3rd party runtimes to download code they have no effective way of monitoring or dealing with security issues. Since JavaScript is Apple’s only scripting option and they can’t allow native code downloading, JavaScript is restored to a privileged position – the only option for those that want to iterate fast. The availability of JavaScriptCore triggered efforts like React Native and NativeScript and the timing of Apple’s relaxation of the code downloading policy has been perfectly timed for their public release.

Will open win?

Web advocates sometimes suggest that the open-standards-based web must eventually win because open always wins in the end. However, Linux is a very clear case where an open ecosystem thrives without a committee agreeing standards. With React Native, Facebook appears to be very rapidly building a developer ecosystem around their open source project. Already having a rapidly growing community around React.js obviously gives them a headstart but the NativeScript team at Telerik are working with Google such that Angular 2.0 should integrate seamlessly. Google are going to support non-DOM environments whether the web standards go in that direction or not. Microsoft and Google might take a long time to agree on the standards they’ll implement in their future browser versions but they’re working together on TypeScript, to make it easier to build complex apps with JavaScript (it turns out compilers are much better than people at spotting type mismatches).

Apple has built some fairly impressive tooling for their new Swift language, particularly the interactive playgrounds. However, Facebook possibly already has a better developer experience with React Native in terms of immediate feedback and rapid cycle times whilst coding. Apple will continue to iterate on that tooling alone, whilst the developer community can now enhance the tooling for these new JavaScript environments. Android may technically be open source but it’s not open in terms of community contribution. Google are enhancing the Android platform and tooling alone. [tweetable]Perhaps it’s really open developer communities that win[/tweetable] and genuine open source based communities can iterate faster than open standards based ones. For these “native UX built with JavaScript” environments to succeed, the platforms don’t have to lose. Apps will still be tailored to the platform look and feel and adopt new platform-specific APIs.

Javascript will win on mobile.

At the moment it looks like the very open JavaScript developer community will win because they get to build apps with native look, feel and performance but a web-style development experience. The closed platforms also win because apps are still being tailored for their captive ecosystems. For now, open web standards lose. It seems likely they can only win if the mobile browser vendors can agree to new standards that enable the creation of apps that genuinely offer an equivalent experience to native ones.

Update: Where we right in our predictions? Here is a latest update on the popularity of Javascript.

What do you use?

Do you think JavaScript will dominate on mobile in the future? Or Java, Objective-C and Swift will continue to lead? What about for the Internet of Things, or on the backend via Node.js? Let us know what you’re building your apps with by taking our survey.

Categories
Platforms

How Soon Is Now For The Mobile Web?

This may be the year when the mobile web apps finally go mainstream. Or, at least, their hybrid cousins will.

how-soon-is-now-for-the-mobile-world

Not because the technology will finally be ready. For most apps, it already is. Rather, the web will finally hit the big time with mobile apps precisely because we’ll talk about it less and use it more.

Time for HTML5
Oh, sure, there are good reasons for the mobile web to finally hit its stride. Sencha’s Nick Harlow offers five:

  1. High quality WebViews are now available on most platforms (and getting dramatically better thanks to Apple’s new WKWebView in iOS 8). While low-quality WebViews persist within the Android device base, on balance things are looking up;
  2. Broad platform support is only economically feasible using web tech;
  3. Web tech bridges the desktop-mobile divide;
  4. Using web tech helps to simplify application management and security; and
  5. Device fragmentation is accelerating. The web helps developers keep up

But before we herald the future of hybrid, it’s worth pointing out that some believe that future is already here. As EmberJS co-creator Tom Dale tells me, “”The dirty little secret of native [app] development is that huge swaths of the UIs we interact with every day are powered by web technologies under the hood.”

While Dale may be getting ahead of himself – [tweetable]the reality is that the web still has a long way to go to achieve mass-market app adoption[/tweetable], and maybe constitutes 10% of apps within the app stores – the trends do point toward more hybrid apps, especially among the enterprise set. VisionMobile’s own survey data shows that today 30% of developers are using some kind of cross-platform tool, of which 60% are using PhoneGap.

This is great, but it doesn’t obviate the need for the mobile web to get better to erase complaints about performance. And it will.

Getting better all the time
Summarizing the Google Chrome Developer Summit, Divshot CEO Michael Bleigh says, “Google is doing everything it can to get mobile web to 60fps, which gives you about 16ms per frame to do everything you need to do. It’s hard to even enumerate all the different ways they’re working on this.” Speed will bolster web app performance, perhaps eliminating the “jank” that many associate with web apps.

But it’s not just about accelerating the mobile web.

We also need to rethink how we approach mobile web apps, as Ionic (based on Google’s AngularJS) and React Native (from Facebook) do. While the latter is not “web technology,” strictly speaking, these frameworks are actively advancing the state of the art for web apps.

The result, as Mozilla (and longtime native app) developer James Long puts it, is impressive:

It only takes a few minutes playing with React Native to realize the potential it has. This works. It feels like I’m developing for the web. But I’m writing a real native app, and you seriously can’t tell the difference. At the UI level, there is no difference; these are all native UIViews beautifully sliding around like normal.

Indistinguishable from native performance… but with a far more accessible development platform. That’s powerful.

A question of competence
But let’s be clear: [tweetable]if your development team isn’t any good, it really doesn’t matter which development platform they choose[/tweetable]. A bad iOS programmer is going to lose every time to a good HTML5/web programmer, and vice versa.

Indeed, one of the primary problems with the web is that it so dramatically lowers the bar to development that virtually anyone with Javascript and CSS skills can build a mobile app.

A lame one, that is.

Mobile developer Nic Raboy nails this:

All my applications, native and hybrid, have mostly positive reviews and if you visit the apps on Google Play, you’ll see no reviews include mention about how the application was crafted. This is an important thing to notice because many haters will attack developers on the idea that hybrid applications do not perform or look as good as native applications. This is simply not true. Native or hybrid, if the developer or designer is no good, the application will suffer regardless.

So as fantastic as advancements like AngularJS and ReactJS will be for web app development, they’re not going to be enough if developers underinvest in learning them. There are already exceptional hybrid apps like Instagram that demonstrate what strong developers can do with the web. We just need more of them.

Or maybe what we need is better tools.

That’s one primary takeaway from VisionMobile’s “How Can HTML5 Compete With Native?” report. As report author Dimitris Michalakos concludes, “The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps.” Given that “HTML5 is like driving a car without a dashboard,” the key is to deliver better dashboards, or tools, to make it easier to build great web apps.

This involves significant improvements to the debugging, profiling, and memory management tools available, but it’s also something the web frameworks can help with.

As such, it increasingly looks like a question of WHEN, not IF, mobile web apps will take off.

And the answer to that question is either “now”, if you’re paying attention to how developers actually build apps today, or soon, if you’re waiting for them to start talking about the fact that they’re building with the web.