I’ve also made the slides available online for those who just want to read (press ‘s’ on your keyboard to see my speaker notes, you may have to allow pop-ups).

Mobile Monday Detroit is a monthly meetup that gets people together to talk about activity in the mobile space. Many topics cover Android and iOS, so it was really cool to snag a spot on the podium and give a talk about one of the ‘alternative’ operating systems. Also presenting this week was Randy Nunez from Ford who gave a talk about the various open source mobile operating systems and Chris Peplin from Ford who talked about the Open XC API for cars that Ford is working on.

If you live in southeast Michigan you should try to make it out to one of the meetings. More information can be found at the Mobile Monday Detroit Meetup page.

Well, we were “jamun”. This past week we shut off the Jamun project branch of Australis and moved our focus to the UX branch.

What does all this mean?

In a nutshell, this means that the Australis customization rewrite has progressed enough to the point that we feel it is ready to start getting much broader testing. We’re in the final stretch of the project, and we want our changes to reach testers at a faster pace.

Here’s where we stand today:
* Most customization workflows are possible. Not all UI migrations are complete.
* Most polish on the edges isn’t there. It does however look pretty close on Windows and Mac now.
* Some final graphics are missing, but they’re not far away.

Wait, wait, what are we talking about here?

Ah, okay, I’ll take a step back. A while back, in fact, a looooong time ago… there was a presentation from the Firefox UX team about a new browser UI refresh and rewrite of our customization workflows. It turns out that many users don’t know that Firefox is customizable. Some users accidentally customize their browser and don’t know what went wrong. Then, there’s this super-tiny super-expert user group that has figured out how to customize Firefox and they *adore* it.

So, what are we doing about it?

Well, the first thing that we’re doing is making entering and exiting customization of Firefox much easier. No longer will a user have to right-click on a special portion of a toolbar and choose “Customize…”. This was way too hard to find for the vast majority of users. We’ve left that same entry point there, but we’ve also created a very visible “Customize” button.

Sounds good, where is this Customize button though?

Great question! Another goal of Australis is to unify the user experience between Windows, OS X, and Linux. On Windows and Linux, Firefox has an “Application Menu” in the top-left corner of the browser. We’ve moved this menu to the right-side of the navigation toolbar and it will now be visible on all three platforms. We’ve also been hard at work trying to make this menu easy to use and navigate. The Customize button is located at the bottom of this menu.

Another really cool thing about this menu is that it will be customizable. When you enter Customization mode, you’ll be able to add, remove, and rearrange items in the menu as well as items on the toolbars.

Here’s a screenshot of what the Customization mode looks like today on Windows:

As I mentioned earlier, all of this is still very much a “work-in-progress”, so it’s expected that people will find bugs and rough edges. If you’d like to play with it today, you can download the UX Nightly builds and give it a run. The UX Nightly builds will update daily with new changes to the customization.

Please let us know about any bugs that you find by filing a bug in Bugzilla in the Firefox::Theme or Firefox::Toolbars component (and mark the bug as blocking bug 770135). If you don’t feel comfortable doing the above, then just leave a comment on this blog post and I or someone else will file the bug for you.

It has been estimated that in the next 10 years, five billion people will gain access to the internet. Many of these people will be accessing the internet using mobile connection exclusively.

One of the main goals of Firefox OS is to provide a device to people that brings with it the full web as compared to the limited subset of the web that is currently accessible on more basic feature phones. This also means providing web applications better access to hardware, so application developers can provide rich environments comparable to that of other mobile phone operating systems.

As we build these hardware APIs, we have been working very hard to standardize them and push for other browsers to adopt them. You can follow along with the progress of the WebAPI project by visiting our wiki. All of the FirefoxOS roadmaps, feature lists, etc can all be viewed online. This project really defines openness

Mobile Monday Detroit is hosted at Compuware’s headquarters in downtown Detroit, at One Campus Martius. The event will start at 5:30pm and run until 8pm. Food and drinks will be provided. Please RSVP (it’s free!) if you plan on attending so the organizers will have a good idea of how much food to order.

Randy Nunez from Ford will also provide information on a variety of additional open source mobile OS platforms that are catching the attention of the developer community.

Monday, May 13, 2013
5:30 PM to 8:00 PM
Compuware Building
One Campus Martius, Detroit, MI (map)

Check out the video below for the interview (1m 38s):

I also got a chance to interview the other two students working on the project, Bill de Araujo and Brandon Waterloo. I posted Bill’s interview a couple days ago and Brandon’s interview yesterday.

Check out the video below for the interview (3m 13s):

I also got a chance to interview the other two students working on the project, Bill de Araujo and Ray Heldt. I posted Bill’s interview previously and will be posting Ray’s interview shortly.

Check out the video below for the interview (1m 31s):

I also got a chance to interview the other two students working on the project, Brandon Waterloo and Ray Heldt. I’ll be posting their interviews in the coming days.

The goal of the triage is to look at old bugs (6 years and older) and either:

1. Resolve as fixed (fixed through some other means), wontfix, or invalid
2. Move to a different component, or
3. Leave as-is

Our first three triages focused on the following components:

• Firefox::Tabbed Browser
• Firefox::General
• Firefox::{Menus, Microsummaries, Migration, Page Info Window}

In the first three triage meetings we closed 257 bugs! We have only been focusing on bugs marked as “NEW”, meaning that they have been confirmed but work has not begun to fix them. The Firefox product in Bugzilla currently has 8,579 “new” open bugs, so these three triages have trimmed close to 3% off of our previous total.

How do we run the triages?

Before the triages, I run some Bugzilla queries to gather a list of about 175 bugs within Firefox components. I chose that number of bugs so each person can get about 25 bugs apiece (we tend to have about 7 people triaging).

The bug list is then split in to ranges of about 25 bugs in size and people assign themselves to one of the ranges using our etherpad. I then send out a meeting invite with a link to the etherpad and ask that people triage their assigned bug range individually before our meeting.

About a week later we have our triage meeting, where we discuss bugs that we were unsure of.

Bugs that need retesting are marked as-so on the etherpad. We hope to have a Firefox front-end testday sometime soon to go over the bug list that we have curated.

Where do we go from here?

A lot of these dead bugs were easy to close, but as we’ve cleaned them up the newer bugs (2008 and onward) are getting harder to close. They are more relevant and still exist as valid issues with the product. We are able to associate some of them with newer features that will fix them indirectly, and others we are able to turn in to “good first bugs” or fix outright (see my recent post for one example).

We are continuing to have more bug triages (we had another one today, which has so-far closed 24 bugs). After we have hit all of the Firefox components we should have less dead bugs in the system, and it will be easy to have triages that occur less often but cover the whole Firefox product.

We can also start triaging some of the more recent bugs and being more proactive about closing out bugs that don’t align with our goals.

We also need to schedule that testday that I mentioned above. I (or someone else) will have to coordinate with the QA team to schedule a day where people can help us test and close out some of these bugs.

What have I learned so far?

I’ve had a few takeaways from this process:

1. We should be more open to closing bugs when we know that there is not a realistic chance of the bug getting fixed. This line of communication is important to provide to the people that file bugs, and it also provides a permanent background as to our stance at the time. This is much more helpful when revisiting a bug than finding years of silence and inactivity.
2. Lots of feature requests carry great inspirations for add-ons. As we strive to keep Firefox lean and agile, we need to make sure that features that find their way in to Firefox are useful to over 95% of our users. Implementing an add-on allows greater potential and a deeper feature set than we would be able to pursue if the feature was standard to Firefox. One great example would be to compare Firefox’ click-to-play implementation with that of FlashBlock.
3. Splitting tasks like this up ahead of time allows our meeting to be very focused and fast-moving. I’ve participated in triages before where everybody at the meeting went through a list of bugs and discussed each one individually. While that allows for deep discussion on each bug, it’s not a very effective use of our time. Many bugs are easy to close, and ones that may require a deeper dive can be tabled until our meeting.

FirefoxOS is Mozilla’s new mobile operating system, based entirely on web technology. FirefoxOS will bring full device capabilities to the web stack, allowing web developers to create immersive experiences in a cross-platform and device agnostic manner.

This talk will briefly cover the motivations of FirefoxOS and then dive in to the new technology and APIs that are being opened up to developers who are looking to create apps for FirefoxOS.

MobiDevDay Detroit was the first conference of its kind. Now in its third year, MobiDevDay is dedicated to bringing the world of Mobile to Michigan’s Software Developer Community. We hope to grow MobiDevDay Detroit into the most important polyglot Mobile Developer conference in the world.

MobiDevDay Detroit 2013 will be held at the Cobo Conference Center on May 4th.

Breakfast, Lunch and Free Parking will be provided.

Register today for the conference before it sells out. I’ll share more details about my talk as the date gets closer.

In Firefox Aurora, web developers can adjust the speed that HTML5 videos are playing at using the mediaElement.playbackRate API. This API lets websites control the speed that videos play at, whether they are in slow-motion, normal, or high-speed.

Starting today in Firefox Nightly, you can adjust the speed that videos play without needing to know JavaScript. To try this out, right-click on a video and enter the Play Speed menu:

The menu, implemented by darkowlzz, allows the user to change the playback to one of four speeds:

• Slow Motion (0.5×)
• Normal Speed
• High Speed (1.5×)
• and … Ludicrous Speed (2×)

I should note that there is still one remaining bug with the feature. Videos that are switched to the non-default playback speed will not switch back to Normal Speed using the context menu. This bug is on file and will need to be fixed before we can ship this feature on our Release channel. A simple workaround is to seek the video, as that will reset the playback speed.

For example, this file is very hard to read when the lines aren’t wrapped. The lines scroll offscreen horizontally, and the user has to use the horizontal scrollbar on the bottom of the screen to read the file (yuck!). Here’s a screenshot of what I’m talking about:

Long lines are not wrapped

With word wrapping applied, the text is much easier to read and the line length will adapt to the size of the browser window:

With long lines wrapped

Some documents aren’t ideal for word wrapping, and to aid that we have made it easy to disable the feature. To toggle whether the document is wrapped on a case-by-case basis, you can change between the “Wrap Long Lines” stylesheet and “No Style”.

If you’d like to disable the feature entirely, you can go to about:config and set the plain_text.wrap_long_lines preference to false.