<< Weekly Status Report, W42/2007 | The roads I take... | Harmony in Space >>
Goals For SeaMonkey 2 - My View
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.
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.
Entry written by KaiRo and posted on October 25th, 2007 15:43 | Tags: Mozilla, SeaMonkey, SeaMonkey 2 | 3 comments | TrackBack
from Madrid, Spain
I must cheer the SM Council for your work, in general, and for this sort of manifesto about what to expect for SM 2 in particular. I especially like your view about being conservative when changing defaults and doing them in a progressive way (compared to other software I know, namely NetBeans, your view is far more sensible to me).
If only I had been able to progress in my L10n tool as fast as you're doing with SM 2, so we could use it to replace MT... (shame on me).
from Pleasant Hill, California
Thanks for all your great work.
Not sure why, but Seamonkey seems to work really great on Puppy.
The interface seems a bit different, and it's super fast.
And, being a newbie, it was great to discover the Composer window.
I was able to do my snail mail letters wile surfing about to jazz
stations in another window.
It works fantastic off the Puppy live disk.
By the way, the name of the browser is the coolest.
Thanks again from all of us.
http://www.fagickycbluepill.com/site1/ [url=http://www.fagicuymbluepill.com/site2/]site2[/url] site3 <a href=http://www.fagickbcbluepill.com/site4/>site4 site5 [LINK http://www.fagicgqdbluepill.com/site6/]site6[/LINK] duabh