Best of luck to Scott, David, and the entire Thunderbird community as they move forward with their project. With greater autonomy comes more responsibility but also an exponential growth in possibilities. The future is bright!
Needless to say, given the state of the Mozilla Foundation/Corporation today, I think this is probably the best move for the Thunderbird community.
Editorial Note: I don't typically post to this blog anymore since I'm not actively contributing to Firefox these days. However I've received suggestions that I link to this post from here since it's Mozilla-related, so that folk who subscribe to planet will receive the link to the April post on my personal blog.
"One of the great things about open development discussion is that you can usually expect some crank to come along weeks after a heated debate and throw gas on the fire.
Tonight I am that crank. In the thread "Mozilla 2 repository migration dirlist" in the mozilla.dev.platform group there is a lot of discussion about the allocation of resources to various projects within Mozilla by the Mozilla Corporation. This brings to a head an issue that I've seen growing for the past couple of years since the Mozilla Corporation was formed."
It's getting too hard to manage spam (Movable Type's comment viewer is just awful) and since I don't post much over here anymore, I am turning off comments.
Email and comments on my Personal Blog still work.
I've read a number of reviews comparing Firefox 2 and IE7's RSS capabilities. Every time Firefox comes up short. There's a reason for this though, and it relates to the Firefox philosophy of having enough features, not too many or too few.
Mike Connor blogs that "The trademark and copyrighted icon were not created by the community. Firefox and its icon was created by the Mozilla Foundation in private, as a brand used for “official” releases as a sign of quality."
I think I understand what Mike is trying to say here, but this sentence is far too easily misinterpreted. I believe he is saying that the Mozilla Foundation can be credited with taking steps towards protecting the Firefox mark, by filing a trademark, and owning the copyright on the graphic image icon.
It is however not correct to say that the Mozilla Foundation "created" either actual entity in substance, since both of them were created by community members who volunteered their contribution to the cause.
The Mozilla Foundation as an entity did NOT:
I just wanted to make sure everyone understood these historical facts when interpreting Mike's blog.
Hi Mark. (You know who you are).
Did you file a bug?
Wow, the feed UI is looking especially ugly right now. The button/widget alignment is wacky, the subscribe button no longer has emphasis, etc.
As for sniffing, what would you propose we do? (Hint: don't say "respect specified content type")
I have re-opened my personal blog for topics that aren't directly related to my current Firefox development activities.
It's Fourth of July Weekend here in the States (not being a native 'Merkin I always end up finding out about these things just as they're happening) and I'm sitting at home after a long day of tidying up the house and running errands. I find myself sitting here at my desktop computer, which I originally bought for Firefox development back in 2003, but never ended up using that much. These days there doesn't seem to be that much difference between state of the art and old tech - this computer is three years old and doesn't feel significantly slower or less well featured than my Google-issued system which is about 18 months old. Without getting into the scary optimizations like RAID and so on, is there much about new systems that really makes them worth upgrading? Every Mac upgrade I've been through has felt more impactful. Anyhow, on to the point of this post.
I am writing this post (and the last two posts too) in the Firefox browser that was installed on here. I look in the about box and discover it's Firefox 1.0RC1, a build dated October 1, 2004. That's almost two years old. (The About box reads "Preview Release" because back in the day we didn't rev the version number until the 11th hour, because otherwise we knew someone would misinterpret our test builds as official and let all of the air out of our release balloon...)
I know there are countless security bugs and so on that have been fixed since 1.0RC1, but I had to think hard about the things that would actually get me to upgrade. This build being pre-release there's not even a red christmas tree in the top right corner to entice me to upgrade. Where's the innovation been in Firefox over the past two years that I care about? Well, a couple of things manifest themselves:
This isn't to say that a lot of other very good worthwhile work didn't go on during the time between Firefox 1.0 and 2.0 - it did. But just using the browser for casual surfing and blog posting, these are the two things I noticed most. (On my work system where I'm constantly crashing and restarting, I often appreciate session save too) Every release of FIrefox gets a little better. As long as we continue to have at least one feature per release that is "sticky" enough to keep people from downgrading, and continue to make improvements to performance, memory usage and overall product polish/quality, I think we're in good shape.
Today, Mitchell writes about creativity, and touches on some other issues such as openness etc.
It�s good to have ideas, and prototype them. This philosophy is the core of the Mozilla project that I love � it�s how I�ve tried to operate myself much of the time� to not let myself get bogged down in all the negatives and suffer what some call �analysis paralysis�� not all of my adventures have succeeded: some of the code I have written has never gone anywhere � Vixen, Manticore, etc. It�s why I love extensions. They give people the ability to play with something that could be impractical, but who cares, it won�t hurt anything� there�s a chance it could be really useful so what�s there to lose?
I see the benefit of a process surrounding out-of-band innovation as a useful step to take in a corporate environment where people need to be able to spend some amount of their time doing some more novel/long term research. It's a good thing to establish culturally so that you don't get the "angry boss man" type of situation we had at Netscape. Personally, creativity and exploration has always been my modus operandi - it's how I begun working on this project, and I think I share this trait with at least a few volunteers.
On the topic of communication I fundamentally agree with what she says. Opening your idea to comment from the start may not always be the right thing to do, depending on what you�re trying to achieve. Often, there are two outcomes � your plan gets mired down in a bunch of negative or �stop� energy, or you get no useful feedback at all. Over my history contributing to Mozilla, I�ve experienced both, a lot of the time.
The trick is where the rubber meets the road. When you do go public � and eventually you will if your code makes it in to Firefox � you need to be prepared to provide justification for what you�re proposing. Hopefully, your idea will stand on its own merits, and little explanation will be necessary, but you should prepare for it all the same. If you have the courage of your convictions, you should be able to stick to your guns. Maybe you learn a thing or two in the process. Good contributors in a healthy community ask questions and make reasonable suggestions for improvement. When it's time to tell more people about your concept, the important thing is not to go into it with a finished product. Some people say you should always show UI mockups as sketches, because it presents them as being more accessible to modification based on feedback since the work to actually implement them hasn't been done. A few of us have had pretty bad experiences in the past when organizations have arbitrarily pushed fully formed visions on the rest of us without much explanation, and little recourse. Remember we don�t just do things because we can, or just for concepts like �the good of the web� because they�re nice to say.
Why do we do what we do?
We always do things for a reason, but do we ever stop to ask ourselves how good our reasoning is?
Are we doing things simply because �we can�?
I was talking to Leslie about this recently. She said that doing things simply because you could was a pretty bad reason to do anything. I�ve been thinking about that one for the past few weeks, chewing on it. I thought of things I�ve done in the past� I thought of things I was happy with and things I wasn�t so proud of� things in the latter category had usually been done in part because I thought I could get away with them. I�d been feeling a bit of guilt about a bunch of those lately, and I couldn�t quite put my finger on why (other than the fact that they were bad things to do)� but this sort of sums it up.
�Because I can� is one of the most destructive reasons to do anything� I think it�s by that logic that the world is in the state it�s in now. War, poverty, mean-spiritedness, a whole lot.
A lot of what we do are things that we find enjoyable. That�s cool. I like potato chips. I experiment with different kinds because I enjoy the different tastes and qualities. We need to think though about the consequences of our actions on other people, though. Does our enjoyment result in someone else�s misery? (Or somewhere in between in the spectrum of happiness) What makes our enjoyment so valuable that it�s worth depriving someone else? If the answer is not satisfactory, then we�re really doing it �because we can�.
We need to consider the consequences of our actions carefully. We need to also think about whether or not we truly believe in the reasons we tell our conscience for why we do things. Are they real reasons, or just excuses? Just catch phrases that are convenient ways to allow us to keep thinking that we�re good people?
How many times do you need to say �I�m doing this to help people� or, �I�m doing my part to keep the Internet open� before you really believe it? Or is everything we do really just all for ourselves? I really hope not. For the sake of humanity�
A little story�
We recently traded Leslie�s Hybrid Civic in on a new Infiniti M45. We hated the Civic. It drove like crap� it�s not so much that it was slow (it was) � mostly it lacked comfort and decent handling (both of which don�t contribute much to poor fuel economy � at least not as much as a big honkin� V8 does). The M gets about 15mpg at the best of times (almost exclusively city driving). I never really thought about it in those terms before signing the papers. It�s pretty bad. The car is exceptionally enjoyable, but what�s the cost? I got the tires replaced on my bicycle recently. I�ve ridden it to work a couple of times since, and I need to make more of a habit of it. I need the exercise.
I was just now talking to Brett, who's been working on Spell Check for the past few weeks. One of the difficulties Firefox 2.0 faces is that there's no compatibly licensed pan-language dictionary. We're using MySpell now, which is LGPL for English only, I think. From what I'm told, we'd really like to use ASpell, because their dictionaries are way better, but because they are GPL, we can't. IANAL, so I can't give all the reasoning behind any of this.
What this means anyway is that we have an dictionary for English now that marks "Firefox" as a misspelling and our experience for users in other languages is that they have to manually go and download a dictionary. That sucks.
It'd be great if ASpell was also available under a compatible license, or some other compatibly licensed dictionary of similar quality were to emerge.
We use Comcast for Cable TV and Internet services. I last paid them by credit card some time ago, and must have forgotten to set up automatic payment (probably because no one on the phone when you call them seems to know how, and their website is mysterious and useless, and as an internet customer you get no information about how to log into it). While we were in New Zealand, they suspended our service for late payment. What follows is the set of steps
we had to go through to get it reactivated. While I understand this is probably mild in comparison to the experiences of some, with a whole variety of service providers, I still think some public shame is required.
var demo = new Hotness();
if (manager)
demo.fail();
else
demo.run();
--- demo-rules.js 2006-05-08 09:59:46.775999400 -0700
+++ demo-rules.js 2006-05-08 10:00:12.809415200 -0700
@@ -1,4 +1,4 @@
-if (manager)
+if (manager && !sacrificeMadeToDemoGods)
demo.fail();
Today's nightly builds now show some basic entry content for feed entries:
After a2 I'm going to go through and make some more UI changes (see Mike Beltzner's post to dev.apps.firefox for more info) but this is a good start.
Thanks to Robert Sayre for writiing the new Feed Processor which provides a convenient XPCOM component for parsing various feed formats to Gecko applications. After 2.0, we will convert Firefox Live Bookmarks over to use it, and Thunderbird will transition over too. This will provide an excellent building block for RSS/Atom based extensions and XULRunner applications too.
Underneath this is a new scriptable SAX DOM parser which Robert also wrote. Thanks also to Peter Van der Beken for the review of this significant new component.
Firefox's user interface is built using an XML grammar called "XUL" (for XML User interface Language). Shortly after the decision was made to switch to Gecko, the Netscape team began developing a web-based user interface toolkit for the new Mozilla browser. The rationale was that it would allow the application to be built for the variety of target platforms and toolkits once, rather than individually. Without going into a long history lesson that many
of you will already know from other places, this approach turned out to be trading one set of problems for another. But we ended up with some cool and ultimately useful technology as the platform stabilized.
The problem is this: almost all of XUL as it exists today hasn't changed much if at all since it was originally written in the charge to Netscape 6, and as a result the capabilities and problems with the platform reflect the quick cycle and shortcuts that had to be taken.
Today, we're in a difficult spot. XUL and the Mozilla platform at large allowed Firefox 2 to be built very rapidly and have many capabilities, including its popular extension system. Other projects like XULRunner have grown up too. The popularity of Firefox and the perceived flexibility of XUL to an outsider mean that now there are many extensions, and a growing number
of XULRunner applications.
As I said earlier, very little work has been done on it over the years since the Netscape XPToolkit team moved on. There have been a lot of minor incremental fixes that have made many aspects of the system more stable, but significant bugs and critical failings remain. This is immediately obvious to anyone who has ever built with XUL but who isn't part of the "Mozilla community" where the sort of work that people do sort of self-selects towards the things that XUL is capable of. There is a web of inconsistency (for instance today a colleague of mine asked a question which pointed out that we have several different ways to get the "width" of a XUL widget: boxObject.width, width Attribute, and the width held by the computed CSS style of the object. The problem only gets worse if you extrapolate "widget" to include "top level window". There are also things that just don't work as they should, like layering any kind of complex widgets using the <stack> element (see creative workarounds in the Safe Browsing code).
What really needs to happen is a holistic, top to bottom review of the XUL API with significant overhauls where necessary. This sort of review needs to be done from the point of view of "What do app developers expect from modern toolkits" not "what will be possible to implement within the framework of Mozilla". This is a culture thing we have to shake. This is in my opinion the
only way XUL has a chance at being capable of delivering the sort of applications that users will expect to run on their systems in the future.
There are many things that we could be doing now, things that aren't necessarily gated by the Cairo work that's going on, etc. These include building a more capable tree widget, revising APIs, etc.
Why aren't we doing things like this? Well, one reason is I think in many ways as a community we have come to think of XUL as a "frozen" thing, despite the fact that no review or freeze process was conducted on the API. What we're stuck with then is a lot of self-induced confusion and stop energy when it comes to making changes that push the XUL platform forward.
My opinion (just my own, and I know I'm controversial) is that we should break whatever we have to in order to get XUL into good shape. We never said this platform was frozen. We built (inconvient but effective) version restrictions into extensions as a result of this. We actively don't promise that folk using non-frozen APIs won't be broken by new major Gecko versions. So why don't we use this as an opporunity to fix what's broken and take the time to do the right thing by the platform, our developers, and ultimately our users?
I think we should do this to the exclusion of supporting the old XUL APIs. The reason for this is that by adding rather than replacing we increase the overall size and thus complexity of the code. Every time there are two different components that do similar things we raise the barrier to entry for new hackers and we frustrate people building on our technology.
As someone who spends a lot of his time building with XUL, I can tell you it's not a pretty picture. Over the years I have become accustomed to the quirks and I have formed little shortcuts in my brain that I apply when I run into problems. Not everyone has had a chance to do this, and I don't think that they should have to.
These days, developers have a lot of platform choices when building their applications. Once you're familiar with XUL it can let you develop applications incredibly rapidly and within it lies true value. We need to take steps to not only to make sure it keeps pace with developments elsewhere in the software world but also to make sure that it lives up to what could be said as being its presently superficial promise of making application development easier.
Another thing I've noticed people saying a lot is "Oh that will be fixed once we switch to Cairo." and "We'll be able to do that in 3.0". This scares me. I have a very limited understanding of how most of layout works, but it's my understanding that if there's a bug in XUL, the bug is often in the XUL layer itself, or something else like the native widget code or the View system. Changes like the switch to Cairo may make possible a certain class of
toolkit features, but only if the bugs in the layers between graphics and the application developer are fixed.
We have just enabled an experimental Feed Handling feature, which will be available in nightly builds starting Friday May 5 2006. When you click on links to RSS or Atom feeds, you will be shown a preview page that lets you subscribe to the feed using your favorite reader. The idea for Firefox 2 is to also make web readers available as options. We are allowing web sites to register as Feed Readers using a method exposed on window.navigator. As this is not yet implemented, for Firefox 2 alpha 2 we are offering users the ability to customize this through about:config, and we have also seeded the list with a few providers.
To edit your web feed readers, go to about:config and type in browser.contentHandlers.
The preferences work like this:
browser.contentHandlers.#.type |
The mime type of the content, must be application/vnd.mozilla.maybe.feed |
browser.contentHandlers.#.uri |
The RESTy subscribe URI of the service, with a %s where the URI of the feed should be inserted. |
browser.contentHandlers.#.title |
The title of the service |
In each of the examples, # is the next number in the sequence after the last registered set.
Once you have created these preferences for your favorite web service, it will show up as an option in the Feed Reader selection UI.
You can also subscribe with a client application or continue to use Live Bookmarks. To test the feature click on links to RSS/Atom content in web pages, or click the Subscribe icon in the Location Bar when it appears. To change your settings after you've made them, go to Tools, Options, General and click on Choose Feed Reader.
And finally, here's a screenshot:
This is a work in progress, not all of the functionality works yet but it was a solid enough improvement over the status quo (where clicking links that are feeds shows garbage) that we thought it was a good idea to get it out there. File bugs in the RSS Discovery & Preview component in the Firefox product in bugzilla.
See my previous post on feed handling for more information about how this was implemented.
One of the areas of focus for us for Firefox 2 is Feed Handling. With this release we are seeking to make feeds more useful to more users, and along the way to that goal improve on some of the shortcomings of Firefox 1.x. My plans are outlined in this newsgroup posting.
What this post is about however is not about UI design but about implementation. This has been a very interesting journey so far, and I�ve learned a lot about our networking APIs in the process. Thanks much to darin, bz and biesi for the help.
Here I�m going to focus on the first of two interesting aspects of the requirements described in my newsgroup posting: showing a display page when feed links are loaded.
Towards the end of Firefox 1.5, a prototype feed pretty printer was landed. It had very many problems, and was removed. The solution was a hack � it observed every page load and tried to guess if the content was a feed or not. It guessed wrong many times because of the various types feeds are (incorrectly) served as, was jarring to use (since it appeared only after the feed document had initially loaded and potentially displayed some content to the user) and had many issues.
For Firefox 2, I wanted to approach this from a different angle. I wanted to integrate this well, using the APIs exposed by our system, for clean code, but also to prove that it could be done.
A lot of people read my previous post and came to a very reasonable conclusion: "If you take Places out of Firefox 2, shouldn't it be called Firefox 1.6?"
I don't agree that Places was the one and only thing that sold Firefox 2 though. I took a look through the Firefox 2 Requirements page to look at some of the other stuff that's going on. Reading that document, I think I can see now why people are down in the dumps about no-places Firefox 2. I don't think that document necessarily does the best possible job of capturing the excitement I have about some of the Firefox 2 features we're pursuing.
For the past week or so, I've been toting around a printout of another document, which I wrote because I wanted to convey some of the vision I have of the Firefox 2 product as a whole - a more holistic view as it were.
If you take a look at the black buttons stacked in the right column of this page, you'll see that one of them reads "Safer, Faster, Better." I don't knowwho came up with that one but it's a good tag line. It has a certain cadence about it. People have attached lots of these to Firefox in the past - "Take Back the Web" was the one I came up with, there's "Rediscover the Web", the FirefoxFlicks project has yielded a few good ones too - I like "Web For All". But "Safer, Faster, Better" is not just a tag line, it can also map into a set of themes for product development.
So, taking a look at the Requirements page, I attempted to do that. My document wasn't a comprehensive collection of everything on that page, I was focused more on the things immediately visible to most users. I guess my problem with the Requirements page has always been its very engineering/technical focus. The result of this is that the priority of items tend to reflect how difficult something is to implement, or where it lies in the development cycle, not necessarily the impact on the user. What I ended up with I guess is a sort of "Shadow PRD" that reflects what I personally thought was cool about Firefox 2, and what I wanted to get out of it.
A copy of the document is here.
Some notes:
All in all, I think there's easily enough here to justify a "2" designation. That's just my opinion though. I also think whole numbers are probably easier for the general populace to understand than decimals.
Firefox has never been about date driven development (within reason). The changes with Places should not be seen as a change in this sentiment. What we're about is high quality software development with real advantages to
users, and I think that with the updated plan we're still on a trajectory that supports and encourages that, perhaps more firmly now than before.
And that's it from today's "Ben waits for the tinderboxen to clear" report.
When we began work on Firefox 2, we decided to focus on a development branch, a continuation of the Mozilla 1.8 branch. The reason for doing this was that there was to be a lot of significant architectural changes going on on the trunk, with the prospect of a new rendering back end, a rearchitecture of reflow in layout, and various other things. Shipping a Firefox 2 release in 2006 off of this code did not seem possible.
As a result, we decided to pursue a release focused on application level improvements, on a separate branch. Going into it, we knew the perils of multi-branch development. We knew the divergences that would inevitably form between branch and trunk. We had experience from the painful development of Firefox 1.0 on the Aviary branch. We resolved to be more methodical about our commits, but we knew to expect some pain. The goal was to produce a high value release in short enough time so that we could all return to the trunk and help build new features that utilize the back end being developed there, to help shake them out.
Late last year, we put together a list of things to pursue for the Firefox 2 release. A month or so ago, we got together as a group and formalized this more in a Firefox 2 PRD. We had scheduled four major pre-release milestones, two alphas and two betas. We have already shipped one alpha. The intent of the second is to be "Feature Complete".
The people driving the various sub-projects on the Requirements list get together weekly to check status. As the weeks have gone by, it has become clear to us that the most complex feature on the plan is Places. It is easily an order of magnitude more complex than anything else on the plan. Places is a great feature and it has been exciting watching its capabilities grow. We are looking forward to the capabilities that it will expose. What we have learned though is that the work required to complete Places is probably too substantial to gate the Firefox 2 release. It falls more into the "significant rearchitecture" category of feature that's generally been targeted at Firefox 3.
What we have decided to do is as follows:
We think this is a good decision for two reasons:
Michael Schroepfer of the Mozilla Corporation has a newsgroup posting with additional information. His thread is also the most appropriate forum for discussion of this topic.
I have been working on refining some of the messaging surrounding feature content and prioritization on the PRD. I will post the initial results of that here soon.
... that I hate this computer?
While I'm at it... the up arrow key cap fell off after about three weeks, in early 2004. About six months later I lost the little rubber membrane thing that made it slightly easier to push the arrow. Since then, I've been typing by pushing down on the little connection thingy on the keyboard tray.
It's been shedding pieces of plastic too. I've never dropped the computer once, but pieces of the shell have begun to snap off.
When I first got it, when the secondary battery was in place, when the primary drained the machine would hibernate, even though the secondary was present! Pretty awful bug to ship with. There was never a solution that I could find. Speaking of batteries, the primary battery is pretty much toast... it won't go for more than 5 minutes before shutting down. It began doing this at around the 12-18 month mark. And the battery light permanently flashes orange whenever the system is on.
Why don't I call the hotline? I guess I'll have to, before my warranty runs out. I don't because it usually involves 45 minutes on hold or explaining to someone who only has a script to read from that the issue involving a missing up arrow doesn't require restarting Windows or running some stupid diagnostic tool. I could have paid more for "premium support" at build-time but I found that concept sort of insulting: why should I have to pay extra to speak to someone who is smart and doesn't think I'm a moron?
And I don't want a Thinkpad either. I hate those computers. They have old-fashioned 4:3 displays, and the function key and left Ctrl key are reversed. I know I could map them differently but why would I? Why couldn't IBM just have designed the product correctly in the first place? Oh, and I'd sooner drink paint than run the awful IBM access connections software to connect to a wireless network, or deal with the fact that the Num Lock key seems to reset to ON every time the system is rebooted.
Why doesn't someone make the perfect laptop? I'd be interested to hear from someone how long the compile times are for FirefoxDebug on a 2.16GHz MacBook Pro...