Difference between revisions of "Closing the gap with native"

From W3C Wiki
Jump to: navigation, search
(Monetization)
(Suggested actions)
Line 124: Line 124:
 
* discovery of context-relevant Web apps?
 
* discovery of context-relevant Web apps?
 
* making Web apps 1st class citizens
 
* making Web apps 1st class citizens
 +
* organize developers expression: survey? collection of "use cases" voted up/down?
 +
* make it easier for companies to have an impact in Working Groups, through training (incl. training on browser spec development, webidl, but also high level guidance)?
  
 
([[Payments_Task_Force|payment headlight]] hopefully will lay down a plan that will help for monetization; performance headlight likewise for performance)
 
([[Payments_Task_Force|payment headlight]] hopefully will lay down a plan that will help for monetization; performance headlight likewise for performance)

Revision as of 14:37, 31 January 2013

Problem definition

What is the problem?

While most innovation on traditional computers (desktop/laptop) has been happening on the Web over the past decade, most of the action on mobile devices (phones and tablets) is happening using native technologies.

What are the indicators that show that there is or is not a problem?

What are the risks?

  • it reduces the ability of the Web to open up silos of information, content and services
  • as mobile devices are taking the center of stage as computing devices, there will be less investment in improving Web technologies if it is not seen as relevant on mobile devices
  • native technologies require multiple development per platform, which improductively increases the cost of providing and obtaining content and services
  • native technologies and their associated distribution channel are under control from single commercial entities, putting developers and users at risk of censorship, monopoly, etc.
  • any development platform critically needs developers; developers can only target so many different platforms, so for the Web to strive as a platform, it needs to be one developers strongly rally to

Parameters of the analysis

Audiences involved

  • platform providers
  • application developers
  • users

Type of Web-related Apps

Probably should define some terminology; hosted/packaged Web apps likely to be defined in SysApps Security model

  • Hosted Web app (available via http/https)
  • Packaged Web app (distributed in a package à la widgets)
  • Hybrid apps (usage of Web technologies in otherwise native app)

questions

  • what are the identified issues?
  • why are they happening on mobile on not on desktop? can we learn from the succss of the Web on desktop to inform our strategy on mobile?
  • how important is that issue (compared to other priorities)? Are there ways to assess its relative importance? How likely can W3C be effective on addressing it?
  • what are the advantages of the Web in this space? Can they be strenghthened?
  • which actors matter in this space? what incentives are there to align their goals with the needs of the Web?
  • what are we already doing?
  • is the pace of what we're doing sufficient? if not, how can we increase it?
  • what are we not doing?
  • is W3C naturally well positioned to do it? If not, can/should it? Who else would be?
    • what W3C is known for: standards and guidelines
    • what W3C has started investing more in: documentation, tutorials (WebPlatform), developers outreach
    • actions W3C has not taken so far: running surveys (dev, users), running cross-vendors marketing campaign

Useful persons to reach out to

  • Analysts (incl. Strategy analytics)
  • Scott Jenson
  • People who are driving work in this space: TobieL, PaulB, JoR, DanA, JamesP
  • Developers of native and web apps
  • Fred Wilson?

Analysis

Obviously, some aspects of the high level categories are intermixed (e.g. performance can be seen both as a problem for developers and for users); probably best is to look at them through the largest audience (in this case, users)

Strengths

Useful to assess whether there are advantages of the platform that we could use to increase its appeal compared to native, as well as to make sure we don't weaken them by trying to work around some of the weaknesses

  • no-install/no-update needed for hosted apps: less work for users, so opens up a variety of usage
  • hosted Web apps comes with a number of promises that users rely on (privacy, security)
  • hosted and packaged Web apps can be made to work on many platforms/devices with less development/maintenance cost
    • (what does the arrival of “dumb” connected devices change to this? how native will expand to other smart devices? which other smart devices are likely to matter in the same scale as mobile phones?)
  • Web apps are pretty much the only contender for cross-devices interactions
  • service/content provider is in control of whether and when a hosted Web app is published and updated
  • the Web technology roadmap is defined by a consensus-based process, not controlled by a single commercial entity
  • links make it easy to integrate content with other content, and to get the user to land on one's hosted Web app by following links
  • for platform providers that have less visibility among developers, Web techonologies are a great way to gather more mass/momentum
  • hosted Web apps have historically shown various ways to build long standing revenues for many companies (how does native compare?)
  • Web technologies are developed under royalty-free licensing, which gives important guarantees in the mobile space that is known for its large IPR battles
  • most connected applications talk to a server-side component that uses Web technologies (JSON, XML, HTML, RSS, etc), often via HTTP; this is the natural environment from Web apps

Weaknesses

Platform providers also control their mobile browser

  • many mobile devices can't use non-default browser; many users don't know or care about additional browsers
  • default browser is controled by platform providers who benefit from locked-in app stores
  • (but browsers can be made point of entry for a more open environment as long as they are considered a competitive feature of the underlying platform; e.g. Amazon selling mp3 via the iphone browser)

Capabilities of the platform

  • comparison of APIs native vs Web?
  • input from Facebook analysis of top 100 apps
  • existing work: HTML, CSS, Web Apps, DAP, SysApps, etc. (see Standards for Web Applications on Mobile: current state and roadmap)
  • the capabilities may exist in spec, but
    • they aren't available widely enough for developers to rely on (CoreMob trying to fix that, but need a long term strategy to keep up)
    • the pace to which they're deployed doesn't match developers need — WGs priorities more often reflect local circumstances (e.g. who can edit, who can review, who can test) than what the outside world needs most urgently
    • they come with so many drawbacks (e.g. user prompts) to be unusable in practice?
  • W3C already worked on "packaged Web apps" via widgets, which didn't take off; what can we learn from that?

Programming challenges

  • building nice UIs for mobile (existing work: competing CSS approaches for building UIs)
  • adapting UI to the various underlying platform (is it a goal?)
  • inconsistent APIs
  • interoperability (cf Testing efforts, CoreMob)
  • "write once works everywhere" only interesting if trying to work everywhere
  • offline capabilities (difficulties with AppCache, ongoing work in this space)
  • lack of sufficient tooling to inspect/debug
  • lack of documentation? (WebPlatform Docs should help)
  • adpative UI: Responsive Web Design is hard™

Monetization

  • advertizing more difficult/less effective on mobile (still, represent ~1/4 of expected revenues for mobile native apps in 2013 according to "App Ecosystems Opportunities; Apps Forecast 2008-2013; Virtual Goods Drive Real Revenue"); how do advertizing in mobile apps compare with mobile Web? is advertizing on mobile just inherently harder (due to screen space), or is fragmentation part of the difficulty?
  • payment useful both for first access (aka download on native) and for additional features / virtual goods
  • payment harder (cf Payment headlight) than on native, in particular because there is no payment-provider lock-in (native app stores induces lock-in for users and developers);
  • tying payments (by default?) to operator billing could be part of the approach (but leaves open the question on how developers get funds from a myriad of operators); Firefox OS comes with navigator.mozPay() (bound to carrier billing?)
  • DRM currently not available on the Web makes it impossible to use it as a platform for DRM'd content

User Experience

  • “Consumers indicate that mobile apps provide quicker, direct access to the content they are seeking, while mobile browsing provides more flexibility to take multiple action paths, allowing for more "casual browsing". Mobile apps also allow users to see the content they want through a delivery mechanism built specifically for that content.” Mobile Internet Behaviors: Browser and App Preferences
  • performance and perception thereof (cf Performance headlight)
  • (hosted) Web apps are not integrated as "first class citizen" in the phone UIs, making it less easy to access for the user, less likely to access; the user cannot know whether (or realize that) a Web is available for offline usage

Discovery and User Awareness

  • “unless you are a large company, discovery is very important, so stores remain very important” (despite their costs)
  • why don't search engines work as well on mobile? Search remains keyboard-centric (less than ideal on mobile), and results don't feature specifically mobile-tailored Web apps (why?)
  • users may also not know that Web applications can do a number of things that native apps can (e.g. access to compas, acceleration data, camera, work offline, etc.)
  • availability of apps seen as important device sale factor according to "App Ecosystems Opportunities; Survey Says: China to Fuel App Surge"
  • possible approaches: embrace app stores (e.g. via SysApps packaged Web apps), extend the model to Web apps (à la Mozilla Web Apps Market), or strenghthen the non-store approach (e.g. invest on context-relevant discovery?)


Suggested actions

these are purely speculative, unordered ideas, and may bring your computer down if you read them the wrong way

  • upgrade CoreMob to increase its ability to influence priorities of group?
  • set up regular check points for groups whose work is needed?
  • organize workshop on cross-channel/trans-media Web apps?
  • search for Web Apps?
  • discovery of context-relevant Web apps?
  • making Web apps 1st class citizens
  • organize developers expression: survey? collection of "use cases" voted up/down?
  • make it easier for companies to have an impact in Working Groups, through training (incl. training on browser spec development, webidl, but also high level guidance)?

(payment headlight hopefully will lay down a plan that will help for monetization; performance headlight likewise for performance)