In The News Mozilla

Wired on Reporter

Wired’s blog Monkey Bites has a small mention on reporter in response to a comment I left the other day. Very cool to get a little publicity for the tool. Those reports really do make a difference. The more reports in the database, the more we know about problems facing users on that wild wild web.

Mozilla Open Source

The Road To Firefox 2

John Carey and Matt Shichtman have started putting some video up as part of their efforts to document the “Mozilla experience”. Definitely something to check out. and keep an eye on. The first is Mike Connor EXPOSED! (odd title, but likely a better choice than “Mike Connor Gone Wild”).

Hopefully at some point they will adopt the Conan O’Brien “Celebrity Secrets” style and format. That’s right, I want the dirt ;-).

Make sure to check out The Road to Firefox 2, and keep an eye on it (RSS feed).

Mozilla Open Source

Filtering out the Channel Noise

Ben wrote a must read post about public discussion that I think any Open Source developer needs to read. If you’re a Mozilla contributor, read it extra close. It really makes only 1 point (make more discussion open). But it doesn’t really address all the problems that prevent that goal from becoming a reality. I mentioned it briefly in a comment, but thought I’d make a post on the topic of channel noise.


Reporter NextGen

Just a little status update for the curious. I’ve been hacking away at reporter quite a bit lately, after a little break. I discussed my plans a few months ago. My tree now has the ability to send an image of the page I’m reporting to my dev instance of the reporter server. This will make it much easier for us to see what users are trying to tell us.

I’ve also worked on a few of the smaller UI quirks in the client and suggestions given, more will be taken care of before 2.0.

I’ve been spending the bulk of the time on the server, with enhancements (flexible query result table, multiple output formats, next/prev navigation for reports among others), and making it a bit more flexible. For quite a while my dev instance was really buggy, at this point it’s looking pretty good. As soon as I finish with screenshot support, and getting the bugs out of all the stuff that’s been touched, my plans are to make it work better with bugzilla (associate reports with bugzilla bugs). That will make it much easier to go through the data and see what’s acknowledged, and what’s new.

The other big thing I want to do is re-order the query page a bit so that it’s more logically setup and easier to understand if you’ve never used the system before. I’ve got some ideas for grouping. When I get a chance, I’ll make some mock-ups and post them for some feedback. I’ve even been considering a little AJAX to help enhance things a bit in that respect.

One step at a time.

Mozilla Security

Reporter, the next generation

Now that I’ve basically stabilized the new reporter tool for the branch, I’ve been planning for what will come in the next version. Quite a few neat little enhancements, some small, some larger.

Client Side

  • Screenshots – you will be able to attach a screenshot when sending a report. The option will be disabled by default (likely a button or a checkbox on send) to prevent submitting screenshots of things you shouldn’t for security reasons, you can send when you want.
  • Remember Email Address – I’ve been debating if this is necessary. It would just remember your email address for you so you don’t have to type it in again and again.

Server Side

  • Adjustable Columns – you can choose what columns to show in the results page, making it much more useful to analyze. [Done]
  • Reporter Proxy – this will give the ability for a company to host it’s own reporter server, capture reports within their intranet, and forward the rest to the mozilla reporter server. Perfect for companies who want to improve the Firefox experience on their intranet. [Work In Progress]
  • Screenshots – see above, this is pretty much the same thing.
  • Mark Invalid – some reports are on occasion totally bogus. We don’t need them in the database. We’ll have an option to report bogus reports, and an admin can confirm and get rid of them. This will keep everything as accurate as possible.
  • Bugs for Host – we’ll have the ability to view related bugzilla bugs on a particular host.
  • Reporter Toys – yea, I’ve been tinkering. I won’t say what this exactly is, but it’s a variety of extra code and stuff that could be fun to play with.
  • Templating – on the technical side, were moving to templates so the html is separate. Much easier to manage from a programming point of view. [Done]
  • Bug Fixes – during the above templating, a bunch of bug fixes and other small changes. [Done]
  • Stats – some statistics are always fun to have. Basic right now, we may expand as time and ideas become available. [Done]
  • CSS Design Love – reporter’s webtool is rather pathetic visually. I’m the first to admit it. I’d love an improved stylesheet. Something that makes reporter look cleaner, and more professional.


Some of the server stuff already landed. Some is in the works (in particular proxy). I’m not promising any particular feature in any timeframe at this point. Some of the above may be bumped to another milestone, or scratched all together. If you have any ideas, or feel like contributing, feel free. I’d love to get some good css, or perhaps some patches for reporter.

That basically serves as the roadmap/status update of where the tool is right now. We’ve got some great feedback, and close to 5000 reports already (and were only at alpha 2 in the release cycle).


Quiz, class, fun

2 classes, a Quiz this afternoon, then some fun 😀

One easy class Thursday, so Wednesday afternoon marks the unoffical end of my week.

I’ve got some stuff on my agenda for tonight, lots of work, and perhaps some neat toy.

Last night, I put up a nice patch for Bug 235577. I think it’s a pretty cool enhancement. Then again, just my personal opinion. Hopefully it will get reviewed in a few days, and all can use it.


The big debate

Time to make a little statement regarding Firebird vs. Seamonkey, and End User vs. Developer.

End User vs. Developer

I’ll start with this first.

Moving from a Developer/Development focus to an End user focus is a much better choice. The only mistake made in the past was not doing this since the early Milestones. Now the question you ask is why?

Every product needs an audience. If it doesn’t have an audience. It’s worthless. Mozilla is a solid application. The result of endless hours of coding on behalf of many excellent programmers. Someone should take advantage of this work they did. End Users are the ones who can benefit. End Users can use this beast that was created.

But what about the Developers you may ask? Who says they have to be ignored? Are they working on a moving target? Right now yes. But will it eventually become more stable? Of course. I have no doubt things will become more stable, and innovation will still continue.

The end user should be the focus. The end user should have always been the true focus. That doesn’t mean you can’t pay attention to the developers. And even help them out (documentation!). But the End user should be the ultimate goal. Help the developers help the end users. Help Mozilla help the end user. The end user should be in every sentence. If it isn’t… then what’s the point?

That’s not to say innovation, and “for the love of standards” is out the window. In fact it’s more relevant than ever. But it’s done with the hopes that the end result will be good enough “for the end user”. That amazing new feature that will revolutionize computing… for the end user.

Developers are important. They are what makes the Mozilla community what it is. But without a target audience (end user). What is this community serving? What is it bring to the Internet at large? A ton of code. What’s a ton of code that’s revolutionary, and able to benefit millions. A ton of good stuff.

End users should be Mozilla Foundations target. The Developers should be targeting End Users as well.

Mozilla Foundation should be helping Developers make this their target through better documentation

Firebird vs. Seamonkey

Firebird vs. Seamonkey is also quite a debate. Personally I’m all for Firebird. But here is my personal vision (not this is personal):

When I refer to “component(s)” I am referring to each product (Firebird, Thunderbird, Sunbird, etc.)


Downloads should be available as separate installers for each app, or one “super installer” (capable of installing all with a “download n’ install” method).


GRE should include auto-update functionality. As Mozilla evolves quickly, end users should have it as easy as possible. Ideally it should check each component and see if it’s been updated. Even extensions.


Just because the conjoined twins are separated doesn’t mean they can’t still be siblings. For example if Firebird sees Sunbird installed, it should be able to integrate itself so that you can have outlook like functionality (calendar and mail integration). If not found, it should look as if there is nothing missing.

The app suite has the advantage of integration. But just because the apps are separate doesn’t mean they can’t work together. They just need the ability to work on their own. Because not everyone is at liberty to change email clients (those whose companies use Outlook Exchange). But they still want to be saved from the hells of Internet Explorer.

I’m for integration with separation. Firebird is great. But it would be nice to see all the new Apps be aware of each other, and work together. To make me. the end user. happy.

So I’m for moving forward. There are two types of programs. Ones under development and dead ones. Mozilla is under development. Changing and evolving. Every Lizard needs to go through puberty before it can become a mature adult. Puberty is an awkward stage. But it will pass.


My own bug

I created a new about:buildconfig page. Something to mimic the about:plugins page. I then took my page and filed a bug. Only things I messed with were XHTML and CSS.

It’s mighty neat filing a bug and the code to resolve it. First time for me. Now I need someone to review, and put in CVS. Not to mention love my work and worship me for my silliness.

Why is this page better?

Consistent design – Matches the plugins page
XHTML Compliant – w3c validator certified. It’s good solid code.
Looks nicer – could even provide more info in the future in a much more organized, professional looking way.

So hopefully someone will review it soon. We shall see…