Categories
APIs Languages

Websites vs Web apps: What the experts think

websites-vs-webapps

Definitions of web sites vs. apps

Web sites are so deeply embedded into our daily culture that it is impossible to imagine life without them. Even as a developer, I find it hard to remember the times from my childhood when my chubby little hands didn’t yet know how to type. In the last two decades, the Internet has grown, expanded, exploded and became impossible to ignore, making any keyboard without an Internet connection pretty much useless.

In the last few years, the web brought with it a new term that can be exciting and confusing at the same time: “web app”. But what is a “web app”, how does it differentiate from a “web site” and why does it matter?

Understanding this difference ultimately makes us better users or developers? Is a business going to blossom just by marketing its online presence as a “web app” instead of a “web site”?

To figure out the boundaries between websites and web apps, I interviewed several prominent figures in the web technology domain who contributed with their experience and professionalism to help guide the debate: Dominique Hazael-Massieux (Mobile Web Initiative Activity Lead at World Wide Web Consortium), James Pearce (Head of Developer Advocacy at Facebook), Michael Mullany (CEO at Sencha), Christian Heilmann (Principal Developer Evangelist – HTML5/Open Web – at Mozilla Corporation) and Stephen Pinches (Head of Learning Technologies – ELT at Pearson plc and Group Product Manager – Mobile & Emerging Platforms at Financial Times). In this article I pieced together their expert input to help answer the web site vs web app debate.

The difference between Web sites and Web apps

In the pre app store era, the word “applications” had been applied to Web sites that provided advanced user interactions and capabilities previously available only through installable software. Early examples of web applications include Webmail, Google Maps and Google Docs. Compared to the classic web, i.e. blogs and news sites, web apps provided a richer user experience and access to advanced browser capabilities.

Today single-page web sites might still be referred to as web apps, but it’s more about the task focus than the technology itself. From this perspective, as Christian Heilmann explains, “The use case of an application is always to DO something with it”.

The task centricity of web apps is easier to understand if you think of smartphones or tablets: an app’s purpose is to achieve a specific task, like making a call, checking your email or finding a taxi nearby.

Some may argue that we can simply classify Web sites as being read-only and Web apps as being read-write. That certainly seems simple enough: Web sites are for consumption what Web apps are for creation. Does it sound right?

For developers, it is easier to draw the line between web sites and web apps if we think of the technical distinctions. Web apps have some defining attributes that bring them closer to their native counterparts:

  • self-contained
  • rich/interactive user interface, possibly mimicking the native UI of the device,
  • using advanced device capabilities – like geolocation, camera integration, or other technologies that the W3C Device APIs and Policy Working Group is developing,
  • action oriented rather than information oriented
  • not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, address bar),
  • working off-line, for example using HTML5 ApplicationCache, localStorage, or indexed database.

Mozilla’s Christian Heilmann argues that the offline attribute is not a technical necessity in terms of definition, but rather a crucial usability distinction:

“Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online”.

But how can we explain the difference to non-technical users? And, do we need to?

According to Dominique Hazael-Massieux, a Web site can be presented as a Web app as long as users consume it in a similar way they do a native app. If it’s exposed as an iconified app and used for a specific task, it shouldn’t matter whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web sites and Web apps. I‘ve summed up his arguments:

Creation versus Consumption

Pearce asserts that read-only interaction should be classified as a site, but this criteria is not sufficient to distinguish between web sites and web apps. We still have cases like Flipboard (clearly oriented towards consumption) or Twitter and Facebook (with entirely user-generated content) that do not fit in any box.

Linkability

Since both web sites and web apps can be launched by entering a URL into a browser or from a home-screen icon, this is clearly “not a reliable way to distinguish between web apps and web sites” according to Pearce.

User Experience

Visual pizzazz is an important argument, one that users might particularly relate to, but is also a fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list appears as hyperlinks instead of ‘tappable’ items? What if I use plain scrolling instead of smooth fancy bars?

Architecture

In the case of single page webapps, is SEO the price to pay when choosing to give the browser far more autonomy and responsibility and take advantage of its HTML5 APIs like storage? Do Web sites have SEO capabilities while Web apps don’t? We are back to explaining the differences between the two by using technical terms.

Should you be building web apps or web sites?

This question might be regarded as a technicality with a pinch of marketing to spice it up. This reminds me of the “HTML5 is ready” contest by Sencha that was announced a few months back, encouraging developers to draw inspiration from native apps and create similar web apps that show off the capabilities of HTML5.

The creators of the competition correctly argued that “the mobile web is the most fertile ground for leading edge web development because it doesn’t have the legacy of the older internet explorers that the desktop does. You can start your development with the assumption that your app or your content will be used in a fairly recent browser, so you can take advantage of a whole host of features like Canvas, inline SVG, HTML5 video, CSS3 styling etc. that bring the experience alive for the user”, as Sencha’s Michael Mullany explains.

Would it be safe to argue in favour of building web apps instead of web sites especially on mobile? Mobile users perform specific tasks on their devices, so a web app that offers the same experience as a specialised native app might gain more interest compared to a regular website.

Long term the distinction should not matter. According to FT’s Stephen Pinches, it really doesn’t make any sense, on the long term, to speak about the future of the mobile web: “there shouldn’t be “mobile” and “desktop” but simply good, user-centered design, which adapts and responds to the screen size and features of the device upon which it is displayed. However, on short to medium term, there is a need to differentiate and ensure the user experience is as good as possible on a given device.”

The ‘app-ification’ of the Web

Whatever your preference may be, there is an increasing number of mobile developers targeting web apps. Based on VisionMobile’s latest Developer Economics survey of 6,000+ developers, already 23% of HTML5 mobile developers develop web apps, compared to 38% who develop mobile websites.

With browsers increasing support for device APIs, and with a growing number of developers going direct to native with PhoneGap, Icenium or Appcelerator, or even with the recently launched Firefox OS, the web world is clearly moving in the direction of apps.

As Sir Tim Berners-Lee said in 2012, “the solution is in your hands: develop web apps!”

Categories
Tools

Cross-Platform Tool Trends – Freemium & Flexible

CPT trends

Creating versions of an app for multiple platforms (at least iOS & Android) is an increasingly common requirement. Building and maintaining native code for every platform supported is both difficult and expensive. Cross-Platform Tools (CPTs) offer a solution to this problem by enabling sharing of code across platforms and in many cases a single code base can target multiple platforms. With such significant cost savings available, why don’t all developers use CPTs?

Learning curves & licensing

Unfortunately the platform spanning magic provided by CPTs doesn’t come without any costs. Most CPT vendors depend on licensing revenue – developers have to pay to use the tools. Of course the cost of licensing most of these tools is far less than the cost of a full native port of an app to one additional platform. However, there are more costs associated with adopting a tool than the license fee; learning to use a CPT and building confidence in it’s suitability for future projects requires a significant time investment. The potential future cost of switching away from a tool that isn’t working out as hoped is also something that developers must consider.

The spread of Freemium models

In order to build sufficient confidence in a CPT to build their businesses around it, some developers need lots of time for evaluation, perhaps building a side project before risking major apps or customer projects. For many the 30 day trials that were typical in the sector just weren’t sufficient. One of the first mobile CPTs, MoSync, was very early to recognise this and had generous free options early on, they even went open source with a dual licensing model back in 2009 around the time many of their competitors were just launching. This year has seen a tipping point, possibly partly due to increased competition in the sector but also to capture a larger share of the ever growing demand for mobile development – Appcelerator, Corona, RunRev, Unity and Xamarin have all either switched to freemium models or expanded their free offering for mobile. RunRev has also joined MoSync in releasing their code under an open source license, Appcelerator have open sourced more of their code and Xamarin have just open sourced some of their cross-platform API wrappers. Having access to the code for the cross-platform layer can help remove developer fears of getting blocked by a bug in their chosen tool and being entirely dependent on the vendor for a rapid fix.

Technical tradeoffs

In many areas platforms are sufficiently different that it’s not possible to unify them under a single API. CPTs get around this in a number of different ways:

1) Not providing access to the problematic functionality – this restricts what developers can create.
2) Providing a lowest common denominator API – this prevents developers from using the full power of the native platforms.
3) Providing their own implementation of the functionality – this can bloat apps and often prevents them from having a fully native experience.
4) Providing thin wrappers or separate extensions for each platform – this gives maximum control but adds complexity to the code, reducing the benefits of a cross-platform approach.

Different apps, or even parts of apps, will have different priorities that determine which of the above approaches are acceptable. For example, a mass market consumer utility app is likely to require a completely native look and feel for the UI, while an internal app for a large enterprise may want to look and feel exactly the same on all platforms to minimise both development and staff training costs. The same tradeoffs won’t always apply to every part of an app either; most games have a completely custom UI and don’t require access to the native platform UI components at all, however, they may well want access to the new Google Play game services, or the iOS 7 Game Controller APIs as soon as they are available.

A flexible future

Faced with a still growing list of platforms to support and wide array of new features in each new platform version, CPT vendors now have to specialise for a sufficiently profitable subset of the market that has fairly narrow requirements or become increasingly flexible. Most vendors currently provide flexibility through a native interface that enables the creation of third party extensions or plugins. Xamarin’s approach to flexibility enables developers to (semi-)automatically generate wrappers for any native API or library, which is ideal for developers who want to stick with C# for all of their own code yet build on the work of native developers for each platform.

Even greater flexibility is possible though. What if you could just build the parts of an application that made sense to be cross-platform with a CPT? RunRev has a beta for an embeddable library version of their engine to enable this, although currently only for iOS. They are also re-architecting their engine to put 3rd party extensions on an equal footing with the core functionality – even allowing them to extend the language where necessary. Another interesting option going forward here is Digia’s Qt, the open source cross-platform framework that was acquired and re-purposed for mobile by Nokia before they dropped it in favour of Windows Phone. Qt is now the native framework on BlackBerry 10, Ubuntu Mobile and Sailfish OS and is close to production readiness for iOS and Android; it also has a Tizen port ahead of the release of that platform. The core of Qt being C++, it can easily interface with native code on most platforms and has always been delivered as a library, so it’s also embeddable within native apps.

Flexibility enables greater agility

This library format means that developers can start cross-platform and add or optimise parts of their app with native code later. It’s possible to just add a full native experience for the platforms that get the most traction. Alternatively, starting on a single platform and then adding new functionality that works across all platforms after achieving some success and starting to port to other platforms is also an option. Last but not least, the library format also removes any concerns about lock-in. If a developer decides to migrate away from a CPT, they can do so gradually, without having to port/re-write everything in one go. It’ll be interesting to see how many vendors can push flexibility this far and how many developers take advantage of it.

Categories
Tools

Rise of the Mega SDK Vendors in Mobile

transformer

Many would argue that the mobile platform consolidation in the form of today’s Apple / Google duopoly is a good thing for developers; less choice, but two mature platforms and a billion-smartphones addressable market. Despite the platform consolidation, developers face real challenges not just in developing, but also in prototyping, designing, marketing, selling and supporting apps.

The quality bar for apps is increasing; apps need to incorporate more functionality in a slicker UI, a sexier package (graphical assets and messaging), as well as through the right marketing channels and at the right price, which is usually free-to-try. App consumers are demanding, expecting utility, convenience and easy of use – all at a low or free price point with monetization shifting from paid downloads to advertising and in-app purchases. Enterprise apps have to talk to legacy systems, be an effective part of a company’s business strategy, enhance brand image, while being secure, reliable and cost efficient to develop and maintain.

To support the community of 500,000+ mobile developers globally, a new “SDK economy” has emerged to cater to the needs of mobile developers. A storm of over 500 SDK startups and Enterprise IT incumbents, have emerged since 2009 to help developers in everything from app prototyping and debugging, to user analytics, planning tools, and customer support. These days developers can choose from a gazillion tools to monetize their apps, test, monitor app performance, manage security, study user behaviour, cross-promote apps to attract & engage users, and manage API use and simplify use of cloud services.

Today most of the supporting infrastructure for app developers resides, within 3rd party developer tools, rather than within the platform itself. This SDK economy has become the critical infrastructure underneath the app economy.

Growth and consolidation in the SDK economy

The SDK economy has seen an impressive amount of growth and consolidation in the last 4 years. It’s also an economy that’s intensely suffering in terms of monetisation.

The very first SDKs or tools for mobile developers were App store analytics (tracking sales & downloads) from the likes of Distimo and App Annie. Then came ad networks (mobile-centric like AdMob, acquired by Google), later followed by web ad networks expanding to in-app advertising, with ad networks and servers now in abundant supply. Cross platform tools followed soon after, helping develop apps for more platforms, from a single code base. Led by PhoneGap and Appcelerator, the supply of CPTs has exceeded 50 vendors, practically making this area of the tools economy a red ocean.

Looking for investment opportunities, VCs began investing in the companies that support Enterprise and Consumer mobile app development. The VC capital created value but it also changed developer perceptions of value, by forcing tool vendors to offer base products for free. It also led to a string of acquisitions (see below), as covered in VisionMobile’s Developer Economics Q1 2013 report.

Table: Mergers and Acquisitions in Mobile Developer Tools

Company Product & type Acquired by Date
Aptana Development environment Appcelerator Jan-11
Metismo Bedrock Java-to-native source code translator Software AG May-11
TapJS Game hosting platform and API AppMobi Jun-11
TapLynx App factory Push IO Jun-11
RhoMobile Rhodes enterprise apps framework Motorola Solutions Jul-11
Particle Code HTML development tools Appcelerator Oct-11
Nitobi Makers of PhoneGap Adobe Oct-11
Strobe Web app framework and app management platform Facebook Nov-11
Usergrid Backend-as-a-Service Apigee Jan-12
Cocoafish Post-download app services Appcelerator Feb-12
Worklight Enterprise app platform IBM Feb-12
Chomp App store search and discovery Apple Feb-12
TestFlight Beta testing Burstly Mar-12
Trestle Back-end-as-a-service Flurry Jul-12
Appstatics App performance trackingservice Appsfire Jul-12
Instaops User analytics Apigee Aug-12
Cabana A tool to turn Facebook pages to mobile apps Twitter Oct-12
Nodeable Big data processing Appcelerator Nov-12
Crashlytics Mobile crash reporting Twitter Jan-13
Wavii Natural Language Processing Google April-13
Parse Mobile Backend as a Service Facebook April-13
Handmark/ OneLouder App Store & Mobile app advertising platform Sprint Nextel May-13
Proxomo Software Mobile backend technology Lucent Mobile May-13
Appshed Cross platform tool & App Factory IDG Group May-13
IrisCouch Mobile Backend as a Service Nodejitsu May-13
Aepona API exposure and monetization platform Intel May-13
Mashery API management and monetization Intel May-13
Staq Game management platform PlayHaven May-13

There are three reasons behind the consolidation of the SDK economy:

  1. Capital changing the perception of value. VC capital allowed tool vendors to offer developer products for free to accelerate user acquisition.
  2. The need to subsidise developer onboarding. Developers are always the side of a mobile platform that Apple, Google, Microsoft or BlackBerry will need to subsidise. As a result platform-provided tools will be usually free and 3rd party tools will be prime acquisition targets for platforms themselves.
  3. Catering to adjacent developer needs. There are substantial benefits to developers by integrating functionality across tools (e.g. ad networks with user analytics or crash reporting with performance management), which inevitably leads to acquisitions on tools that are adjacent in the developer journey. Catering to adjacent developer needs also helps tool vendors attract and, most importantly, retain their user base.

Who stands to survive and win in this ongoing consolidation of the SDK economy? As is already evident from the earlier M&A list, consolidation will become clustered around where developer money is flowing into: App Marketing Services & Enterprise Mobile Services.

App Marketing Services

Mobile Advertising is expected to be a 20B market by 2015. Traditional ad networks have already ported their existing products – banner advertising – over to mobile in the form of in-app advertising. This model doesn’t work well yet in mobile and is a factor in why traditional ad networks are not yet profitable.

One VC backed company, Flurry, followed a completely different path to capture app marketing revenue. Flurry recognized developers would first worry about the challenges of developing their app(s) and then worry about monetization. Flurry offered developers a host of tools (many of them free) to develop and track their app usage, built a relationship of trust with their developers, emerged as a leader in the mobile services market, and then launched a range of products that will help developers monetize their apps.

Flurry considered the developer journey and built a spectrum of solutions to engage developers from the beginning to the end of that journey:

  • Analytics: a free service to measure actual use of the application
  • AppCloud (free): a back-end as a service
  • AppSpot: helping developers monetise, once an app has achieved traction
  • AppCircle: where developers can re-engage, promote and reach out to more users

Flurry is capturing the lucrative app monetization dollars because VC funding gave them a head start. With strategic acquisitions like TrestleApp (a backend service startup that helps developers minimise backend coding) and giving away their analytics for free, Flurry is building the first true mobile, data driven (Big Data) ad network.

Other companies are understanding this formula and making a play for App Marketing Services. Burst.ly acquired TestFlight earlier this year in a bid to become the vertical solution that covers all developers’ needs. Similarly, Facebook wanted to reinforce its relationship with developers and did so by acquiring Parse, a BaaS service. This acquisition reflects a growing trend where non-mobile companies see developers as platforms rather than customers, and developer tools as routes for customer acquisition, rather than feature enhancement.

Enterprise Mobile Services

Enterprise IT needs are different from consumer app needs. In enterprise apps, companies are less concerned with advertising or virtual good purchases and care more about security, stability, predictability and scaling down costs of mobile development and maintenance. Enterprise apps take performance, security and systems integration much more seriously than virality, direct monetization and high engagement.

So which mobile tools do enterprises need? User analytics, app performance analytics, crash reporting, integration with existing business logic (connectors with SAP, Oracle, IBM), identity management, data security, and own app store distribution, to name a few.

In enterprise IT, the incumbent back-end systems players like SAP, IBM and Oracle have been in the space for years and are very well positioned to ride the enterprise mobility wave. They stand as a formidable wall, deterring smaller vendors from entering the enterprise mobility market because they “own” the back-end and related ecosystems (including solution providers and integrators) within the largest companies. Mobilising those “owned” back-ends by 3rd parties is expensive because of the licensing schemes imposed by the incumbent back-end vendors.

At the same time, a wave of smaller, more nimble vendors is making a play at enterprise mobility. Appcelerator, after failing to effectively monetize their cross-platform tools, is now making a vertical stack play, much like Amazon AWS, for mobile. They help developers of any platform access traditional services, such as user management, object persistence, push notifications and analytics via API calls to their cloud services or on-premise installations of their suite. Apigee announced a new product aiming at Mobile, offering user analytics, performance management, crash reporting and network analytics. All of these players clearly want to offer much more than a product that focuses on a tiny vertical or niche market. On the server side, there are tools like Splunk, which give insights into how an app is performing, identify bottlenecks and discover patterns. These tools don’t exist yet in Mobile, and big players, like New Relic, just entered this space. At the same time, the back-end incumbents are strengthening their mobile play. IBM has laid out a mobile strategy that wants to bring in Mobile as part of a more traditional IT strategy. The recent acquisition of Tealeaf aims at helping traditional business better understand and analyze their mobile audiences.

Consolidation is already playing out within enterprise mobile services.

As the mobile market heats up, we agree that consolidation will likely result, as larger vendors look to shore up their mobile service offerings. Operational tools, especially those that deliver critical capabilities for monitoring the performance of mobile platforms and the web infrastructures upon which they rely, will become a strategic area of focus in this process. At the end of the day, any vendor who wishes to emerge as a key player in this arena must effectively monitor the whole application environment – transactions, mobile devices, network response, real user experiences, application servers, database connections and more.
— Jim Gochee, SVP Products, New Relic

Tool vendors who stick to single functionality – be it prototyping or internationalisation or customer support – will become either niche players with a small but profitable market segment or zombie companies, surviving with minimal profitability and, given the Series A crunch, they will drive consolidation to new heights in 2013.

The rise of the Mega SDKs

The consolidation of the SDK economy will continue to accelerate leading to the rise of the Mega SDKs, along the two clusters:

  1. App Marketing Services
    Winners will be those who build developer trust with end-to-end app development support, monetizing all channels that can maximise revenues or reach (e.g. ad networks, cross-promo networks, user analytics).
  2. Enterprise Mobile Services
    Winners will be those helping developers write across more screens, manage more users, and better understand users (e.g. cross-platform tools, BaaS, app performance management, API management).

Competition in the marketing tools will force companies to offer more and more for free, making it difficult for smaller startups to compete with the breadth of tools and the scale of companies like Flurry and Facebook. In the enterprise IT world, we should expect new titans to emerge or incumbents like IBM to enter and become the Amazon Web Services of mobile.