| 2009-04-08 15:07:37 |
Karl Fogel |
bug |
|
|
added bug |
| 2009-04-08 15:09:31 |
Karl Fogel |
description |
This is a bit of a grab-bag issue about our current mailing list archive user experience.
We regressed in UI when we switched from the pipermail archives at lists.ubuntu.com to the mhonarc-based system in lists.launchpad.net. In the new interface:
- the name of the mailing list is not shown on its archive index pages
- indexes are single-page, not multi-page: a 100,000 message list means a page with 100,000 items on it :-).
- indexes list messages earliest-first, instead of latest-first
- indexes do not show the date next to the message
- text is black-on-neutral-browser-default, instead of at least black-on-white like the rest of Launchpad
These regressions aren't really MHonArc's fault; we just need to make better use of its built-in customization ability, to do multipage indexes, etc. It's almost done on this branch-in-progress: https://code.edge.launchpad.net/~kfogel/launchpad/ml-archiver-ui; thanks much to barry for answering lots of Launchpad questions for that branch.
Secondly, aside from the above regressions, our archives have always had some problems:
- archives not searchable (we could solve this by outsourcing to $Google via a site-bound search form)
- UI look and feel not similar to the rest of Launchpad
- message URLs not predictable. See http://wiki.list.org/display/DEV/Stable+URLs for a way to solve this.
Note that switching to MHonArc did bring some advantages. We now have stable message URLs (even if not predictable ones). That is, if you regenerate an archive from the source mails, you'll get the same message URLs again. Obviously, that property comes along with predictable URLs anyway, so if we get that feature, we don't have to do anything extra to get stable URLs.
Also, when a thread is split across different months (well, across different pages of a multi-page index), the archiver should do something sane with that, instead of pretending that there's no connection. IIRC, pipermail does not indicate any connectedness. The dangling message does not even have a "next in thread" / "prev in thread" link (see Jason Earl's message at the top of https://lists.ubuntu.com/archives/bazaar/2009q2/thread.html#55942 for an example). MHonArc at least gives an indication that the thread extends backward or forward to another page, although the UI for that connectedness could be better.
Anyway, all the above is a rough description of what a truly pleasant archiving system would look like :-). It would be nice if we got closer to that, whether by improving Pipermail or MHonArc or writing something from scratch. (Although MHonArc is in Perl, while Pipermail and Launchpad are both in Python, MHonArc turns out to be quite extensible, so it's not automatically the wrong choice.) |
This is a bit of a grab-bag issue about our current mailing list archive user experience.
We regressed in UI when we switched from the pipermail archives at lists.ubuntu.com to the mhonarc-based system in lists.launchpad.net. In the new interface:
- the name of the mailing list is not shown on its archive index pages
- indexes are single-page, not multi-page: a 100,000 msg list means a page w/ 100,000 items :-).
- indexes list messages earliest-first, instead of latest-first
- indexes do not show the date next to the message
- text is black-on-neutral-browser-default, instead of black-on-white like the rest of LP
These regressions aren't really MHonArc's fault; we just need to make better use of its built-in customization ability, to do multipage indexes, etc. It's almost done on this branch-in-progress: https://code.edge.launchpad.net/~kfogel/launchpad/ml-archiver-ui; thanks much to barry for answering lots of Launchpad questions for that branch.
Secondly, aside from the above regressions, our archives have always had some problems:
- archives not searchable (could at least outsource to $Google via a site-bound search form)
- UI look and feel not similar to the rest of Launchpad
- message URLs not predictable (see http://wiki.list.org/display/DEV/Stable+URLs)
Note that switching to MHonArc did bring some advantages. We now have stable message URLs (even if not predictable ones). That is, if you regenerate an archive from the source mails, you'll get the same message URLs again. Obviously, that property comes along with predictable URLs anyway, so if we get that feature, we don't have to do anything extra to get stable URLs.
Also, when a thread is split across different months (well, across different pages of a multi-page index), the archiver should do something sane with that, instead of pretending that there's no connection. IIRC, pipermail does not indicate any connectedness. The dangling message does not even have a "next in thread" / "prev in thread" link (see Jason Earl's message at the top of https://lists.ubuntu.com/archives/bazaar/2009q2/thread.html#55942 for an example). MHonArc at least gives an indication that the thread extends backward or forward to another page, although the UI for that connectedness could be better.
Anyway, all the above is a rough description of what a truly pleasant archiving system would look like :-). It would be nice if we got closer to that, whether by improving Pipermail or MHonArc or writing something from scratch. (Although MHonArc is in Perl, while Pipermail and Launchpad are both in Python, MHonArc turns out to be quite extensible, so it's not automatically the wrong choice.) |
|
| 2009-04-08 15:10:09 |
Karl Fogel |
description |
This is a bit of a grab-bag issue about our current mailing list archive user experience.
We regressed in UI when we switched from the pipermail archives at lists.ubuntu.com to the mhonarc-based system in lists.launchpad.net. In the new interface:
- the name of the mailing list is not shown on its archive index pages
- indexes are single-page, not multi-page: a 100,000 msg list means a page w/ 100,000 items :-).
- indexes list messages earliest-first, instead of latest-first
- indexes do not show the date next to the message
- text is black-on-neutral-browser-default, instead of black-on-white like the rest of LP
These regressions aren't really MHonArc's fault; we just need to make better use of its built-in customization ability, to do multipage indexes, etc. It's almost done on this branch-in-progress: https://code.edge.launchpad.net/~kfogel/launchpad/ml-archiver-ui; thanks much to barry for answering lots of Launchpad questions for that branch.
Secondly, aside from the above regressions, our archives have always had some problems:
- archives not searchable (could at least outsource to $Google via a site-bound search form)
- UI look and feel not similar to the rest of Launchpad
- message URLs not predictable (see http://wiki.list.org/display/DEV/Stable+URLs)
Note that switching to MHonArc did bring some advantages. We now have stable message URLs (even if not predictable ones). That is, if you regenerate an archive from the source mails, you'll get the same message URLs again. Obviously, that property comes along with predictable URLs anyway, so if we get that feature, we don't have to do anything extra to get stable URLs.
Also, when a thread is split across different months (well, across different pages of a multi-page index), the archiver should do something sane with that, instead of pretending that there's no connection. IIRC, pipermail does not indicate any connectedness. The dangling message does not even have a "next in thread" / "prev in thread" link (see Jason Earl's message at the top of https://lists.ubuntu.com/archives/bazaar/2009q2/thread.html#55942 for an example). MHonArc at least gives an indication that the thread extends backward or forward to another page, although the UI for that connectedness could be better.
Anyway, all the above is a rough description of what a truly pleasant archiving system would look like :-). It would be nice if we got closer to that, whether by improving Pipermail or MHonArc or writing something from scratch. (Although MHonArc is in Perl, while Pipermail and Launchpad are both in Python, MHonArc turns out to be quite extensible, so it's not automatically the wrong choice.) |
This is a bit of a grab-bag issue about our current mailing list archive user experience.
We regressed in UI when we switched from the pipermail archives at lists.ubuntu.com to the mhonarc-based system in lists.launchpad.net. In the new interface:
- the name of the mailing list is not shown on its archive index pages
- indexes are single-page, not multi-page: a 100,000 msg list means a page w/ 100,000 items :-).
- indexes list messages earliest-first, instead of latest-first
- indexes do not show the date next to the message
- text is black-on-neutral-browser-default, instead of black-on-white like the rest of LP
These regressions aren't really MHonArc's fault; we just need to make better use of its built-in customization ability, to do multipage indexes, etc. It's almost done on this branch-in-progress: https://code.edge.launchpad.net/~kfogel/launchpad/ml-archiver-ui; thanks much to barry for answering lots of Launchpad questions for that branch.
Secondly, aside from the above regressions, our archives have always had some problems:
- archives not searchable (could at least outsource to $Google via a site-bound search form)
- UI look and feel not similar to the rest of Launchpad
- message URLs not predictable (see http://wiki.list.org/display/DEV/Stable+URLs)
Note that switching to MHonArc did bring some advantages. We now have stable message URLs (even if not predictable ones). That is, if you regenerate an archive from the source mails, you'll get the same message URLs again. Obviously, that property comes along with predictable URLs anyway, so if we get that feature, we don't have to do anything extra to get stable URLs.
Also, when a thread is split across different months (well, across different pages of a multi-page index), the archiver should do something sane with that, instead of pretending that there's no connection. IIRC, pipermail does not indicate any connectedness. The dangling message does not even have a "next in thread" / "prev in thread" link (see Jason Earl's message at the top of https://lists.ubuntu.com/archives/bazaar/2009q2/thread.html#55942 for an example). MHonArc at least gives an indication that the thread extends backward or forward to another page, although the UI for that connectedness could be better.
Anyway, all the above is a rough description of what a truly pleasant archiving system would look like. It would be nice if we got closer to that, whether by improving Pipermail or MHonArc or writing something from scratch. (Although MHonArc is in Perl, while Pipermail and Launchpad are both in Python, MHonArc turns out to be quite extensible, so it's not automatically the wrong choice.) |
|
| 2009-04-08 15:11:40 |
Karl Fogel |
description |
This is a bit of a grab-bag issue about our current mailing list archive user experience.
We regressed in UI when we switched from the pipermail archives at lists.ubuntu.com to the mhonarc-based system in lists.launchpad.net. In the new interface:
- the name of the mailing list is not shown on its archive index pages
- indexes are single-page, not multi-page: a 100,000 msg list means a page w/ 100,000 items :-).
- indexes list messages earliest-first, instead of latest-first
- indexes do not show the date next to the message
- text is black-on-neutral-browser-default, instead of black-on-white like the rest of LP
These regressions aren't really MHonArc's fault; we just need to make better use of its built-in customization ability, to do multipage indexes, etc. It's almost done on this branch-in-progress: https://code.edge.launchpad.net/~kfogel/launchpad/ml-archiver-ui; thanks much to barry for answering lots of Launchpad questions for that branch.
Secondly, aside from the above regressions, our archives have always had some problems:
- archives not searchable (could at least outsource to $Google via a site-bound search form)
- UI look and feel not similar to the rest of Launchpad
- message URLs not predictable (see http://wiki.list.org/display/DEV/Stable+URLs)
Note that switching to MHonArc did bring some advantages. We now have stable message URLs (even if not predictable ones). That is, if you regenerate an archive from the source mails, you'll get the same message URLs again. Obviously, that property comes along with predictable URLs anyway, so if we get that feature, we don't have to do anything extra to get stable URLs.
Also, when a thread is split across different months (well, across different pages of a multi-page index), the archiver should do something sane with that, instead of pretending that there's no connection. IIRC, pipermail does not indicate any connectedness. The dangling message does not even have a "next in thread" / "prev in thread" link (see Jason Earl's message at the top of https://lists.ubuntu.com/archives/bazaar/2009q2/thread.html#55942 for an example). MHonArc at least gives an indication that the thread extends backward or forward to another page, although the UI for that connectedness could be better.
Anyway, all the above is a rough description of what a truly pleasant archiving system would look like. It would be nice if we got closer to that, whether by improving Pipermail or MHonArc or writing something from scratch. (Although MHonArc is in Perl, while Pipermail and Launchpad are both in Python, MHonArc turns out to be quite extensible, so it's not automatically the wrong choice.) |
This is a bit of a grab-bag issue about our current mailing list archive user experience.
We regressed in UI when we switched from the pipermail archives at lists.ubuntu.com to the mhonarc-based system in lists.launchpad.net. See here for an example of what the new interface looks like:
https://lists.launchpad.net/launchpad-users/
Some problems with it:
- the name of the mailing list is not shown on its archive index pages
- indexes are single-page, not multi-page: a 100,000 msg list means a page w/ 100,000 items :-).
- indexes list messages earliest-first, instead of latest-first
- indexes do not show the date next to the message
- text is black-on-neutral-browser-default, instead of black-on-white like the rest of LP
These regressions aren't really MHonArc's fault; we just need to make better use of its built-in customization ability, to do multipage indexes, etc. It's almost done on this branch-in-progress: https://code.edge.launchpad.net/~kfogel/launchpad/ml-archiver-ui; thanks much to barry for answering lots of Launchpad questions for that branch.
Secondly, aside from the above regressions, our archives have always had some problems:
- archives not searchable (could at least outsource to $Google via a site-bound search form)
- UI look and feel not similar to the rest of Launchpad
- message URLs not predictable (see http://wiki.list.org/display/DEV/Stable+URLs)
Note that switching to MHonArc did bring some advantages. We now have stable message URLs (even if not predictable ones). That is, if you regenerate an archive from the source mails, you'll get the same message URLs again. Obviously, that property comes along with predictable URLs anyway, so if we get that feature, we don't have to do anything extra to get stable URLs.
Also, when a thread is split across different months (well, across different pages of a multi-page index), the archiver should do something sane with that, instead of pretending that there's no connection. IIRC, pipermail does not indicate any connectedness. The dangling message does not even have a "next in thread" / "prev in thread" link (see Jason Earl's message at the top of https://lists.ubuntu.com/archives/bazaar/2009q2/thread.html#55942 for an example). MHonArc at least gives an indication that the thread extends backward or forward to another page, although the UI for that connectedness could be better.
Anyway, all the above is a rough description of what a truly pleasant archiving system would look like. It would be nice if we got closer to that, whether by improving Pipermail or MHonArc or writing something from scratch. (Although MHonArc is in Perl, while Pipermail and Launchpad are both in Python, MHonArc turns out to be quite extensible, so it's not automatically the wrong choice.) |
|
| 2009-04-17 06:31:56 |
Karl Fogel |
attachment added |
|
Screenshot of new mailing list index page. http://launchpadlibrarian.net/25596236/new-launchpad-mailing-list-appearance.png |
|
| 2009-04-17 06:34:37 |
Karl Fogel |
attachment added |
|
new-launchpad-mailing-list-appearance.png http://launchpadlibrarian.net/25596633/new-launchpad-mailing-list-appearance.png |
|
| 2009-04-28 20:29:32 |
Karl Fogel |
attachment added |
|
Test data for loading into a mailing list archive. http://launchpadlibrarian.net/26091302/lp-ml-test-data.tar.gz |
|
| 2009-07-14 23:50:47 |
Diogo Matsubara |
affects |
launchpad-foundations |
launchpad-registry |
|
| 2009-07-14 23:51:16 |
Diogo Matsubara |
tags |
|
mailing-lists |
|
| 2009-07-15 02:33:37 |
Curtis Hovey |
launchpad-registry: status |
New |
Triaged |
|
| 2009-07-15 02:33:40 |
Curtis Hovey |
launchpad-registry: importance |
Undecided |
Low |
|
| 2009-07-15 02:34:00 |
Curtis Hovey |
tags |
mailing-lists |
mailing-lists ml-archive-sucks |
|
| 2009-07-15 18:08:44 |
Karl Fogel |
launchpad-registry: status |
Triaged |
Fix Committed |
|
| 2009-07-15 18:35:19 |
Curtis Hovey |
launchpad-registry: milestone |
|
2.2.7 |
|
| 2009-07-15 18:35:19 |
Curtis Hovey |
launchpad-registry: assignee |
|
Karl Fogel (kfogel) |
|
| 2009-07-23 01:11:16 |
Curtis Hovey |
launchpad-registry: status |
Fix Committed |
Fix Released |
|
