HTML5 Articles

This article covers a Web project that rethinks how TV appliances can be used in public spaces for real-time content and interaction with social networks. Tela Social is a powered by Mozilla system application that runs in Linux appliances and creates a visual experience that presents custom and interactive content with real time data using the Web. It’s different of a standard kiosk and far from the personal browser experience because it’s not tailored for an individual. Instead, it explores how online data can be used to provide impact to users in common areas. In the following sections, you will read about the general system’s architecture; a special focus is given to how CSS3 and JavaScript is used to support the user experience with engaging animated effects.

First, boot to the Web

The application starts following the Linux system’s reboot. A monitor process is launched and starts to check whether the Gecko-based client is running or not. If not running, it starts the main process: a Gecko-based single window browsing engine with no toolbars in full screen.

The following image shows an overview of the web stack infrastructure that is launched. The web application sits above the engine in a similar way to applications such as Firefox or other Powered by Mozilla apps using Gecko.

Online and Offline

Instead of loading a remote web page, most of the resources are loaded from a local web server written in JavaScript using NodeJS — TelaSocial Mediator. This system is also monitored in order to reduce problems in the case of script execution failures.

Once the web app comes from a local web server, a main HTML layout may bring inner HTML components that are loaded within iframes. This degree of separation exists to help developers to create isolated components in a standard test environment: all the components are made of plain pages. As part of this project, an experimental project script was created to help developers to quickly deploy new grid layouts — Gridtype.JS can take strings as arguments and can generate a grid layout that is tableless. The following example shows how to generate a grid of DIVs:

grid('abcdabee',4);

The above “string” specification will generate the following layout:

Free of pop-ups or unwanted desktop interfaces

There are many systems using online data to display information in TV appliances. Some of these systems are applications launched on top of the operating system graphic user interface. The following photos were taken from airports in 2012 in Brazil. These are a few of many examples of problems with unwanted user interface elements that are displayed on top of systems using operating system desktops. For this reason, and also the principle of simplicity and cost reduction, the designed approach was to launch Gecko from the basic X Window infra structure. Such approach ensures that no other visual applications are running at the same time, thus creating an improved quality experience without those unwanted pop-ups.

Routing Gecko pop-ups into frames

While OS desktop pop-ups are out of the scene, yet there are some conditions where Gecko used to display pop-ups to alert the user. The solution to this problem was to use Gecko’s preferences API and ask Gecko to display network error messages inline. With this, all errors are displayed in the iframe which is great because it is possible to track the errors and signal application logic outside the Gecko process. As an example, we can monitor the output console and change the layout depending on network error conditions. So, for example, if a weather channel frames brings a network error, the system should be able to launch an alternate layout.

Animation library with zoom and pan

The above elements are essential to keep the level of quality that is expected in enterprise environments. With this functional base, it’s when things can be creative and the web developer mindset rules. HTML5 and modern effects, provided by CSS3, can be used to help understand and improve the user experience in this scenario that is not the same of a desktop or a mobile.

To help the creation of content, a small JavaScript library was also produced as part of this project. The main goal of this library is to help the creation of visual narratives out of HTML pages. The TagVisor library reads a list of <li> elements which tells how CSS3 and other transformation effects are applied with time-referenced data:

<ul id="animation" style="display: none;">
   <li data-target="slidea" data-time="1s"
      data-effect="scalefit" data-duration="3s">
   </li>
   <li data-target="slideb" data-time="6s" 
      data-effect="scalefit" data-duration="3s">
   </li>
   <li data-target="slidec" data-time="12s"
      data-effect="scalefit" data-duration="3s">
   </li>
</ul>

The above script dispatches transformation functions that can modify the document using JavaScript for DOM transformations and DOM style changes that will take care of the visual effects. These effects are common in many systems, including well known JS-based solutions such as Impress.JS. However TagVisor comes with tailored functions that are very important for the scenarios in digital signage. One difference is that the script allows modifications to be performed within iframes which is good for cases where many separated HTML resources are loaded in a grid arrangement.

The zoom and animation metaphor does a lot of the heavy work to ensure a level of smoothness in animation which is expected by users in front of a TV panel. Some effects can also be combined in time in order to produce engaging visual narratives as shown in the TagVisor video demonstration.

Web-driven, for adaptation

User experience is of major importance and a main reason for the use of a web-based infrastructure. Such model brings a level of dynamism supporting organisations who can tailor the system with custom data-sources using web services formats such as JSON or RSS. This approach has allowed us to test the screens with a variety of online sources; and to learn how the stream of web events can impact users in local organisations.

The following videos are examples of systems with Tela Social. The first video refers to the system at a major science park in Brazil (Press release in Portuguese). It’s an example with a variety of content areas that are tied to a variety of sources: from journalists to editors plus open channels using social networks. The second video shows an example where the TV appliance is set in vertical position.

People recognise that using data from events plus local interest content can build local participation. For most people, TV content is something far away and not tailored to their local community interests. To make things different, we have even used TVs in the vertical position to make a point that the whole experience was flipped and that content and interaction is bottom up.

The objective of the project is to develop web-based solutions that can be useful in spaces and bring social-aware experiences that are positive to local communities . While social features can be used in the mobile and on desktop, we believe that our approach can help communities because it extends the physical environment — it creates a social reflection to the environment. It’s a chance for custom web experiences that build awareness about contributions made by local communities and real-time data of interest. This approach also explores challenges in user interfaces since it engages people to interact in new ways: it’s not a direct touch like standard kiosks. It’s the web in the first place and opportunities for interaction are explored based on live data.

WebRTC is getting great press lately for it’s amazing applications in voice and video communication. But did you know that WebRTC also has support for peer-to-peer data? Below I’ll talk about the ‘what’ and ‘how’ of data channels, and then I’ll show you how we’re using them in BananaBread to support peer-to-peer multiplayer.

Continued…

HTML5 has made it easy to do a lot of really cool stuff on the mobile web, but one thing that is still pretty difficult is dealing with photos. Android has supported access to the device camera via the File API since version 3.0 and iOS opened it up last Fall with iOS 6. Allowing users to snap and upload photos in HTML5 is not as simple as just connecting a form to a database however. With a multitude of devices, OS versions, and browsers the image files come in different orientations, sizes, and with different encoding.

I frequently encountered this headache when developing HTML5 apps, which lead myself and my partner to create Mobozi. Mobozi is a front end library that optimizes and normalizes images across mobile devices, OSs, and browsers and also a simple API for photo upload and serving. This post is a brief overview of how we went about creating the API to to be functional and also easy and effort free for developers to use.

Planning

The first thing we did was map our all the functionality we would need and walk through the different use cases and flows from our users perspective. We thought about things like formatting and version control and how we could structure them to make it as developer friendly as possible.

We also considered data formats and decided to support JSON, XML and JSONP in order to keep the API as flexible as possible. We also made sure to model the API calls in a way that they were predictable and did not require the developer to guess. For example, to add an item, POST method is always used and to retrieve GET is used.

Security

Next we thought security, one of the most important parts of any public facing API. We decided to serve our API from a subdomain (https://api.mobozi.com) and allow CORS (Cross Origin Resource Sharing) on this domain only (our main domain and all other sub domains don’t entertain any request that originated from a different domain). Additionally, CORS on Apache is a great resource.

Developer Experience

Once all the nuts and bolts of the domain had been decided upon, we had to think about how developers would actually get access to and implement our API. We decided to provide an API key and use an HTTP token authentication in order to authenticate them. We also spent a lot of time refining our docs and are continuing to listen to feedback in order to get them as streamlined as possible.

Technology

Once we decided on the functionality the API would need to provide, as well as how it would be implemented, we had to choose a stack to build it on. We chose PHP/MySQL because it’s stable, scaleable, and most importantly because our team was very comfortable and familiar with it. Next we began searching for a framework that would keep our API lightweight but also offer our users a very quick response time.

After researching and testing out different API frameworks we found two that met our needs – Limonade and Slim. Limonade is a PHP micro framework for rapid web development and prototyping. Slim is also a PHP micro framework that helps you quickly write simple yet powerful web applications and APIs.

We eventually decided on Limonade because it was easier to implement and provides functionality we needed like clean URLs and cross origin request handling. Slim was powerful and light as well but had issues with cross origin requests as well as with the auto loader.

Here is a brief example from our API. This code will allow you upload an image from any device and get back the URL where it is being stored.

Include this snippet in your page’s head

<script src="http://zeptojs.com/zepto.min.js"></script>
<script src="//js.mobozi.com/v1/mobozi.js"></script>

mobozi.init('123456789');
function uploadImage(){    
    var myFile = document.getElementById('idimage').files[0];
    var imageData = {
        "file": myFile 
    };
    mobozi.image.uploadGetUrl(imageData,function(response) { 
        if (response.status == 201){
            $('#imgUrl').html('URL: ' + response.data.imageUrl);
            $('#upImage').attr('src',response.data.imageUrl);  
        } else {
            alert (response.error);
        }
    });
}

Include this snippet in your page’s body

<input id="idimage" name="idimage" type="file" accept="image/*"/>
<button type="button" id="btnup" onclick="uploadImage();">Upload Image</button>
<div id="imgUrl"></div>
<div><img id="upImage" src=""></div>

A working example

A working example is available on jsFiddle.

Outreach

So the functionality has been hashed out, the plan of attack decided, and the code written; what next? Get developers to use the thing! And hopefully get feedback from them on how to make it better. This is what we’re currently doing at Mobozi by holding a Hackathon (awesome HiFi speaker for the winner). More details in that page and feel free to ask any questions at founders@mobozi.com.

In an interview with Andrew Binstock in 2012, Alan Kay described the browser as “a joke.” If that surprises you, you’ll be glad to know that Mr. Binstock was surprised as well.

Part of the problem Kay pointed out is well-known: feature-set. Browsers are doing today what word-processors and presentation tools have done for decades. But that didn’t seem to be the problem that bothered him most. The real problem? Browser-makers thought they were making an application, when they were really building an OS.

The browser tab is a very small environment. Due to the same-origin policy, the application’s world is limited to what its host reveals. Unfortunately, remote hosts are often closed networks, and users don’t control them. This stops us from doing composition (no pipe in the browser) and configuration (no swapping out backends for your frontend). You can change tabs, but you can’t combine them.

Built out of IRON

Despite these problems, the Web is successful, and the reasons for that are specific. In a paper published in 2011, Microsoft, UT, and Penn researchers outlined the necessary qualities (PDF): Isolated, Rich, On-demand, and Networked. Those qualities are why, on the whole, you can click around the Web and do interesting things without worrying a virus will infect your computer. As they point out, if we want to improve the Web, we have to be careful not to soften it.

That research team proposed a less-featured core browser which downloads its high-level capabilities with the page. Their approach could improve richness and security for the Web, but it requires a “radical refactor” first. With a need for something more immediate, I’ve developed Local, an in-browser program architecture which is compatible with HTML5 APIs.

HTTP over Web Workers

Local uses Web Workers to run its applications. They’re the only suitable choice available, as iframes and object-capabilities tools (like Google’s Caja or Crockford’s ADsafe) share the document’s thread. Workers, however, lack access to the document, making them difficult to use. Local’s solution to this is to treat the Workers like Web hosts and dispatch requests over the postMessage API. The Workers respond in turn with HTML, which the document renders.

This leaves it to the document to make a lot of decisions: traffic permissions, HTML behaviors, which apps to load, and so on. Those decisions make up the page’s “environment,” and they collectively organize the apps into either a host-driven site, a pluggable web app, or a user-driven desktop environment.

One of Local’s fundamental requirements is composition. The Internet’s strength– distributed interconnection– should be reflected in its software. REST is a unified interface to Local’s architecture, a philosophy which is borrowed from the Plan9 file-system. In HTML5 + Local, URIs can represent remote service endpoints, local service endpoints, and encoded chunks of data. The protocol to target javascript (httpl://) allows client regions to link to and target the Workers without event-binding.

This keeps HTML declarative: there’s no application-specific setup. Additional interface primitives can be introduced by the Environment. Grimwire.com tries its own take on Web Intents, which produces a drag-and-drop-based UX. For programmatic composition, Local leans on the Link header, and provides the “navigator” prototype to follow those links in a hypermedia-friendly way.

Security is also a fundamental requirement for Local. The Web Worker provides a secure sandbox for untrusted code (source (PDF), source). Content Security Policies allow environments to restrict inline scripts, styling, and embeds (including images). Local then provides a traffic dispatch wrapper for the environment to examine, scrub, route or deny application requests. This makes it possible to set policies (such as “local requests only”) and to intercept Cookie, Auth, and other session headers. The flexibility of those policies vary for each environment.

Example Environment: a Markdown Viewer

To get an idea of how this works, let’s take a quick tour through a simple environment. These snippets are from blog.grimwire.com. The page HTML, JS, and markdown are served statically. A Worker application, “markdown.js”, proxies its requests to the hosted blog posts and converts their content to HTML. The environment then renders that HTML into the Content “client region,” which is an area segmented by Local into its own browsing context (like an iframe).

index.js

The first file we’ll look at is “index.js,” the script which sets up the environment:

// The Traffic Mediator
// examines and routes all traffic in the application
// (in our simple blog, we'll permit all requests and log the errors)
Environment.setDispatchWrapper(function(request, origin, dispatch) {
    var response = dispatch(request);
    // dispatch() responds with a promise which is
    //   fulfilled on 2xx/3xx and rejected on 4xx/5xx
    response.except(console.log.bind(console));
    return response;
});
 
// The Region Post-processor
// called after a response is rendered
// (gives the environment a chance to add plugins or styles to new content)
Environment.setRegionPostProcessor(function(renderTargetEl) {
    Prism.highlightAll(); // add syntax highlighting with prismjs
                          // (http://prismjs.com/)
});
 
// Application Load
// start a worker and configure it to load our "markdown.js" file
Environment.addServer('markdown.util', new Environment.WorkerServer({
    scriptUrl:'/local/apps/util/markdown.js',
    // ^^ this tells WorkerServer what app to load
    baseUrl:'/posts'
    // ^^ this tells markdown.js where to find the markdown files
}));
 
// Client Regions
// creates browsing regions within the page and populates them with content
var contentRegion = Environment.addClientRegion('content');
contentRegion.dispatchRequest('httpl://markdown.util/frontpage.md');

The environment here is very minimal. It makes use of two hooks: the dispatch wrapper and the region post-processor. A more advanced environment might sub-type the ClientRegion and WorkerServer prototypes, but these two hooks should provide a lot of control on their own. The dispatch wrapper is primarily used for security and debugging, while the region post-processor is there to add UI behaviors or styles after new content enters the page.

Once the hooks are defined, the environment loads the markdown proxy and dispatches a request from the content region to load ‘frontpage.md’. Workers load asynchronously, but the WorkerServer buffers requests made during load, so the content region doesn’t have to wait to dispatch its request.

When a link is clicked or a form is submitted within a ClientRegion, Local converts that event into a custom ‘request’ DOM event and fires it off of the region’s element. Another part of Local listens for the ‘request’ event and handles the dispatch and render process. We use dispatchRequest() to programmatically fire our own ‘request’ event at the start. After that, markdown files can link to “httpl://markdown.util/:post_name.md” and the region will work on its own.

markdown.js

Let’s take a quick look at “markdown.js”:

// Load Dependencies
// (these calls are synchronous)
importScripts('linkjs-ext/responder.js');
importScripts('vendor/marked.js'); // https://github.com/chjj/marked
 
// Configure Marked.js
marked.setOptions({ gfm: true, tables: true });
 
// Pipe Functions
// used with `Link.Responder.pipe()` to convert the response markdown to html
function headerRewrite(headers) {
    headers['content-type'] = 'text/html';
    return headers;
}
function bodyRewrite(md) { return (md) ? marked(md) : ''; }
 
// WorkerServer Request Handler
app.onHttpRequest(function(request, response) {
    // request the markdown file
    var mdRequest = Link.dispatch({
        method  : 'get',
        url     : app.config.baseUrl + request.path,
                            // ^^ the `baseUrl` given to us by index.js
        headers : { accept:'text/plain' }
    });
    // use helper libraries to pipe and convert the response back
    Link.responder(response).pipe(mdRequest, headerRewrite, bodyRewrite);
});
 
// Inform the environment that we're ready to handle requests
app.postMessage('loaded');

This script includes all of the necessary pieces for a Worker application. At minimum, the app must define an HTTP request handler and post the ‘loaded’ message back to the environment. (postMessage() is part of MyHouse, the low-level Worker manager which HTTPL is built on.)

Before the application is loaded, Local nulls any APIs which might allow data leaks (such as XMLHttpRequest). When a Worker uses Link.dispatch, the message is transported to the document and given to the dispatch wrapper. This is how security policies are enforced. Local also populates the app.config object with the values given to the WorkerServer constructor, allowing the environment to pass configuration to the instance.

With those two snippets, we’ve seen the basics of how Local works. If we wanted to create a more advanced site or desktop environment, we’d go on to create a layout manager for the client regions, UIs to load and control Workers, security policies to enforce permissions, and so on.

You can find the complete source for the blog at github.com/pfraze/local-blog.

User-Driven Software

Local’s objective is to let users drive the development of the Web. In its ideal future, private data can be configured to save to private hosts, peer-to-peer traffic can go unlogged between in-browser servers with WebRTC, APIs can be mashed up on the fly, and users can choose the interfaces. Rather than fixed websites, I’d like to see hosts provide platforms built around different tasks (blogging, banking, shopping, developing, etc) and competing on services for their user’s apps. Then, services like Mint.com could stop asking for your banking credentials. Instead, they’d just host a JS file.

You can get started with Local by reading its documentation and blog, and by trying out Grimwire, a general-purpose deployment in its early stages. The source can be found on GitHub under the MIT license.

One of the most common features of web apps is the ability to subscribe:

• Most news websites or blogs have RSS feeds that enable
  users to subscribe to upcoming posts and articles in their favorite readers.
• Social web applications such as Twitter, Tumblr or Instagram allow you to follow other users.
• Github allows you to watch projects to be informed about new code changes

RSS Feeds are complex

Unfortunately, the subscribing experience is less than satisfying: it’s very hard for regular web users to subscribe to a feed in a reader. First, they have to find the feed on a page, then, once they read the cryptic XML code, they have to copy and paste the url into a reader of their choice. When we consider that most people don’t even know what a url is, we know that this experience will never be mainstream.

Centralization is easy

On the other end, it is actually very easy to follow people on twitter or to follow new Tumblr blogs. We actually believe that these platforms are successful because it is indeed easy and works very well. But the ease comes from the fact that these platforms are centralized: you need to be a twitter user to subscribe to other twitter users.

However, this has never been the web’s true spirit: you don’t need to be a gmail user to send an email to another gmail user.

The Browser as the middleman

When we decided to tackle the subscribe problem we had to find a solution that embraced both the decentralized web that we love and the simplicity of a button that user could just click on.

Try it yourself:

The approach we took decoupled the subscribing web applications from the publishing web application by using the browser and its localstorage as a middleman, with a set of redirects and iframes to send the subscriber to its favorite reader.

When you click on the button above, your browser will load an iframe from Subtome, this iframe will extract your data from a localStorage instance with the list of your favorite subscribing applications. The iframe also keeps track of the page on which it was loaded.

Eventually, when you select one of the apps, the browser opens a new window to it with the right information, and voilà!

Code

The implementation is actually surprisingly simple. When you click the button, the following code is loaded. It simply extracts the feed(s) and then loads an iframe which will show the user’s prefered services. The iframe url includes the feeds as well as the url of the page on which the button was clicked.

The iframe is loaded from the subtome.com domain, which means it can access a dedicated localStorage instance for the user.

The “reader” registration for a given user works using the same pattern: a hidden iframe is loaded and the information about that reader is stored in the user localStorage instance. Feel free to check the source code on the Github repository.

Web Activities?

Of course, some of you may be worried that this uses an app running at Subtome. This is perfectly right, except that this application is actually just a static HTML page running on amazon S3: there is no web application. Also, the full code is open source and public on github.

Now, very recently, Firefox adopted Web Activities. Why couldn’t we use that? The first reason is that this spec was only implemented by Firefox, which cuts the rest of the web. The second reason is that we do not expect most readers to implement that yet. This means that there is a need for some kind of “shim” which can do that on their behalf for now!

Get Started!

Interested by this? If you’re a publisher, the easiest thing you could do is start adding such a button to your site or your blog. Remember that people subscribed to your blog will tend to read your articles more and come back more often.

If you’ve created a reader, you could maybe register with Subtome so that your users subscribe to content online more easily. It’s easy to do so!

Finally, this is a very early stage project, you want to learn more, please check the Subtome website. We would love to get your feedback!.

We’ve been talking a lot about Open Web Apps, Firefox OS and more here lately, and I wanted to cover both how to get started, and, maybe more importantly, why.

Why a web app?

If we look at the climate for mobile development, it has usually come down to a choice where developers had to pick their platform and skill. Maybe do iOS and Objective-C, or Android and Java.

The big challenge here, of course, is that if you want to deliver your content on several platforms, you’ve had a few choices:

• Pick one platform, and ignore the others
• Learn a number of programming languages
• Have separate development teams for each platform

For major organizations, having multiple teams has been something they could do, while many other have struggled with that. And naturally, many mobile apps are in addition to a company/service web site, just adding more and more on top of the things that need to be maintained, supported and developed.

Therefore, for reasons like saving costs, simplicity of one development language and more, many developers have jumped on the options like PhoneGap, Titanium and more, thus developing with HTML5 and JavaScript, and then packaging it for various mobile operating systems.

This has been a good and interesting approach, but probably far from optimal in most cases. We at Mozilla want you to be able to use your existing skills as a web developer, but instead of having you jump through hoops to make it work, we want the platforms to evolve and give you more possibilities and power.

This is accomplished by giving you as a developer access to a large amount of WebAPIs, Web Activities and more, to make the web layer as powerful a platform as it deserves to be.

The idea with Open Web Apps is not to make you choose a new platform or, worse, excluding others – on the contrary, it’s about giving you means to reuse your existing code and, if desired, make small additions to make it installable as an app.

Should I build an app?

While many other platforms have a strong interest in getting you tied into their platform, delivering to their app store etc, I would rather say that the first question you need to ask yourself is:

Do I really need to make an app out of this?

In some cases, yes, definitely! But in other cases, you need to be professional and come to the conclusion that it is probably not likely to add any extra value – a few use cases where you don’t need to do an app have been outlined in articles like No, I’m not going to download your bullshit app and Packaged HTML5 Apps: Are we emulating failure?.

I don’t want to trick you into making an app just for the sake of it, or that you’ll do it just because others do. I would rather see you make a fair assessment, and if your app idea has something additional to offer to the end user and overall user experience, then you should consider doing an app.

So, what could those cases be? A few of them might be:

• You want to offer a richer experience than you could offer from a web page, e.g. accessing some WebAPIs specific to the platform/device
• You need to store a lot of information in localStorage or IndexedDB
• The user wants to have a real installation
• The user wants a nice icon on their home screen/desktop for easier accessibility

Types of Open Web Apps

There are basically two types of Open Web Apps you can install:

• Hosted apps
• Packaged apps

Hosted apps

Hosted apps are apps running from a URL, but in an app context. This means that you need to be online to run it, and all resources (e.g. files, images etc) will reside on your server and where you will host it.

One option to avoid the need for connectivity is make sure your app works offline. This is done by adding an appcache file with listings of assets to be made available offline, and then refer to it from your main page:

HTML file

<html manifest="manifest.appcache">

Appcache file

CACHE MANIFEST
# Version 1.0
 
index.html
css/base.css
js/base.js
js/webapp.js
js/offline.js
 
NETWORK:
*
 
FALLBACK:
/ fallback.html

For learning more about offline support and caveats, I strongly recommend looking into these resources:

• Application Cache is a Douchebag
• Appcache facts

Pros

• You completely control the update process
• Just run/reuse currently existing code

Cons

• Requires connectivity (if offline support isn’t implemented)
• Doesn’t have as much access to APIs as a packaged app

Packaged apps

Packaged apps are where you put all your assets in a ZIP file, and then offer that as a complete package to be installed. This makes these files available at all times, and it also gives you elevated privileges – i.e. you can access more APIs – since all the code can be security cleared before install.

Pros

• Available offline by default
• More API access

Cons

• More difficult to maintain
• Update process for getting new versions out

At the end of the day, you need to evaluate your needs, workflow, APIs you need to work with and more to make a good decision whether you want to do a hosted or a packaged app.

Getting started with Open Web Apps

After all that talk, what do you actually need to build an Open Web App? Not much, as it turns out. We’ve documented it on MDN in Getting started with making apps but I’d like to give you a quick run-down here as well.

Basically, all you need to do is take an existing web site/service you have and add a manifest file. Voilà, that’s it! Yes, really. And to get it installed, of course.

The manifest file

A manifest file describes your app, with things like name, icons, developer and such, but also localization support, path to launch, permission request for certain APIs and more. All manifest fields are available in App manifest on MDN.

A simple manifest could look like this:

{
    "version": "1",
    "name": "Firefox OS Boilerplate App",
    "launch_path": "/Firefox-OS-Boilerplate-App/index.html",
    "description": "Boilerplate Firefox OS app with example use cases to get started",
    "icons": {
        "16": "/Firefox-OS-Boilerplate-App/images/logo16.png",
        "32": "/Firefox-OS-Boilerplate-App/images/logo32.png",
        "48": "/Firefox-OS-Boilerplate-App/images/logo48.png",
        "64": "/Firefox-OS-Boilerplate-App/images/logo64.png",
        "128": "/Firefox-OS-Boilerplate-App/images/logo128.png"
    },
    "developer": {
        "name": "Robert Nyman",
        "url": "http://robertnyman.com"
    },
    "installs_allowed_from": ["*"],
    "default_locale": "en"
}

Save this file with a .webapp extension, for instance, manifest.webapp. One very important thing to note here is that this file needs to be served with the Content-type: application/x-web-app-manifest+json.

This is something you need to set up on your server, e.g. through an .htaccess file in Apache:

AddType application/x-web-app-manifest+json .webapp

Once you have your manifest, make sure to validate your app to see that it has the correct format.

Installing the app

Now that your manifest is in order and served with the right Content-type, let’s offer a way to install it. In your web page, you can add an install button that calls this code:

var installApp = navigator.mozApps.install(manifestURL);
 
// Successful install
installApp.onsuccess = function(data) {
    console.log("Success, app installed!");
};
 
// Install failed
installApp.onerror = function() {
    console.log("Install failed\n\n:" + installApp.error.name);
};

Make sure that the URL to the manifest is absolute – a simple way to do this is to extract the URL from the current page with the install button, and to have the manifest file in the same location:

var manifestURL = location.href.substring(0, location.href.lastIndexOf("/")) + "/manifest.webapp";

Optionally, you can also provide a second parameter to the install method, receipts, which is a JSON object. More on that in the documentation for the install method.

Installing a packaged app

The above solution, with a manifest file and an install call, works well with hosted apps. With Packaged apps, you need to go through some extra steps:

ZIP all app content

Make sure to ZIP all the files (not the containing folder), including the regular manifest file. The manifest file has to be named manifest.webapp

Create a mini manifest

Create another manifest file, for instance named package.webapp, and make sure the package_path is absolute to where the ZIP file is located.

Also, developer name and info has to match between mini manifest and the regular one in the ZIP file.

{
    "name": "Firefox OS Boilerplate App",
    "package_path" : "http://localhost/Firefox-OS-Boilerplate-App/Firefox-OS-Boilerplate-App.zip",
    "version": "1",
    "developer": {
        "name": "Robert Nyman",
        "url": "http://robertnyman.com"
    }
}

Installing a package

Instead of using the regular install method, you now call the installPackage method, which points to the mini manifest, which in turn points to the ZIP file/package:

var manifestURL = location.href.substring(0, location.href.lastIndexOf("/")) + "/package.webapp";
var installApp = navigator.mozApps.installPackage(manifestURL);

Turning on Developer Mode

For this to work in the Firefox OS Simulator, you need to turn on the Developer Mode:

Settings > Device Information > More Information > 
Developer > Developer mode

Note: this is a work in progress, and the availability of this option might vary, and not be available in your version of the Simulator or an actual Firefox OS device.

All the releases and pre-releases of the Firefox OS Simulator are available on Mozilla’s FTP.

Specifying permissions

If you plan on using some APIs that only Packaged apps have access to, you need to add a couple of things to your regular (manifest.webapp) file:

• Add type property (e.g. “type” : “privileged”)
• Specify permission access

"permissions": {
    "contacts": {
        "description": "Required for autocompletion in the share screen",
        "access": "readcreate"
    },
    "alarms": {
        "description": "Required to schedule notifications"
    }
}

There is also an interesting option, in the form of packaged-app-server, which offers zipping the files as a package when they get requested at run time.

$ cd ~/myapp
$ python ~/serve_packaged_apps.py

An example app

As an example app – if you want to check out something easy to dissect, tweak and get started with – feel free to test the Firefox OS Boilerplate App. It supports:

• An install button, offering you to install it as a hosted app
• Web Activities – lots of examples and use cases
• WebAPIs in action
• Offline support (disabled by default)
• Packaged apps – install your app as a ZIP file

Which platforms are supported?

Let’s look at where we are right now with Open Web Apps. They are supported in:

Firefox OS

You can install an Open Web App in Firefox OS (the Simulator or on a device) and most WebAPIs and Web Activities will work.

Firefox on Android

In Firefox on Android you can install an app, and have it installed on your home screen with the correct icon. However, it doesn’t support the WebAPIs and Web Activities.

Nightly/Aurora versions on Desktop

You can install and run a stand-alone app in Firefox Nightly/Firefox Aurora, but it doesn’t have access to many WebAPIs and no Web Activities.

The initial strong focus at the moment is support on mobile, but the hope and goal is that Open Web Apps will work on all platforms and devices, by adding support to needed APIs and more.

Marketplace

When it comes to Open Web Apps, you can use or install them from anywhere. Completely up to you.However, if you are interested in being listed, hosted and much more, I recommend taking a look at the Firefox Marketplace.

You can also visit the Developer Hub for a lot more information about app development.

Conclusion

Open Web Apps aren’t here to change your developing ways – they are here to give you the option to install your existing web solutions as apps, access device-specific APIs and more.

Don’t reinvent the wheel – just make it a bit more powerful!

When I launched @websecurify years ago I wrote a lot of JavaScript, native code and XUL but today the technology combo that I use in Websecurify is made of a custom language compiled to JavaScript that sits on top of the modern HTML5 stack that runs inside your normal browser. Sounds crazy but it somehow feels the right thing to do.

Coming to the realisation that HTML5 was ready for Websecurify’s goals wasn’t an easy step. We were entering unexplored land full of dangers and tradeoffs. No one was attempting to do what we wanted to do and it was sort of scary place to be. Websecurify did not start out of nothing. It was primarily a desktop application and over the years we built a solid framework, wrote thousands of lines of code and spent enormous amount of hours fixing and tracking bugs in our own algorithms and the JavaScript interpreters of the time.

There was also this question in the air whether it was actually possible to write a full-blown security testing framework with just browser technologies – something that browsers were really never meant to do for a range of reasons. We did succeed at the end and here are some of the things that made us take HTML5 on board and the things that we’ve learned during the process.

JavaScript And Its Role

We need to start the story with JavaScript – the language that moves the Web. It is funny how predominant this language has become over the years. It feels like it was yesterday when JavaScript was used just to create fancy rollover buttons and popups. We chose JavaScript for our vulnerability testing platform not because we knew that it was a great language but because it was native to Mozilla’s Xulrunner, which looked like a solid cross-platform desktop application framework at the time.

Over the years we’ve learned a few nasty truths about JavaScript as a general purpose programming language. To start with, JavaScript is a scripting language – meaning it is good for writing scripts. If the aim is to glue things together than use JavaScript. For serious applications, expanding to thousands of lines of code, you will need a proper programming language with static compilation, type system and all that jazz. One of the obstacle we had with JavaScript was around garbage collection. As you program in JavaScript you tend to think with closures in mind. Almost everything is inlined as a function. Due to this style of programming, during the first months of our scanning technology we were constantly running into js interpreter quirks, which were difficult to debug. It was either the interpreter or our own code not keeping enough references around and causing all kinds of unexpected bugs.

Sometimes it was not the garbage collection effect but the opposite – memory leaks. All of the sudden we were allocating far too much memory than we wanted to use. The dynamic nature of the language was also an obstacle as it was never possible to tell if the state of all objects was correct at any given point in time. The immediate solution to this problem was to write unit tests, which we happily started doing but solved the problem only to an extend. Even after thousands of lines of unit tests JavaScript felt short to our expectations.

A Custom Language

During one of the miserable periods of dealing with unexpected bugs we decided to replace JavaScript with a custom language that provided enough robustness for our needs and programming ideals. It was an experiment and it was done out of desperation. I believe we were one of the first to start thinking of JavaScript more or less like an assembler than an actual general purpose programming language. We spent 3 months developing the first prototype and the results were remarkable. The first incarnation of our JavaScript compiler was essentially a glorified grep. Things started looking good because at the time we had for the first time a proper web application security framework that runs in its entirety on standard JavaScript interpreters. Our web security scanning technology matured and we rolled out several versions of our desktop product plus a security testing tool for iOS built with a custom compiler for Objective-C.

If it wasn’t for the lack of support for Xulrunner and XUL, we would have never looked at HTML5 as a replacement. That is right. XUL is amazing framework but it is Mozilla-centric (almost like Java, Flash, Silverlight, ActiveX and other) and lacks any support because it was never meant to be used outside of Firefox. XUL was built all around the design principles behind separation of concerns. Internationalization files, styles, structure and code were all kept separately and overlays provided the most powerful way to extend things as you wish. I still believe that XUL and XPCOM is an awesome combination and perhaps the most powerful desktop programming framework ever made but it was never meant to be.

The Mozilla community was betting hugely on HTML5 as the next generation of programming platform and after having a look at some ongoing projects such as B2G (now Firefox OS), the Chromeless browser experiment, Firefox for Android (completely native) we started to realise that XUL might be soon deprecated and we had to think for the future. We decided to go with HTML5 which was a serious gamble. In fact, it was down crazy.

Going With HTML5

HTML5 happened to be a bit difficult initially. It does lacks any native look and feel but after going over this thought for a while, we realised that this is actually an advantage rather than a disadvantage. HTML5 lacks internationalisation support. It lacks the theming and overlaying features of XUL and initially it felt as being quite immature and dull. It lacks XBL. It is certainly not a XML language. When you are programming in HTML5 the only way is to build everything yourself and compose your application from the ground up in whichever way you desire.

It was difficult to envision how that will translate to our needs but we did it. The UI was built from scratch and all the application elements were encapsulated into a small framework. Can we extend the UI in the same way we used to do with XUL? Definitely not! However, it was simpler and less confusing. HTML5 rendering turned out to be quite fast and very robust for both Firefox and Chrome and for once we saw potential.

We had all the bits that we started with we developed our desktop software but the next big problem to tackle was really about how to deliver a web application security scanner as a modern web app. That was the difficult question. It was difficult because in order for the scanner to work you have to break out of the security model that the browser employes and that is not something browsers allow you to do. We were not lost because we already knew that worse come-to-worse, we will simply embed a browser rendering engine and write the rest of the code natively but we hoped to make our next generation product a first class citizen in both Firefox and Chrome.

Adding Our Own API

For sure, we couldn’t do it with the standard API provided by browsers so we decided to do what the B2G folks did with Firefox OS and add our own API that enables our applications to do what we wanted them to do while still remaining web apps by definition. These augmentations, as we like to call them, were delivered as extensions which provided a thin layer between the browser and Websecurify, our own code delivered as a web app. The mechanics behind the extensions are difficult to describe so I will skip this part. However, it is enough to say that our extensions turned out to be maintainable and provide the functionalities that we required from browsers to support in order for our in-browser web application security suite to work in the same way you would expect it to work as a desktop app.

Websecurify Httpview with full access to browser HTTP trafic provided by the Websecurify Firefox Extension.

The HTML5 app plus a browser extension turned out to be a good combo. The HTML5 app takes care of the delivery mechanism, which as you know, it is over the Web. It also simplified the updates because we no longer had to wait for months before we roll them out because we could do them on daily basis as we go (something that we still do today). The HTML5 app that we wrote also meant that we were future-proof and here to stay as a technology company being able to adopt, pioneer and innovate in previously unexplored field. On the other hand the browser extensions that we delivered provided this much needed support to go beyond what modern browsers are capable of without compromising the user experience or security. The result is tremendous.

Conclusion

Until this point you must be thinking why I am writing all these things. What is this guy’s agenda? When we started writing our XUL-based app we always wanted to contribute our framework back to Mozilla while keeping our scanning technology to ourselves. We felt it was a good compromise. Now when we no longer develop for Xulrunner due to all the reasons explained above, the only thing we can share is our experience and I believe there is a lot to learn from it. We are still trying to figure out the best way to make the old XUL framework public.

The main point I want to make is that although both JavaScript and HTML5 have their own hurdles we find them mature enough to write first-class web applications that go beyond data-entry. It is a proof that web apps are mature enough for all kinds of applications including blockbuster games, complex software which is usually only available for various native platforms and others. I am quite excited to see what the future holds and I bet it will be exhilarating.

Since 2007 or so, I’ve been giving talks on my web browser, although browsers did not offer much of the current technology back then! Of course, each talk of mine was based on a new HTML page which isn’t very practical! Power Polygon was then born! And died a few months after that! I kept it working and used it in many of my talks, but I knew it needed some special updates.

In 2012, with BrazilJS Foundation, which I’m a co-founder, and all the mess with those many presentation tools out there, I decided to reopen the project and BrazilJS became the foster father of the project, which you can find in the BrazilJS’s projects page and on BrazilJS Foundation’s github page.

This new version of Power Polygon was entirely re-written and was based on statements of some of the best speakers we know of, putting the identified useful tools together!

Want to see it working? First, you can watch a short video with an overview of these features:

Now, you can check on the following demos:

• A presentation showing the BrazilJS Conference after event information.
• Demo showing many of the available features
• A demo using the parallax theme
• A slider theme demo
• Using a 3D effect for slide transitions: example 1 and example 2

Why Power Polygon?

Well, the first thing is that all the existing presentation tools work by themselves and following their own formats or “fixed” themes and results! The main idea of Power Polygon is to keep it open as the web!
In Power Polygon, there may be addons, themes, transactions and customisations as you need! Even extra JavaScript and CSS or HTML elements can be added.

Your talks in Power Polygon can count on some interesting tools, besides the addons, to help you presenting them, as well as to publish them and making it easier for users to see it afterwards.

Plus, you can change languages of your slides, share it or even profile your talk for different audiences. Once this new version of Power Polygon was born from the knowledge and experience of great speakers and their living situations, you know it is being prepared and maintained to fit such needs!

Power Polygon is open source under MIT license, although, you can create your theme or addon and use its own license, as well as your talks. We believe that being free, means you should be able to CHOOSE what you want to keep for free or not! Still, the Power Polygon core is and will be kept Open Source.

Using it

You can simply load the jquery and power-polygon scripts to your page, and then every section element will become an slide!
All you gotta do is to add, in the end of your HTML code, the following line:

PPW.init();

This will set all the default settings to your talk! So, you can easily copy your slides from a tool to another, as well as copying them from one presentation to another! You can pass your own settings to the .init method and change everything!

Another way of using Power Polygon, is to have all your slides saved in individual HTML files…you can even have different directories for each slides and then, put their images inside each respective folder, Power Polygon will load them for you as you define the slides property in your settings, like this:

PPW.init({
    slides: [
        { id: "myFirstSlide", type: "opening"},
        { id: "anotherSlideOfMine", type: "content"},  // default type, if type is not defined
        { id: "anotherSubject", type: "section"}, // slides of type section look like slide titles
        { id: "anotherSlide", type: "content", notes: ["remember the milk!", "drink water!"]},
        { id: "theLastOne", type: "closing"} // the closing slide is the end of your talk
    ]
});

As you see, your slides may have notes and different types. By defining your slides on the init method, PPW(Power Polygon Web) will look for section elements with the respective IDs in your HTML document, if it is not found, PPW looks for it on a customisable directory.

External slides do not need to have the section element, once PPW will create it for each external slide, giving it the slide id.

You can see more in the full definition of the available settings, and there’s more info in general in the wiki documentation.

Some features

Power Polygon offers all the features we and the many speakers who have helped us building it, realized that would be useful for speakers to use, as well as to the audience to follow. You can easily change the font-size of your slides, the language of your texts(you can create your slides specifying as many different languages as you need), apply new themes, load addons, use CSS3 animations besides the jQuery animations…

Plus, you can see the thumbs of your slides, search into slides and use a group of default shortcuts, or create your own set of shortcuts. You can use some zooming features and add actions to your slides, as well. The presentation tool will let you know about the notes you wrote for each slide, the time left and what slide is next. Also, be alerted as the time passes and you can use the social addon here to see your mentions on twitter during your talk.

You can open your camera to the audience quite easily, so you can show them a device in your hand or anything else, re-sizing, dragging the video, or setting it to full screen. It is also easy for you to test the resolution, colors and font sizes before you start your talk, using the splash screen.
Many other features will be added and you can give us more ideas!

Feel free to submit new issues on our github repository!

Actions and animations

Besides the animations you will already be able to do by using jQuery on your talk, you will also be able to use the PPW.animate() method. The difference here is that the PPW.animate method applies animations using CSS3, instead of JavaScript, and also offers a bunch of different, more complex set of animations, like bouncing or light-effect.

To add actions to a slide, all you gotta do is adding a script INSIDE your slide, either external or not, calling the method PPW.addAction(). This will allow you to create a timming action, or to define what and how it is done, and undone.

Addons and themes

You can also load or create your own addons, so you can add more features to your talk. Among the addons, you can use, for example, the syntax highlight addon, which shows better source codes on your talks, and even allows you to focus on specific lines of code, in case the speaker is a developer.

Another addon can load the mentions you are receiving on twitter, and show them to you on your presentation tool while you are giving your talk! Another example of addon is the remote-control, which allows you to control your talk via cellphone or any mobile device, but not only go forward and backward with your slides, but also to show a pointer or a focus spot area on the current slide! You can even draw on the slide using the screen of your mobile device.

.

Everything that happens in Power Polygon triggers an event that can be listened by using the PPW.addListener() method. You can see the list of available events on the API page.

What is next?

We want the communities, not only from Brazil, to contribute to Power Polygon, to make it more useful for both speakers and attendees! We want the presentations to be creative and open as the web itself, and by that, I mean your talks should be different, should be creative, should be YOURS!

Therefore, we want to have a talk repository, where you can publish your talks, embed them everywhere, and also have them indexed by search engines. Another huge step we want, is to build a great new interface for you to create your talk, create themes or even addons! Also, feel free to contribute to it, as well!

We will be offering a repository with all the published addons, themes and transitions.

We need you!

Power Polygon was created to exist as the web! Open, creative and help people to reach their goals! I know we can’t do it alone, so we need you! Power Polygon can be a much more useful tool with your ideas, contributions, and why not, addons, themes or even pull requests on github!

Also, feel free to submit new issues on our github repository!

By the way, BrazilJS has a bunch of useful, cool projects that may need your initiative! You will be VERY welcome to contribute to our projects and to be at our conference!

I hope you like Power Polygon and look forward to hearing new ideas and feedback from you!

Weekly Resources for HTML5 Apps Developers

Articles

• AngularJS JavaScript MVC Framework and SEO
• JS adolescence
• Compiling to JavaScript: What, Why, and How?
• JavaScript APIs you’ve never heard of (and some you have)
• Responsive Images: What We Thought We Needed

Resources

• Craft.js – small but powerful JavaScript framework
• Cool HTML Visual Test Tool
• ScrobMaster – Master your scroll events based on the elements you are affecting.
• Haraka – a Node.js Mail Server
• TraceKit – Attempts to create stack traces for unhandled JavaScript exceptions in all major browsers.

Bonus Link

• JavaScript – The Real Bad Parts

If you find a link that you think should be included, please feel free to forward it to JStagner at Mozilla.com

This week Mozilla’s Developer Engagement team suggest reading about headtrackr for real-time face tracking, smartphone features you never thought of using, Web browser support for HTML5 Forms and more!

Continued…