As with the platform teams, the Firefox team has spent some time
soliciting input from various groups and stakeholders and identifying
themes and areas of interest for the next version of Firefox, be
developed under the project name "Namoroka".
In contrast to previous product planning exercises, which were
declarative and relatively inflexible, we hope to develop this project
in a highly iterative manner by which we initially declare project
goals and prioritized areas of interest for investigation, and then
spend time determining the exact shape and scope of feature
development tasks. The outcome of these investigations will be a set
of feature design documents (using a common template ) which will
be prioritized and constitute the final product development plan.
An initial draft of the proposed process and areas of development
interest is available at: https://wiki.mozilla.org/Firefox/Namoroka
We are soliciting feedback on:
- the proposed process
- the project goals, as expressed in the draft plan
- the areas of development interest (both of the ones highlighted
and about ones you feel we're missing)
Your input and feedback is requested, either:
- in this thread (please reply/follow-up to dev-pl...@lists.mozilla.org
- on the discussion page at https://wiki.mozilla.org/Talk:Firefox/Namoroka
I wonder whether we could get our gateway to map reply-to to follow-up
and vice versa... right now, setting both from a news client is a pain,
and setting both from a mail client seems to be impossible...
Is the gateway something we control (such that filing a bug on this
would actually be useful)?
> - the areas of development interest (both of the ones highlighted and
> about ones you feel we're missing)
Questions about some of the platform requirements:
1) What does the "solidifying nsIRunnable and thread support before
Mozilla 2" item mean, exactly?
2) Using cache to restore the session on restart won't work for
no-store pages, right? At least not if our cache is actually
obeying the no-store (and hence not putting the data on disk).
I would like to see a goal concerning reducing visual complexity in
the user interface, and in number of steps required to complete a
given task. As an example, Alex mentioned one in private concerning
the number of steps it takes a user to start Firefox and navigate to
Without such goals, I worry that the user interface will get more
complex (and it is already more complex than some other browsers),
because the people who worked on new features will insist that they be
> On Apr 1, 12:40 am, Mike Beltzner <beltz...@mozilla.com> wrote:
>> An initial draft of the proposed process and areas of development
>> interest is available at:https://wiki.mozilla.org/Firefox/Namoroka
>> We are soliciting feedback on:
>> - the proposed process
>> - the project goals, as expressed in the draft plan
> I would like to see a goal concerning reducing visual complexity in
> the user interface, and in number of steps required to complete a
> given task. As an example, Alex mentioned one in private concerning
> the number of steps it takes a user to start Firefox and navigate to
That's two goals, of course. Reducing steps to complete task is
great, though sometimes counter-intuitive to reducing visual
complexity (moving UI out of primary UI means more steps to complete
those tasks). We should continue to do both, and it's intended if not
explicitly called out.
> Without such goals, I worry that the user interface will get more
> complex (and it is already more complex than some other browsers),
> because the people who worked on new features will insist that they be
I think I'm generally a strong gatekeeper against "this needs to be
exposed so that people will find it" as a rationale. I don't know if
there's anything in my head that will add any visual complexity to the
primary UI, or even really add net new UI. Having a goal won't stop
us from making bad decisions if we're dead set on making them, it's a
matter of people like me standing firm and exercising sound
judgement. (God help us all.)
I'm not sure I agree with the use of "continue". Last time we revised
the front-end, we failed to do this. The UI got more complex in Fx3
than Fx2. I don't think anything we added was /bad/, but we didn't
simplify a lot, if at all.
[adjusting the subject so as not to dilute the Firefox.next thread]
It has traditionally been very difficult to remove things. I believe
one reason is the intense outcry we inevitably receive from the
community and our users, combined with our inability to accurately and
quantitatively frame it in larger context. For instance, let's say we
encounter 100,000 instances of seething hatred for a change. Even if
this is a very small percentage of our user base (accounting for the
fact that only a fraction of people will comment), it still feels like
the change was a net negative which makes us conservative.
A few features in Firefox 3 were so clearly useful that they passed
the high bar we set for acceptance (for instance, we don't have a pref
to revert the behavior of the awesome bar despite there being some
limited amounts of public outcry for it). However, other changes,
like moving the home button to the bookmarks toolbar quickly failed
due to the outcry.
The problem is we don't really know what the acceptance rate is for
changes. Just hypothetically speaking, the acceptance rate of the
awesome bar could have been 99.9%, while moving the home button was
only 80%. All we know is that a small group of people sent us hate
mail for the awesome bar, and a much larger group of people of people
sent us hate mail for moving the home button.
So my overall point is given the environment of our required
acceptance rate (compounded by our inability to know what it literally
is), I can't really picture us ripping out major parts of the existing
interface, like the home button, the bookmarks toolbar, and the search
What I'm worried about is that this turns into the classic innovators
dilemma, by paying close attention to our user's reluctance for change
and their comments, we freeze up and revert once when the tidal wave
of hate arrives.
Some possible ways to address this could include (in order from least
extreme to most extreme):
-Rely more on broad metrics data capturing actual usage
-Establish a more scientific way to receive qualitative feedback,
things like test pilot, surveys appearing on the home page for a
randomly selected set of users, etc.
-Design based on core principles and where we want to take the product
(this is essentially the Apple approach, but would be open in the
sense that the discussion of the core principles is debated and agreed
upon amongst the community)
-Establish a new brand so we could break the innovators dilemma with a
radically different interface, and users have no expectation of
consistency (very extreme sollution, many downsides).
It's also worth noting that our conservative approach to UI change has
probably served us well in terms of overall adoption rates, and
leveraging external consistency, so it isn't fair to claim that the
approach was bad. The problem is that in the long run it isn't a
sustainable strategy in a dynamic and competitive market like Web
Perhaps we build a web app that allows Firefox users to "redesign"
(albeit with 'fixed' choices, like removal and addition of widgets only)
the main FF UI. For each "redesign session" we could capture just how
simple or complex the main UI becomes - perhaps we just do this for the
menubar and toolbars? This sounds crazy, but it may leave us with some
great metrics, especially if we really get traffic to the site.
> -Design based on core principles and where we want to take the product
> (this is essentially the Apple approach, but would be open in the
> sense that the discussion of the core principles is debated and agreed
> upon amongst the community)
> -Establish a new brand so we could break the innovators dilemma with a
> radically different interface, and users have no expectation of
> consistency (very extreme sollution, many downsides).
I really like this last idea - where we go out on a limb and iterate on
the main UI vis a vis the new-tab extension. A "cutting edge" 'design'
nightly/weekly/monthly? (We could call it "Mozilla Sprockets", and yes,
it would be all black)
Release new features as extensions (installed by default in nightlies), so
users who *really* *really* hate them can turn them off by uninstalling the
Do we test with/support/fix bugs in/etc. the uninstalled
configuration? I think that would be a false economy, splitting our
scarce resources even more widely and decreasing our return on
investment every time.
In particular about:
Future problems to solve ..
- Support for icons/other styling
What are the pain points here, as a new approach to full skinning.
- Integration of AMO
Combine Personas platform with AMO platform
- Deprecation of old-style themes
In conjunction with extensions 2.0 work, push to make this the primary
avenue for visual experience customization.
There is everything slightly unclear .. exist alredy a more detailed
No more detailed planning exists, no. That's what will come out of the
exploration phase on that topic. From early discussions around the
water cooler, though, I know it breaks down along two lines:
- consider adding support for "skins", like what Personas does
- figure out how to make it easier for people to build themes, and
how to better structure the default theme so it's easier to override/
When i see it right, is the goal from Personas:
Style the browser without having to code = easy to use for a lot more
people, than now with the complicated old-style (nerd) theme system.
But a system for "Style the browser without having to code" is
naturally not, what an old-style themer want.
And think the main problem with the old system is, that every theme must
have the complete theme code.
In particualar the transition to a new Firefox version is every costly.
The result is always the lost from many themes, or incomplete and buggy
themes and only a few theme nerds (can) do it right.
I would prefer a system, which make it possible to change for example
the toolbar icons, or whatever .. and the theme must have then only
these special pictures and code changes included.
Will be still a nerd system, but although much easier to use ;-)
Likly is it inpossible to to combine the Personas goal and the old-style
How both should be inculded in the Add-ons Manager is naturally an
Get Add-ons - Light Weight Themes - Themes - Light Weight Extensions -
Extensions - Plugins - Updates
Want likely nobody ;-)
Some would love a sophisticated theme editor, especially would it help
to find new themer.
But i don`t believe, that the few current theme nerds would use stuff
like this. They have already a developing system and this works
especially without any restrictions.
A system without restrictions for advenced themer and an easy to use
system are preferable. When possible, one system for both, but for
example is Personas in its current condition clearly not such a system.
> On Thu, Apr 2, 2009 at 2:13 PM, Aronnax<aron...@gmail.com> wrote:
>> But a system for "Style the browser without having to code" is
>> naturally not, what an old-style themer want.
> Do you mean that old-style themers would not want to be able to make
> their current themes without having to write code? If we had a really
> sophisticated "theme editor", for example, would they object to it?
> I'm trying to make sure I understand if they really object to the
> process being made simpler (which would lessen the "exclusivity" of
> the activity, and could indeed cause some people displeasure I
> suppose!) or if you mean something else.