Goals For SeaMonkey 2 - My View

Some of you might know that the SeaMonkey team is working hard on something called "SeaMonkey 2" (sometimes dubbed "suiterunner") and of which some pre-alpha testing versions are floating around. Every now and then questions come in about something someone has heard about this magic piece of software that we believe to solve all problems of this world. OK, OK, yes, I'm exaggerating here: not the whole world, probably not even all problems of SeaMonkey 1.x - but we're trying to fix as many problems as possible, and surely some very big improvements will be made in that version.

If that was the only goal for us, we probably would never be able to release this "SeaMonkey 2", as there's always room for further improvements. So, I'm trying to summarize my view of what goals we want or need to meet for that big milestone in the project:

• Modernize the backend framework. This step, also known as "switch from xpfe to toolkit", brings us to building upon even more of the same base shared with Firefox, Thunderbird, Sunbird, Songbird, Miro and other Mozilla-based software. This also implies adopting the much better extension management those applications already have as well as a list of other good improvements.
• Reduce and consolidate SeaMonkey-specific code. The more code we can share with others and don't need to maintain completely within our small SeaMonkey team, the better. Because of that, we try to reuse as much code as possible from the core framework of Mozilla. At the same time, we're moving the code specific to SeaMonkey but previously spread across multiple paces into a common suite/ directory in the Mozilla code tree, so that maintenance of that code becomes easier.
• Modernize the look while still keeping the typical suite feeling. We're replacing the aged icon set we inherited from the Mozilla suite and in many cases even from the original Netscape Communicator with a set of icons that fit in better with the current breed of OS desktops. We might do other small updates to SeaMonkey's look as well, along with that. At the same time, we're trying very hard to keep the typical suite feeling alive by making the new pieces consistent across all parts of the application and leaving all typical and familiar elements in their usual places and keeping the functionality intact that our users have grown accustomed to. That way, our goal is to carry the suite concept from the 1990's to modern work environments.
• Improve functionality without bloating the UI. We might add feed functionality, new Add-Ons management, an improved download backend, reworked page info, new storages for cookies, history, maybe even bookmarks, and even more things, as far as we have people able to do the work in it. In all those cases, the UI needs to integrated without complicating or vastly changing our existing user interface. Though SeaMonkey is targeting advanced users and web developers, who can (and often want to) handle our extensive menu and graphical pref systems, we need to be careful to not make using our software even more complicated. While I can for example imagine adding a find-as-you-type search bar to history or bookmark windows, I don't think adding every imaginable thought-to-be-cool feature to that system while merging history, bookmark and downloads into a single overloaded organizer window is a way we should go. Other apps might be trying to do that, we'll see how it works out. If adding functionality to enable extensions to do that with our backend doesn't cost much overhead, we should look into that instead.
• Improve extensibility. One often-cited reason for Firefox' worldwide success is that it's easy to extend with a growing list of add-ons. While installing extensions in SeaMonkey 1.x works fine, SeaMonkey 2 will pick up the improved system with good integrated uninstall, disable and upgrade capabilities. To further improve on that, we should try to provide similar or the same APIs to extension authors as applications that are more widespread and compatible, so that making existing extensions work with SeaMonkey will be even easier. That means e.g. exposing the Firefox sidebar APIs for the SeaMonkey sidebar (without copying the look) or adopting the same element IDs as other apps in XUL where it makes sense that one extension overlay can hook into our UI with the same code as for the other app.
• Improve customization, keep useful defaults. We want to enable users to customize for example the toolbar layout of the browser, so they can e.g. move the home button to the main toolbar or maybe add elements not yet present in our default UI, but the defaults should stay unchanged to SeaMonkey 1.x unless there are very major reasons to change something (e.g. security or clearly major usability improvements). Changes to defaults should be handled conservatively, while changes to customization should be handled progressively as long as they don't reduce usability or unnecessarily increase complexity.
• Integrate better with current OS desktops. This point is especially important in the case of Windows Vista, where SeaMonkey 1.x is known to have problems e.g. with getting registered as the default browser or mail client. This should get fixed in SeaMonkey 2, as well as getting elevated privileges where needed for installation purposes, etc.
• Enable automatic partial updates instead of full re-installs. With SeaMonkey 1.x, one needs to download a new version and manually reinstall it to get the newest security updates. In SeaMonkey 2, we want to adopt a system that can automatically download only the needed changes and apply them to an existing installation, so that updates are smoother and will be done more eagerly by our users.
• Automatically build and release localizations. SeaMonkey 1.x versions in languages other than US English get contributed by the localization teams themselves and are only available as those have time to rebuild them and only in the versions our volunteer localizers can provide. When doing a SeaMonkey 2 release, we want to be able to build localized versions right along with the original builds and release them in all available languages and for all three primary platforms at the same time, includes the previously mentioned automated updates.

As huge as some of those goals might look, we've already managed to go a major step of the way for most of them, and I'm pretty confident we can manage to meet the vast majority of them almost completely. If you're interested in a target date for releasing this major overhaul of our all-in-one internet suite, the only thing I can tell you right now is "when we are satisfied we have met all the gaols we have in mind for SeaMonkey 2". Oh, and that it won't be sooner than the first stable release of Gecko 1.9, which will be the Firefox 3 release. We need this stable base to build upon, so we at least need to wait for that. I still think our release will once again lag behind the major Firefox release, but we'll see how fast we will be in fulfilling the goals we have set up for ourselves.

We'll probably do an Alpha when we're far enough on all the tasks that we can encourage testing by a broad audience, and we'll go into beta when have the feature set completed and only stabilizing and cleanup work is left. Until then, those of you who dare to possibly test unstable, not completely working code and have good backups of their private data so that possible damage to it is no problem, can test our trunk nightly builds. They meet a good subset of the goals above already, but are very experimental and not for the faint of the heart - esp. not for daily use by normal users - yet. Still, as you can guess from the list in this post, we're working on creating a pretty exciting piece of software here.