I think every feature that has been in 0.9 and won't be in 1.0 should be moved to a menu, advanced, experimental. Have a clear note that these features are buggy/not complete.
Then, optionally make the experimental menu in the advanced section be able to be enabled/disabled by a preference in about:config.

I personally have no problems with moving dynamic themes to an experimental menu. Same goes for work offline.

The problem with about:config as I see it is one of the XUL variety.

Really there should be a way to stick XUL textboxes/dropdown menus in a XUL tree. It would allow for iTunes-like editing. You double click a tree item, and the textbox lets you edit the text. This would do an amazing thing for usability of programs. You could easily make an excel-like spreadsheet! You could easily have a Visual Basic/C++ like properties dialog.

I know it seems trivial because there isn't much difference keystrokes wise, but there is a huge difference usability wise.

Anyway, I'm glad to see that features being removed are getting thought about long and hard.

[rant]
Maybe firefox could have a system like the automatic updates where it gets told of new things to vote on. Every user of firefox could be involved in the future development that way. It would be one way to get mum and dad style end-users to understand what open source is about, in a practical way.

Or maybe have a menu that lets you report a bug to a messageboard. The messageboard gets a note that it was recieved from a firefox user, the people on the messageboard could work out if it was a dupe or report it to bugzilla, and if it's got a fix, firefox could send the user the message of how to fix. Okay maybe this one has some problems from a security point of view...
[/rant]

I agree with removing "Work Offline". It's just too buggy. I don't really agree with removing the alternate style switcher. Maybe it's buggy, but I haven't really noticed that it is in fact buggy. But I don't have strong feelings about that anyway.

But trying to remove "View Source", I thought that was a grave mistake, because IE has it. I heard one of the Firefox developers say that wasn't a good argument. I found that strange to hear that, because I think it is a compelling argument.

Maybe if these things were communicated earlier (planning on removing features when it is clear they will not be bug free before Firefox1.0), it would not create such uproar?

In general, I think the Firefox team is making the right design decisions (I accidently happen to agree with most of them :) ).
I also think it is a good strategy trying to remove most of the bugs/ui glitches, even if it would mean removing (semi-)useful features.

Thanks for acknowledging that you were wrong on the view source thing anyway.

Regarding other buggy features - there are lots of non-trivial and confirmed bugs with extension management, themes, live bookmarks, find toolbar, tabbed browsing. Many of those are 1.0 blockers, but I'm sure many of those will get pushed out. (Not to mention automatic updates and the plugin finder thing, which are new...) I don't see that shipping unknowns is so much worse than shipping with known bugs, and obviously we're not going to dump all the core features, nor are they going to be bug-free in any realistic timescale.

Also, "make it an extension" isn't such a great solution to these things. Stuff like configuring GIF animation and the cache settings certainly aren't something that everyone wants, but it's somewhat embarrassing to have to explain in a FAQ how to change such things via about:config. It'd be nice if extensions existed to do that kind of thing, but the "left out prefs" extension hasn't been updated for 0.9 (AFAIK), and the other extension I'm aware of that does one of those is buggy and introduces a ton of other stuff. There may be others, but I'd rather recommend about:config than some extension that I don't know anything about.

If you take out a buggy feature which not many people use, most of the people that do use it will end up with an extension, which means they have to find the right extension, install it (which isn't always as easy as it should be), and hope that it'll get updated. And assuming they get the extension, it'll probably be just as buggy, if not moreso, than the feature when it was removed. It does mean that other people won't stumble into the buggy feature as easily, and it enables the Mozilla folks to say "yeah, it's just an extension, we don't support it because it's embarrassing", but it probably doesn't improve the user experience.

Having said that - dynamic theme switching has never worked, and getting rid of it has a lower-cost than getting rid of just about anything else - it just means a restart. And with the bugs, a restart is generally needed anyway. So please go ahead and get rid of it for 1.0 :)

Hi Asa, I'm really glad you posted this and I can agree with almost everything you said, I would also disable dynamic theme switching or bookmark notification for Firefox 1.0, but what about the stylesheet switcher UI?
It is not broken (there are only minor bugs or enhancements like persistence), there are no dataloss bugs, the basic feature works great, no IE user can compare this feature with the Internet Explorer and feel that we are not doing a good job, it is must have for CSS 2.1 conformation and many people love and need it.

So, please tell us, why it was a good idea to remove the rock solid stylesheet switching on the one hand and implement very buggy features (find toolbar, live bookmarks, new plugin finder, new popup blocking) on the other hand only some weeks or days before the release of Firefox 1.0(PR).

Asa :

Gawd, what a long post, and half of it questions... Generic questions like :
> Should we ship a wholly broken feature and release
> note that it doesn't work?
> If it's a dataloss problem then do you pull it?
> Will there be crying and gnashing of teeth when those
> features get pulled?
It almost sounds as if someone had his feelings hurt, or something...

Why go to such extremes and hypothesize? The majority of comments I've read on this and a couple of other related blogs + mozillazine forums weren't strongly opposed to any and all "removals". People were opposing some very specific things, like removal of a couple of more than reasonably well working features ("View Source", JS Console), and one kind-of reasonably well working feature (altSS). People have asked what was the rush to remove those specific features. People expressed their disagreement with the reasoning cited. People mentioned a number of reasons (ranging from purely emotional to very logical) why they believed that those very specific features should not be pulled from 1.0. Yeah, sure, I bumped into a couple of posts mentioning that 1.0 having less features per se than 0.9 was absurd. But so what, seems like you've just bumped into a post mentioning Hitler and cancer, so? :(

Let's keep things in perspective : yeah, there's some crying and gnashing of teeth that some parts of the community seem to make in response to someone "announcing" that some solid stuff just got pulled from Fx 1.0 because... well... 'cause someone woke up one fine, sunny morning and decided that it seemed like a cool idea to pull that stuff from 1.0! A certain specific action caused a certain specific reaction, no need to overly generalize (or pretend that someone is strongarming someone else to release a buggy 1.0)!

> not only did I lose all the pages I had in open tabs and
> windows (including a bugzilla bug I was in the middle of
> reporting) but after a restart I couldn't get my browser
> back at all. Something about an XBL error. OK, so that's a
> bad theme, I guess.
What a surprising conclusion!! "OK, so that's a piss-poor theming engine that both can't handle on-the-fly theme switching and is simply bug ridden, I guess!" would get my vote under the circumstances!

> Also, at least one of my themes likes to clear out the
> URLbar when I switch to or from it.
Again that "dog ate my homework" tune... It's just a bloody theme, it should simply define the visuals (more or less)! If someone designed a skinning engine that can occasionally reformat user's HDD if it bumped into a GIF image inside a skin pack instead of a PNG, then I'm afraid the skinning engine is the one to blame for the damages... And, BTW, if that skinning engine provides skins authors an explicit option to issue the command to erase user's HDD, that skinning engine would still be responsible for the damages. Because it's not a file manager, not a "format" and not an "fdisk", it's a bloody skinning engine, it's job should be to permit the app to look differently, not format HDDs, close tabs, or erase URLs!

Totally agreed with Thomas: kill the really broken features. Be sure to do a similar evaluation of the ones that have been added since 0.9, too; take particular note during that evaluation of bug 251821, which doesn't appear to have been triaged yet.

Obviously you (Asa and the Aviary drivers) don't have to answer to "the community", and to put it bluntly, you (all) take full advantage of that fact. Aviary has always been at the whim of Ben, Scott, et al, and they've shown that they've generally got the right idea even when it's controversial. But a detailed explanation of how the style switcher is as broken as dynamic theme switching and thus deserves removal would be a step in the right direction, as would a bug detailing the requirements for its reintroduction. ("Because it isn't done right" isn't sufficient. How, specifically, does it not work in its present form?)

OK, I will demonstrate all my ignorance with this post, but what the heck.
I am not a regular user of Firefox, nor a member of the Mozilla community. I use Firefox as my second browser on a Mac, and I like it a lot. I really like the underlying vision - simplify the user experience; subtract features from Mozilla/Netscape bloated code instead of adding them.

So my question is... why can't you delay the release date of a few months, if that buys you stability for basic features? What is forcing you to meet the published date?

I don't think you should delay to fix esoteric features (I consider JS console and Theme switching among these); but Off-line browsing and Bookmark management should be something you don't want to go live without. Most converts from IE will expect them.
Add a couple of months to the schedule, pick 2-3 things you want to stabilize in that period, and move remaining buggy or incomplete features to a hidden menu accessible through 'about:config' as someone else suggested. Is this doable?

I still strongly disagree with the removal of the buggy Work Offline. I can perfectly agree with you IE users will find it lame if they switch to FF, but MOZILLA USERS already using it (you and I are _not_ the average target for this feature) will be VERY upset to discover the feature they rely on because they have a laptop and travel a lot is not AVAILABLE any more... Hence I think that yes, it's a wrong move.
On a personal note, I know dozens of people here around me using Work Offline w/o any problem. They are usually NOT software engineers, and have very little computer knowledge. They use Seamonkey/FF because their sysadmin does not want to have infected machines to fix every day. They like Seamonkey/FF. And they rely, for their WORK, on Work Offline because they just don't know how to organize a lot of documents saved with "Saved Complete Page".

Such a feature, that HAS BEEN available for years (even buggy), should be moved to an "advanced feature can" enabled only when a specific checkbox is checked in the Preferences, and invisible/unreachable otherwise. That way, new adopters won't be shocked by our Work Offline, and existing users can still use it.

It's a world of compromises.

""Brendan was right and I was wrong about JS Console and View Source. ""
- It takes guts to admit you are wrong, thanks for doing so, that shows credibility and respect.

I am in agreement with OFFLINE, it's too buggy and doesn't work as it is "supposed" to. Although, like D. Glazman says, you really shouldn't leave old/current users hanging. Make it a pref. then for 1.x we can do it right and enable it by default.

Makes sense to me.

Product mangagment is always rough, and it is rougher in an Open Source environment (but you end up with a better product). I don't know much about the specific features you are discussing, but one always has to cut features at the end of a development cycle.

"Cut to fit, get it done. Put the rest in 1.1." PM 101.

Thanks for the hard work. (I've been there myself).

It is nice to see you admitting you are were wrong. Thanx. I too however feel that the grunt of this post is too generic. Please try as suggested in my blog and here to be specific. Many of the argument for non-removal were very specific. Please don't remove feature xxx because of yyy and zzz.A lot of these arguments (if not all) simply stands un-countered and valid.

Asa, thanks for taking the time to explaining the situation.

I agree fully with the decision to hide or remove buggy features which would take too much time to get working before 1.0. Dynamic theme switching surely is one feature which could be turned off until after the release. It is, as you write, buggy and there is potential data loss. I'm sure most users will have no problems with having to restart the browser after installing a theme, just as for extensions, though I'm sure some will complain bitterly anyway.

Moving high visibility broken or buggy features into an "experimental features" menu might be a good idea, but that menu should definitely be hidden by default. An about:config entry to enable it could be a good solution. That way people who really want Offline Support and whatever else you put in there would still have access to it.

As for AltCSS, as I wrote in an earlier comment, the bugs are more like RFEs than real bugs. The switcher works, even though it could work better. But since it's so small and unobtrusive, it should be kept in. It's still very useful.

I understand the wish to release Firefox ASAP. There is an unmatched window of opportunity this year, with several high profile security holes in IE, and a media that is devoting major time to covering them, and recommending alternatives to IE. As XP SP2 rolls out that window will probably be closing. Some of the major points in Firefox's favor, like popup blocking, will be negated. Though I don't doubt that there will be more security holes found in IE, there is a real chance that SP2 will make the average user feel more safe, and thus not in need of switching to Firefox.

That is why I agree with not pushing the release of 1.0 back more than necessary. Maybe it wouldn't matter, maybe it's be ok to release it next year. But I wouldn't want to take that chance. Not if I want Firefox to be more than a niche product like Opera or the Mozilla Suite.

Thanks for the explanation. For theme switching, I think you are right, there are too many issues with it. But in your explanation, you left out style switcher.

In http://bugzilla.mozilla.org/show_bug.cgi?id=253722 you mention 7 bugs to justify the bugginess of CSS switcher. But 5 of them are enhancements, while the other two are minor issues. OTOH, removal of the style switcher breaks CSS 2 conformance. So, what is the real reason for removing style switcher?

The problem you seem to have identified is that some features of are not as strongly owned as they should be. Over time, this tends to lead to increasing numbers of bugs (as other changes break the feature in question). You also note that finding relevant bugs in bugzilla is difficult since they may be misassigned, unconfirmed or otherwise not obvious.

What seems to be required is some clear and straightforward communication that a certian feature does not meet the level of quality required for a shipping product and, unless someone can bring it up to the quality expected within a reasonable amount of time, it may be removed. This announcement really needs to be obvious i.e. it should be in the newsgroups and on mozillazine, not on a forum read by few coders or hidden in bugzilla. Then, if someone starts patching bugs, they need to get actual review attention. Nothing puts me off coding for firefox more than the sight of simple patches that sit unreviewed for months. If a feature is in an unsatisfactory state somone who can review must actively watch the bugs on that feature and be prepared to conduct timely reviews of patches. At some point there needs to be a fair assessment of whether the effort has made the feature meet release quality expectations or not.

Clearly this process needs time. Therefore, if it's announced that a particular release is feature complete and that all remaining work will be bug fixing rather than feature work, there needs to be a freeze on feature work. If time allocated to fixing bugs is spent adding features that make cosmetic improvements to funconality that already works, it's inevitable that less time will be spent fixing actual bugs. That leads directly to a situation where useful features get pulled at the last minute.

In the specific case of the alternate stylesheet UI, fantasai has clearly stepped up to own the feature and, given her track record, it's reasonable to expect that she can fix the existing bugs (but not all the enhancement requests) for 1.0.

> We removed bookmark notification because it was highly buggy and no one was
> working on making it less buggy. The same for off-line. Was that the wrong move?

Yes. The right move would have been to say three months ago "bookmark notification is going on date X unless someone fixes bugs Y and Z." It's called product planning and leadership :-)

If there are going to be further feature removals, we should publish such a list now.

good point Gerv!
And brainstorm _is_ needed and _is_ extremly usefull.

Asa,

You mentioned many features in your essay that can be considered as candidates for removal. But, funny, you didn't mentioned the one that gathered most votes against removal - style switcher. I don't really see much talking about removal of Work Offline around the blogosphere :-)

Talking about style switcher - yes it has bugs. But many people consider it useful. It provides basic functionality which does make sense even on pages with their own switchers: it provides consistent interface to the feature. Similarily, we don't remove the ability to adjust links and fonts appearance based on fact that many sites provide this styling themselves. So many people would, I believe, agree that with all its bugs (not sticky, can't reapply basic style, doesn't work well with genreated contents) style switcher is still useful feature.

Every software has bugs. And mere existance of a bug is not a reason to disabling a feature. It's severity (in general terms, not Bugzilla's) that matters. Core FireFox developers are perfectly able to decide a severity of a bug from a developer point of view. But the other side of the question - about usefullness - can't be figured without users' opinion.

So I think that such decisions should not be based soleyly on "has bugs" principle. This is a question of quantity: is some feature more buggy or more useful, does it more harm or more profit and, hence, should it be removed or left. These are, by nature, a community-driven decisions. IMHO :-)

This is exactly why all these recent decision made such a great roar. I think that core FireFox developers don't fully imagine the need in those features. Yes people know that they are buggy. But they, as you yourself said, got used to this features. And not only because they love the product and can forgive more bugs but also because no other product offers such distinсtive useful features. There are not only IE converts who will (as we all hope) use FireFox. There are many smart and good people that use Mozilla and FireFox about 5 or 6 years.

And even those IE users who will evaluate the browser won't simply throw it away because IE users know very well what bugs in software are. And they also got used to them.

"Yes. The right move would have been to say three months ago "bookmark notification is going on date X unless someone fixes bugs Y and Z." It's called product planning and leadership :-)"

You, as well as anyone, knows how short on resources we are. If I discover tomorrow that export bookmarks causes Mac OS X installations to become completely corrupted, melt hard drives and potentially eject DVDs with such force as to kill small children and pets, would you say "the time to cut that feature was months ago."

We address problems as we find them. If we had more people helping to find and assess various problems we could get to some of them faster. We've all been extremely busy. We're shipping three and four products at a time from three different code bases. Could better planning have helped, of course. Are we able to turn back the clock and come up with better estimates of the lifetime of the aviary branch, the need for three or four security releases of three different products since the 1.7 branch, or other factors that have put us where we are? No. So we deal with what we have and where we are today.

If I had had the time to investigate off-line browsing (like I assume mscott did when he pulled off-line from Thunderbird and made it an extension) or dynamic theme switching months ago when I was burried under the mountain of 1.7 branch preparation or some other important task, maybe we could have pulled them sooner. But unfortunately, we're behind on this like we are on most other things.

Planning work is hard. Scheduling is hard. Shipping quality software is hard (and that's one of the reasons you don't see it happen all that often.) No one ever anticipates everything that can come up or go wrong. You do what you can with what you have. No one thought it was going to take several years to change our licenses :-)

--Asa

I'm all for removing really buggy features that don’t work right. But for those features that work fine but have a couple of problems with them, why not just hide the menu items and allow someone to show them using userChrome.css (making a preference for this seems a little overkill)? I'm currently using this method to hide menu items that I don’t use, so why can’t it be used to show things I want. That way, most people won’t know of the existence of the features, and those people that use the features can easily turn them on and subject themselves to the bugginess.

"We address problems as we find them. If we had more people helping to find and assess various problems we could get to some of them faster."

But the whole Bugzilla is filled with responses from those 'more people' - us. This is what most of us do for you - respected developers and project leads. Bugs filed for Work Offline, Style Switcher and other subsystems are old. Some even very old. Problems are known and well described.

Maniac, when you've spent 1/100th the time I have in bugzilla, I'll be happy to hear you tell me how things are. If you actually believe that I needed to hear that from you, you're considerably more out of touch with this project than I would have guessed.

--Asa

Asa, that is all true, but please tell us exactly what is the problem with stylesheet switcher? The bugs you mentioned are only enhancements or have minor severity and the basic feature works great. We all know, that almost every component in Firefox or Seamonkey has some minor bugs or enhancement request without being removed.

Mr. Asa Dotzler,
I agree with you 100% percernt about a Stable piece of software cannot have well known bugs. I think you are right in telling this may scare users. And I think you have decided it's better to Firefox 1.0 not to have these features because we can't fix them in time and we think these bugs should not stop the 1.0 release(I'm extrapolating, of course). But One feature I haven't seen discused is the download manager that in fact in 0.9.3 has still very odd bugs. These features(DM) are certainly more critical than the style switcher et al. and IMHO these would have to be blockers for the Firefox 1.0 release( Forgivem if they are but I look at the bugs blocking using the query's in the project's page and didn't find anything related).

Thanks

I think the Stylesheet Switcher should be left in since it doesn't add to any cruft or complexity, and since I doubt many people here have had problems with it. I can't say I've noticed any bugs and due to the lack of complaints, they must be fairly trivial.

I also think the View Source should be in since it's in IE and works.
That's a reason enough for me.

It's different with Work Offline also being in IE, since it doesn't work.

Do you guys actually do 'regular user' testing or is everything conducted within the 'Mozilla community' echo chamber?

dzd, yeah, pretty much the 'Mozilla community echo chamber' (which isn't necessarily always wrong.)

We had a number of formal usability studies contributed by Netscape back in the day and we are in the middle of some now. But when it comes to making actual changes in the product, those 'regular users' aren't terribly vocal on the web so when Firefox isn't working for them, they don't scream about it at blogs and complain in bugs, they just go back to IE.

--Asa

This is the most balanced post of yours that I have read. It carefully acknowledges where Firefox needs to improve and explains some of the thinking behind various trade-offs. It gives me renewed confidence in the project. Thanks.