Interactive Digital Signage with Krellian

Today I’m excited to announce that Krellian (Webian’s commercial sponsor since 2011), are planning to commercialise parts of the Webian open source project for applications in the digital signage market.

The years of research and development which have gone into the Webian project will provide a valuable basis on which to build Krellian’s new software platform for interactive kiosks and digital signage. That will include a simple, reliable web-based operating system to run on connected displays and a secure cloud service for monitoring, controlling and deploying web content to those displays over a standard web protocol.

You can read more in this blog post and register your interest today at

In search of a web runtime for Webian Shell

I’ve been experimenting with various web runtimes for running the system chrome of Webian Shell.


  • Enable me to create browser chrome which can safely embed web content
  • Provides an API to expose aspects of the content via methods and events (e.g. location and title changes, icons, app manifests etc.)
  • Ideally allow me to write the chrome in HTML, CSS and JavaScript
  • Ideally be portable across desktop and tablet hardware as well as other form factors like TV and VR in future
  • Provide a route to create an OS which boots directly to Shell without any other graphical applications running

Previously Webian Shell has used used XULRunner, Mozilla Chromeless and B2G from Mozilla, but all of these projects have now been discontinued. Gecko is no longer seen as a platform for building applications, just the back end of Firefox. This means it’s very difficult these days to build anything except Firefox with Gecko.

During the transition of B2G to the community I thought it would be possible for me to continue using B2G OS as a base, using the new simplified architecture we had created with a split between system chrome and system web services. Unfortunately all B2G code is now being ripped out of Gecko so that isn’t an option.

Since then, the runtimes I’ve investigated include:

  • Positron
  • GeckoView
  • Electron
  • Android WebView
  • React Native
  • qbrt
  • Muon


Positron was meant to be an Electron-compatible app runtime for creating desktop apps based on Gecko. This would have been ideal for the desktop version of Shell, but unfortunately that project has also now been discontinued.


On the mobile side, GeckoView is meant to be a Gecko-based alternative to Android’s WebView. I experimented with creating a tablet version of Shell using GeckoView as part of an Android app. My idea was to use Android Things to boot to Shell as the only Android app running on a tablet device.

I got Android Things running on a Raspberry Pi booting a basic Android app which provides a status bar and a clock. The downside of this approach is that it would mean a completely separate code base for desktop and tablet versions, as GeckoView is designed to have chrome written in Java. I tried to get GeckoView running chrome-privileged HTML so that I could write the chrome in HTML, CSS and JavaScript but there’s currently no obvious way to package HTML (or XUL) chrome in an Android app for use with Gecko. Also, GeckoView is still very immature, tricky to use and limited in features. Firefox Focus is still using Android’s native WebView and although there’s a branch using GeckoView I don’t have confidence that’s going to ship any time soon. GeckoView remains an experiment.


Electron is a well supported desktop app runtime created by GitHub for the Atom text editor which allows you to write desktop applications in HTML, CSS and JavaScript. An advantage of Electron is that it uses the Chromium code base but also allows you to use NodeJS APIs. With a chrome + web services split for the Shell architecture this could mean being able to run the front end chrome and back end web services using the same runtime, which is quite attractive.

The downside of Electron is that it’s not really designed for writing browser applications. The Tofino team discovered some limitations when trying to prototype new desktop browser experiences. Some of these limitations aren’t so much of a problem for Shell, but it seems likely that at some point I’m going to come across a missing feature.

One example of a feature which Gecko has which Electron lacks is an event to tell the <webview> embedder when a manifest link relation is detected in a web page. This is needed by Shell to detect and install web applications. I filed a feature request for this but in the meantime the community suggested a workaround by using a “preload script” which allows you to inject a privileged script into web pages which runs before the content is rendered. I don’t really like this approach but it does provide a route for me to polyfill over missing features.

In terms of providing a route to booting an OS straight to Shell I discovered that has a template for booting Resin OS straight to an ElectronJS application. What’s particularly cool about this is that they have support for various IoT developer boards including the Raspberry Pi and apparently have support for touch events. As I’ve been trying to prototype the tablet version of Shell using a Raspberry Pi with a touch screen (for use as a smart home controller), this could be ideal. It would allow me to write both the desktop and tablet versions of Shell using the same runtime and share code between them. The question is how well this performs in practice, which is going to require some more experimentation.

Android WebView

As GeckoView is still quite immature I tried using the native Android WebView instead. This obviously works fine as an Android app, but I got stuck when I realised that Android Things on Raspberry Pi didn’t yet support WebView because it lacked OpenGL support. Trying to add a WebView to an Android app would just crash the app. Presumably this would also prevent me running a GeckoView based app on Android Things.

This bug has just been fixed so it should be possible to use WebView in Preview 5 of Android Things. But it would still mean a completely separate code base for the tablet version of Shell and I’m not sure the native Android WebView has all the features I need.

React Native

React is an interesting option. React Native compiles to native Java for Android and has a webview component, albeit probably not very tested for building a full browser application. React can also be used with Electron on desktop, although code probably needs to be different between desktop and Android. This is attractive as it would allow sharing some code between desktop and tablet versions of Shell. But writing in React is not really writing in HTML, CSS and JavaScript. It’s writing in JavaScript which is compiled to HTML, CSS and JavaScript, or to a Java Android application. It would have to be a conscious choice to re-write the whole Shell application in a React style using JSX and style definitions in JavaScript.


The “Quantum Browser Runtimerose from the ashes of Positron with a less ambitious goal of providing a desktop application runtime using Firefox and existing Gecko APIs, rather than trying to be compatible with Electron.

This was great news and really unblocked me in moving forward on the desktop version of Shell. qbrt can easily be installed using npm and allowed me to run chrome written in HTML, CSS and JavaScript with a simple command, much like XULRunner and Mozilla Chromeless from the days of old.

The downside is that because Gecko is so tightly coupled with Firefox these days, qbrt includes a bit too much of Firefox in its current incarnation. This makes for a bulky download and weird issues like my application calling home to Mozilla for things because it thinks it’s still Firefox. These things may well be fixed over time, but qbrt still feels like a side project and I don’t have confidence that it’s going to stick around very long.

Technically Firefox is still using B2G’s Browser API which I need to create Shell and there is a vague plan to move Firefox from XUL to HTML over time, so my needs should be fairly in line with the long term plans for Firefox. But this plan is slow moving and while the “platform” team (now the Firefox back end team) is laser focused on the current needs of Firefox, anything that gets in their way gets ripped out of Gecko. For example, methods on the Browser API which were used by B2G to set the visibility of browser tabs to prioritise processes were removed without notice to make way for a new process priority manager in Firefox.

I really want to use Gecko for Webian Shell, but I’m finding the Firefox team are quite hostile to anyone except the Firefox team using Gecko to build things and it’s getting harder and harder to do so.


Muon is a fork of Electron created by Brave for their desktop web browser. It’s like Electron but designed for building browsers and browser-like applications using HTML, CSS and JavaScript. It uses the Chromium source code directly rather than Electron’s fork (so it can keep better track of new Chromium features), supports Chrome extensions and has better security features for building browsers.

I haven’t yet come across any of the limitations of Electron that Muon is designed to fix, but I imagine that eventually I will. Also, I understand that the Kai OS team is using Muon to try to replace Gecko on B2G by porting Blink and Muon to the Gonk OS layer (basically the lower layers of Android). If they made that open source it would mean that there could be a path to running Muon-based applications on Android hardware in the future, which is quite exciting.


There is no obvious solution which currently meets all of my requirements. I think the neatest solution I’ve found so far is Electron. It would allow me to embed web content in a <webview> which has a fairly mature API and a mechanism to polyfill missing webview features. It would allow me to write the chrome in HTML, CSS and JavaScript. It may be possible to run it on both desktop and touch-based hardware (at least using a Raspberry Pi) and a has an existing potential route to creating an OS which boots directly to Shell (via Resin OS). As a bonus it would allow me to run both the front end chrome and back end web services using the same runtime.

Electron has some limitations when it comes to building a browser and I’m not sure how well it will perform on touch based hardware compared with say a native Android app running on Android Things, and there’s currently no easy way to get it running on Android tablet hardware. Also, it would mean leaving behind Gecko which Webian Shell has been using from the start.

In an attempt to hedge my bets I’ve been trying to write a common layer of abstraction on top of both Electron’s <webview> and qbrt’s <iframe mozbrowser> HTML elements by creating a <webian-webview> web component with my own WebView API. This would allow me to support both Electron and qbrt with the same front end chrome code. This in itself was not easy because Gecko still doesn’t support Custom Elements or the Shadow DOM. I was able to achieve it using the webcomponents.js polyfill, although there’s a bug with that library which prevents my current implementation of the chrome from running in Gecko. I also created a startup script which can detect whether it’s running in Electron or qbrt and follow the correct code path accordingly. Whilst I like the flexibility of being able to run on both Gecko and Blink, this adds an extra layer of abstraction which will probably hurt performance in the long term and may get quite complicated as I get into more advanced features which are significantly different or simply missing from qbrt or Electron.

I think my overall conclusion is to start with Electron. Electron is well supported, comes pretty close to what I need and it provides an easy path to migrate to Muon and/or a potential KaiOS runtime in future. If Spidernode goes anywhere and Mozilla puts some real commitment behind a Gecko app runtime then I could potentially migrate back to Gecko in future, but for now it’s just too damn hard to use. The Electron approach might not work so well for touch-based devices if the Kai OS runtime doesn’t get open sourced as I suspect performance on Resin OS isn’t going to be great and I’ll have to implement my own on-screen keyboard which I’d probably get for free with Android Things. So I may keep experimenting with a native Android version or even using React and compiling to different platforms.

Webian Shell & Webian Home Update

I recently wrote about The Story of Firefox OS, which ends with Mozilla no longer continuing their work on the Boot to Gecko project.

Having worked on the concept of a web oriented OS for over a decade now, I have no intention of stopping just because Mozilla has lost interest. I intend to continue hacking on Webian when I can.

In February I gave the Webian website a bit of a refresh and updated it with my latest designs for Webian Shell (now including both a tablet and desktop UI) and Webian Home (the home server part of Webian which I started earlier).

Webian Shell

Webian Shell is a graphical shell for the web.

Webian Shell tablet mockup.

Now that Mozilla Chromeless, XULRunner, mozApps and B2G have all been stopped, it’s incredibly difficult to use Gecko for anything other than building Firefox. The Positron and GeckoView projects hold some promise of Gecko being embeddable again in the future (on desktop and mobile respectively), but in the meantime I have to consider the possibility of using something else for Webian Shell.

One possibility I’m considering for the tablet version is re-writing the UI shown above as a full screen Android app using Android’s WebView, which could eventually be used as a stand-alone front end running on top of Android Things.

On the desktop side I’m considering using Electron, although the Tofino team has already discovered some of the limitations of that approach.

This split approach also isn’t ideal as I’d ideally like to share code between the two versions (rather than have one in Java and one in JavaScript!), so I’m open to other ideas. I’ve looked at other potential solutions like React Native, but so far haven’t found anything that does what I need.

When I get the chance I’ll try prototyping one of these approaches and see how far I get.

Webian Home

Webian Home is a web server for your home.

Webian Home Mockup

My work in Connected Devices at Mozilla has also re-kindled my interest in building a home web server. I have a broad vision for the use cases of a web server in the home (some examples below), but I hope that the work in my day job might contribute to the smart home aspect of that vision.

Smart Home

  • Heating
  • Lighting
  • Security

Home Media

  • Family photos
  • Music collection
  • Home videos

Family organisation

  • Family calendar
  • Family todo list
  • Family noticeboard

Don’t expect to see much progress on either the client or server parts of Webian in the near future, I have a day job to do. But I also have no intention of stopping working on these projects any time soon 🙂

What is a Web App?

Reposted from

What is a web app? What is the difference between a web app and a web site? What is the difference between a web app and a non-web app?

In terms of User Experience there is a long continuum between “web site” and “web app” and the boundary between the two is not always clear. There are some characteristics that users perceive as being more “app like” and some as more “web like”.

The presence of web browser-like user interface elements like a URL bar and navigation controls are likely to make a user feel like they’re using a web site rather than an app for example, whereas content which appears to run independently of the browser feels more like an app. Apps are generally assumed to have at least limited functionality without an Internet connection and tend to have the concept of residing in a self-contained way on the local device after being “installed”, rather than being navigated to somewhere on the Internet.

From a technical point of view there is in fact usually very little difference between a web site and a web app. Different platforms currently deal with the concept of “web apps” in all sorts of different, incompatible ways, but very often the main difference between a web site and web app is simply the presence of an “app manifest”. The app manifest is a file containing a collection of metadata which is used when “installing” the app to create an icon on a homescreen or launcher.

At the moment pretty much every platform has its own proprietary app manifest format, but the W3C has the beginnings of a proposed specification for a standard “Manifest for web applications” which is starting to get traction with multiple browser vendors.

Web Manifest – Describing an App

Below is an example of a web app manifest following the proposed standard format.

  "name": "My App",
  "icons": [{
    "src": "/myapp/icon.png",
    "sizes": "64x64",
    "type": "image/png"
  "start_url": "/myapp/index.html"

The manifest file is referenced inside the HTML of a web page using a link relation. This is cool because with this approach a web app doesn’t have to be distributed through a centrally controlled app store, it can be discovered and installed from any web page.

<!DOCTYPE html>
    <title>My App - Welcome</title>
    <link rel="manifest" href="manifest.json">
    <meta name="application-name" content="My App">
    <link rel="icon" sizes="64x64" href="icon.png">

As you can see from the example, these basic pieces of metadata which describe things like a name, an icon and a start URL are not that interesting in themselves because these things can already be expressed in HTML in a web standard way. But there are some other other proposed properties which could be much more interesting.

Display Modes – Breaking out of the Browser

We said above that one thing that makes a web app feel more app like is when it runs outside of the browser, without common browser UI elements like the URL bar and navigation controls. The proposed “display” property of the manifest allows authors of web content which is designed to function without the need for these UI elements to express that they want their content to run outside of the browser.

  "name": "My App",
  "icons": [{
    "src": "/myapp/icon.png",
    "sizes": "64x64",
    "type": "image/png"
  "start_url": "/myapp/index.html"
  "scope": "/myapp"
  "display": "standalone"

The proposed display modes are “fullscreen”, “standalone”, “minimal-ui” and “browser”. The “browser” display mode opens the content in the user agent’s conventional method (e.g. a browser tab), but all of the other display modes open the content separate from the browser, with varying levels of browser UI.

There’s also a proposed “orientation” property which allows the content author to specify the default orientation (i.e. portrait/landscape) of their content.

App Scope – A Slice of the Web

In order for a web app to be treated separately from the rest of the web, we need to be able to define which parts of the web are part of the app, and which are not. The proposed “scope” property of the manifest defines the URL scope to which the manifest applies.

By default the scope of a web app is anything from the same origin as its manifest, but a single origin can also be sliced up into multiple apps or into app and non-app content.

Below is an example of a web app manifest with a defined scope.

  "name": "My App",
  "icons": [{
    "src": "/myapp/icon.png",
    "sizes": "64x64",
    "type": "image/png"
  "start_url": "/myapp/index.html"
  "scope": "/myapp"

From the user’s point of view they can browse around the web, seamlessly navigating between web apps and web sites until they come across something they want to keep on their device and use often. They can then slice off that part of the web by “bookmarking” or “installing” it on their device to create an icon on their homescreen or launcher. From that point on, that slice of the web will be treated separately from the browser in its own “app”.

Without a defined scope, a web app is just a web page opened in a browser window which can then be navigated to any URL. If that window doesn’t have any browser-like navigation controls or a URL bar then the user can get stranded at a dead on the web with no way to go back, or worse still can be fooled into thinking that a web page they thought was part of a web app they trust is actually from another, malicious, origin.

The web browser is like a catch-all app for browsing all of the parts of the web which the user hasn’t sliced off to use as a standalone app. Once a web app is registered with the user agent as managing a defined slice of the web, the user can seamlessly link into and out of installed web apps and the rest of the web as they please.

Service Workers – Going Offline

We said above that another characteristic users often associate with “apps” is their ability to work offline, in the absence of a connection to the Internet. This is historically something the web has done pretty badly at. AppCache was a proposed standard intended for this purpose, but there are many common problems and limitations of that technology which make it difficult or impractical to use in many cases.

A new, much more versatile, proposed standard is called Service Workers. Service Workers allow a script to be registered as managing a slice of the web, even whilst offline, by intercepting HTTP requests to URLs within a specified scope. A Service Worker can keep an offline cache of web resources and decide when to use the offline version and when to fetch a new version over the Internet.

The programmable nature of Service Workers make them an extremely versatile tool in adding app-like capabilities to web content and getting rid of the notion that using the web requires a persistent connection to the Internet. Service Workers have lots of support from multiple browser vendors and you can expect to see them coming to life soon.

The proposed “service_worker” property of the manifest allows a content author to define a Service Worker which should be registered with a specified URL scope when a web app is installed or bookmarked on a device. That means that in the process of installing a web app, an offline cache of web resources can be populated and other installation steps can take place.

Below is our example web app manifest with a Service Worker defined.

  "name": "My App",
  "icons": [{
    "src": "/myapp/icon.png",
    "sizes": "64x64",
    "type": "image/png"
  "start_url": "/myapp/index.html"
  "scope": "/myapp"
  "service_worker": {
    "src": "app.js",
    "scope": "/myapp"

Packages – The Good, the Bad and the Ugly

There’s a whole category of apps which many people refer to as “web apps” but which are delivered as a package of resources to be downloaded and installed locally on a device, separate from the web. Although these resources may use web technologies like HTML, CSS and Javascript, if those resources are not associated with real URLs on the web, then in my view they are by definition not part of a web app.

The reason this approach is commonly taken is that it allows operating system developers and content authors to side-step some of the current shortcomings of the web platform. Packaging all of the resources of an app into a single file which can be downloaded and installed on a device is the simplest way to solve the offline problem. It also has the convenience that the contents of that package can easily be reviewed and cryptographically signed by a trusted party in order to safely give the app privileged access to system functions which would currently be unsafe to expose to the web.

Unfortunately the packaged app approach misses out on many of the biggest benefits of the web, like its universal and inter-linked nature. You can’t hyperlink into a packaged app, and providing an updated version of the app requires a completely different mechanism to that of web content.

We have seen above how Service Workers hold some promise in finally solving the offline problem, but packages as a concept may still have some value on the web. The proposed “Packaging on the Web” specification is exploring ways to take advantage of some of the benefits of packages, whilst retaining all the benefits of URLs and the web.

This specification does not explore a new security model for exposing more privileged APIs to the web however, which in my view is the single biggest unsolved problem we now have left on the web as a platform.


In conclusion, a look at some of the latest emerging web standards tells us that the answer to the question “what is a web app?” is that a web app is simply a slice of the web which can be used separately from the browser.

With that in mind, web authors should design their content to work just as well inside and outside the browser and just as well offline as online.

Packaged apps are not web apps and are always a platform-specific solution. They should only be considered as a last resort for apps which need access to privileged functionality that can’t yet be safely exposed to the web. New web technologies will help negate the need for packages for offline functionality, but packages as a concept may still have a role on the web. A security model suitable for exposing more privileged functionality to the web is one of the last remaining unsolved challenges for the web as a platform.

The web is the biggest ecosystem of content that exists, far bigger than any proprietary walled garden of curated content. Lots of cool stuff is possible using web technologies to build experiences which users would consider “app like”, but creating a great user experience on the web doesn’t require replicating all of the other trappings of proprietary apps. The web has lots of unique benefits over other app platforms and is unrivalled in its scale, ubiquity, openness and diversity.

It’s important that as we invent cool new web technologies we remember to agree on standards for them which work cross-platform, so that we don’t miss out on these unique benefits.

The web as a platform is here to stay!

Introducing Krellian, Webian’s New Sponsor

by Ben Francis

Firstly, thanks for the incredible continued contributions from the Webian community and for all the work you’ve done on Webian Shell, which has now had more than 95,000 downloads!

Introducing Krellian

This week I left my job as Product Manager of Clinked at Rabbitsoft to start a software consultancy called Krellian.

Through Krellian I will be able to continue to lead the Webian project, and I will also be taking up a new contract with the Mozilla Corporation to work with them on Boot to Gecko (B2G).

Like me and the other members of the Webian community, Mozilla believes that the open web can displace proprietary, single-vendor stacks for application development. The B2G project will include prototype APIs for exposing device and OS capabilities to web content, a privilege model to safely expose these new capabilities, a complete “low-level substrate” for Android-compatible devices and a collection of web apps to prioritise and prove the power of the platform.

Benefits to Webian

The potential benefits for Webian are enormous. Webian Shell was already hitting limitations of what is currently possible with Mozilla Chromeless and this new work on the core Mozilla platform promises to make many more of Webian’s goals possible. While B2G initially focuses on the mobile space, Webian can focus on nettop and netbook form factors and perhaps eventually the two projects could even converge.

Sponsorship from Krellian will provide the ongoing resources necessary for running the Webian project and ensure that it remains free and open source.

I’m excited about this new chapter in Webian’s story and believe more strongly than ever in the future of the open web.

Keeping Web Apps Open

by Ben Francis

The Universal App Platform

The best thing about web apps is that they can run on any platform. This is because they use a set of open standards which are universally supported. The latest incarnations of these standards like HTML5 and CSS3 are more powerful than ever and it seems inevitable to me that the web will eventually win out as the open, universal app platform.

The current generation of popular desktop operating systems like Windows 7, OS X and Linux and mobile operating systems like iOS, Android and Windows Phone treat web apps as second class citizens, inferior to their native platform-specific counterparts. But that’s all set to change.

Microsoft Windows 8, Google Chrome OS, The Linux Foundation’s Tizen and Mozilla B2G will all join Webian in putting web apps centre stage, as the preferred category of app on their respective platforms.


Thanks to HTML5 and related standards web apps are already pretty powerful, but there is still some way to go before web apps can do everything that native apps can do. On mobile platforms new APIs are needed for access to telephony, messaging and cameras for example, and some kind of “app store” style distribution and installation mechanism is likely to be needed to provide a more app-like experience. “Installing” a web app is a little like bookmarking a web site and can provide an opportunity for the app to ask the user for all the permissions it needs up-front, download any resources which will be needed for offline use and perhaps add an shortcut icon to an app list.

Because there aren’t currently established standards for all of these features, each platform is intially rolling its own approach. Apps for Chrome OS can only be found via Google’s own “Chrome Web Store“, you have to have a Google Account to install them and many of the apps found there will only work in Chrome. Windows 8 will have a set of APIs for its new Metro user interface, but apps written for Metro won’t necessarily work on other platforms. We don’t yet know much about Tizen, but previous mobile platforms like HP’s WebOS and the MeeGo Web Runtime have also had platform-specific APIs.

An Open Approach

Mozilla is also working on a new set of web APIs, but in line with their mission of promoting openness on the web they’re doing so in a more open way. You can see the progress of their APIs for telephony, messaging (SMS), battery, visibility, settings, power management and contacts on Bugzilla. These new APIs on Mozilla’s core platform are the first step towards a new mobile OS from Mozilla called B2G or “Boot to Gecko”. B2G will have a highly customisable UI built entirely with web technologies and will allow for the installation of Open Web Apps, as proposed by Mozilla Labs. With Open Web Apps, anyone can run their own app store or directory and the aim is to create cross-platform installable web apps.

Mozilla is also collaborating with Google on “Web Activities” or “Web Intents” which could provide a standard mechanism for apps to call other apps for certain functions. This collaboration is a promising sign because Mozilla can not define standards on their own and will need to co-operate with other browser & OS vendors.

Towards Standards

There are already standardisation efforts in this area at the W3C such as the Device APIs Working Group and the Widget Packaging and XML Configuration recommendation, but W3C recommendations are not always in line with what the implementors (browser & OS vendors) are doing.

For example, W3C Widgets provide a mechanism for installing a “widget” locally on a device by packaging up all of its resources in a zip file, including an XML manifest file. The specification was used for widgets in the Opera browser but when the MeeGo Web Runtime tried to use it as a method of installing fully fledged web apps it didn’t work out very well.

Mozilla and Google are taking a different approach to installable web apps, both choosing to use a JSON manifest file and rely to a large extent on HTML5’s offline capabilities for caching and updating offline resources. Even these two similar implementations have subtle differences which make them incompatible with each other so there’s a real need for standardisation in this area if we’re to have cross-platform installable web apps.

Hosted vs. Packaged

One slightly odd trend in the standardisation of “web apps” is the tendency to focus on “packaging” apps rather than “hosting” them. This seems to be an attempt to emulate the way mobile and desktop apps currently work by bundling up all of the app’s resource in a “package” which is downloaded and installed locally. The whole package then needs to be updated every time any of the resources change. This seems odd to me because this isn’t the way the web usually works and it doesn’t seem very web-like at all.

The fact that an individual resource can be identified by a URI is what makes it a part of the web, so to package resources up in one big bundle to be downloaded and used locally seems to break the web paradigm and therefore these apps are not “web apps” in my view, just apps downloaded over the web. This is how W3C widgets work and it’s also how Chrome “packaged” apps work and seems to be the direction of the Wholesale Apps Community, the EU funded Webinos project and the Native Web Apps community on the W3C web site.

For an app to be part of the web, I think all of its resources (HTML, CSS, JavaScript, images etc.) must be identifiable by a URI. Resources which are needed when operating offline can be marked as such in an HTML5 cache manifest, which then also provides an automatic update mechanism when these resources are changed. This maintains one of the great characteristics of web apps which is their ability to be updated seamlessly with new features and bugfixes without the user having to manually upgrade to a new version. Mozilla Open Web Apps seem to work in this way, and so do Chrome’s “hosted” apps.


It seems that web apps will be the preferred category of apps for a whole new generation of operating systems, but in order for these web apps to remain cross-platform new open standards must be agreed upon for APIs which give web apps all the power of native apps.

A mechanism for the discovery, installation and updating of hosted installable web apps and a trust framework which allows for secure open distribution is also something which I think desperately needs standardisation if the vision of a universal open web app platform is to be realised.

Webian Shell – Past, Present and Future

Webian Shell was announced last week and the response has been incredible, already more than 60,000 people have downloaded the prototype and it’s caused a bit of a stir in the blogosphere and tech press.

I thought I’d post an update to explain a bit of background to the project, talk about the buzz surrounding the Shell prototype, summarise the amazing feedback I’ve already received, answer a few frequently asked questions and set out a roadmap for the future.

Sorry this blog post is so long but I didn’t have time to write a shorter version.


First, some background on the project’s origins.

  • 2006 – An idea for a full screen web browser which could replace the traditional desktop environment and window manager and take advantage of emerging web standards for graphics, audio, video and voice.
  • 2007 – An experiment to implement that idea using Mozilla’s XUL markup language and XULRunner platform, then some funding to try and turn this and other ideas into a business plan.
  • 2008 – Discussions with colleagues during my internship with Google who encouraged me to take it further.
  • 2009 – I released a design concept with a series of static mockups to explain the idea better and my friend Sam starting hacking on a Python/Webkit/GTK version, then shortly afterwards Google announced Chrome OS which was a very similar idea. Google seemed to be doing a better job of it than I could, so I switched my attention to another of my long running ideas, a home web server.
Webian screenshots since 2006

When some old colleagues from Google got in touch to tell me that the company had just announced something very similar to my idea, I felt I couldn’t possibly do a better job than Google so there wasn’t much point in continuing. I was impressed by their focus on speed, their innovative security model and their work with netbook manufacturers to achieve tight hardware integration.

But then towards the end of 2010, Mozilla Labs announced the Chromeless project which allows you to build desktop applications using web technologies (HTML, CSS & JavaScript) and the Open Web Apps project which proposed a more open model for web app stores than the approach taken by the Chrome Web Store.

This inspired me to start working on the concept again for two reasons. One was that I could now rapidly prototype the software using all the power and flexibility of web technologies themselves. The other reason was that I was inspired by Mozilla’s vision of a more open ecosystem for web apps which wasn’t dominated by one vendor with a single shop front. Surely if there’s room in the marketplace for more than one browser and more than one web app store, there is room for more than browser-based OS.

With Chrome OS, every user has to have a Google Account, they can only “install” web apps from Google’s Chrome Web Store and they can only use hardware approved by Google. With Webian I wanted to try a more open approach where you don’t need an account with a single vendor to log in, you can choose to install apps from multiple app stores or direct from vendors and you can choose from a wider range of commodity hardware like netbooks and tablet devices.

So towards the end of last year I started working on a prototype of the user interface in my spare time based on my design concept from 2009. With a bit of help from the Mozilla Chromeless team, 6 months later I had Webian Shell 0.1. Mozilla Labs invited me to write a guest blog post about my project and suddenly, five years after starting to work on the idea, the project started to get a lot of interest.


Day One

In the first 24 hours after the Mozilla blog post, the Webian Shell 0.1 prototype had been downloaded 3000 times. My web server started to struggle with the load so I got in touch with my hosting company late at night and they were able to upgrade the server to cope with the demand within an hour.


Then the news started to spread in the blogosphere and twittersphere. I saw blog posts in English, German, Italian, Greek, Czech, Polish, Spanish, Japanese, Chinese, Phillipino, Arabic, Portuguese and Bulgarian! I also got contacted by a news agency in Germany and the news started to spread around European technology news sites like and pressetext.

Tech Press

Then we got slashdotted. That’s when things really started to take off. Webian Shell was featured by Engadget, Gizmodo, Techworld, PC World, PC Advisor, IT Pro Portal, Reddit, Ostatic, The H, Conceivably Tech and others and hits on the web site soared.


The aim of the initial prototype was to convey the basic idea behind the project and capture peoples’ imagination and I think it worked! As of today, Webian Shell 0.1 has been downloaded more than 60,000 times! The web site has had over 55,000 visitors from 163 countries, the announcement video on YouTube has been watched 45,000 times and the project has assembled quite a following on Twitter, Facebook and the Google Group.


Best of all are the 120+ responses (ideas, questions, problems and praise) which have already been posted on the feedback page. Sam has been helping me try to get through them all and start to list all of the feature requests and bug reports on the project tracker, with a view to putting together a roadmap.

This feedack falls into a few categories:

As well as feature suggestions and bug reports we’ve already seen other awesome contributions in the form of UI mockups and code. I’d like to put in place better tools and processes for accepting these valuable contributions (see below).

Frequently Asked Questions

There are a few questions which keep coming up, and some misconceptions which have become quite widespread which I’d like to address here.

Is Webian a Mozilla Project?

No. A lot of headlines for news articles which talk about Webian Shell incorrectly state that Webian is a Mozilla project. Webian Shell is built on Mozilla Chromeless from Mozilla Labs and was featured on the Mozilla Labs blog but it is an independent project.

Members of the Mozilla Chromeless team were a huge help in getting Webian Shell 0.1 off the ground and I definitely hope that this collaboration will continue. Mozilla Labs experiments demonstrate a huge range of innovative ideas which could be incorporated into the Webian project.

Is Webian a clone of Chrome OS?

No. Webian Shell has been in development under different names since at least 2006 and was designed independently of Chrome OS. However, Chrome OS has gone a long way towards validating the concept of a brower-based OS and I hope that both projects will be able to learn from each other and even co-operate in the future.

It’s a little premature to compare Webian with Chrome OS because so far all that has been released is a simple JavaScript prototype of a user interface which piggybacks on your existing OS, Chrome OS is an entire operating system with an ecosystem of apps, an innovative security model and partnerships with hardware manufacturers.

Is Webian a derivate of Debian?

No. At least not yet. The long term goal of Webian is to create an operating system dedicated to hosting and using web applications. That may well be based on Debian but that isn’t decided yet.

The name “Webian” is derived from “web” (the shortened form of “World Wide Web”) and the english suffix “-ian” (meaning “of” or “belonging to”) – therefore “Webian” means “of or belonging to the World Wide Web”. The similarity is largely a coincidence and currently there is no relationship between the two projects. That may change in the future.

Is Webian just a graphical shell?

No. Webian Shell is a graphical shell dedicated to the web and forms part of Webian, but Webian has broader goals.

WIll I be able to run desktop applications using Webian?

No. Running desktop applications is beyond the scope of the project. Webian is aimed at people who spend the vast majority of their time on their computer using the web, and therefore don’t really need a traditional desktop environment.

If you don’t feel you’re ready to part with all of your desktop applications then that’s fine, perhaps in future you could dual boot Webian with your desktop OS, or use Webian on a secondary device (like a netbook or tablet) which is used exclusively for the web.

Jolicloud is another project which lets you run web applications and desktop applications side by side which might interest you.

Will Webian be runnable in windowed mode?

No. The whole point of Webian Shell is to replace your desktop environment and window manager with a full screen interface dedicated to browsing the web, it isn’t intended to be run alongside other desktop applications. If this is what you’re looking for then I’d advise a desktop web browser like Firefox or Chrome.

Is Webian open source?

Yes. Webian Shell is licensed under the GPL and one of the key principles of the Webian project is to support open source and open standards.

A list of FAQs will be maintained here.



In the 0.2 release I’d like to focus on fixing bugs and implementing some obvious features.




The features for 0.3 are open for debate, but I’d really like to start looking into integrating Mozilla’s Open Web Apps.


I’d like to start mapping out a roadmap to a Webian Shell 1.0 release, and then a roadmap for a Webian OS which comes bundled with Webian Shell as the front end.

To me Webian Shell 1.0 should be good enough to be a drop-in replacement for Gnome or KDE on Linux which allows you to use web sites and web apps, but also do basic operating system functions like changing system volume, configuring displays, configuring network devices etc.

I think it’s unlikely that we’ll be able to implement all of these features in a cross-platform way, but it would be nice to keep maintaining an app which can run on Windows and Mac for people to try out if possible.

Webian OS

Later I envisage a stripped-down Webian Linux distribution which boots up quickly and uses Shell as its front end. My current preference is to base this on Debian, but that is up for discussion.


At the moment, the Webian community is fragmented across Twitter, Facebook, Identica, YouTube, GetSatisfaction and Google Groups. I’d like to create a more central place for all of these people to go to communicate, collaborate and contribute to the project.

It’s also currently not very easy for people to contribute content like UI mockups and code contributions. I’m open to suggestions on how to achieve this but these are a couple of things I’d like to try.

Clinked Group

I’ve set up a group on Clinked for the Webian Community so that people can sign up to create wiki pages, hold discussions, manage tasks, schedule events and share files. I’d encourage everyone to sign up!

Disclaimer: I’m the Product Manager for Clinked so I’m a little biased towards it.


I’d like to start accepting code contributions via Github in the form of pull requests and use it instead of Trac and Subversion.

Thank You

Finally, thank you. Thank you to Lloyd Hilaiel and Marcio Galli from the Chromeless project for all their help developing and promoting Webian Shell 0.1. Thank you to Sam Black for helping me sort through all the user feedback.

And thank you to you, our new community, for all your help spreading the word and for sharing all of your ideas. I’m blown away by the response we’ve seen and I’m really excited about the future of the project and what we can achieve together!

Announcing Webian Shell 0.1

Webian Shell is a full screen web browser for devices that don’t need a desktop. As of today you can download a prototype which you can try for yourself.

Update: Webian Shell featured by Mozilla Labs!

A Graphical Shell for the Web

If you’re anything like me then you’ll find that most of the stuff you do on your PC these days happens in a web browser and the desktop environment you used to depend on is now just getting in your way. Modern web applications can do just about everything traditional desktop applications can do (like flashy graphics, sound, video and offline storage) so often all you really need is the browser.

The idea of the Webian Shell project is to replace your computer’s interface with something much simpler, which treats web applications as first class citizens and does away with all the un-necessary clutter.

Rapid Prototyping with Mozilla Chromeless

Shell started as a simple design concept with a few static mockups, but when Mozilla Chromeless came along it was suddenly possible to rapidly develop a working prototype using standard web technologies like HTML, CSS and JavaScript. As a member of the wider Mozilla community this was an opportunity I couldn’t resist so I quickly got to work on putting together a prototype using the technologies I already knew from web development.

This initial early release really just gives you a minimalist, full screen, tabbed web browser with a clock and a rather empty looking home screen. I hope this is enough to convey the basic idea behind the project and that with the open source community’s help we can quickly iterate this prototype to encompass lots of exciting ideas about what living on the web could really be like.

Future Directions

These are some of my ideas for future directions to take the prototype, but I’d love to hear your ideas.

  • Home screens – instead of a desktop, Shell could have multiple home screens like you see on mobile devices, but containing web widgets and icons for “installed” web apps. See Mozilla’s Open Web Apps project for some inspiration.
  • Hardware controls – any graphical shell for a hardware device needs the ability to monitor and control hardware for things like sound, network, GPS, battery etc.
  • Zoomable tiled window manager – zoom out to a view of all currently loaded web pages (like Panorama in Firefox or Expose in OS X), then zoom in to the page you want.
  • Split Screen – view two pages side-by-side
  • On-screen keyboard – for touch-screen devices like tablets.

Download the Prototype

You can find out more on the Webian web site or go straight ahead and download and install Webian Shell 0.1 on your Mac, Windows or Linux computer today. I’d really love to hear your feedback!

You can propose ideas, report bugs and ask questions on GetSatisfaction, or join the Google Group to take part in the conversation.

You can also follow Webian on Twitter or, like it on Facebook and check out the channel on YouTube.

Rise of the Smart TV

Apart from netbooks, tablets and smartphones another key target device for accessing Webian Home Server will be TVs. With big players having recently announced their entries into the smart TV space, this blog post explores their different approaches and the unique challenges of designing for the TV.

Google TV

Many companies have tried to combine web and TV experiences before, but it’s never really caught on. Google believes that their approach will be a success because they aren’t trying to re-create the web for the TV or make you choose between the web or TV, instead they want to give you access to the whole of the existing web and all the channels you already receive, as well as allowing you to install apps from the Android marketplace all from one device.

Google TV

Google TV will allow all of this to be done via a 10ft interface with a remote control including a full QWERTY keyboard and pointing device. The software stack will include the Android operating system, Chrome browser, Flash and a new IP-based protocol to interface with DVR boxes allowing you search TV listings and schedule recordings.

Rather than a releasing a single Google branded device, Google has defined a standard hardware and software platform which will be implemented by multiple device manufacturers. Among the first will be an HDTV and BluRay player from Sony and a set-top box from Logitech which are expected this autumn.

Apple TV

Apple has recently announced the release of the latest generation of Apple TV which takes a very different approach to that of Google. The original version of Apple TV was released in 2006 but didn’t prove to be a huge success. In the keynote announcing the new version, Steve Jobs explained that Apple had learnt a lot from the customers who did buy the original set-top device and that this time they think they’ve cracked it.

Apple TV

Apple’s observations were that consumers want premium HD content delivered to their TV, but they don’t want a “computer” on their TV or to have to manage storage on their TV or sync content with other devices. Their response is a new generation of Apple TV which is a smaller streaming-only device which streams content from other Apple products (iPod, iPhone, iPad or iMac) over the home network or from Apple’s partners over the Internet with a rental model.

The new Apple TV is characteristically proprietary but well designed, with a slick custom UI for a closed list of tightly integrated online services. Apple has chosen a much simpler remote control with just a few buttons and opts for an interaction style much more familiar to TV users.


Another smart TV option comes in the form of the Boxee Box from a small startup in the US. You can already download a beta of the Boxee software to your PC but with “Boxee Box”, D-Link has manufactured a piece of hardware dedicated to using Boxee on your TV which is available to pre-order now.

The Boxee software has an interesting heritage (having been derived from the open source XBMC project) and has a great UI which is well suited to a 10ft interface. The remote control which comes with the D-Link device has a simple ordinary looking remote on one side, but you can flip it over to reveal a full QWERTY keyboard if you need it.

Boxee is pretty rich on features, it will let you stream films, TV shows, music and photos in a large variety of formats over your home network and adds a social dimension by allowing you to share what media you’re viewing with your friends. Boxee will also have a Webkit-based web browser built in and is extensible through the development of apps.


Whilst big and small tech companies in the US launch their entires into the TV space, big media companies in the UK have been collaborating to create a new platform called YouView. YouView is billed as a replacement for the popular free-to-view TV “FreeView” boxes currently popular on this side of the pond.

YouView (previously codenamed Project Canvas) will provide the familiar digital TV channels but will also provide on-demand catch-up content from all of the major UK channels on your TV. YouView will also let you pause & rewind live TV, it will provide pay-TV options and will allow developers to create apps for the platform.

The BBC’s heavy involvement in YouView is controversial with some other media companies who complain that the license fee funded corporation should not be using their resources to develop this platform which they argue damages competition for smaller players. Although the collaboration of so many large media and communications companies makes YouView a compelling choice in the UK, it doesn’t follow existing standards common in Europe and the rest of the world.

Currently YouView is publicly little more than a collection of technical documents available on the web, but the first devices are scheduled to be launched in Q1 2011 and are likely to make a big splash in the UK.

Other Players

The products described above seem to have caught the attention of the media and blogosphere recently, but there are of course many other options out there. Other big players in this space include Microsoft’s older Zune and Mediaroom platforms for the XBox 360 games console and set-top boxes respectively and Samsung’s own app platform for their high end TVs. There are also many open source projects like MythTV which provide a geekier way to create your own smart DVR.


The four different products described here take quite different approaches to the smart TV problem but also have similarities. I very much support Google’s open approach but they could learn a thing or two from Apple’s user experience, I’m really not sure a QWERTY keyboard and pointing device is going to catch on in the living room – the TV is not a PC. Boxee provides a compelling alternative but their app platform may struggle faced with competition from Android and others. YouView will be difficult to ignore in the UK but it provides yet another platform to develop apps for.

One thing all four have in common is the idea that the TV is for streaming content from other sources, not as the media centre for the home. The smart TV solutions presented here allow you to stream media from the Internet or from other devices like PCs, tablets and smartphones on the home network to your TV – but there is no central store for your whole media collection which can be accessed 24/7 by all of these devices.

If there was such a centralised media store then creating an app for every smart TV platform, mobile platform and tablet platform in order to access that media would seem impractical. The common denominator among all of these devices (with the exception of Apple TV which currently offers no opportunities for third party development) is the web, specifically HTML5. A single HTML5 web application hosted in the home could allow access to your entire media collection 24/7 from all of these devices.

Central Home Media Store

The challenge for such web applications will be to create a user interface which works well on such a range of form-factors – from a small multi-touch smartphone through to the 10ft interface of a smart TV with a simple remote control. This will require a new breed of applications which can be controlled in a variety of ways and can adapt to a range of different screen sizes. Some examples of these experimental new types of web applications are YouTube Leanback, Google Reader Play and Clicker but it’s likely to take a long while for best practices to emerge.

With approximately 1 billion PC users, 2 billion mobile users and 4 billion TV users worldwide – web applications with the potential to support all of these devices would seem very compelling indeed!

This is why the Webian project will strive to create a graphical web interface which provides an enjoyable user experience across all of these form factors.

Webian Project Inception

A quick update on some foundations being laid for the Webian project.

The project scope has been set. Broadly this covers managing photos, music and videos but with some potential future directions and specific exclusions as well. Some very high level requirements have been developed for the first release with a focus on photo management.

The focus for the first release will be on making a really good job of photo management using a slick HTML5 interface. That includes uploading photos, organising them into albums, tagging them, subscribing to photo feeds, browsing and searching.

A simple initial architecture design describes an HTML5 interface served from a Django-based Python web application. The next step is to build some technical prototypes to explore some key technologies and UI prototypes to validate the key high level use cases. This will mark the end of the “inception phase” of the project and next will be the “elaboration phase” when the architecture design will be tested with a working architecture prototype.

Talking of phases, the project plan approximates the Agile Unified Process but with a particularly user-centered flavour. The AUP is kind of an Agile version of the heavyweight Rational Unified Process used in enterprise software development. The AUP is described as being “serial in the large, iterative in the small” and aims to take a lightweight, iterative approach to software development, but with the recognition of distinct phases of the project. I’ve chosen to experiment with this methodology to try and get the best out of both user-centered design and agile development. If it doesn’t work, I’ll switch to something else!

If you want to get involved in the Webian project then sign up to the mailing list and introduce yourself!