The roads I take...

KaiRo's weBlog

April 2014
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Popular tags: Mozilla, SeaMonkey, L10n, Status, Firefox

Used languages: English, German


April 2014

March 2014

February 2014


April 1st, 2014

How Effective is the Mozilla Stability Program?

One of my goals for last quarter was to get some basic metrics for the effectiveness of Mozilla's stability program. This can most easily be determined by measuring how often Firefox Desktop and Firefox for Android crash over time. Below you'll find some graphs and discussion on the data I could gather on that topic so far.

The Crash Rate

The crash rate is our primary stability measure used at Mozilla. We measure this rate in "crashes per 100 active daily installations (ADI)" or "crashes / 100 ADI". (ADI is the number of daily requests sent by Firefox Desktop and Firefox for Android to update their copy of our add-on blocklist. This value is considered a good enough estimation for usage for our purposes.)

Challenges for a Long-Term Rate

In our daily work, we tend to look at crash rates in terms of short-term changes within a single version, esp. development versions, so we can determine regressions and then dig deeper into what those are. For determining long-term program efficiency, it makes sense though to look at cross-version crash rates instead, so we know how our releases (or betas) improved. So it might make sense to look at all users on the release "channel", i.e. anyone using a stable release. On the other hand, we sometimes have leftover users of old and unsupported users producing a lot of crashes, but those are not really relevant to our current effectiveness of the stability program, so I wanted some way to age out old versions from this overall rate. To take all that into account, I needed some way to more or less "concatenate" the stability rate graphs of a series of versions. Also, people updating to or installing a release very soon after it's published tend to have somewhat different usage patterns than those installing it only after some time and therefore crash rates to those updating late in the cycle, so I needed to find some way to smoothen over that as well and ideally make this into an algorithm that can be automatically requested and put into an SQL query (as the data I base this on is in a PostgreSQL database).

Used Methodology

So, I began to think we could always sum up the crash and ADI numbers of the most recent two releases, or the ones that have the most users. But sometimes we release two adjacent versions 6 weeks apart and sometimes we do a fast update after a week and when the second of those is released, the one before might not have a lot of people updated to it yet so taking only those two might only cover a small portion of users and skew the numbers. So in the end, I decided to go with a moving window that always counts all versions where the builds have been created within the last 12 weeks for the Release channel, and the last 4 weeks for the Beta channel (I had 9 and 3 in the beginning but extended that to make numbers smooth over the impact of the 2-week hiatus we had over New Year's this year). The data we have in usable form goes back to the last few days of September 2011, so that's what I could use for the graphs (I'm trying to get some older data but that is harder to dig out).

Graphs & Discussion

So, here are some screen copies of the graphs I have created out of the data collected with that algorithm (includes data up to March 5, which was current when I originally wrote up this post):

Image No. 23207

The first graph, with data from the Firefox desktop release channel, shows three lines, as the legend says the include crashes of the browser process, those of a plugin process (the vast majority of the plugin processes are Adobe Flash), and so-called "hangs" where we kill the plugin process after it doesn't react to contact from the browser process for a long time (by default, 45 seconds).
For one thing, you'll see that weekends have higher crash rates than weekdays. This could for example be because the ADI data isn't as reliable/accurate as one would hope or because people using Firefox on weekends do things that are more crash-prone (including work/home usage pattern and possibly machine differences).
In this graph we can also clearly see the results of known stability events in this time frame: For example, it nicely shows the Google Doodle crash of August 2012, where almost every startup of the browser crashed when Google was set as the home page, and where we scrambled to get a fix out in very short time (and Google helped us by putting a workaround in their doodles as well). It's also easy to see a few other sharp spikes where we had ADI (upwards) or crash submission (downwards) issues, as well as the crash-and-hang-rich Flash 11.3 release in June of 2012 and subsequent fixes for Flash, including the concerted efforts between Adobe and us to get down to the old levels with fixes on both sides in May/June 2013. For the most time on the graph, you'll see that the browser crash rate didn't change very much (other than the sharp spikes mentioned). In January of 2013, though, it's possible to see the rise in crashes that caused us to ship Firefox 18.0.2 with a fix for that. Right following that, at the end of February, you'll see the sharp rise in crashes when we released Firefox 19.0, triggered by a bug in certain AMD CPUs, which we worked around by rebuilding and releasing a 19.0.1. Those examples, like anything showing up in that graph significantly and not being a data error has pretty intricate story, any of those could make up a separate blog post.
That said, the fact that we could keep the crash rate pretty much at 1.0 browser crashes / 100 ADI over that whole time (and even slightly improve to just below that with the Firefox 26 release in December 2013) is a statement on how effective the Mozilla Stability Program is on keeping Firefox crashes down even though a whole lot of code has been added to support a ton of new features that the web has gained over that time.

Now, let's see how Firefox Beta looks in comparison:

Image No. 23208

At the end of 2012, we apparently did manage to improve base level stability of the Beta channel, but you'll see that this channel is more noisy - which is expected as here we still see regressions and work on fixes before the issues hit release. For example, you can see that Firefox 27 Beta regressed stability in December 2013. We fixed that only very late in the cycle so that you don't see 27 being worse on the Release channel, but 28 had other regressions in the beginning and a rather large one in 28 Beta 4 (mid February 2014) - once we fixed that, you see that we come down to the 1.0 line in the last one or two weeks, so that looks pretty good for the 28 release, which was to be released ~2 weeks after the end of that data.
Also, you'll see that the plugin improvements of early 2013 are about 6 weeks earlier in Beta than in Release, which shows pretty well that there were actual patches in our code that helped with Flash hangs and crashes (as our code is on a 6-week cadence while Adobe's releases hit both channels pretty much at the same time).

Now, let's see how the picture looks when we look at a product that was newly created while we already had the mechanisms in place to record this data, like the current "native UI" Firefox for Android:

Image No. 23211

The early releases had higher crash rates, but we significantly improved over time due to our efforts in the Stability Program. You also can make out that the sharper changes happen pretty exactly at the edges of the 6-week release cycles. Also, you'll see that Firefox 23 for Android in September 2013 was pretty good but we became worse in the following months. Because of that, we started a renewed effort to improve stability of Firefox for Android this January. The current Firefox 27 for Android release is somewhat better than the one before, but it's not where we want to be yet, obviously. We didn't have too much time to pound on issues from the start of the year until 27 was release, but Beta can show us if our newer efforts are pointing in the right direction:

Image No. 23212

Now this graph looks pretty nice, doesn't it? When we started off putting this product on Beta the first time, we were seeing the usual churn of exposing a new product to a wider audience for the first time, but we burned down the issues pretty well. Then we had a big regression, fixed it, and burned down bugs slowly over multiple months again. The regressions of late 2013 look even more dramatic here as we had even worse issues there but could actually fix the worst parts of those so that the regressions on the Release channel weren't as bad as the first Betas we had there. Many of the 6-week cycles in this graph look like burn-down charts, high in the beginning, going down over the cycle as we push for bugs being fixed. It's also pretty awesome to see how the efforts since the start of this year have really paid off and current Beta is rivaling the best Beta numbers we had so far - you can imagine how I was looking forward to Firefox 28 for Android hitting Release based on that data! :)

All that said, we know there's more we can do on both products, and while holding crash rates pretty stable over a long time while adding a ton of features is awesome, we strive for improving overall stability. Those graphs are one part of measuring the effectiveness of the stability program. I hope we will be able to put them up in a more dynamic and daily updating form at some point (right now I manually construct them in LibreOffice).

And in case you're interested in digging deeper into the source of the graphs, the code to pull the data from the crash-stats DB is in my crash-report-tools repo and the JSON coming out of that and powering my charts is in my directory on crash-analysis (F*-bytype.json files). Also feel free to contact me for more details.

By KaiRo, at 19:58 | Tags: CrashKill, Mozilla, stability | 1 comment | TrackBack: 0

March 29th, 2014

Lantea Maps conversion to WebGL

I blogged about Lantea Maps 18 months ago. As its marketplace listing describes, the app's purpose is displaying maps as well as recording and displaying GPS tracks.

I wrote this app both to scratch an itch (I wanted an OpenStreetMap-based app to record GPS tracks) and to learn a bit more of JavaScript and web app development. As maps are a 2D problem and the track display requires drawing various lines and possibly other location indicators, I wrote this app based on 2D canvas. I started off with some base code on drawing bitmap tile maps to canvas, and wrote the app around that, doing quite some rewriting on the little bit of code I started from. I also ended up splitting map and track into separate canvases so I wouldn't need to redraw everything when deleting the track or when moving the indicator of the last location or similar. Over time, I did a lot of improvements in various areas of the app, from the tile cache in IndexedDB via OpenStreetMap upload of tracks to pinch zooming on touch screens.

Still, performance of the map canvas was not good - on phones (esp. the small 320x480 screens like the ZTE Open), where you only have a handful of 256x256 map tiles to draw, panning was slightly chunky, but on larger screens, like my Android tablet or even my pretty fast desktop, it ranged from bad to awful (like, noticeably waiting from any movement until you saw any drawing of a move map). Also, as it takes until images are loaded (cached from IndexedDB or out from the web) and that's all called asynchronously, the positions the images ended up being drawn often weren't completely correct any more at the time of drawing them. I tried some optimizations with actually grepping the pixels from the canvas, setting them in the new positions and only actually redrawing the images on the borders, but that only helped slightly on small screens while making large ones even worse in performance.

Given what I read and heard about how today's graphics chips and pipelines work, I figured that the problem was with the drawImage() calls to draw the tiles to the canvas as well as the getImageData()/putImageData() calls to move the pixels in the optimizations. All those copy image data between JS and graphics memory, which is slow, and doing it a lot doesn't really fit well with how graphics stacks work nowadays. The only way I heard that should improve that a lot would be to switch from 2D canvas to WebGL (or go to the image-based tile maps that many others are using, but that wouldn't be as much fun). I don't remember all sources for that, but just did get another pointer to a Mozilla Hacks post that explains some of it. And as Google also seems to being moving their Maps site to WebGL (from image-based tiles, mind you), it can't be a really wrong move. :)

So, I set out to try and learn the pieces of WebGL I needed for this app. You'd guess that Mozilla, who invented that API together with Khronos, would have ample docs on it, but the WebGL MDN page does only have one tutorial for an animated 3D cube and a list of external links. I meanwhile have filed a bug on a WebGL reference so may improve this further in the future, but I started off first trying with the tutorial that MDN has. I didn't get a lot to work there except some basics, and a lot of the commands in there were not very well explained, but the html5rocks tutorial helped me to get things into a better shape, and some amount of trying around and the MSDN WebGL reference helped to understand more and get things actually right.
One thing that was pretty useful there as well was separating the determination of what tiles should be visible and loading them into textures from the actual drawing of the textures to the canvas. By doing the drawing itself on requestAnimationFrame and this being the only thing done when we pan as long as I have all tiles loaded into textures, I save work and should improve performance.

Image No. 23214 Image No. 23213
2D Canvas (left) and WebGL (right) version of Lantea Maps on the ZTE Open

As you can see from the images, the 2D canvas and WebGL versions of Lantea Maps do not look different - but then, that was not intended, as the map is the map after all. Right now, you can actually test both versions, though: I have not moved the WebGL to production yet, so still uses 2D canvas, while the staging version already is WebGL. You'll notice that panning the map is way more fluid in the new version and the tile distortions that could happen with delayed loading in the old one do not happen. I still wonder though why it sometimes happens that you have to wait very long for tiles to load, esp. after zooming. I still need to figure that out at some point, but things render after waiting, so I found it OK for now. Also, I found the WebGL app to work fine on Firefox desktop (Linux), Firefox for Android, as well as Firefox OS (1.1, 1.2, and 1.5/Nightly).

So, I'm happy I did manage the conversion and learn some WebGL, though there's still a lot to be done. And as always, the code to Lantea Maps is available in my public git as well as GitHub if you want to learn or help. ;-)

By KaiRo, at 01:02 | Tags: B2G, Firefox OS, Lantea, Mozilla, OSM, Web Apps, WebGL | 1 comment | TrackBack: 0

February 27th, 2014

Preserving Software: Emulators

It's been a while since I wrote a post here, and even longer since I wrote about preserving software. But there's two more topics I have on my list to write about the event I attended last May. This is one of them.

One problem for preserving software is that the original hardware that the software did run on might not survive very long. Some people are still keeping some old machines like C64, Apple ][ and others running, but at some point there won't be many left as the original ones wear out or get damaged, and other hardware might not be usable at any more already at this point. And for sure, those machines are not available broadly to the public. Ideally, we'd have the hardware and recreate the full experience, e.g. how you connected the machine to your own TV in the living room and played or worked with it there - but that is pretty unlikely or at least hard to do, esp. with the hardware being less and less available, as I mentioned.

But there's one way to bring at least part of the experience to users: We can emulate the old machines and let the preserved software run within that emulator. That doesn't give us the living-room-TV experience, but there's a better chance in both preserving that way of running the old pieces of software for a long time and making the experience broadly available. Now, it's not always easy to get emulators running well, but there are a number of projects out there, and we heard about a few interesting solutions in the preserving software event at the LoC, but one was particularly appealing to us as Mozillians.

I blogged about The Internet Archive ( and Jason Scott already some time ago, and he was it that mentioned this very appealing kind of emulator called JSMESS. What hides behind that name is the multi-platform MESS emulator, cross-compiled into JavaScript via EmScripten, a project that should be well-known here at Mozilla. :)

Since the event in May, a lot of work has been flowing into JSMESS, and as Jason has blogged about, there are a thousand cartriges available now in the Historical Software Collection of The Internet Archive, and performance is pretty decent within the browser now.

With that, a whole lot of old software is available for everyone, at any time, to try and experience within their own browser!

That's a powerful way to preserve software for the current world and upcoming generations, isn't it?

By KaiRo, at 02:40 | Tags: history, Mozilla, preservation, software | no comments | TrackBack: 0

December 19th, 2013

LCARStrek and Australis

The latest version of my LCARStrek theme does not just support the latest SeaMonkey and Firefox releases. As I'm using it myself on Nightly, I'm trying to keep it working in an experimental way with that as well - and with that, a pretty huge challenge came up in the last weeks: A redesign of the Firefox interface code-named "Australis".

I blogged a month ago about how it may affect my customizations and I have dealt with those to a good degree by now, even though not yet even as drastically as I thought when writing that blog post. As always, more will follow. It took me some time until I switched over actually, as I wanted to keep using my theme, but it was naturally not compatible with such a huge redesign.

But after a lot of hours of my free time in the last few weeks, I have experimental support for Australis working in LCARStrek. The new changes living together with support for pre-Australis Firefox in the same theme require quite a few hacks to have a number of styles only apply on one side or the other. But then, I have been doing theme design for long enough (about 14 years now) that I know a few tricks and could use those - thankfully, there are a few changes in attributes set on the main toolbox, for example.

There's still a lot to be done in this area to fix some details (and I see a painting issue that is triggered in the submenus of the new main menu but is probably Linux-specific and connected to transparency used in the arrowpanel), but the main things seems to work decently now. See this screenshot:
Image No. 23159

Given that I'm using it every day, I hope starting now gives me enough experience with it that I can deliver a really decent theme when Australis finally will ship, probably with Firefox 29. :)

By KaiRo, at 23:43 | Tags: Firefox, LCARStrek, Mozilla, themes | 1 comment | TrackBack: 0

December 6th, 2013

Firefox OS DevTreff Vienna

Last month, I was contacted within a few days by a local "open mobile devices" enthusiast, a Mozilla events manager and a fellow German-speaking Mozilla Rep, all of them pointing to an event here in Vienna called Firefox OS DevTreff Austria.

While the local just asked me if I'd go there, the Mozilla contacts had been asked by the organizers for a speaker to open up the event. We were trying to get someone more used to talking about Firefox OS, but everyone's busy this time of year, so in the end we settled with me doing this keynote.

Now, I have been giving presentations on different occasions and events in the last years, but I never have actually keynoted anything, so that made me somewhat nervous. The other talks that were lined up for the evening were about app development, to some part about very concrete pieces of it, so I figured I should give that some frame and introduce people to Firefox OS, starting with why we are doing it, moving to what and where it is and giving a bit of glance onto where we want to take it. So I came up with "Firefox OS: Reasons, Status & Plans" as the title (my slides are behind the link).

Image No. 23157 Image No. 23158

The audience was supposed to be about 50 people, I guess 30-35 really showed up (the pictures, taken "in style" with Firefox OS on my Peak, only show one part of the room), but those were an awesome bunch. They were really into the topic, asked interesting questions, and the talks following me were showing that we really had capable developers in the room, from those that do JS in their free time to those who earn their bread and butter by doing apps.
We also had two Mozillians, both of which I had not met in person before, even though I spent a lot of time in this city in the last decade!

As the event was going on, I was often the voice in the room who would have answers from the Mozilla side or could explain our point of view and initiatives - and in quite a few cases, I could loop back to something I said in my keynote. It was really great to see how apparently I had touched exactly on the right things there and gave everything else a good base to build on. Interestingly, there was quite a bit of interest in the DeviceStorage API, probably because accessing local files is something people can refer better to than storing items in-app. I was thankful someone did a talk on our Marketplace and in-app payment API/Services as that's one area I'm actually weak in, but it also sparked quite a bit of interest. The permission model did also get a few questions.

We surely had people with Firefox OS app experience in there, but I think more of those people might pick up web app development, esp. if more similar events come around, which would be cool. And maybe someone should tell them how to do simple apps without larger libraries or frameworks, and explain app manifests in more detail. I hope they will organize more of those and the chance for that will come along!

By KaiRo, at 05:16 | Tags: apps, B2G, Firefox OS, mobile, Mozilla, presentation, Vienna | no comments | TrackBack: 0

November 18th, 2013

Bye, Bye, My Customizations - Hello New Ones?

Australis is landing on Nightly and therefore in my builds, and so it's time to review my customizations.
The illustrations below are from my pre-Australis state (though with my custom LCARStrek theme removed to make it easier to see what the customizations are). I still need to figure out the post-Australis state fully.

Image No. 23154

For one thing, I like having everything bookmark-like bundled in the bookmarks toolbar. That starts with the home button (that goes to my custom start page), the bookmarks menubutton, and then quick-access bookmark items like a menu with Bugzilla query live feeds and frequently visited sites. All those items, including the home and bookmarks buttons, have the same layout of an icon with text next to it and the same small height. I'm using the home button quite frequently to get to that site, same for the bookmark items, and I'm using the bookmarks list in the menubutton for retrieving sites I rarely visit (so they're often falling off the awesomebar) but want to go to every now and then (say, those sites where I buy karaoke songs every few months - I might not remember the exact name but I know where to find them in my bookmarks hierarchy). Australis removes the text from the buttons and actually makes them larger in height (which would make the whole toolbar higher), so I cannot place them in that place any more without breaking design. I might remove the home button completely and replace it with just a bookmark item pointing to the page, which should do the same job nicely (though the home button might not actually increase height, I need to test that a bit more). For the bookmarks button, I'm not sure. I don't feel like I want it at the right of any bar where it's far away from the bookmarks, and I don't want to size of the bookmarks bar to grow. Maybe I'll also hide it away completely, possibly place it in the "Hamburger" menu, as I don't use the starring feature too much anyhow, and move my whole bookmarks hierarchy to a folder on the bookmarks bar. That might seem strange in the logic of bookmark hierarchies, but it should do the job.

Image No. 23155

The throbber button at the right of my tab bar and the "Nightly" button on its left need to go as well, so I'll get rid of the former (even though it's an old friend from days gone by - but it's not even available for customization any more), and the latter is being morphed into the "Hamburger" button the right of the navigation bar, it's default location. While we're at the right of the navigation bar, I might think about removing the search field, actually. I find it annoying that it reminds me for hours of the last search I did because its content never goes away, and I do my Google searches from the location bar anyhow - and other searches by first going to the respective site and search from there. Maybe the old "Search Tabs" idea comes along one time and gives me nicer ways to use alternate search engines.

Image No. 23156

And then, there's add-ons. I have/had the Sync, Lightbeam and Diaspora EasyShare buttons as well as the MemChaser display in my add-ons bar. The Sync button is only showing if Sync is in progress and able to trigger one intentionally, I probably will remove that as I can easily live without it. Diaspora Easyshare might move to the bookmarks or even navigation bar, I'm not using it a lot but it actually looks very handy and I do use Diaspora quite a bit as my only social network. MemChaser will need to go away, unfortunately. It's nice to look at those numbers every now and then, esp. when problems might occur, but there's just no place in Australis where I can place a large and constantly updating thing like that without constant distraction. The bottom border of the screen/window was perfect for that. But OK, I'll probably end up removing or at least disabling the add-on completely. Lightbeam will either go away or move to the "Hamburger" menu - given how rarely I use it, it has no place at the top of my window in primary UI. While I'm at it, it might make sense to go through my add-ons list and do some cleanup there in general.
And once I get a feeling if I can do my work with the new "Hamburger" menu or not, I will see if I'll need to turn on the menu bar again or leave it hidden, like I've had it for a while now - but first I want to see how well the new stuff works for me so I can really evaluate it.
Unfortunately we don't have the capability in desktop FHR to track add-on behavior changes or uninstalls that might come with Australis (mobile has a new format that can track that), otherwise it would be interesting to see if it's just me or if others are disabling or uninstalling add-ons as well with that change.

What changes does this mean for you? Are you able to cope (like me), excited about them, or distracted by them?

By KaiRo, at 20:19 | 9 comments | TrackBack: 0

November 7th, 2013

Internet Archive Fire: Donate to Rebuild

I just got word that a fire destroyed the Internet Archive Scanning Center in San Francisco.

I have blogged about what the archive has and can do a few months ago and I probably will mention it again when I get to more posts on preserving software.

I think it's in the best interest of everyone, esp. us as Mozillians, to keep this organization going and make the history of the Internet and more openly available to current and future generations.

Please help them to rebuild and continue on their way and make a Donation. I will for sure.

By KaiRo, at 19:04 | Tags: history, Mozilla, preservation, software | no comments | TrackBack: 0

November 1st, 2013

Badges for Stability Contributions?

Various groups at Mozilla have been thinking about awarding Open Badges for contributors in the recent year or so (there's even a contributor badges site for easily awarding them). I again and again wonder if we could do that for stability contributions as well, but it's a tough nut to crack.

One idea would be to award badges automatically to people who leave their email in a crash report (i.e. a badge for taking part in our efforts by delivering data through crash reports) - but that would probably end up being a bad badge because you' award people for crashing Firefox (and not award people who don't see crashes). We really do not want people to search for how they can crash so that they can get a badge - after all our mission is to avoid crashes, not provoke them. So, no badges for submitting crashes (thanks to Benjamin for pointing me to that issue right away when I was rolling that idea).

So, how can we potentially award a badge for Stability/"CrashKill" work without rewarding bad behavior?

One thing I could think of was "filed x crash bugs that ended up fixed". That should be relatively easy to get out of Bugzilla data and I think there's no doubt that filing bugs that end up with a fixed resolution is a good thing.
This idea would also open up the avenue for different badges for different amounts of badges (similar to the webdev badges), or to create a badge for developers who fixed x crash bugs, and similar things.

What do you think? Which ideas do you have for awarding badges for contributions to the Mozilla Stability program?

By KaiRo, at 18:14 | Tags: CrashKill, Mozilla | 1 comment | TrackBack: 0

October 28th, 2013

Nichtkommerzieller "Location-Service" von Mozilla: Hilfe erwünscht!

Mozilla hat soeben auch öffentlich verkündet, dass wir an einem nichtkommerziellen "Location-Service" arbeiten, also einem Dienst, der aus WLAN- und Telefon-Sendezellen-Daten die eigene Position ermitteln kann (wenn man so will).
Derzeit gibt es nur kommerzielle Anbieter für so etwas, allen voran Google Location Service, aber eine offene Variante öffnet die Tür für Implementierungen, die mehr Wert auf Datenschutz und Privatsphäre legen und trotzdem den gleichen Komfort bieten (z.B. könnte man einen Ausschnitt der Daten für eine Umgebung lokal herunterladen und dann ohne Übermittlung der genauen Daten eine Ortsbestimmung lokal durchführen).

Für so einen Service braucht man jedenfalls die an sich öffentlich einsehbaren Daten über die "sichtbaren" WLAN-Netze und Telefonmasten an verschiedenen Orten. Diese Infos wollen wir über Crowdsourcing gewinnen, und eine "Stumbler"-Anwendung für Android ist verfügbar, die diese Arbeit verrichtet (natürlich sind die Quellen für den Stumbler und den Server genauso offen wie eine API zum Service, wir sind schließlich Mozilla).

Hilfe ist natürlich erwünscht, vom Senden der Daten mittels Stumbler bis zur Verbesserung dessen und auch der Server-Seite!

By KaiRo, at 17:53 | Tags: geolocation, Mozilla | 2 comments | TrackBack: 0

September 8th, 2013

Wanted Apps: Simple IRC

At Mozilla, as well as a lot of other Free / Open Source Software projects, IRC (Internet Relay Chat) is the backbone of real-time communication within the project.

The beauty of this chat service is that it's a really simple and lightweight protocol and there's a ton of different clients to access it, including for example ChatZilla, which is written completely in JavaScript, and multiple web-based clients. The latter would make nice Firefox OS apps, one might think, but their major downsides are that they are all running on the server-side and not really on the device you installed the app in - and their UI doesn't really fit the phone form factor.

Now, what I'd really like to see, though, is an app that runs locally on the Firefox OS device in its entirety, and which has a UI that is useful and nice on a phone. Especially the latter might mean not implementing all the fancy functionality that many IRC clients have, but only those parts required for some simple chatting.

We have the technology to run a full IRC client on a Firefox OS phone with the TCPSocket API, and the simplicity of the IRC protocol would make it a nice reason for someone who wants to play with this API.

The UI, OTOH, would make a very interesting challenge for someone who like UX design, as on a phone, you need to be way more minimalistic, and you probably need to consciously decide what functionality and which elements to leave out, or implement completely differently than what we might be used to.

I'd really love to be able to have an easy way to tell my manager via IRC that I'll be late for a 1:1 while I'm on my way, or be able to make a quick inquiry in a chat channel while I'm traveling.

Anyone up for the challenge?

By KaiRo, at 02:57 | Tags: apps, B2G, Firefox OS, Mozilla | 9 comments | TrackBack: 0

Feeds: RSS/Atom