Add-ons Manager: Should extensions and plugins be combined into one list?
Blair McBride
Add-ons Manager[1], a couple of people asked why we couldn't combine
extensions and plugins into just one list.
Doing so could remove a lot of confusion over what is really just a
technical detail: What's the difference between a plugin and an
extension? Does the difference matter?
I can't think of any good reason not to do this, other than "they've
always been separate". Code-wise, this would be a pretty simple thing to do.
So I'd be great to get people's opinions on this: Is there a reason to
keep extensions and plugins separate?
- Blair
[1]
http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/4bb11dd1118b37ab
Alex Faaborg
while extensions (usually) modify chrome. I'm all for putting them into one
unified list to reduce the number of items on the left side navigation. I
would imagine that some users will want to be able to sort the list by type
however, and we might want to default to a sort by name and then by type.
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
flod
> While discussing the wording of "extensions" and "plugins" in the
> Add-ons Manager[1], a couple of people asked why we couldn't combine
> extensions and plugins into just one list.
Honestly I don't like this idea:
* I use few extensions but I have to bear with a bunch of plugins,
some of them I'm not even aware of having installed. Some people don't
use extensions at all, probably because they don't know what they are.
The result would be a confusing list for a lot of people.
* I don't remember the last time I checked the "plugin" section of the
Add-ons manager. The only reasons I see to open the plugin tab is to
check the current version of a plugin or disable it if I'm having
problems. If the plugin-checker website start to spread (or the checks
in the start page begin to cover more plugins than Flash player), the
number of visit to that section would decrease even more.
Francesco
Rimas Kudelis
> While discussing the wording of "extensions" and "plugins" in the
> Add-ons Manager[1], a couple of people asked why we couldn't combine
> extensions and plugins into just one list.
>
> Doing so could remove a lot of confusion over what is really just a
> technical detail: What's the difference between a plugin and an
> extension? Does the difference matter?
>
> I can't think of any good reason not to do this, other than "they've
> always been separate". Code-wise, this would be a pretty simple thing to
> do.
>
> So I'd be great to get people's opinions on this: Is there a reason to
> keep extensions and plugins separate?
Reposting what I said there:
>>
well, we translated add-ons, extensions and plugins into three different
words for Lithuanian. However, I personally think that even if I
shuffled those words, nothing would change because essentially their
meanings are really close to each other. In my opinion, this distinction
between plugins and extensions is really technical and quite vague.
Don't we have extensions that ship with binary files? We do! (Lightning)
Don't we have extensions that add new "content type" support? We do!
(WML) And now we actually have two new add-on categories: Personas and
Jetpacks, but for some reason we don't try to make distinction between
them and Themes/Extensions respectively.
IMHO, we should really consider merging lists of extensions and plug-ins
into one list, and just drop the distinction. In fact, I don't think
non-technical users know what that distinction is, and I don't really
see a point in introducing it to them.
<<
Having said and re-read all that, I know that the underlying
technologies are really different. However, I still can't see anything
BUT technology being different between extensions and plug-ins. Both
types of add-ons can be (and are being) installed by third parties,
often without even asking, both can have binary libraries, both can add
support for new content types. Even their current icons (lego piece vs.
puzzle piece) convey very similar meanings. And functionality-wise,
Firebug Extension adds much more value to my Firefox than Java Plug-in.
Rimas
Chris Ilias
> So I'd be great to get people's opinions on this: Is there a reason to
> keep extensions and plugins separate?
I think that in the end it would be nice for the UI not to differentiate
between the two, but I'm sure there is a list of things to do to make
sure the UX doesn't differentiate them first.
* Safe Mode does not yet disable plugins. That's
https://bugzilla.mozilla.org/show_bug.cgi?id=342333
* Can extensions be put in a separate exe? (Yes, I know not all plugins
are separate right now)
Can't think of any others right now.
sabret00the
install and have little control over. Extensions are about making my
life better/easier. If someone really wanted the list combined, then
the best move would be to install an extension to do so. If that
extension then got masses of downloads, it'd then be worth having this
discussion. At this time however, it's best to keep them separate and
for any users that don't get the difference between the two, then
perhaps we should investigate how to better educate them rather than
penalising more educated users.
> [1]http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/...
Matrus
One possible problem could be that extensions can be installed,
updated, and more importantly, uninstalled from within Firefox. This
is not possible for plug-ins which can right now only be deactivated.
Wouldn't this seemingly random difference in behaviour be confusing to
the user who is not aware of the difference between extensions and
plug-ins?
Soufian Jaouani
Agreed. That's my objection too. As long as we can't fully "remove"
plugins, they're not the same as regular extensions.
Rimas Kudelis
Not all extensions can be removed. For example, I have an extension
called "PC Sync 2 Synchronization Extention" which I can only disable,
just like a plugin. That's because it's installed by Nokia's installer
into some system-wide location.
Similarly, extensions installed system-wide on Linux can only be
disabled from within Firefox, but not uninstalled.
Rimas
Dao
the plugins list, e.g. "The plugin for this content has been disabled.
Click here to manage your plugins." This could be rephrased, but getting
a list of all kinds of add-ons when clicking that message seems
inconvenient nevertheless.
Generally, for users who do understand the difference it doesn't seem
like a mixed list is ever going to be beneficial. At least I can't think
of a case. When I open about:addons it's because I want to do something
about a theme OR an extension OR a plugin. The current separation makes
sense to me.
Michael Kohler
Sincerely,
Michael Kohler
Shawn Wilsher
> I'm not sure users understand the distinction, but plugins modify content
> while extensions (usually) modify chrome. I'm all for putting them into one
> unified list to reduce the number of items on the left side navigation. I
> would imagine that some users will want to be able to sort the list by type
> however, and we might want to default to a sort by name and then by type.
Cheers,
Shawn
Dao
Well, "modify content" wasn't quite the right description for plugins.
They enable certain content types.
EE
confusion than there already is. Plugins are like applications without
interfaces, and are called upon when needed (and the calling application
supplies the interface), but are not in use when not needed. Extensions
make themselves part of the application and are therefore always in use.
Benjamin Smedberg
> They are not the same thing. Putting them together would create more
> confusion than there already is. Plugins are like applications without
> interfaces, and are called upon when needed (and the calling application
> supplies the interface), but are not in use when not needed. Extensions
> make themselves part of the application and are therefore always in use.
That's not true either. All plugins are loaded the first time we encounter
an unknown content type, and can run arbitrary code at that time. And
extensions can perform certain tasks only on request, and not run until they
are needed.
Really, binary plugins and jetpacks and XUL are all different technical
means of accomplishing something the users wants, and I think they should be
grouped together.
--BDS
Alex Faaborg
> * I use few extensions but I have to bear with a bunch of plugins,
> some of them I'm not even aware of having installed.
>
Soufian Jaouani:
> Plugins are things I'm generally made to
> install and have little control over. Extensions are about making my
> life better/easier.
>
I view this as a really significant problem, if we were to create a single
list, that list should consist of things the user both wants, and has direct
control over. It seems like there a few different issues:
-even users who actively manage extensions don't seem to actively control
their plugin list (in terms of disabling)
-even if they wanted to take more control over their plugins, they can't
(impossible to remove)
-these plugins have performance and security implications for Firefox
(although thankfully no longer stability implications)
Are we making the correct distinction between "disable" and "remove." Even
if we can't delete the file on the disk, we can make sure it isn't active
anymore, and isn't displayed in our UI. From the user's perspective, that
is basically removing something from Firefox.
This is slightly off topic, but here's a quick way to visualize our add-on
landscape. I get the impression that plugins are nearly always in the
orange or red boxes: http://newdefault.tumblr.com/post/804343648
-Alex
On Tue, Jul 20, 2010 at 12:14 PM, Benjamin Smedberg
<benj...@smedbergs.us>wrote:
Benjamin Smedberg
> I view this as a really significant problem, if we were to create a single
> list, that list should consist of things the user both wants, and has direct
> control over. It seems like there a few different issues:
Where does that leave the things the users doesn't want (or doesn't know
whether they want), but are currently enabled?
We do have a presentation problem with some plugins, because the user
doesn't know they want Flash until they discover that hulu and youtube don't
work.
> This is slightly off topic, but here's a quick way to visualize our add-on
> landscape. I get the impression that plugins are nearly always in the
> orange or red boxes: http://newdefault.tumblr.com/post/804343648
I'm not sure I agree with some of the elements of this chart. Just because a
user did not directly install an add-on doesn't mean that its presence is
"bad", as represented by orange and red on the chart. In fact, we have tried
to make it easy for systems to pre-install addons via the registry.
Obviously there is tension there, but if the user installs Acrobat and
Firefox, we should generally presume that they want Acrobat/Firefox
integration (which currently takes the form of a binary plugin, but could
just as easily take the form of a Firefox extension).
99% of users who doen't know about add-ons want Flash player.
--BDS
Michael Lefevre
...
> -even users who actively manage extensions don't seem to actively control
> their plugin list (in terms of disabling)
> -even if they wanted to take more control over their plugins, they can't
> (impossible to remove)
> Are we making the correct distinction between "disable" and "remove." Even
> if we can't delete the file on the disk, we can make sure it isn't active
> anymore, and isn't displayed in our UI. From the user's perspective, that
> is basically removing something from Firefox.
In my experience as on of the few who does actively control plugins, I'm
afraid there are more issues with this. Being disabled and being
removed isn't the from the user's perspective - in either case, websites
may tell you that you need to install a plugin. If the plugin is
installed and disabled, then what you actually need to do is enable it
within Firefox.
I guess most users also wouldn't have a clue which plugins they actually
want and which they don't. Presenting a big combined list including
plugins with indecipherable names might just scare them away from the
add-ons manager, rather than inspiring them to try and work out what
everything is and disable/remove the ones they don't want.
As pointed out already, there are some extensions which are installed
outside Firefox and cannot be removed. Maybe the distinction should be
"stuff that user installed within Firefox and can remove" vs "stuff
installed outside Firefox that the user can't remove", instead of addons
and plugins?
I think that at least the UI shouldn't try to gloss over technical
issues, if the technical issues actually have an impact on the user.
Michael
Zack Weinberg
It seems like chipping away at the _need_ for NPAPI plugins might be
the way to improve the user experience here. Is there anything
stopping an XPI-bundled, JS-coded, (ideally) Jetpack-API extension
from implementing the _functionality_ of a plugin (that is, drawing the
contents of an <embed> or <object>)?
Conversely, could we make it possible for binary NPAPI plugins to be
_distributed_ as XPIs and for their installation to be managed in the
same way that we manage extensions?
zw
Rimas Kudelis
NPAPI is currently supported by all popular browsers but IE (and on all
platforms). Why would we drop it?
Conversely, XPI is ONLY used by Firefox and SeaMonkey. Why enforce it on
others?
No, I don't think it's a good idea...
Rimas
Rimas Kudelis
Rimas Kudelis
<..>
> As pointed out already, there are some extensions which are installed
> outside Firefox and cannot be removed. Maybe the distinction should be
> "stuff that user installed within Firefox and can remove" vs "stuff
> installed outside Firefox that the user can't remove", instead of addons
> and plugins?
This does make sense. I would still consider showing all those add-ons
in one list though, but perhaps think about ways to explain the user why
certain add-on cannot be removed (which is basically always because it's
installed system-wise).
Rimas
Benjamin Smedberg
> It seems like chipping away at the _need_ for NPAPI plugins might be
> the way to improve the user experience here. Is there anything
> stopping an XPI-bundled, JS-coded, (ideally) Jetpack-API extension
> from implementing the _functionality_ of a plugin (that is, drawing the
> contents of an<embed> or<object>)?
It cannot currently be implemented (at least I don't know how), but I filed
a bug about it, see bug 558184.
> Conversely, could we make it possible for binary NPAPI plugins to be
> _distributed_ as XPIs and for their installation to be managed in the
> same way that we manage extensions?
They can already, but that isn't the recommended method: we have recommended
for years that plugin authors ship their plugins via an installer and
registry entries (all NPAPI browsers share the install method). What's wrong
with this method?
--BDS
Zack Weinberg
> On 7/20/10 6:15 PM, Zack Weinberg wrote:
>
> > It seems like chipping away at the _need_ for NPAPI plugins might be
> > the way to improve the user experience here. Is there anything
> > stopping an XPI-bundled, JS-coded, (ideally) Jetpack-API extension
> > from implementing the _functionality_ of a plugin (that is, drawing
> > the contents of an<embed> or<object>)?
>
> It cannot currently be implemented (at least I don't know how), but I
> filed a bug about it, see bug 558184.
Cool beans.
> > Conversely, could we make it possible for binary NPAPI plugins to be
> > _distributed_ as XPIs and for their installation to be managed in
> > the same way that we manage extensions?
>
> They can already, but that isn't the recommended method: we have
> recommended for years that plugin authors ship their plugins via an
> installer and registry entries (all NPAPI browsers share the install
> method). What's wrong with this method?
It causes precisely the problem being discussed here, i.e. the add-ons
manager cannot manage plugins because they are installed outside of
its bailiwick. Also, it only works on uninteresting legacy platforms
(I'm only half joking here).
zw
Chris Ilias
> Just one question: Will Safe Mode still disable just the extensions? If so, it could be a little bit confusing to see the list whilst in Safe Mode.
Yeah, I mentioned that in an earlier reply. Here's the bug to make safe
mode disable plugins: https://bugzilla.mozilla.org/show_bug.cgi?id=342333
Benjamin Smedberg
> It causes precisely the problem being discussed here, i.e. the add-ons
> manager cannot manage plugins because they are installed outside of
> its bailiwick. Also, it only works on uninteresting legacy platforms
> (I'm only half joking here).
The addons manager *does* manage plugins, at least in the context of
Firefox. You can choose to have them enabled or disabled.
Are you trying to solve the case that users cannot uninstall Flash from
within Firefox? Or solve the *perception* that the user cannot control Flash
from inside Firefox? I fully support making it easier to disable+hide a
plugin if the user is sure that they don't want to think about that decision
any more. That's roughly the equivalent of uninstalling, from the user
perspective.
--BDS
Ron Hunter
I believe in keeping the user AWARE of any changes that ANY program is
making to his setup. When a new add-on, be it extension, or plug-in, is
detected, then the user should be notified, and a choice of uninstall,
diable, or approve offered. I really HATE these 'stealth installs' that
so many companies are adding to their downloads. While I may choose to
approve most of these add-ons, I believe I should be the one to make
this decision, not Microsoft, HP, or Google.
Zack Weinberg
> On 7/20/10 7:23 PM, Zack Weinberg wrote:
>
> > It causes precisely the problem being discussed here, i.e. the
> > add-ons manager cannot manage plugins because they are installed
> > outside of its bailiwick. Also, it only works on uninteresting
> > legacy platforms (I'm only half joking here).
>
> The addons manager *does* manage plugins, at least in the context of
> Firefox. You can choose to have them enabled or disabled.
>
> Are you trying to solve the case that users cannot uninstall Flash
> from within Firefox?
Just so.
We seem to be pretending to be an OS these days, we may as well be
good at it.
zw
Robert Strong
> Benjamin Smedberg<benj...@smedbergs.us> wrote:
>
>> On 7/20/10 7:23 PM, Zack Weinberg wrote:
>>
>>> It causes precisely the problem being discussed here, i.e. the
>>> add-ons manager cannot manage plugins because they are installed
>>> outside of its bailiwick. Also, it only works on uninteresting
>>> legacy platforms (I'm only half joking here).
>> The addons manager *does* manage plugins, at least in the context of
>> Firefox. You can choose to have them enabled or disabled.
>>
>> Are you trying to solve the case that users cannot uninstall Flash
>> from within Firefox?
>
> We seem to be pretending to be an OS these days, we may as well be
> good at it.
other than the things we own and to do so is overstepping a boundary
which invites other apps to treat us in the same manner. At best I could
see us launching the OS provided UI that provides the ability to
uninstall other applications that include plugins or uninstalling it as
far as Firefox is concerned which would be hiding / ignoring the plugin
or any other add-on as Benjamin suggested.
Robert
Zack Weinberg
> >> Are you trying to solve the case that users cannot uninstall Flash
> >> from within Firefox?
>
> We don't manage things on an OS (e.g. one of the tasks of being an
> OS) other than the things we own and to do so is overstepping a
> boundary which invites other apps to treat us in the same manner. At
> best I could see us launching the OS provided UI that provides the
> ability to uninstall other applications that include plugins or
> uninstalling it as far as Firefox is concerned which would be
> hiding / ignoring the plugin or any other add-on as Benjamin
> suggested.
This is why the original suggestion was to install plugins like other
extensions for Firefox, bringing them within the set of things
that we legitimately manage.
zw
Robert Strong
> Robert Strong<rst...@mozilla.com> wrote:
>>>> Are you trying to solve the case that users cannot uninstall Flash
>>>> from within Firefox?
>> We don't manage things on an OS (e.g. one of the tasks of being an
>> OS) other than the things we own and to do so is overstepping a
>> boundary which invites other apps to treat us in the same manner. At
>> best I could see us launching the OS provided UI that provides the
>> ability to uninstall other applications that include plugins or
>> uninstalling it as far as Firefox is concerned which would be
>> hiding / ignoring the plugin or any other add-on as Benjamin
>> suggested.
> This is why the original suggestion was to install plugins like other
> extensions for Firefox, bringing them within the set of things
> that we legitimately manage.
supported by add-ons but I personally don't see it as pretending to be
anything like an OS but that's off topic. Most vendors rightfully IMO
want to install one time for all apps on a system and I really don't
think this will become a preferred method for vendors installing plugins
that support multiple applications. The hide plugin would be the
equivalent of uninstall as far as Firefox is concerned and could be done
somewhat reasonably.
Robert
Dao
> The addons manager *does* manage plugins, at least in the context of
> Firefox. You can choose to have them enabled or disabled.
>
> Are you trying to solve the case that users cannot uninstall Flash from
> within Firefox? Or solve the *perception* that the user cannot control
> Flash from inside Firefox? I fully support making it easier to
> disable+hide a plugin if the user is sure that they don't want to think
> about that decision any more. That's roughly the equivalent of
> uninstalling, from the user perspective.
What if the user changes his mind, though? Installed extensions can be
re-installed. How would this work for installed but ignored/hidden plugins?
Rimas Kudelis
here's an idea:
We could hide all disabled add-ons from their respective lists, but have
a checkbox at a top to Show disabled add-ons. Disabled flash, disabled
extensions and anything else would then be unhidden and could be enabled
back provided no compatibility problems would arise.
This would be somewhat similar to "Show updates" in Windows XP's
Add/Remove Programs dialog.
However, bug 342333 (disable plug-ins in safe mode) should be solved
before merging the lists.
Rimas
Peter Lairo
(like this one)
My suspicion is that even the developers (and inexplicably, the
Thunderbird developers) are not using the Mozilla Thunderbird newsreader
when posting to our newsgroups. I really don't understand it. IMO
newsreaders (and particularly Mozilla Thunderbird) are far superior to
web-based news-forums and mailing lists in most ways (one of which is
functioning threading).
PS. Sorry for the ranty post, but al lthese broken threads everywhere
are "bugging" me.
FU to mozilla.dev.apps.firefox (for continuity)
On Tue. 20.07.2010 4:05, Alex Faaborg wrote:
> I'm not sure users understand the distinction, but plugins modify content
>
> On Mon, Jul 19, 2010 at 6:58 PM, Blair McBride<bmcb...@mozilla.com> wrote:
>> While discussing the wording of "extensions" and "plugins" in the Add-ons
--
Regards,
Peter Lairo
Bugs I think are important:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444
Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis
Rimas Kudelis
> Why are so many posts in the Mozilla newsgroups not threaded properly?
> (like this one)
Well, you answered it yourself: It's because some prefer mailing lists
to newsgroups, and post their replies that way.
The mail-news gateway could be smarter about it, of course...
Rimas
Mike Shaver
> What if the user changes his mind, though? Installed extensions can be
> re-installed. How would this work for installed but ignored/hidden plugins?
I think that plugins and add-ons installed on the system should be
shown as available-for-install, probably via the "get add-ons" page.
Conceptually they're installing, to match the "hidden = uninstalled"
model for things we don't actually remove from the filesystem.
I think I proposed this in an earlier thread about handling
system-installed add-ons, but apparently I didn't file a bug for it.
Or maybe I just can't find such a bug?
Mike
Wayne Mery
I think you'll find in many cases it happens when posters are using a
gatewayed mailing list. In the case of news.mozilla.org it's mailman -
and it doesn't provide the header fields needed make threading correct.
And it's annoying.
http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/196084655b3f2122
has some info
I'm not sure this covers all the issues that need to be fixed ...
http://www.gnu.org/software/mailman/todo.html
"Add a moderation option to pass through any message which is a reply to
a message previously distributed through the list, even if it comes from
a non-member. Treat that non-member as a member for the duration of the
thread. Use In-Reply-To, References and Message-ID to match these up."
On 7/21/2010 7:05 AM, Peter Lairo wrote:
> Why are so many posts in the Mozilla newsgroups not threaded properly?
> (like this one)
>
> My suspicion is that even the developers (and inexplicably, the
> Thunderbird developers) are not using the Mozilla Thunderbird newsreader
> when posting to our newsgroups. I really don't understand it. IMO
> newsreaders (and particularly Mozilla Thunderbird) are far superior to
> web-based news-forums and mailing lists in most ways (one of which is
> functioning threading).
>
> PS. Sorry for the ranty post, but al lthese broken threads everywhere
> are "bugging" me.
>
> FU to mozilla.dev.apps.firefox (for continuity)
>
>
> On Tue. 20.07.2010 4:05, Alex Faaborg wrote:
>> I'm not sure users understand the distinction, but plugins modify content
>>
>> On Mon, Jul 19, 2010 at 6:58 PM, Blair McBride<bmcb...@mozilla.com>
>> wrote:
>>> While discussing the wording of "extensions" and "plugins" in the
>>> Add-ons
--
http://wiki.mozilla.org/Thunderbird:Testing
http://www.spreadthunderbird.com/aff/165/
Alex Faaborg
> Where does that leave the things the users doesn't want (or doesn't know
> whether they want), but are currently enabled?
>
> We do have a presentation problem with some plugins, because the user
> doesn't know they want Flash until they discover that hulu and youtube don't
> work.
>
In these cases the user is prompted to install Flash to access the content,
and if they do so I would count that as the green box (the user
intentionally did something that they wanted to do). It's of course kind of
blurry, they might have just been following instructions or clicking the
whatever button until their video played, but either way that's a different
situation than things like the eBay browser highlighter that was deployed
with Skype installs.
-Alex
Stanimir Stamenkov
> Why are so many posts in the Mozilla newsgroups not threaded properly?
> (like this one)
Because messages sent through the mailing list interface get
different Message-ID when landing in the newsgroup (or something
like that).
> My suspicion is that even the developers (and inexplicably, the
> Thunderbird developers) are not using the Mozilla Thunderbird newsreader
> when posting to our newsgroups. I really don't understand it. IMO
> newsreaders (and particularly Mozilla Thunderbird) are far superior to
> web-based news-forums and mailing lists in most ways (one of which is
> functioning threading).
>
> PS. Sorry for the ranty post, but al lthese broken threads everywhere
> are "bugging" me.
>
> FU to mozilla.dev.apps.firefox (for continuity)
--
Stanimir
Jens Müller
> Wed, 21 Jul 2010 13:05:26 +0200, /Peter Lairo/:
>
>> > Why are so many posts in the Mozilla newsgroups not threaded properly?
>> > (like this one)
> Because messages sent through the mailing list interface get
> different Message-ID when landing in the newsgroup (or something
> like that).
>
The solution would probably not to use Mailman's own NNTP<->SMTP gateway
functionality, but something separate.
Mike Easter
> Why are so many posts in the Mozilla newsgroups not threaded properly?
> (like this one)
>
> My suspicion is that even the developers (and inexplicably, the
> Thunderbird developers) are not using the Mozilla Thunderbird newsreader
> when posting to our newsgroups. I really don't understand it. IMO
> newsreaders (and particularly Mozilla Thunderbird) are far superior to
> web-based news-forums and mailing lists in most ways (one of which is
> functioning threading).
>
> PS. Sorry for the ranty post, but al lthese broken threads everywhere
> are "bugging" me.
Reading newsgroups with a threaded view is not the only way to do it.
Personally I almost never configure my newsreader to sort threaded -
perhaps you should learn how to do it another way so that when you are
in a group which has 'disruption' in the References line it won't
disturb you so much.
Most - almost all - 'threads' have the same subject, except when in a
group full of people who like to change the subject a lot. Most readers
would prefer to leave the subject unchanged even when topic drift has
taken the conversation away from the original subject matter.
Since the general situation is that the thread has the same subject, if
you stop sorting by thread and start sorting by subject, you will find
that the thread is grouped primarily by subject and secondarily by date.
Thus you can read your 'thread' chronologically and it won't be
disturbed by problems in the References line.
The (Another) problem with sorting by thread is that the thread tree is
not consistently chronological -- and I prefer to read the messages in a
'conversation' or thread or topic in chronological order rather than in
the non-chronological tree which results from threading.
When you are reading in a group in which the participants are not
consistently using newsreaders with a reliable References line, such as
those who are contributing from other channels, then the threading
mechanism is going to break.
--
Mike Easter
Peter Lairo
> Peter Lairo wrote:
>> Why are so many posts in the Mozilla newsgroups not threaded properly?
>> (like this one)
>
> you stop sorting by thread and start sorting by subject, you will find
> that the thread is grouped primarily by subject and secondarily by date.
> Thus you can read your 'thread' chronologically and it won't be
> disturbed by problems in the References line.
>
> The (Another) problem with sorting by thread is that the thread tree is
> not consistently chronological -- and I prefer to read the messages in a
> 'conversation' or thread or topic in chronological order rather than in
> the non-chronological tree which results from threading.
Your solution (actually it's a workaround) only works well for *linear*
conversations. Most newsgroup threads have *branches*, where people are
responding to different posts within the thread at different
(non-linear) times.
Sorting by Subject + Date only works well with linear threads:
original post
- response 1
- response 2
- response 3
- response 4
Threading works with linear posts *and* with threads that have branches:
original post
- response 1
- response 2
- response 4
- response 3
- response 5
(See how reading response 3 before response 4, and reading response 5
after response 4 could be confusing?)
With threading I can *follow the sub-threads chronologically*, which is
much more relevant than following everything bunched together
chronologically.
> When you are reading in a group in which the participants are not
> consistently using newsreaders with a reliable References line, such as
> those who are contributing from other channels, then the threading
> mechanism is going to break.
That is why I would prefer it if Mozilla changed its current course of
emphasizing mailing lists and started (re)emphasizing newsgroups more.
BTW: Why, during the installation of Thunderbird, is the check-box to
make Thunderbird the default program for newsgroups *not* selected by
default?
Mike Easter
> Mike Easter wrote:
>> The (Another) problem with sorting by thread is that the thread tree is
>> not consistently chronological -- and I prefer to read the messages in a
>> 'conversation' or thread or topic in chronological order rather than in
>> the non-chronological tree which results from threading.
>
> Your solution (actually it's a workaround) only works well for *linear*
> conversations. Most newsgroup threads have *branches*, where people are
> responding to different posts within the thread at different
> (non-linear) times.
That is correct. And/But in my opinion, the ideal conversation is well
trimmed and contextualized in the body.
Since the message's context is provided by the trimming and
contextualization within the body of the message, the integrity and
branches of the References tree is not necessary. Chronologically by
subject works fine.
> Sorting by Subject + Date only works well with linear threads:
>
> original post
> - response 1
> - response 2
> - response 3
> - response 4
>
> Threading works with linear posts *and* with threads that have branches:
>
> original post
> - response 1
> - response 2
> - response 4
> - response 3
> - response 5
>
> (See how reading response 3 before response 4, and reading response 5
> after response 4 could be confusing?)
I have also seen conversation become confused because they were sorted
by references line instead of chronologically. Both ways. In order to
prevent both kinds of confusion, it is sometimes necessary to read all
of the current messages in a thread before responding to an earlier one.
And our conversation here started with the problem that you brought up
in which the References lines weren't reliable.
I am not interested in trying to convert a person who prefers to read
threaded over to one who instead sorts by subject chronologically -- the
purpose of my sorting style remarks was to suggest to you that sorting
by subject chronologically was superior to trying to read threaded when
the threads are disrupted/shattered/broken by faulty References.
> With threading I can *follow the sub-threads chronologically*, which is
> much more relevant than following everything bunched together
> chronologically.
Except when you can't, which is what we are discussing.
>> When you are reading in a group in which the participants are not
>> consistently using newsreaders with a reliable References line, such as
>> those who are contributing from other channels, then the threading
>> mechanism is going to break.
>
> That is why I would prefer it if Mozilla changed its current course of
> emphasizing mailing lists and started (re)emphasizing newsgroups more.
I would rather participate in a newsgroup than a mailing list, but I
wouldn't count on someone 'emphasizing' newsgroups to make people change
from mailing list to newsgroups.
There are a great many technically oriented people in the world
including many who man support desks who do not use a newsreader - never
have. They are not acquainted with setting up a news agent with a news
server.
However, they are quite familiar with email. You would need to
'convert' some of those people. You are less likely to convert a
non-newsreader person from email than you are to convert a newsreader
person who is currently not threading over to one who is threading :-)
--
Mike Easter
Peter Lairo
> Peter Lairo wrote:
> trimmed and contextualized in the body.
>
> Since the message's context is provided by the trimming and
> contextualization within the body of the message, the integrity and
> branches of the References tree is not necessary. Chronologically by
> subject works fine.
Further down you say that it would be too hard to get people to use a
newsreader, and here you say that people should learn to trim their
replies properly. I would say that both are (nearly) equally difficult
to achieve, and thus (absent other relevant criteria) the one with the
greater benefit should be chosen (i.e., newsreaders).
> I have also seen conversation become confused because they were sorted
> by references line instead of chronologically.
You're saying that people wouldn't have gotten confused if the messages
had been sorted chronologically. How so? Sounds pretty unlikely and an
edge case to me.
> the
> purpose of my sorting style remarks was to suggest to you that sorting
> by subject chronologically was superior to trying to read threaded when
> the threads are disrupted/shattered/broken by faulty References.
That would mean that I would have to switch all my newsgroups that also
have mailing lists to chronological sorting. Thanks, but I prefer the
clarity of threading and will grudgingly bear the broken threading from
those who insist on using mailing lists (or who don't know better).
>> With threading I can *follow the sub-threads chronologically*, which
>> is much more relevant than following everything bunched together
>> chronologically.
>
> Except when you can't, which is what we are discussing.
I'm hoping that Mozilla (actually, the Thunderbird devs) will
re-emphasize newsgroups, and improve the ease-of-use in Thunderbird's
newsreader. I don't think this will happen soon because there currently
don't seem to be many devs with deep knowledge of Thunderbird (e.g., see
bug 250539). I'll just have to wait for the next generation of devs...
> I would rather participate in a newsgroup than a mailing list, but I
> wouldn't count on someone 'emphasizing' newsgroups to make people change
> from mailing list to newsgroups.
Why not? That seems the sensible course of action by those who (should)
know better.
> There are a great many technically oriented people in the world
> including many who man support desks who do not use a newsreader - never
> have. They are not acquainted with setting up a news agent with a news
> server.
Isn't it possible to click a nntp(?) link on a web page and Thunderbird
would auto-setup the linked news-server and newsgroup? Isn't that
technically possible? Shouldn't the admin of the support desks be able
to set up a news-server + newsgroups for the support staff. It's not any
more difficult than setting up an e-mail account (all you usually need
is the server name, and then subscribe to the newsgroups).
> However, they are quite familiar with email.
The Newsgroups UI is nearly identical to the e-mail UI (e.g., "Create
new message", unread messages are bold, hit "Reply").
> You are less likely to convert a non-newsreader
> person from email than you are to convert a newsreader person who is
> currently not threading over to one who is threading :-)
I like how you snuck-in the "who is currently not threading". ;-) I
think threading is the default setting in Thunderbird, and most
newsreader users will be using threading (because it's so much better),
so I think it would be pretty hard to convert newsreader users to use
mailing lists - more difficult than setting up a newsreader account and
getting people to use that.
Mike Shaver
> On Mon. 26.07.2010 0:21, Mike Easter wrote:
Can you guys take this somewhere other than dev-apps-firefox? If you
have to preface your subject with "OT", you should probably either put
it somewhere else (a blog post? .general?) or endeavour to keep the
thread quite short.
Thanks,
Mike
Peter Lairo
That's a reasonable request. I'll make this my last post in this thread.