Removing features from bookmarks in Firefox
l.m. orchard
in Firefox. In order to maybe divert some of the discussion from the
bugs themselves to here, I'll start this thread as requested.
The bugs in question are these:
* bug 622051 - Remove support for microsummaries
* bug 622045 - Remove smart bookmarks support
* bug 622047 - Remove support for tagging bookmarks
* bug 624049 - Get rid of livemark support
I commented on most of them, but probably should have started by posting
here. I've also blogged about this:
http://decafbad.com/blog/2011/02/06/pay-phones-and-firefox-features
In a nutshell: I don't want to be a stop energy generator, but I think
some of these are important features. Okay, not microsummaries so much,
but maybe smart bookmarks and definitely tagging and livemarks. In fact,
dropping some of these will result in user data loss (eg. tags in
particular)
Again, not to make work for others, but: If we're dropping these from
core Firefox, it might help to have a transition plan for people who use
them. Could any or all of these be spun off into add-ons and possibly
adopted by motivated developers? That might be a better story than
simply getting rid of the features.
--
l.m.o...@pobox.com
http://decafbad.com
{web,mad,computer} scientist
Mike Beltzner
> Again, not to make work for others, but: If we're dropping these from core Firefox, it might help to have a transition plan for people who use them. Could any or all of these be spun off into add-ons and possibly adopted by motivated developers? That might be a better story than simply getting rid of the features.
Hi Len,
It's difficult to see what bugs have been filed because project leaders have had discussions elsewhere and are now putting plans on record, vs. those which have been filed to begin discussions. As a project leader on Firefox who hadn't heard of any of these proposals until this email, I can tell you that we are very much dealing with the latter of those cases at this point in time.
That's not to say "these won't happen," but rather to thank you for taking those discussions here, and to your blog. The analogy to phone booths is almost right (in that it highlights the cost of maintenance and upkeep, especially when things are broken) and a good framing. I have personal opinions and instincts here unfounded on data (microsummaries flopped despite my love for them, smart bookmarks should either be invested in or left to add-ons, tagging should stay and continue to be developed, we should either invest or divest from RSS) but first, I'd love to hear from the person who filed the bug about the rationale. Removing features is often virtuous, but we should - as you say - understand why we're doing it.
Let's all please try to keep this discussion focused on the costs and benefits, and look for real (not anecdotal) data where possible to support claims. Unfounded claims are welcome (indeed, that's how a lot of our product has been designed - by instinct) but please call those out when you're making them (as I did, above)
cheers,
mike
Shawn Wilsher
> Let's all please try to keep this discussion focused on the costs and benefits, and look for real (not anecdotal) data where possible to support claims. Unfounded claims are welcome (indeed, that's how a lot of our product has been designed - by instinct) but please call those out when you're making them (as I did, above)
for the Places team. All four of these features do a bunch of
synchronous disk I/O, which is something we are trying to move away
from. I can see it easily taking one to two months of work for one
person to rewrite each feature to be asynchronous, but we'd have to
create those asynchronous APIs first (probably two to three months worth
of work). Some of this work is parallelizable, but we are still looking
at six to eleven months of an engineer's time (and these estimates
aren't any good since I haven't done much work investigating
specifically what needs to be done; my gut tells me I'm probably missing
some important details and it will take longer).
Given that we only have two people (Marco and myself) really working on
Places code for anything other than random bug fixes, both of which have
responsibilities outside of Places code, this is an awful lot of
engineering resources to spend on updating this code. There are
certainly other performance improvements we need to make in Places code
too, which will compete for engineering resources.
With all that said, the Places team hasn't really discussed this yet
ourselves. This bug was filed by a member of the Sync team because
there was a cost of supporting these features with Sync. I'll let
Phillip comment on that.
Hope this helps!
Cheers,
Shawn
P.S. Before anybody asks, yes, we have to convert all these features to
use asynchronous APIs.
Marco Bonardo
> It's difficult to see what bugs have been filed because project leaders have had discussions elsewhere and are now putting plans on record, vs. those which have been filed to begin discussions.
Most of those bugs have not been filed after leaders discussions I
think, but it's still good to discuss the point of features removal if
there is a good rationale to do so.
Microsummaries bug is probably the most "near" to what was discussed,
the point about their removal is that Microsummaries as a standard,
really never took off. The cost to retain them is high in the sense that
the code is not that much maintained (low prio), the benefit is small
(percentage of websites and users using them) and it's a really big pile
of code (actually the biggest js component we have in Places, reaching
70KB).
If we're not going to remove the support we need at least to put their
code on a diet and only support a minimal feature (just read and save
them from pages).
Tags, livemarks and queries have different issues, where the
implementation is costly because:
- the database schema is hard to change (downgrade compatibility) and
causes complicate code
- the backend API is all sync and a perf killer
- rewrite features on top of changing APIs is time consuming
I don't feel like we should drop these features, a "reset" of their
implementation is probably needed though.
I think that, if those features are going to slow down or complicate the
process of modernizing (async) the underlying API and schema, it's even
possible we could ask to kill them for a release and reimplement them
better on the new API.
I such a case we should be prepared to the noise around those decisions
though, removing stuff promising to reintroduce it in future, is not
that different from just removing it from the user's point of view, he
won't have that feature for months.
Marco
Mike Shaver
> - the database schema is hard to change (downgrade compatibility) and causes
> complicate code
I think we should consider walking away from downgrade compatibility, tbh.
Mike
Philipp von Weitershausen
avoid having this discussion during the Firefox 4 end-game, so I
merely filed a few bugs. I would definitely have brought this up post
Firefox 4, but alas, people actually watch Bugzilla :)
These bugs were a classic case of rage-file while I was walking
through our bookmark sync code. It is brittle and probably buggy. It
will need a rewrite, if not for this then for the async I/O Shawn has
already mentioned. Shawn and I spent several man-months making history
sync do async I/O so he's got his estimates on what it would take for
bookmarks quite right IMHO.
A lot of people seem to care about tags, and I personally feel the
least strongly about removing those. However, it turns out the
database schema for tags is the most problematic one (sdwilsh and mak
may back me up or disagree with me here) and will probably require the
most engineering effort going forward. That said, if lots of people
care about tags, then we have even the more reason to fix this!
I haven't seen much pushback about microsummaries and smart
bookmarks/queries. I think the latter are a neat feature, but
something that I'm not sure we need to support in the bookmarking UI.
If add-ons want to use places queries to display the bookmark tree in
different ways, that'll be great. But given our drive to leaner UI,
they seem like a good candidate for a UI feature to drop (not to
mention that they're nearly impossible to create right now in the UI).
As for Livemarks, we just have to make a call about whether we want
Firefox to be an RSS reader (and a bad one at that) or not. I
personally think the web has solved this problem better and if we feel
like Mozilla needs to continue to be in this space, you know, we do
cloud services these days...
Philipp von Weitershausen
+1
I think we should consider having each major version of Firefox use a
different profile with an explicit upgrade step. That way, if users go
through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
sometimes do, their original profile won't be destroyed. We could even
trim no longer used data in various DBs, potentially solving some of
the slow startup problems users with ancient profiles are seeing.
Ideally such a step would be silent (as would the upgrade be),
although copying/converting a profile could be rather expensive.
Zack Weinberg
> I think we should consider having each major version of Firefox use a
> different profile with an explicit upgrade step. That way, if users go
> through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
> sometimes do, their original profile won't be destroyed.
I'd like to second this proposal wholeheartedly.
zw
Rob Campbell
On 2011-02-07, at 15:09 , Philipp von Weitershausen wrote:
> On Feb 7, 10:25 am, Mike Shaver <mike.sha...@gmail.com> wrote:
>> On Mon, Feb 7, 2011 at 10:10 AM, Marco Bonardo <ma...@supereva.it> wrote:
>>> - the database schema is hard to change (downgrade compatibility) and causes
>>> complicate code
>>
>> I think we should consider walking away from downgrade compatibility, tbh.
>
> +1
>
> I think we should consider having each major version of Firefox use a
> different profile with an explicit upgrade step. That way, if users go
> through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
> sometimes do, their original profile won't be destroyed. We could even
> trim no longer used data in various DBs, potentially solving some of
> the slow startup problems users with ancient profiles are seeing.
Not a bad idea. Plus, if the Places backup schema (json) remains compatible, users could restore from their "future" profile to the previous one and not lose any data, albeit, with a manual step to bridge the two profiles..
Speaking of cloud services, I'd love to have the ability to actually share my places bookmarks (tags and all).
PS, +1 to not killing tags, thx.
~ rob
Les Orchard
> I realize I should've come to this list first. I was mostly trying to
> avoid having this discussion during the Firefox 4 end-game, so I
> merely filed a few bugs. I would definitely have brought this up post
> Firefox 4, but alas, people actually watch Bugzilla :)
Hope I wasn't too much of a troublemaker there! (Sorry if I was!) I
started angst-commenting based on a "hey, I just started using that!"
knee-jerk.
> These bugs were a classic case of rage-file while I was walking
> through our bookmark sync code. It is brittle and probably buggy. It
> will need a rewrite, if not for this then for the async I/O Shawn has
> already mentioned. Shawn and I spent several man-months making history
> sync do async I/O so he's got his estimates on what it would take for
> bookmarks quite right IMHO.
That does indeed sound like hard enough work to do some reflection on
whether some features are worth the trouble.
I'm a noob to Firefox development - so it's probably best I stay out of
the kitchen - but I'm interested enough in some of these features to
help if I can.
> A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one (sdwilsh and mak
> may back me up or disagree with me here) and will probably require the
> most engineering effort going forward. That said, if lots of people
> care about tags, then we have even the more reason to fix this!
Tags are one of those things, I suspect, that may have a small audience
but are relied upon heavily by that group.
For me personally, folders are useless. I suspect that it's a matter of
scale. Once you get above a certain number of items, hand-maintained
hierarchical structures become less useful and search / on-the-fly
tagging becomes more handy.
I guess it comes down to "what are bookmarks"? Is the feature in Firefox
meant to be a small collection of often-visited sites? Or, is it the
basis for a personal search engine? I want the latter, but I admittedly
want weird things sometimes. :)
> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
Microsummaries did indeed seem neat when I first saw them years ago, but
have never revisited them since. Smart Bookmarks, I never knew about
until the last month or so. They seem keen, but maybe still in need of
baking.
> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).
As long as Places URI's still work, it seems like Smart Bookmarks would
be a good candidate to spin off as an addon. Then, if someone really
cares about smart bookmarks, better UI could be worked on there by
developers with time and interest.
> As for Livemarks, we just have to make a call about whether we want
> Firefox to be an RSS reader (and a bad one at that) or not. I
> personally think the web has solved this problem better and if we feel
> like Mozilla needs to continue to be in this space, you know, we do
> cloud services these days...
This is an area where I personally have more enthusiasm than answers, so
I can't say that Livemarks are a hill to die on. But, I do think we
should explore this space. It seems like we have had some interesting
experiments in Labs, and I'd like to play too.
FWIW, something I hadn't considered until bwinton pinged me today in IRC
is that this may more properly be Mozilla Messaging's bailiwick than
Firefox's. I haven't had the chance to play much with Raindrop, but
something in that genre may be a better answer than making Firefox into
a better RSS reader.
lsblakk
>
> PS, +1 to not killing tags, thx.
>
I tag my bookmarks, it helps me find things faster in the awesomebar.
Tagging + awesomebar = a lot of win for me.
my $0.02
Mike Beltzner
So far, over in the other thread or indeed in the bug itself, I have not yet heard a thoroughly compelling reason to *remove* tags. There are costs, to be sure, but it's generally acknowledged that the extensibility and usage patterns around tags warrant trying to solve those costs in other ways.
cheers,
mike
Hasse
8g2000prt.googlegroups.com>, Philipp von Weitershausen wrote...
> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).
Why do you continue to insist that they are nearly impossible to
create? Didn't you learn in https://bugzilla.mozilla.org/show_bug.cgi?
id=622045#c5 that it is as easy as doing a search and clicking on the
Save button?
--
Hasse
sv-SE l10n team
lsblakk
> So far, over in the other thread
Link please? I realize my input is not data-driven so I'm really just
asking out of curiosity and to see what happens
> or indeed in the bug itself,
I came over here because https://bugzilla.mozilla.org/show_bug.cgi?id=622047#c24
which said the bug was not the place to discuss.
> I have not yet heard a thoroughly compelling reason to *remove* tags. There are costs, to be sure, but it's generally acknowledged that the extensibility and usage patterns around tags warrant trying to solve those costs in other ways.
Thanks for this.
Philipp von Weitershausen
I apologize for my use of words. I didn't mean to say "impossible", I
meant to say "extremely difficult". So far I count two ways:
* drag a tag from the Tags folder to somewhere else (creates a smart
bookmark that queries that tag).
* save a search
I find both extremely undiscoverable. In fact, I didn't know about
them at all before I actually started asking people how the heck you
create a smart bookmark.
Marco Bonardo
> A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one (sdwilsh and mak
> may back me up or disagree with me here) and will probably require the
> most engineering effort going forward.
What requires the most engineering effort imo is the downgrade issue,
and that's globally an issue that hits a lot of modules. I second your
suggestion to solve this issue once and for all, through a profile
behavior review, it would also help solving the longstanding
"dirty-profiles" issue.
Making a revised tagging backend would not be that hard, sure, it would
require some time, but it's a pretty self contained feature and would
simplify a lot of the code that today has to figure out if a bookmark is
real or is a tag.
Most likely a good tagging UI would be harder to make.
> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
I agree the UI is not that great, and I could even agree we could want
to remove it and try to come with something better. The point is that
this won't save a thing, Places would still have to handle place:
queries internally, and Sync would still have to manage them.
the UI part is not a large cost for Places, originally we had a
truth-table-like UI to build complicated queries, we removed most of it
for its complexity and maintenance cost (plus it was never finished)
during the process that brought to Firefox 3. So yes, what we have today
is a cut-off UI feature, the less expensive part of it. Removing it
would be a no-brainer, but there is no clear win. Instead there was (and
I think the project is still valid) discussion to move the Library to
content (like it was done in about:addons) and then having a place: uri
that can represent a filtered content comes back to be useful.
> As for Livemarks, we just have to make a call about whether we want
> Firefox to be an RSS reader (and a bad one at that) or not. I
> personally think the web has solved this problem better and if we feel
> like Mozilla needs to continue to be in this space, you know, we do
> cloud services these days...
I feel like, now that we have lost the rss indicator, this is a hard
discussion to get right. Surely the button was not used that much, but
that's an hard indicator of RSS usage, I use them everyday, but I add
new ones rarely (probably once every 2 months). What Firefox has, is
enough for me, using an add-on could even be fine... for me.
The problem is that livemarks are today provided by most web pages and
browser is moving away from the concept of being just a html reader. In
some markets it's seen and used more like an entertainment system. As a
user of this system, I'd be surprised to being unable to access some
information in a format that most of the websites provide by default.
Even if we remove our crappy livemarks-as-folders support, we will have
to spend time to provide an alternative to give access to this resource.
Regarding the maintenance cost, livemarks have similar cost (and
solutions) of tags, with the subtle difference that we don't care about
safety of their contents (since we can always re-download them).
Globally, most of the features you feel unfinished ARE unfinished (in
the sense of far-from-perfect), due to re-prioritization of stuff they
mostly got low priority in the cycle and were built, adapted or cut to
work in the most common use-cases. They can be improved, this is not a
new fact to anyone.
Marco
Philipp von Weitershausen
> Let's all please try to keep this discussion focused on the costs and benefits, and look for real (not anecdotal) data where possible to support claims. Unfounded claims are welcome (indeed, that's how a lot of our product has been designed - by instinct) but please call those out when you're making them (as I did, above)
Filed a bug to get test pilot data for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=632153
Shawn Wilsher
> A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one (sdwilsh and mak
> may back me up or disagree with me here) and will probably require the
> most engineering effort going forward. That said, if lots of people
> care about tags, then we have even the more reason to fix this!
certainly something that needs to be fixed moving forward (working off
the assumption that we keep tags). It's one of the most painful
architecture issues we have left to tackle in Places, IMO. In fact, if
I could call do-over, this would be #2 on my list of things we should
change from the original Places architecture.
Cheers,
Shawn
Shawn Wilsher
> Globally, most of the features you feel unfinished ARE unfinished (in
> the sense of far-from-perfect), due to re-prioritization of stuff they
> mostly got low priority in the cycle and were built, adapted or cut to
> work in the most common use-cases. They can be improved, this is not a
> new fact to anyone.
enabled, the vast majority of the work that has been done has been
fixing architectural issues and some very minor polish of features (at
least that is the impression I've gotten while working on it over the
years). We simply do not have the engineering resources to do much of
anything else (and I don't foresee that changing within the next year).
With that said, if people want to step up and help out, I'm certain that
Marco, Dietrich, or myself would be happy to help by pointing out bugs
at a specified level of difficulty for you to work on, helping figure
out how to fix an issue, and providing prompt review so we can get
things fixed in Firefox 5.0 and beyond. Feel free to poke us on irc
(mak, dietrich, or sdwilsh) or send us mail directly.
Cheers,
Shawn
Shawn Wilsher
> How tags are stored in the database is pretty problematic, and it is
> certainly something that needs to be fixed moving forward (working off
> the assumption that we keep tags). It's one of the most painful
> architecture issues we have left to tackle in Places, IMO. In fact, if I
> could call do-over, this would be #2 on my list of things we should
> change from the original Places architecture.
not do synchronous disk I/O (ever).
Cheers,
Shawn
Dao
> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).
By default there's a "Most Visited" folder on the bookmarks toolbar. I
see random people use that every now and then.
That folder is going to be mostly undiscoverable with the bookmarks
toolbar being hidden by default, though...
Alex Faaborg
A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one
>
I've never really liked that we have both tags and folders, and that we felt
that the path of least resistance was to layer on greater levels of
complexity so as not to offend users of the existing system. Ideally we
would introduce a single grouping mechanism that had the properties of both
systems (ability to be nested in a hierarchy, pages can exist in multiple
places, either mouse or keyboard based input for associations). In terms of
fixing the database schema, that's of course orthogonal to if we want to
support two competing organization schemes in our UI.
As for Livemarks, we just have to make a call about whether we want
> Firefox to be an RSS reader (and a bad one at that) or not. I
> personally think the web has solved this problem better and if we feel
> like Mozilla needs to continue to be in this space
>
We might be introducing an ambient news feed in the Home Tab. Martell has a
really nice mockup here:
http://blog.seanmartell.com/wp-content/uploads/2009/04/newtab_1.jpg
That would effectively be the same use case as a Livemark (not the kind of
feed reader that behaves like an email client, and you read every message,
but just some glance-able information from your favorite sites.)
These bugs were a classic case of rage-file
>
Nice use of the phrase rage-file :)
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Axel Hecht
> Il 07/02/2011 20:08, Philipp von Weitershausen ha scritto:
One thing to keep in mind is that we shipped a live bookmark in default
profiles for ages. Ripping this out will not be as easy as just removing
code. Not rocket science either, too.
Axel
Axel Hecht
<...>
> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).
I'd like to comment on the microsummaries and rss piece, because I felt
that'd be interesting from an "implementors" side.
I did consider microsummaries for my variant of tbpl on the l10n
dashboard, kinda showing how builds for a landing progress.
The default timing is 15 mins IIRC, which was pretty much "neither fish
nor flesh". Not often enough to be up-to-date, and too often to not be a
hassle on the server for left-overs.
I did end up doing RSS feeds with a build status overview, though, check
out https://l10n-stage-sj.mozilla.org/builds/builds_for?change=70520 for
an example.
Axel
Alex Faaborg
> By default there's a "Most Visited" folder on the bookmarks toolbar. I
> see random people use that every now and then.
>
Also an extremely likely candidate for Home Tab placement, to still allow
for the same use case.
-Alex
Asa Dotzler
> On Feb 7, 10:25 am, Mike Shaver<mike.sha...@gmail.com> wrote:
>> On Mon, Feb 7, 2011 at 10:10 AM, Marco Bonardo<ma...@supereva.it> wrote:
>>> - the database schema is hard to change (downgrade compatibility) and causes
>>> complicate code
>>
>> I think we should consider walking away from downgrade compatibility, tbh.
>
> +1
>
> I think we should consider having each major version of Firefox use a
> different profile with an explicit upgrade step. That way, if users go
> through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
> sometimes do, their original profile won't be destroyed. We could even
> trim no longer used data in various DBs, potentially solving some of
> the slow startup problems users with ancient profiles are seeing.
That assumes we're supporting downgrades and I honestly don't know if
that's the right thing to do. We'll certainly have reconsider our
downgrade and older version support commitment if we move to doing
several releases a year.
- A
Michael Lefevre
Having data is probably a good thing, but I wonder how it might be used.
I don't think that simply looking at the percentage of users that use a
feature gives a complete assessment of the benefit.
In a year's time, will someone be coming along to find that not so many
users are using sync or panorama or app tabs or the web console and
propose dropping them?
I'm not suggesting it's happening yet or will happen, but going too far
in this direction would seem to lead to constantly implementing new
features, not polishing them enough, and then dropping them again, which
can't be good...
Michael
Shawn Wilsher
> In a year's time, will someone be coming along to find that not so many
> users are using sync or panorama or app tabs or the web console and
> propose dropping them?
to cost of maintenance. If the maintenance cost is low, and the usage
is low, I'm not sure we'd have a strong argument to cut a feature.
However, with some of these things, the cost is very high, so if it's
not being used, that's a data point that I would consider to be in favor
of dropping it. It certainly shouldn't be the only data point either.
Cheers,
Shawn
Asa Dotzler
I also think we do look at a couple of different audiences when working
out our features and so we'll evaluate based on the audience the feature
was designed for.
For example, I don't think it's reasonable to say "let's cut the Web
Console because only 2% of our general audience use it" when the feature
isn't designed to be used by a general audience.
Fortunately, we have ways within TestPilot to survey users and determine
which audience they come from. So, if we found that near zero percent of
our Web Developer audience were using a Web Developer features, then
we'd probably want to start talking about opportunity costs for the
Mozilla developer hours put into that feature.
- A
Boris Zbarsky
> That assumes we're supporting downgrades and I honestly don't know if
> that's the right thing to do. We'll certainly have reconsider our
> downgrade and older version support commitment if we move to doing
> several releases a year.
I feel like we really need to support downgrades to at least the version
before current, for people who install current and it breaks something
they rely on. What are they supposed to do? Not browse the web until
we fix it?
Downgrades past that point I'm not worried about.
-Boris
Mike Beltzner
continuing to support N-1 versions of the product once we've shipped
version N.
We do that now (in fact, we're planning on supporting 3.5 and 3.6 once
we ship 4.0!) but I don't think we can take that assumption for granted.
The only competitor of ours that continues to do that struggles mightily
for it and fragments their own user base.
cheers,
mike
Asa Dotzler
That's sort of what I was getting at. And the most effective competitor
at keeping all their users on the latest version doesn't support n-1 and
never has.
I think supporting older versions is a huge burden and something we
should seriously consider moving away from especially as we move to a
more frequent release cadence.
- A
Boris Zbarsky
> I think supporting older versions is a huge burden and something we
> should seriously consider moving away from especially as we move to a
> more frequent release cadence.
I think there's a difference, though, between "we no longer support
version N-1" and "if you ever try to run version N-1 after running
version N, it will corrupt your profile". The latter is where we are
now; for example the user "loses" places.sqlite in that situation (can
be recovered if you know the right magic, but it's not exactly obvious
magic).
iirc Chrome solves this by simply having version N-1 refuse to use the
profile if it detects that it's been upgraded to version N, but it's
been a bit since I tested this carefully.
Of course this does mean that if version N isn't working for some reason
you're screwed.
-Boris
Shawn Wilsher
> I think there's a difference, though, between "we no longer support
> version N-1" and "if you ever try to run version N-1 after running
> version N, it will corrupt your profile". The latter is where we are
> now; for example the user "loses" places.sqlite in that situation (can
> be recovered if you know the right magic, but it's not exactly obvious
> magic).
to go from 3.6 -> 4.0 -> 3.6 without corrupting their profile (I tested
this manually). We even have a test case in the tree that tests 4.0 ->
3.6 -> 4.0 [1] as well as one that tests 3.6 -> 4.0 [2]. There was a
time (during most of our beta phase) that going to back to 3.6 after 4.0
would cause this corruption (which I know you hit), but for most of our
users, that will never be a problem.
Cheers,
Shawn
[1]
https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10_migrated_from_v11.js
[2]
https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10.js
Alex Faaborg
that we decide that Sync servers will continue to have N-1 support), then we
could pretty effectively rely on that for downgrade. We wouldn't have to
worry about changes to the places schema, etc. and users will still have
access to all of their data (bookmarks, passwords, etc.) across both N and
N-1.
-Alex
On Mon, Feb 7, 2011 at 8:32 PM, Shawn Wilsher <sdw...@mozilla.com> wrote:
> On 2/7/2011 8:22 PM, Boris Zbarsky wrote:
>
>> I think there's a difference, though, between "we no longer support
>> version N-1" and "if you ever try to run version N-1 after running
>> version N, it will corrupt your profile". The latter is where we are
>> now; for example the user "loses" places.sqlite in that situation (can
>> be recovered if you know the right magic, but it's not exactly obvious
>> magic).
>>
> I don't believe we are in either case right now. Users should be able to
> go from 3.6 -> 4.0 -> 3.6 without corrupting their profile (I tested this
> manually). We even have a test case in the tree that tests 4.0 -> 3.6 ->
> 4.0 [1] as well as one that tests 3.6 -> 4.0 [2]. There was a time (during
> most of our beta phase) that going to back to 3.6 after 4.0 would cause this
> corruption (which I know you hit), but for most of our users, that will
> never be a problem.
>
> Cheers,
>
> Shawn
>
> [1]
> https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10_migrated_from_v11.js
> [2]
> https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10.js
>
>
Boris Zbarsky
> There was a
> time (during most of our beta phase) that going to back to 3.6 after 4.0
> would cause this corruption (which I know you hit), but for most of our
> users, that will never be a problem.
Ah, excellent. That makes me feel much better!
-Boris
Philip Chee
> In a nutshell: I don't want to be a stop energy generator, but I think
> some of these are important features. Okay, not microsummaries so much,
> but maybe smart bookmarks and definitely tagging and livemarks. In fact,
> dropping some of these will result in user data loss (eg. tags in
> particular)
We have SeaMonkey users reluctant to move from SM2.0 (bookmarks.html) to
the forthcoming SM2.1 (Places) due to perceived possible loss of
functionality. Tags were one of the features that we used to sell Places
bookmarks to them as a replacement workflow to what they were used to
with the bookmarks.html implementation.
> Again, not to make work for others, but: If we're dropping these from
> core Firefox, it might help to have a transition plan for people who use
> them. Could any or all of these be spun off into add-ons and possibly
> adopted by motivated developers? That might be a better story than
> simply getting rid of the features.
I hope that Firefox only removes the tagging UI as SeaMonkey would
certainly want to retain that as a selling point and a differentiator
to a less capable Firefox.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Philip Chee
> I've never really liked that we have both tags and folders, and that we felt
> that the path of least resistance was to layer on greater levels of
> complexity so as not to offend users of the existing system. Ideally we
> would introduce a single grouping mechanism that had the properties of both
> systems (ability to be nested in a hierarchy, pages can exist in multiple
> places, either mouse or keyboard based input for associations). In terms of
> fixing the database schema, that's of course orthogonal to if we want to
> support two competing organization schemes in our UI.
I notice in user groups there are people who think in terms of tags and
there are people who think in terms of folder hierarchy and these two
groups can never agree. I'd suspect that neither would be willing to
accept a compromise either.
Robert Kaiser
> I hope that Firefox only removes the tagging UI as SeaMonkey would
> certainly want to retain that as a selling point and a differentiator
> to a less capable Firefox.
SeaMonkey can't go and impose requirements on what Firefox developers
can do or not, so let's not get into that.
If this was to be removed, it would be nice if there was a possibility
for some consumer of the core code like SeaMonkey to implement it as an
extension of the core code - but then, this is all hypothetical and I
don't think that tags will be removed in the end anyhow.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
EE
> On 2/7/11 2:08 PM, Philipp von Weitershausen wrote:
>> I realize I should've come to this list first. I was mostly trying to
>> avoid having this discussion during the Firefox 4 end-game, so I
>> merely filed a few bugs. I would definitely have brought this up post
>> Firefox 4, but alas, people actually watch Bugzilla :)
>
> started angst-commenting based on a "hey, I just started using that!"
> knee-jerk.
>
>> These bugs were a classic case of rage-file while I was walking
>> through our bookmark sync code. It is brittle and probably buggy. It
>> will need a rewrite, if not for this then for the async I/O Shawn has
>> already mentioned. Shawn and I spent several man-months making history
>> sync do async I/O so he's got his estimates on what it would take for
>> bookmarks quite right IMHO.
>
> whether some features are worth the trouble.
>
> I'm a noob to Firefox development - so it's probably best I stay out of
> the kitchen - but I'm interested enough in some of these features to
> help if I can.
>
>> A lot of people seem to care about tags, and I personally feel the
>> least strongly about removing those. However, it turns out the
>> database schema for tags is the most problematic one (sdwilsh and mak
>> may back me up or disagree with me here) and will probably require the
>> most engineering effort going forward. That said, if lots of people
>> care about tags, then we have even the more reason to fix this!
>
> but are relied upon heavily by that group.
>
> For me personally, folders are useless. I suspect that it's a matter of
> scale. Once you get above a certain number of items, hand-maintained
> hierarchical structures become less useful and search / on-the-fly
> tagging becomes more handy.
>
> I guess it comes down to "what are bookmarks"? Is the feature in Firefox
> meant to be a small collection of often-visited sites? Or, is it the
> basis for a personal search engine? I want the latter, but I admittedly
> want weird things sometimes. :)
>
>> I haven't seen much pushback about microsummaries and smart
>> bookmarks/queries. I think the latter are a neat feature, but
>> something that I'm not sure we need to support in the bookmarking UI.
>
> have never revisited them since. Smart Bookmarks, I never knew about
> until the last month or so. They seem keen, but maybe still in need of
> baking.
>
>> If add-ons want to use places queries to display the bookmark tree in
>> different ways, that'll be great. But given our drive to leaner UI,
>> they seem like a good candidate for a UI feature to drop (not to
>> mention that they're nearly impossible to create right now in the UI).
>
> be a good candidate to spin off as an addon. Then, if someone really
> cares about smart bookmarks, better UI could be worked on there by
> developers with time and interest.
>
>> As for Livemarks, we just have to make a call about whether we want
>> Firefox to be an RSS reader (and a bad one at that) or not. I
>> personally think the web has solved this problem better and if we feel
>> like Mozilla needs to continue to be in this space, you know, we do
>> cloud services these days...
>
> I can't say that Livemarks are a hill to die on. But, I do think we
> should explore this space. It seems like we have had some interesting
> experiments in Labs, and I'd like to play too.
>
> FWIW, something I hadn't considered until bwinton pinged me today in IRC
> is that this may more properly be Mozilla Messaging's bailiwick than
> Firefox's. I haven't had the chance to play much with Raindrop, but
> something in that genre may be a better answer than making Firefox into
> a better RSS reader.
>
While you are at it, why not remove "Unsorted Bookmarks"? I never could
see any point to that folder. I want to put bookmarks into the proper
category immediately, not into some temporary storage.
Asa Dotzler
> Philip Chee schrieb:
>> I hope that Firefox only removes the tagging UI as SeaMonkey would
>> certainly want to retain that as a selling point and a differentiator
>> to a less capable Firefox.
>
> SeaMonkey can't go and impose requirements on what Firefox developers
> can do or not, so let's not get into that.
> If this was to be removed, it would be nice if there was a possibility
> for some consumer of the core code like SeaMonkey to implement it as an
> extension of the core code - but then, this is all hypothetical and I
> don't think that tags will be removed in the end anyhow.
>
> Robert Kaiser
It's the core code that's being considered for removal.
- A
Dao
All of Places?
Asa Dotzler
No. That's silly.
The discussion was about Places support for microsummaries, smart
bookmarks, tagging, and livemarks. There's non-trivial Places-level,
(core code) work that is required if these features are going to live
on. See Shawn's comment estimating 6 to 11 months worth of work just to
get them onto async IO.
- A
Dao
> On 2/8/2011 12:27 PM, Dao wrote:
>> On 08.02.2011 21:12, Asa Dotzler wrote:
>>> On 2/8/2011 8:39 AM, Robert Kaiser wrote:
>>>> If this was to be removed, it would be nice if there was a possibility
>>>> for some consumer of the core code like SeaMonkey to implement it as an
>>>> extension of the core code - but then, this is all hypothetical and I
>>>> don't think that tags will be removed in the end anyhow.
>>>>
>>>> Robert Kaiser
>>>
>>> It's the core code that's being considered for removal.
>>
>> All of Places?
>
> No. That's silly.
I know. Places is the core code that Robert was hoping to extend in case
tagging wouldn't be part of it anymore.
Asa Dotzler
I hadn't realized that Robert was signing up for the months worth of
work in Places code to keep those features alive. Nothing he or Philip
said suggested they wanted to take over support of core places code to
support their front-end features.
- A
Dao
Quite right. If extending Places is an option, they can just do that
without signing up for something. It's their core extension backing
their front-end then.
Shawn Wilsher
> On 2/8/2011 12:55 PM, Dao wrote:
>> I know. Places is the core code that Robert was hoping to extend in case
>> tagging wouldn't be part of it anymore.
>
> I hadn't realized that Robert was signing up for the months worth of
> work in Places code to keep those features alive. Nothing he or Philip
> said suggested they wanted to take over support of core places code to
> support their front-end features.
referring specifically to the tagging code in Robert's post ("If this
was to be removed"), whereas Dao appears to be referring to the core
code ("implement it as an extension of the core code") which doesn't
include the tagging back end.
To answer Robert's concern, yes, someone could still do tags if we
decided to drop that feature (they would have a few options to do so too).
Cheers,
Shawn
Philip Chee
> While you are at it, why not remove "Unsorted Bookmarks"? I never could
> see any point to that folder. I want to put bookmarks into the proper
> category immediately, not into some temporary storage.
I think this is useful for those people who don't think hierarchically
and don't use folders but use tags instead.
Also I don't think unsorted bookmarks causes much if any performance
hit, probably less as the SQL query doesn't have to sort or filter
anything at all.
Ron Hunter
> On Tue, 08 Feb 2011 13:01:39 -0700, EE wrote:
>
>> While you are at it, why not remove "Unsorted Bookmarks"? I never could
>> see any point to that folder. I want to put bookmarks into the proper
>> category immediately, not into some temporary storage.
>
> I think this is useful for those people who don't think hierarchically
> and don't use folders but use tags instead.
>
> Also I don't think unsorted bookmarks causes much if any performance
> hit, probably less as the SQL query doesn't have to sort or filter
> anything at all.
>
> Phil
>
innocuous, and is the first thing I delete when making a new bookmarks
toolbar.
Robert Kaiser
> I hadn't realized that Robert was signing up for the months worth of
> work in Places code to keep those features alive. Nothing he or Philip
> said suggested they wanted to take over support of core places code to
> support their front-end features.
I wouldn't sign up for any such SeaMonkey work, I guess. Still, I just
said that Philip should have asked if there was a way to morph it into a
SeaMonkey-only extension to the core if it was removed instead of
implying that core needs to keep it for that project's sake.
In any case, this is all moot until there are real plans to actually
remove tagging permanently, and I don't that day will actually come (the
outrage among Firefox users would be way worse than any few SeaMonkey
people complaining).
EE
> On Tue, 08 Feb 2011 13:01:39 -0700, EE wrote:
>
>> While you are at it, why not remove "Unsorted Bookmarks"? I never could
>> see any point to that folder. I want to put bookmarks into the proper
>> category immediately, not into some temporary storage.
>
> I think this is useful for those people who don't think hierarchically
> and don't use folders but use tags instead.
>
> Also I don't think unsorted bookmarks causes much if any performance
> hit, probably less as the SQL query doesn't have to sort or filter
> anything at all.
>
> Phil
>
clutter.
EE
It is not possible to delete it from the bookmarks organizer window.
Ron Hunter
bothering me for ever.