Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Feature Brainstorming + Firefox 3

4 views
Skip to first unread message

Deb Richardson

unread,
Oct 11, 2006, 5:13:11 PM10/11/06
to dev-pl...@lists.mozilla.org
Over the past few weeks some of us have been brainstorming and going through
the various public discussions about suggested features for Firefox. The
end result is an updated and reformatted version of the "Firefox Feature
Brainstorming" list, which you can find here:

http://wiki.mozilla.org/Firefox/Feature_Brainstorming

This is a living document that will grow and change over time, to be used
for all future Firefox release planning. You are welcome (and encouraged)
to add new ideas to the Feature Brainstorming document at any time, and we
will be maintaining it more rigorously from this point forward.

We went through this effort in preparation for planning Firefox 3. The next
step will be to devise a user-centric method for determining which features
on that list will be selected and turned into a plan for Firefox's next
development and release cycle. Please ensure that all features you think
should be considered for Firefox 3 are on this list. Thanks!

~ deb

Gervase Markham

unread,
Oct 13, 2006, 6:27:01 AM10/13/06
to
Deb Richardson wrote:
> This is a living document that will grow and change over time, to be used
> for all future Firefox release planning. You are welcome (and encouraged)
> to add new ideas to the Feature Brainstorming document at any time, and we
> will be maintaining it more rigorously from this point forward.

Are we sure a single document is the right approach? And a wiki the
right format?

As I look through this document, I see some good ideas, some terrible
ones, and some which simply make no sense. Take, for example:

Scrolling

* Add smooth scrolling

We already have a feature called "smooth scrolling" - Preferences |
Advanced | General tab | "Use smooth scrolling". Is this different? If
so, how? Who put this request there? Any random internet person who
can't read the prefs dialog? Or some short-of-time core developer who
means something different? Who do I ask? How do I know?

If everyone who wants to comment on the Firefox feature set tries to
edit the page, even if it's just to add links to newly-created user-page
-space pages with their views, it's not going to work. How can you have
a coherent conversation about a feature via sub-pages in the user pages
namespace?

This has shades of our attempts to create a list of things to do for the
summer of code, which suffered from similar "random edit" and page
overload problems - and this list has the potential to be much bigger.

I don't quite know what the correct way of doing this is - but does
anyone else agree that there's a potential problem?

Gerv

Mike Beltzner

unread,
Oct 13, 2006, 9:39:37 AM10/13/06
to Gervase Markham, dev-pl...@lists.mozilla.org
On 13-Oct-06, at 6:27 AM, Gervase Markham wrote:

> Are we sure a single document is the right approach? And a wiki the
> right format?

Yes and no, respectively. I do, however, think that a wiki is the
right-est format given the tools options we have at hand.
Collaborative creativity tools is a hard and as-yet unsolved problem.
Suggestions welcome. I think that ideally we'd have some sort of
better tool here, perhaps more like the ones the W3C and WHATWG use
to mark up their specifications. We'd also have someone own this
document. Nominations welcome. You seem to be doing a bang-up job. :)

> As I look through this document, I see some good ideas, some
> terrible ones, and some which simply make no sense. Take, for example:

Of course. And you've been doing the right thing by asking for
clarification and adding excellent notes from the history and context
of the project.

> We already have a feature called "smooth scrolling" - Preferences |
> Advanced | General tab | "Use smooth scrolling". Is this different?
> If so, how? Who put this request there? Any random internet

Well, in that case, smooth scrolling was inherited from the survey
that Deb did of dev.apps.firefox, dev.planning and the previous
brainstorming document. I'd fully expect that we're gonna have some
garbage in there. If we already do it, just remove it. If the idea
was different, the person can re-add it. Just be sure to mark a
comment with your edit explaining why you removed it.

> person who can't read the prefs dialog? Or some short-of-time core
> developer who means something different? Who do I ask? How do I know?

In most cases the addition will be marked in the wiki History. I
don't see why that's hard. But perhaps we should add further
instruction to the "How to use this page" explaining that for the
purposes of tracking, people should insert rationale and details into
the comment field when making changes, and should also ensure that
they have a User page with contact details so we can get back in
touch with them for clarification.

> If everyone who wants to comment on the Firefox feature set tries
> to edit the page, even if it's just to add links to newly-created
> user-page -space pages with their views, it's not going to work.
> How can you have a coherent conversation about a feature via sub-
> pages in the user pages namespace?

That's really the responsibility of the feature implementers if/when
they get around to selecting the feature for implementation (either
as a Fx feature, or an extension that someone decides to write, or
whatever). Again, I don't see how this is different than what happens
now, other than at least there's a central place to build an index of
knowledge and links. Also, you're ignoring the possibility that an
interested party might create a single page to hold discussion of a
feature.

> I don't quite know what the correct way of doing this is - but does
> anyone else agree that there's a potential problem?

I agree that there are potential problems, yes. I disagree that we
should stop until we see those problems arise. I just browsed through
the history since Dria's initial posting (there are about 25-30
edits, 5 of which are yours) and right now I feel that signal *far*
outweighs noise, so let's keep going, but definitely keep our minds
open to evolving this.

Another thought: this document is just a flat list of features, some
of which -- most of which -- are at the level of bugs. The obvious
implication is that we should probably link them to bugs as well. The
less obvious implication is that it means people aren't getting
guidance on higher-level direction about what we feel that Firefox
"Future" should look like. Maybe this is one of the problems you're
referring to, Gerv. Do we think we should add some way of indicating
what project drivers believe is the right direction for areas like
"Browser Chrome" (ie: "minimal set of relevant features",
"unobtrusive UI", etc) to guide people's suggestions, or do we think
letting people as broadly generative as possible is more important?

cheers,
mike

Gervase Markham

unread,
Oct 13, 2006, 10:25:38 AM10/13/06
to
Mike Beltzner wrote:
> In most cases the addition will be marked in the wiki History. I don't
> see why that's hard. But perhaps we should add further instruction to
> the "How to use this page" explaining that for the purposes of tracking,
> people should insert rationale and details into the comment field when
> making changes, and should also ensure that they have a User page with
> contact details so we can get back in touch with them for clarification.

That makes good sense. What I'd really like is something like CVS blame,
but with the "lines" being bits of content rather than at a markup
level. But as you say, no-one's invented that yet, so we'll have to do
without.

> That's really the responsibility of the feature implementers if/when
> they get around to selecting the feature for implementation (either as a
> Fx feature, or an extension that someone decides to write, or whatever).
> Again, I don't see how this is different than what happens now, other
> than at least there's a central place to build an index of knowledge and
> links. Also, you're ignoring the possibility that an interested party
> might create a single page to hold discussion of a feature.

What would be really cool would be if each page had a feature, each
feature page had a summary reflecting the current view, and that summary
was auto-magically transferred into the main document. But, as you say,
no-one's invented...

> I agree that there are potential problems, yes. I disagree that we
> should stop until we see those problems arise. I just browsed through
> the history since Dria's initial posting (there are about 25-30 edits, 5
> of which are yours) and right now I feel that signal *far* outweighs
> noise, so let's keep going, but definitely keep our minds open to
> evolving this.

OK.

> Another thought: this document is just a flat list of features, some of
> which -- most of which -- are at the level of bugs. The obvious
> implication is that we should probably link them to bugs as well.

Agreed.

> The
> less obvious implication is that it means people aren't getting guidance
> on higher-level direction about what we feel that Firefox "Future"
> should look like. Maybe this is one of the problems you're referring to,
> Gerv.

Yes, I think so. It's certainly hard to take in a document that large
and understand the overall vision. That may, of course, be because there
isn't one yet. :-)

Developing that vision (or even, working out a mechanism where we can
develop it) seems like an even harder problem than just keeping a list
of potential features... On the one hand, it would be a shame if Firefox
3 were merely a collection of what each individual module owner wanted
to implement in the time; on the other hand, having an overall vision
may well imply that some module owners or hackers would need to be
persuaded to do something other than what they might choose given a free
hand... But I guess I'm not articulating a new problem here!

> Do we think we should add some way of indicating what project
> drivers believe is the right direction for areas like "Browser Chrome"
> (ie: "minimal set of relevant features", "unobtrusive UI", etc) to guide
> people's suggestions, or do we think letting people as broadly
> generative as possible is more important?

I certainly think the document should state who owns each area; once
we've done that, they may choose to outline their vision for going
forward above the specific list of features, so as to guide discussion.

Gerv

0 new messages