The roads I take...

In my talk on SeaMonkey 2 & The Vision Beyond today at FOSDEM, I showed the new SeaMonkey vision to people for the first time. This version basically a near-to-final draft, which we are planning to put up on our website soon, but I think I should bring it to you in this blog right now as the earlybirds who were up and here at 9am have heard and seen about it as well.

After our initial goals of making the suite survive and porting it to toolkit have been reached or are being reached with SeaMonkey 1.x and 2 respectively, it's time to have some guidelines for the future of the project. There are a few balance acts in there where the detailed decisions are to be made by the SeaMonkey Council and module owners on a case-by-case basis.

The topics, integration, configurability, innovation, security and stability are not ordered by importance but are all at the same level and taking up the same space in the project, but it wouldn't be good for readability to display them in the same space at the same time.

Here's the actual (draft) vision text:

• Strengthen and improve integration of the core SeaMonkey components with each other, as well as with optional components and add-ons
• Despite the software having a technical split into components, SeaMonkey should feel as a single application with tightly connected features.
• Browsing and messaging are the primary parts that need to be tightly connected, but optional components/add-ons like web tools, calendaring and others should also feel like they are an integral part of the application once they are installed.
• We should investigate an "everything can be a tab" metaphor that spans not just websites in the browser, but messages/conversations, application parts (preferences?) and anything else that sounds reasonable, possibly all running within a single SeaMonkey window.
• The user experience should be consistent in all parts of the SeaMonkey application, including a set of preferences that affects all those components at once.

Provide choice to power users through a reasonable set of configurable and customizable features paired with extensibility through add-ons

Power users, being one of the main target groups of SeaMonkey, should be able to choose what functionality they want to use in what way.

At the same time, the amount of options must be kept comprehensible for users that are not yet accustomed to everything SeaMonkey has to offer and managable for the team writing and maintaining the code.

Development of SeaMonkey add-ons should be made as easy as possible, for example through providing similar or the same APIs as Firefox and Thunderbird for add-on developers.

Everything normal SeaMonkey users need to tweak should be available in UI preferences, things only a small minority of very advanced users want to change should not be in standard preferences UI.

Add-ons should be able to easily extend, configure and customize functionality.

Continually evolve SeaMonkey and both foster and integrate innovation on the Internet

The distinctions and strengths of the SeaMonkey suite need to be deepened and made to stand out more to make the suite a compelling offer for people.

SeaMonkey needs to keep up with changes in how the Internet is used and should also innovate new ways of using it.

The user interface should evolve gently but steadily to feel familiar to both long-time suite users and people switching from other applications to SeaMonkey.

SeaMonkey needs to master the challenge of combining new uses and workflows with accustomed user experiences.

Protect and enhance security and privacy of SeaMonkey users as far as possible.

Individuals' security on the Internet is fundamental and cannot be treated as optional. (see The Mozilla Manifesto)

The suite needs to offer its users realistic options for understanding, accessing, managing, combining, sharing and moving data created by or about them.

When a feature that provides more security threatens to invade privacy (e.g. sending some of the user's data to a server to check for possible security risks), this effect needs to be minimized, both weighted against each other for default settings, and an option to disable this feature must be provided in some way.

Keep the SeaMonkey user experience stable and mature

The SeaMonkey user interface should be kept familiar to former users of the integrated Internet suite.

Apply "constructive conservatism" to the user experience - don't revolutionize and don't deny change but evolve it in a controlled way.

SeaMonkey should be practical and simple enough for beginners as well as able to adapt/adjust for more experienced users.

"Stable" SeaMonkey releases should be tested well enough by the community that we can trust they feel mature enough for production use.

I hope those guidelines can safely take SeaMonkey to new destinations in the future while keeping up and deepening the strengths and distinctions of what the suite is about.