Context-based URLs are confusing to users

The different URLs are used to present the bug page slightly differently given the context in which the bug is reported. An obvious use of this currently on Launchpad is that a bug in one context (i.e. one of its URLs) might have a low heat number and no flame icons while the same bug in another context (i.e. another URL) might have high heat and four flame icons.

This is just one example, but we do use the different URLs to convey context and do not want to redirect every context to the short form url. This bug can't be fixed for that reason.

On 24 March 2010 14:47, Deryck Hodge <email address hidden> wrote:
> The different URLs are used to present the bug page slightly differently
> given the context in which the bug is reported.  An obvious use of this
> currently on Launchpad is that a bug in one context (i.e. one of its
> URLs) might have a low heat number and no flame icons while the same bug
> in another context (i.e. another URL) might have high heat and four
> flame icons.

This is a source of some user confusion and bugs though, because the
aspects of the page that vary depend on the user having a fairly
advanced mental model of Launchpad's namespace. It might be better
for instance to put the heat icons next to the task they describe
(though that might be complicated too, in various ways.)

Of course you're right that this is more than just a matter of putting
up redirects.

--
Martin <http://launchpad.net/~mbp/>

ok. thank you for explaining the the idea behind the many urls.

i didn't know that the heat is context dependent. i think, since it is context dependent, it should go in the context dependent section of the page, by that i mean the "affects table". the page trail (that thing directly beneath the bug title) is also context dependent, it should also go in the "affects table".

the "affects table" is already crammed enough as it is now. but i find it very confusing to have some context dependent information *inside* the table, and some context dependent information (heat, trail) *outside* of the table. maybe it is time to redesign the table, perhaps with some information hidden until the user clicks on an expand button for a specific row.

another thing, about the direct urls to the comments. these two links point to the same comment:
https://bugs.launchpad.net/hundredpapercuts/+bug/490772/comments/3
https://bugs.launchpad.net/gedit/+bug/490772/comments/3
the first links show the comment in the context of the hundredpapercuts project. here the context makes sense (the comment states that the bug is not in the hundredpapercuts project). the second link, however, shows that comment in the context of the gedit bug. if i landed on that comment by that link i will find it very confusing. why should someone talk about the hundredpapercuts project in a gedit bug?

curiously, this link leads to an error page: https://bugs.launchpad.net/bugs/490772/comments/3

question: by what rules is the context chosen if one uses the short url? is it always the original context it was reported in?

yet another thing, about this url:
https://bugs.launchpad.net/ubuntu/+bug/490772/
it lands on a page which i think i can call contextless, with a confusing title (bug #xxx is not in ubuntu). what about that?

i think i have to split this bug up, if you maintain the position for the many context dependent urls.

I'm not suggesting we should maintain the way we do context via URL. I'm saying that this is the way it is for now, and that it is involved to change this. Like Martin says, it is confusing for users, so if we could find a way to have a context-specific view of a bug via a less confusing mechanism or UI, then of course I would be in favor of that.

Certainly feel free to file bugs about specific issues or ideas. There are some existing bugs against malone around these issues already.

I've previously raised the need for a short final URL for bug reports in bug 237153 and bug 317136. As far as I can tell, though, this is the only bug report devoted to the issue, and while it may be complex to fix, I think it's valid.

To reprise my suggestion from those reports:

* Most bug reports (I assume) have a single context. The canonical URL for these should be https://launchpad.net/bugs/NNN -- or maybe https://bugs.launchpad.net/NNN (bug 2132), but not the redundant https://bugs.launchpad.net/bugs/NNN.

* For a multi-context bug report, the URL should be https://launchpad.net/bugs/NNN?in=context, e.g. https://launchpad.net/bugs/12345678?in=ubuntu/+source/firefox. The context-less URL should redirect as I proposed in bug 153763.

* None of this should have any effect on the visible navigation: the page title, hierarchy links, etc should work exactly as they did with the previous URLs.

* The only things that should change depending on what context you're viewing a report in should be (a) its <title>, (b) the highlighted row in the Affects table, and (c) the top navigation and "What next?" navigation. There should be no other differences in content or function. Heat should not be context-dependent, "Target to release" should not be context-dependent, and so on.

Implementing this would obsolete bug 237153 and bug 474425.

Agreed that we should keep this bug around to track a way to fix this, even if we may not get to this anytime soon. Thanks, mpt, for the comments, ideas, and links to other bugs.