The Methodology Behind Ringmark

On Tuesday, we announced that Ringmark is open source. We also explained why we built Ringmark and how you can help.

In this post, we’ll dive into how we’re approaching the challenge and the methodology that we’re using to tackle it.

The Problem and Methodology

Developers want to build a great user experience on mobile. They want the experience to be fast, easy, and rewarding for the user. However, because of a mix of performance issues, broken features, or worse—missing features, this is quite difficult with the current state of the mobile web.

The best way to fix this is by focusing on those features that will actually help developers build high-quality apps.

And since the web is constantly evolving, we're taking a versioned approach to this effort, starting from the basics and building up, as illustrated by “Rings”.

Ring 0

First, we need to establish a baseline of functionality. With this baseline, developers can understand what functionality is immediately available for their web apps. Consolidating around that baseline can set a common ground for all mobile web browsers going forward and provide a clear and definitive understanding of the market size of the mobile web for a particular app.

At a high level, Ring 0 is the intersection of functionality offered by iOS5 and Android 2.2 Froyo, which represents the majority of the smartphone market today.

Apps that can be built on Ring 0 devices include content apps like the New York Times, Washington Post Social Reader, and Flixster; games that have a low amount of animating sprites like Words with Friends, Skyscaper City, Poker; music apps like AudioVroom and SoundCloud; and ecommerce apps like Amazon. But these are just a small sample--Ring 0 contains an exhaustive list of features. We encourage you to run Ringmark, scroll down the page, and see what’s included.

Ring 1

The next Ring is focused on enabling as many developers to build their apps as possible, while keeping the feature scope as small as possible. The scope was determined by surveying most popular types of apps that are being built on mobile devices today. Other considerations are also accounted for, like ease of implementation for browser vendors and the degree to which the feature spec is baked.

By enabling Ring 1, we believe that we could enable web developers to build eight or nine out of every ten of the most popular apps that are created today.

The major categories of apps that developers are building today and which we’ve included in Ring 1 are 2D games, audio and video apps, and camera apps. Examples of each include 2D games like Angry Birds and Where's My Water?; audio and video apps like Netflix, Hulu, Spotify, and Turntable; and camera apps like Twitter, Facebook, Instagram, and Foodspotting.

Here are the main features that we’re targeting and will be made available in Ring 1, in roughly prioritized order. More tests will be integrated and the prioritization updated, as the W3C Core Mobile Community Group makes its recommendations and there's better understanding of how each feature should work.

• Accelerated canvas
• DRM (audio and video)
• Audio element*, mp3 codec*, and audio mixing (ability to play more than one audio file at the same time)
• Camera (File APIs, Blob, Media capture input, XMLHTTPRequest 2, “accept” and “multiple” form attributes)
• Orientation lock and device orientation event (device motion)
• Multi-touch*
• Session history management*
• Overflow scrolling*
• Web workers (Basic support—non-shared web workers)
• Network Information API
• navigator.onLine support*
• Indexed DB
• WOFF (Web Open Font Format)
• HTML5 form features

  • email, tel, url, search, number, datetime, datetime-local
  • placeholder, maxlength, accept and multiple
  • progress, output
• Non-prefixed Ring 0 features

*denotes features that are already available in Android versions Gingerbread (2.3) and above, and iOS 5.

Ringmark doesn't only test if a feature is available--it tests if the feature is actually implemented well. That's why it goes above and beyond basic feature tests and is tests edge cases developers hit.

One area that isn't covered is performance testing. Going forward we plan to tackle this challenge, which is particularly prevalent for games, where some experiences require the ability to test performance for physics, drawing (canvas performance), and garbage collection pauses.

Let's dive into each feature and outline why it's important for Ring 1.

Accelerated canvas

There’s a large market of 2D games that can’t be built because of poor canvas performance. We need the browser to be able to animate X sprites (depending on the type of game that's being built) at a minimum 30 FPS.

DRM (audio and video)

Due to contractual obligations, nearly every audio and video app needs DRM. We recognize that this is a particularly complicated issue, but we also know that, without DRM, every major audio and video app developer will never be able to use the web to build their app.

Audio element, mp3 codec, audio mixing

The audio element is broadly available in browsers today, but it's nowhere near perfect. Many times, particularly when trying to play multiple sounds at the same time (audio mixing), there will be auditory quirks like popping and sounds stopping. This needs to be fixed in order for rich audio apps to be built. To reduce fragmentation, we also believe that all browsers should have at least one of the same codec for audio--mp3, because it's the most popular codec today and developers are already using it.

Camera APIs

The camera is one of the most popular experiences on smartphones today. Android browsers already support the form element. This is a viable option for most apps, so we're proposing that all browsers should implement this, along with the ability to asynchronously send it to a server and offline access, which will drastically improve the user experience. This doesn't enable every use case for the camera (e.g. augmented reality), but it covers most use cases for the most popular apps built today.

Orientation lock and device orientation event (device motion)

This is required for 2D games. A lot of games require the screen to be locked in portrait or landscape mode. Currently web developers have to display an error message when they detect that the orientation has changed, resulting in a poor user experience. Device motion is required for games like Doodle Jump and Rolando.

Multi-touch

Unfortunately, Android didn’t support this before 3.0. This is necessary for many types of apps like maps, photos, etc.

Session History Management

Modern mobile web apps are typically "single-page" apps, meaning they don't navigate between pages. In order to support this, browsers need to be able to allow mobile web apps to manipulate the browser history so that navigation buttons work.

Overflow Scrolling

Users are accustomed to native-style momentum scrolling. Currently, developers need to emulate this by using JavaScript libraries, which results in a sub-optimal user experience. This problem can be fixed by the browser by enabling overflow scrolling.

Web Workers

Needed for computationally expensive tasks without interrupting the user experience (e.g. physics engines, background i/o). It will significantly help the user experience for all apps..

Network Information API

Games utilize this to determine if multiplayer should be an available option. Music and video apps use this to determine what bitrate media should be played. Long term, adaptive streaming would be preferred for streaming media,, but that’s currently outside of scope for Ring 1.

navigator.onLine support

This is necessary to understand when the phone goes online or offline, in order to stop or start network requests.

Indexed DB

Apps are becoming complicated, particularly in terms of the breadth of data they handle, so it's imperative to include a database in the browser. WebSQL is already implemented in a couple of browsers, but the spec has been deprecated in favor of Indexed DB--leading to confusion for web developers. It's important that a dev has the option to use a database that isn't fragmented, particularly given the types of apps that Ring 1 is targeting.

WOFF (Web Open Font Format)

Fonts are valuable to apps, particularly games, to create a rich experience. WOFF enables licenses to be bundled with fonts, which makes them much simpler to embed into web apps. Also, WOFF fonts are always g-zipped, which is important for mobile apps, given limited bandwidth.

HTML5 form features

This set of features is focused on the user interface, including progress bar, placeholder, etc. This will allow web apps to maintain some consistency within particular browsers and operating systems, if needed.

Non-prefixed Ring 0 Features

In order to reduce fragmentation for app developers, pre-fixed CSS properties need to be eliminated across browsers. By forming a consensus around features in this Ring, browsers will be able to eliminate the need for their prefixes.

Ring 2

While Ring 1 is primarily focused on enabling mobile apps that are already being built today, Ring 2 is organized to unlock the rest of the most popular apps, as well as new functionality that will enable developers to build entirely new types of apps on mobile.

The concepts in Ring 2 are very new and we expect them to change substantially over the next year.

Here are some features that Ring 2 targets.

• WebGL
• Adaptive streaming (video and audio)
• Web notifications
• Audio API
• WebSockets
• Form validation
• The rest of the HTML5 form elements
• Sandbox attribute for IFrames
• getUserMedia section from WebRTC 1.0
• Navigation Timing API
• SVG

We believe this class of features will enable the final portion of market share for apps being built today, including 3D games. It will also unlock new possibilities for rich apps like augmented reality, real-time multiplayer games, and more nascent categories.

More Rings and Evolution

What makes the web great is innovation and constant evolution. Ring 1 is primarily about enabling the consistent use cases that developers are building today.

It's important to note that, if any tests fail in a Ring, the next Ring will not run. This is so that we can avoid fragmentation--developers need a dependable web platform across all devices.

That’s why, once Ring 1 is established and becomes the status quo, we’ll focus on enabling Ringmark to test the next sets of mobile bowser features—Rings 2, 3, 4, and so forth.

Let's Build the Future Together

Ultimately, we want Ringmark to embody the next generation of the mobile web. That's why we want your feedback. Leave a comment below and join the W3C Community Group to participate.

Have you run Ringmark in a mobile web browser? Spread the word about rng.io and post a photo to the Ringmark Facebook Page or tweet using the hashtag #ringmark.