Work on payments at W3C was supported in part by the HTML5Apps project, and today, the project’s team is pleased to announce that W3C just launched the Web Payments Working Groupto make payments easier and more secure on the Web.

The Web payments Working Group is charteredto develop standards to support a wide array of existing and future payment methods. Standard APIs will allow users to register payment instruments (such as credit cards or payment services) and select the right payment type through the browser, making payments faster, more secure, and easier, particularly on mobile devices. The standards should also make it easier for Web developers to integrate existing and new payment flows into their applications.

The Web Payments Interest Group, under the leadership of co-chairs Erik Anderson (Bloomberg) and David Ezell (NACS), will continue to identify additional areas for future standardization.

W3C invites organizations to participate in the new Working Group. W3C Members, including Bloomberg, Deutsche Telekom, Digital Bazaar, ETA, Federal Reserve Bank, Ingenico Labs, MAG, NACS, Qihoo360, Rabobank, Ripple and WorldPay have already announced their support.

Filed under: Payment , Standardization

Last week a new charter for the Web Content Accessibility Guidelines (WCAG) Working Group (WG)was formally approved by W3C after having been reviewed by the W3C Member organizations. For the first time since the finalization of WCAG 2.0 in 2008, this charter allows the Working Group to explore ways to provide guidelines beyond WCAG 2.0.

The WCAG 2.0standard continues to be the preeminent reference for web accessibility.  A growing number of national and organizational policies around the world reference WCAG 2.0, including Canada, Australia, Japan, India, and the United States. WCAG 2.0 holds up well today despite significant changes in technology.

There have been some changes to the technology landscape, however, that were not fully anticipated in the development of WCAG 2.0. Changes in how people access the Web on mobile devices require success criteria that address those situations more specifically. Users with cognitive and learning disabilities and users with low vision have suggested ways in which success criteria could better address their requirements. In recent years the WCAG Working Group formed task forces on mobile , cognitive , and low visionaccessibility to define requirements and candidate success criteria for these three areas. New technologies on the horizon and the rapid evolution of the underlying technologies for user interaction on the Web are likely to continue to drive the need for new guidance.

To address these needs, the WCAG Working Group has begun to develop a framework for WCAG 2.0 extensions. These would be separate guideline documents, to increase the amount of coverage on particular accessibility needs. Authors and policy-makers would be able to choose to meet the guidelines with one or more extensions, which inherently meet the base WCAG 2.0 guidelines, while organizations that have policies built around WCAG 2.0 alone would not be impacted by the extensions.

The WCAG charter just approved will serve as bridge to begin work on extensions now while we continue to define what the next generation of WAIguidelines will look like. The Working Group is gathering requirements that may lead to the creation of an updated version of WCAG, or a new set of accessibility guidelines altogether, or both. In order to better integrate the components of web accessibility into a single set of guidelines, the Working Group is exploring the possibility of merging with the Authoring Tool Accessibility Guidelines and User Agent Accessibility Guidelines Working Groups. The Authoring Tool Accessibility Guidelines Working Group (ATAG WG) has just published the completed Authoring Tool Accessibility Guidelines (ATAG) 2.0 ; and the User Agent Accessibility Guidelines Working Group (UAWG) has just published an updated working draft, rolling in comments from browser vendors and others, and will be publishing the User Agent Accessibility Guidelines (UAAG) 2.0as a Working Group Note soon.

WCAG 2.0 extensions and setting the stage for next-generation accessibility guidelines means this is an excellent time to join the WCAG Working Group!

The HTML5Apps continues its series of interviews of European SMEs. Today, we go to Germany, where the Cocomoreheadquarters are located. The discussion was held with Alejandro Leiva, based in the Cocomore Spanish office in Seville, is the technical lead of mobile and emerging technologies, and with Christian Winter, Head of Frontend Development in Frankfurt, specialized in responsive Web design and the optimization of interactive Web applications for mobile devices.

Hello! Would you please describe your company, its mission/vision and its customer audience?

Cocomore is an international agency for Marketing and IT services with 140 employees at our head office in Frankfurt, and in Geneva and Seville. We are developing integrated communication and IT solutions with best practices in crossmedia, branding, CRM, marketing automation and e-commerce.

Our mission and our promise are measurable results in these particular areas, achieved using creativity and technology. Our main focus is on projects where it comes not only to appeal to customers, but also to create a long-term customer relationship. Therefore, data and IT is important but above all, you need content which is appealing, entertaining and useful for communication with customers.

That is why Cocomore has not only designers and creative directors, but also editors. On the basis of our four values, which are innovation, tradition, progress and responsibility, our agency is trusted by leading clients including: the European Union, Lilly, Nestlé, Procter & Gamble, Merz, RTL and Sanofi. Our customer relationships usually grow from year to year and are long-term based.

Recently, we have accomplished a project regarding a cross-platform mobile application for Germany’s largest drugstore chain: dm. We developed a game app, named “Mission Morgen” to support communication around sustainability topics. After the functional concept phase was completed, we looked at which technological approach would be best to implement the app; in particular, we evaluated which of a pure native or hybrid app would fit the project. For reasons of cost, time, supported devices and the required features, we decided to go with an hybrid app.

Our technology selection has proven to be the right one: the combination of ngCordova, AngularJS and Ionic allowed us to focus on the important tasks as we did not need to spend much time on the development of basic functions. Especially ionic provides an optimal basis. With the use of AngularJS, we were able to divide the tasks clearly and to scale optimally the frontend team. In addition, thanks to this technological choice, we have retained over the entire duration of the project a good code base and we were able to integrate new modules quickly and with high quality in the existing app. The backend development was realized on top of Drupal. The resulting free application is available for smart phones with the operating system iOS or Android.

As another example, Cocomore developed a pure native mobile application for Pampers. We are currently evaluating relaunching it as a hybrid app. Our goal is to provide updates with new features or extensions several times a year. Regularly, we provide information with the dynamic newsfeed on the homepage of the app about current actions on the Web site and on Facebook (competitions, new craft instructions, new stories to download). The Web site and the mobile app are optimally matched: there is no duplication of content, the app features complement the Web site features.

Initially, when we first developed the app, we wanted to target as many mobile devices as possible, so we designed two native apps, one for Android an one for iOS. We have now decided to re-launch as a hybrid app since this means a smaller development cost and the opportunity to operate on more mobile devices.

Cocomore has realized many other mobile projects, e.g. an iPad app for our client Fresenius. This app teaches health care professionals in an entertaining way about the benefits of the product OsvaRen. It is a very visual app with embedded videos and an in-app game.

We also developed a guided product tour for the medical device company Spine Art. It shows to surgeons the product range of implants, how-to-videos and animated 3D visualizations of their products.

Other projects included a career app for the HR department of a large pharmaceutical client, a recipe database targeted at diabetes patients to easily monitor calory intake, an ecommerce app allowing consumers to shop diapers when waiting for the bus or tram. And many more.

Web apps are very different in this regard: they can be programmed by an experienced Web developer for several different smartphone operating systems without having unique knowledge about the device-specific development methods. For us, with our strong existing engineering skills in Web development, this is a huge benefit.

Moreover, native applications are designed for an operating system such as iOS, Windows Phone or Android, which means they run only on these devices. Here, the different operating system versions have to be considered, so that the correct functionality is ensured. When a new version of the operating system is introduced, the native app must be updated.

This does not affect Web apps. Web applications are specially programmed HTML5 sites that recognize the mobile device and optimize the content for representing, they run on all Web-enabled devices.

The big drawback of Web apps is their lack of access to phone specific functionalities like camera, microphone. Since Web apps run in the browser of the device access to phone hardware is very limited.

Cocomore deliberately focuses on cross-platform mobile applications (also called hybrid apps), which help bridge the gap between native and Web apps. This kind of application consists of a Web app, i.e. a backend and frontend running on a server. Thereby, the app can also be accessed by desktop browser. It is then displayed as a normal Web site.

The second component is an app container which can be uploaded to the various app stores. This container allows the access to the smartphone hardware and it draws its content from the Web app. Thereby it combines the advantages of both types of apps. In fact those hybrid apps are build using Web technologies and with some native code, so they can be converted via framework in a native app container very easily. But due to their architecture leveraging the many advantages of the Web applications, such as the cross browser compatibility and the cost benefit, the future could be these hybrid apps. The most important factor being here the availability of all the native features.

A Web app is particularly advantageous regarding total cost of ownership and implementation time. It bears comparably low development costs and short development periods. This technology is directly accessible via a link, so it has the ability to run on many mobile devices and operating systems and runs on each smartphone without installation.

In practice, the approach we currently recommend to our customers is to have a mobile Web portal for general information sharing, and a cross-platform hybrid app for more interactive / engaging content.

• Our customers don’t necessarily accept that a browser-based approach can give good enough results in terms of performance and UI,
• They tend to see also a “real” app as a better marketing/communication channel,
• The app tend to be for shorter-term campaign, with often a gamification aspect, and it’s not obvious to end-users that you would obtain a game or game-like experience from within the browser,
• On the Web, our quality expectations require good results on a much wider set of platforms that we would target with our hybrid apps (i.e. mostly iOS and Android), and thus the more interactive you make the Web app, the more likely you’ll encounter bugs in older or less advanced mobile platforms.

With regard to the specific native look and feel of each platform, we usually recommend to use a single UI paradigm across platforms, without trying to customize it. Once you start customizing the UI, and taking into account e.g. the inconsistent availability of a hardware back-button between iOS and Android, it makes maintaining the whole app workflow much more difficult.

An area where we’ve found we had to rely on specific Cordova plugins in our hybrid developments is for media playback; for instance, we’ve found that playing an audio file in loop using the basic audio capabilities of a Web view wouldn’t work well on mobile, and that’s a pretty fundamental issue e.g. in a game.

We’ve also had issues with using Web sockets in some older Web views, but this had more to do with implementation bugs than issues in the standard from what we’ve determined.

We’ve struggled for a while with storing data — localStorageproved unreliable as the stored data could be wiped out by the OS; but we’ve now switched to Indexed Database which seems to solve that issue well enough for us.

Thank you!

Filed under: html5apps

The two-year EU-funded HTML5Appsproject proudly looks back to its achievements. The project, ending in September 2015 successfully accelerated the development of standard Web technologies required to make HTML5 apps competitive with native apps, specifically in the areas of Web payments and rich mobile Web APIs.
[The full press release is available in the Press sectionof this Web site].

HTML5Apps initiated W3C Payments standardization work

Payments have been identified early on as a major gap, and on March 2014, the HTML5Apps project organized a W3C Workshop on Web payments . It immediately gathered a lot of interest from a wide variety of stakeholders, ranging from banks, merchants, payment service providers, mobile operators, and many others. As a result, a W3C Web Payments Interest Group was formed. Chaired by Bloomberg and NACS representatives, the group is composed of 104 participantswho have been busy at identifying specific standardization opportunities and building consensus on which of these need to be addressed within W3C.

After gathering industry use cases and requirements to help ensure that the standards developed have the ability to include business-to-business (B2B) payments as well as financial institution-related payments, the group proposed to standardize APIs – supporting functionality such as payment instrument registration, payment initiation, and payment completion – to enable an automated secure foundation for future Web payments capabilities. As a result, W3C is now in the final stages of starting new standards work to make Web payments both easier and more secure.

HTML5Apps publishes mobile Web standardization roadmap

HTML5Apps conducted a series of interviews with European SMEs to investigate their need for fast and easy development of innovative Web-based services. As a result, there is a need and strong support for in-progress standards around offline access, push notifications and access to device APIs. Where specification efforts had not started yet, the project brought them to the W3C Web & Mobile Interest Groupto report new standardization opportunities.

“Seeking input directly from European developers and SMEs enabled us to better understand their challenges of using Web apps over proprietary formats,” explains Dominique Hazaël-Massieux, HTML5Apps lead. “As a result, and to facilitate information, coordination and participation from these developers, we maintained a standardization roadmap tracking efforts inside and outside of W3C.”

For the past two years, the HTML5Apps team published, on a quarterly basis, a roadmap entitled “ Standards for Web Applications on Mobile ”. Acclaimed by Web developers, this document summarizes the various technologies developed in W3C that increase the capabilities of Web applications, and how they apply more specifically to the mobile context. The latest edition of this roadmap was published in August 2015. It notably includes additions related to emerging work such as the proposed charter for a Web Payments Working Group.

Filed under: HTML5 , html5apps , Mobile , Payment , Standardization

The HTML5Apps team continues its series of SMEs interviews across Europe. Today, we go to Spain, and more precisely to Gijón (in Asturias, north of Spain), where is located the startup UbiqWare. UbiqWare is specialized in the development of cross-platform multi-device software solutions, offering products, services, knowledge and experience to other software companies.

Hello, can you tell us more about your company and its business at a high level?

UbiqWare is a startup focused on improving the ability of other software companies, mainly but not solely start-ups, to develop software. More specifically, we help companies to:

• Create cross-platform solutions, including back-end, thus providing final users with access via the Web browser (desktop, mobile and, in general, any form factor) and mobile apps (mainly based on Apache Cordova, but also applying native development when required);
• Adopt agile methodologies that facilitate success in software projects, regardless of their complexity. We propose tools such as the Atlassian suite (JIRA, JIRA Agile, Confluence, etc.) or other free alternatives, such as Redmine. We put a strong focus on continuous integration and continuous delivery/deployment. For this, we use DevHaven, our solution for continuous integration and delivery with a special focus on cross-platform development, with initial support for Apache Cordova projects, and plans for Grails, native iOS, native Android and Web projects soon.

Part of the team is coming from the R&D department of Fundación CTIC. We worked in projects involving development under native and (desktop-only, responsive and mobile-first) Web development. In the early stages of our work in CTIC, Web and native were separated worlds. JavaME, Symbian and Windows Mobile were the most popular technologies used, whereas XHTML-MP and other HTML subsets and flavors were used for mobile Web development. In particular, we worked on MyMobileWeb, an open-source platform for browser detection which delivered the most suitable markup (and rest of resources) formats.

Since we created UbiqWare with two other colleagues (Jorge Román and Mario San Román, with large experience in back-end development) in November 2015 , we worked in the following projects (while developing DevHaven):

• We first collaborated with a Spanish startup on a cloud service to provide companies with a unified vision of their digital properties and general business performance by means of the integration of all their business metrics, Web analytics, campaigns and social media data in a single panel. They work with quite a few well-known international companies from a variety of industries.We analysed the code of their Web app and created a much smoother version that was packaged as an Apache Cordova app for iPad, adding offline capabilities. Thanks to their Web development skills, they are creating a universal iOS version and an Android version, both for mobile and tablet devices.We are now starting another project improving the way in which they organize their code and software development methodology, trying to take them to a single codebase that finally generates Web apps and mobile apps. This company is the first user of DevHaven, in its current internal stage.
• Support for a Web development company in mobile apps creation. They have designed Web sites and applications for public institutions or consulting companies. Following increased requests from customers to create a mobile app in addition to a Web application or site, they chose UbiqWare as their technology provider and advisor to create cross-platform solutions based on responsive Web + Apache Cordova (and the corresponding plugins and extensions).
• Development of a mobile video surveillance application for a company that provides video surveillance services for large companies. One such company has started to complement their fixed video surveillance system with the use of a mobile application by their security guards. The first version of the application was developed for iPad, under a native development approach. An Android version for tablets is expected to be requested in the next months. This is a case in which performance suggested a native approach, due to the requirement to display several video sources as smoothly as possible while providing a UI with minimum response time.
• Mobile application to manage the balance associated to NFC bracelets used for digital payments, developed for one of the leaders in Spain in the field of digital payments. It has been developed in Apache Cordova.

What do you think about the gap between native and Web apps?

When the guys in Nitobi, the original company who created PhoneGap later acquired by Adobe, were asked about the future of PhoneGap, they said the ideal situation would be that PhoneGap would no longer be required. They expected that the path leading to browsers having access to native features would continue, thus making the existence of tools such as PhoneGap (contributed to the Apache Foundation as an open source later named Apache Cordova, which is the foundation to PhoneGap) unnecessary.Unfortunately, the expectations on Device APIs in Web browsers have not been fulfilled and there are many cases in which native development is required. Sometimes, completely using a native approach or by enhancing hybrid technologies with native plugins.

It is also true that the operating systems and browsers makers are reducing the gap. Apple used a different JavaScript engine in their UIWebView native component, much slower than the one used by Mobile Safari. Their new WKWebKit is much faster. Google has recently provided Chrome’s WebView component in Android as an independent software piece than can be updated separately of Chrome itself and is focusing on improving its performance. Google also encourages other Android browsers makers to release their own WebView components, so technologies such as Apache Cordova allow developers to choose which WebView to use.

In addition, more powerful processors, larger memory chips and faster secondary storage technologies are included in newer devices. This reduces the difference in the perception of performance for human beings, between Web applications and native applications.

This is something that has been evolving day after day since the creation of hybrid development approaches. Therefore, the amount of business cases in which hybrid development can compete with native development is increasing. This is the reason why development teams with skills in responsive or mobile-first Web development dare to start with the release of mobile applications via app stores.

And this is the reason why the first platform to be supported in DevHaven is Apache Cordova. Web developers focus on HTML, CSS and JavaScript + knowing the Cordova plugins required to enhance functionality. DevHaven stops them from dealing with requiring an OS X to build for iOS, Windows to build for Windows Phone, installing and updating Xcode, Android SDK and Visual Studio, etc.

But in general, our customers want both a responsive Web app and a presence on the app store, for which an hybrid app (sometimes, but not always built upon the responsive Web app) is required. While we believe in the Web as a universal platform, our customers are not quite convinced yet!

This would stop us developers from requiring Cordova plugins, although Cordova (or similar solutions) would still be necessary in order to generate the mobile app.

The APIs for which we call upon Cordova plugins the most frequently are:

• file and file-transfer plugins, to implement local caches and, thus, offline access to information;
• device plugin, to harvest device information for conditional functionality or for analytics purposes;
• and push-messaging plugin to send remote notifications.

Thank you for your time! I will note that your town is also the home of the W3C Spanish Office!

Filed under: Developer , HTML5 , html5apps , Mobile , Standardization

A deliverable of the HTML5Apps project, the August 2015 editionof the W3C Standards for Web Applications on Mobileis out!

It includes a few changes and additions since May 2015, particularly emerging work such as the proposed charter for a Web Payments Working Group and the development of a draft charter for a Hardware Security Working Group.

Other changes are detailed below:

Emerging Work

• The early work on a generic sensor APIis now emboddied in an editors draft
• A proposal to enable CSS transitions between Web pageswas brought to the CSS Working Group
• A proposal to detect the input-capabilities of devices(in particular their ability to react to touch) was brought to the Web Applications Working Group
• The Web Performance Working Group is considering the definition of a callback mechanism for scheduling function callsand has a proposed editors draft for it;
• A charter for a Web Payments Working Grouphas been proposed; the group would work on a browser API that would vastly simpiflify payments on the Web
• A draft charter for a Hardware Security Working Groupis being developed; it would bring interaction with secure hardware modules to the Web platform

Published as First Public Working Draft

• The Geofencing API, enabling developers to be notified when the user enters specific geographical areas, was published as a First Public Working Draft
• The Entry Point Regulation specification, which provides another layer of protection against common attack vectors such as cross-site-script or cross-site request forgery, was published as First Public Working Draft
• The Preloadspecification, which offers a way to load stylesheets and scripts immediately, but defer their application, was published as a First Public Working Draft

Returned to Working Draft

• The Proximity Events and Ambient Light Events APIs went back to Working Draft status (respectively from Candidate Recommendation and Last Call status) based on the expectation of their significant rework to match the emerging generic sensor APIwork

Reached Candidate Recommendation

• The Canvas API, a programmatic graphics API, re-entered Candidate Recommendation phase after it had gone back to Last Call following a substantive change
• The Tracking Preference Expression (DNT) specification, which defines a mechanism for expressing the user’s preference regarding tracking, reached Candidate Recommendation status

Specification merged, split or abandoned

• The System Applications Working Group closed, and work on the Contacts Manager API and the Task Scheduler APIhas stopped as for the other specifications from this group;

This document is the 18th edition of this overview of mobile Web applications technologies. The previous edition was released in May 2015 . A live version of this document accepts contributions on the W3C Web and Mobile Interest Group Github repository.

Filed under: Developer , Mobile , Standardization , SysApps

The 9th edition of the State of the Developer Nation Q3 2015 reportis now available for download. It presents the key findings from a survey that the HTML5Apps project helped to promote.

This report covers all the latest trends in mobile, desktop, IoT and cloud services development. It looks at most popular platforms, languages, vertical markets and hosting providers.

The report provides interesting key insights and consolidated graphs such as the one shown below. The global community of people involved in developing software for mobile devices, desktop computers, the Internet of Things and cloud services is fairly homogenous. In Europe, as in all other continents, developers are predominantly young and male dominated. The survey results also show that most developers manage to be involved in several areas of development, via a hobby or side project in addition to their professional work.

Filed under: Developer , HTML5 , html5apps

The Internet Society (ISOC) just released its second annual Global Internet Report, with a focus this year on the mobile Internet. The report explores mobile Internet availability, affordability, and relevance to potential users, and highlights opportunities as well as challenges to ensure all users can enjoy the full benefits of mobile access to the open Internet.

The HTML5Apps team contributed significantly to the report in two key sections of this report which are related to:

• the challenges presented by the current app ecosystem
• the recommendations to address these challenges based on the work W3C is undertaking

These contributions were depending on the work conducted earlier by the project on the native/Web gap analysis and on the API gap review.

Filed under: html5apps , Mobile , Standardization

I was present at the Edge conferenceon 27 June in London, UK, representing the HTML5Apps project. That conference, organized by FT Labs for the past 5 years, targets discussion and debate of leading-edge use of client-side Web technologies. It aims at being very participative in its nature, and was organized this year around a set of panels in the morning and breakouts in the afternoon.

About 180 developers attended the conference, including renowned developers, technical evangelists and standards advocates.

The context of the conference (“leading edge”) and its attendees made it indeed a great place for conversations and interactions. Specifically, I had good discussions related to:

• Interest and adoption around some of the arrival in mobile browsers, esp. push notifications, installable Web app (via manifest) and offline via ServiceWorker. In particular, these technologies seem to open up to great “conversion rates” of installing Web apps via a manifest compared to the native installation workflow enabled by traditional banners — the notion that installing a Web app is a much smoother and less intrusive action seems to have teeth.
• Publishers think that the Web remains a critical part of the traffic they get on mobile, and that the notion of progressive appscoined by Alex Russell matches well with the experience these publishers are facing with native.

On the organized sessions of the conference themselves, I attended/participated to:

• The panel on security, with good conversations on the needs and issues of adopting a higher base-level security (with HTTPs and CSP);
• The panel on front-end data, which illustrated some of the tensions between providing the right low-level primitives (in this case indexedDB) and providing an easy-to-use API;
• The “installable web apps” breakout, which was a really good discussion on the model enabled by App Manifest, as well as some of the questions that remain open about it: Chrome chose to make “installing” something offered to the user under some conditions (serviceworker, repeated usage, responsiveness), where Opera is investigating surfacing that option more visibly in the UI; can these appmanifests help surface mobile Web apps in native stores (where users have been trained to look for content and services)? “Installing” a Web app is really “adding it to homescreen”, but that means they remain a 2nd class citizen in a number of ways (integration in app lists, integration in app settings, etc). This was my preferred session of the day;
• A breakout on network operators where the Natasha Rooney from GSMA was looking for input and feedback on how developers see operators could be useful to their goals, with a lot of discussion similar to the topics in the Web & Mobile Interest Group networking task force.

Overall, this developer conference was a success and the project’s team is looking forward to the next edition!

Filed under: Developer , Event , HTML5