Webian Blog

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 krellian.com.

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

Requirements:

• 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

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.

GeckoView

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

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 resin.io 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.

qbrt

The “Quantum Browser Runtime” rose 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

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.

Conclusions

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.

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.

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.

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 🙂

Reposted from tola.me.uk.

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.

http://example.com/myapp/manifest.json:

{
  "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.

http://example.com/myapp/index.html:

<!DOCTYPE html>
<html>
  <head>
    <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.

http://example.com/myapp/manifest.json:

{
  "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.

http://example.com/myapp/manifest.json:

{
  "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.

http://example.com/myapp/manifest.json:

{
  "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.

Conclusions

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!

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.

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.

Background

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.

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.

Buzz

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.

Blogosphere

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 golem.de 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.

Following

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.

Feedback

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:

• Bugs (some of which were already known) which should be fixed ASAP such as Shell not working with key web sites like GMail and Twitter and full screen problems in Windows.
• Obvious missing features like keyboard shortcuts, the ability to open a link in a new tab and setting basic preferences. These should be added to the prototype as soon as possible.
• More ambitious features like multi-touch gestures, a process manager, a dedicated OS and bootable live CD and various innovative ideas for window management which need to be part of the longer term roadmap.

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.

Future

0.2

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

Bugs:

• Problems with full screen in Windows
• Doesn’t work with key web sites like GMail and Twitter
• CSS looking wrong on some web sites
• Odd behaviour when you have too many tabs open to fit on one line
• Favicon doesn’t always change when it should
• Switching tabs makes flash objects reset themselves
• The address bar sometimes shows the wrong URL

1.0

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.

Community

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.

Github

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!