Launchpad should offer a "Get tinyURL link" option for each page

This is an amazing idea, and I'd absolutely love to have it in LP.

+1 on the shortcut within the launchpad URL-space thing -- great idea!

Here's an idea I've had sitting around in a file for years, waiting for just such an occasion. I sure hope Malone preserves the columnar formatting below, or the diagram won't make much sense:

---------------------------------------------------------------------
  When we generate unique identifiers, users must sometimes manually
  transcribe them. But because certain digits and letters look alike
  (depending on the font), users often mistranscribe identifiers, as
  they're just random sequences with no recognizeable meaning.

  We can reduce mistranscriptions by putting similar symbols into
  equivalence classes. The consuming software would treat all of a
  given equivalence class as the same, so that even when the user
  mistranscribes, the identifier would still work.

  Each column in the diagram below is an equivalence class, giving a
  "base 23" alphabet from which to generate safe identifiers:

                   8 7
                   6 9 1 0 5 3
             2 4 a b c d e f g h i k m n o p r s t u w x z
                 A B C D E F G H I K M N O P R S T U W X Z
                             Q l v
                             q L V
                                 j y
                                 J Y

  For example, if the original identifier were "9sx43y", the software
  receiving it would accept "qsx43y" too (for that matter, it would even
  accept the much further off "G5X4zu", though one would have to wonder
  about the user in that case).

  Base 23 is a high enough base that identifiers will remain short -- at
  10 places, we have 41,426,511,213,648 unique values.

Nope. Actually, Malone's behavior was more unpredictable than I expected (if that's not a contradiction in terms):

The comment input box uses a proportional font, but the comments are *displayed* in monospace... and we fold repeated whitespace, apparently, so that the "V"s above (which should have been below the "U"s) are instead below the "I" column. Similar problems exist with other letters.

So we give conflicting signals about how we're going to interpret the user's input (the proportional vs monospace question, and the fact that we fold repeated whitespace with no warning), and we don't give users any opportunity to preview their comment.

I'll search for a bug on this, & open one if none.

Okay, the relevant bugs all exist already:

   bug #76604: Indentation isn't preserved for patches
   bug #58246: The textarea's for bug descriptions/comments should use a fixed-width font
   bug #292237: There is no preview when submitting bugs or comments

A Web site's URLs are too long, so it clutters every page with a mechanism to generate a shorter URL? If I may make a modest suggestion ... Why don't you just make the original URL shorter to begin with?

For example, the ultimate URL for this bug report needn't be <https://bugs.edge.launchpad.net/launchpad/+bug/317136>, it could be <https://launchpad.net/bugs/317136>, with ?in=project appended for subsequent targets of multi-target bugs. And the URL for a merge proposal needn't be <https://code.edge.launchpad.net/~user/project/branch/+merge/number>, it could be <https://launchpad.net/~user/+merge/number>. There's no law saying the URL has to contain every step of the data model hierarchy, even if that's what Zope encourages.

Shortening the actual URL would help 100% of the people who wanted it to be shorter, whereas a shortcut redirect system would help only those people who knew and remembered to use that system instead of doing the usual thing and copying from their browser's URL field.

Trying to solve it using the URL scheme is unlikely to yield great results. The current long URLs are verbose, but have the advantage of being memorable and transparent. If we try to change them we'll end up in an arms race where we never get significant improvements (significant enough to remove the requirement for a real tiny URL) and the URL scheme for LP as a whole is becoming baroque.

We already know that Tiny URLs are a good solution (because so many people use them). The only question is whether we can make it even easier to acquire them.

> Trying to solve it using the URL scheme is unlikely to yield great
> results. The current long URLs are verbose, but have the advantage of
> being memorable and transparent. If we try to change them we'll end up
> in an arms race where we never get significant improvements (significant
> enough to remove the requirement for a real tiny URL) and the URL scheme
> for LP as a whole is becoming baroque.

I agree.

One of the things that Launchpad has been praised for is the quality
of its URLs. They're easy to build as long as you know the general
rules of their structure.

That said it would be nice if any shortcut URLs we produced were of a
memorable (if not necessarily guessable or hackable) format.
http://linkpot.net does this nicely by using dictionary words,
although by choosing to do that you then impose a natural limit on
yourself. Also, it has a tendency to pick really inappropriate words.

Maybe one option would be to go with something like:

http://shortcuts.launchpad.net/$object_abbreviation/$object_identifier

Where $object_abbreviation could be something like 'br' for a branch,
'mp' for a merge proposal and so on. $object_identifier is more
difficult; we don't want to expose DB IDs in URLs (unless we already
do so, say for merge proposals). For a merge proposal, you could have:

http://shortcuts.launchpad.net/mp/1234

But for branches you need to worry about the Person and Product to
which they belong, too, so I'm not sure what The Right Way to do that
is (if we went with sc.lp.n/br/~foo/$product/$branch we're actually
going to end up with a longer URL than we would if they just used
code.lp.n...).

I've heard Launchpad developers praise Launchpad for the quality of its URLs, but I don't remember anyone else doing so. :-) Conversely, I've seen complaints that http://bugs.launchpad.net/<bug-number> doesn't work (bug 2132), complaints that including project IDs in bug URLs causes both 404 errors (bug 153763) and misfilings (which I reported as bug 246041), a complaint that blueprint URLs change when the blueprint ID changes (bug 311203, albeit indirectly caused by bug 126522), and occasional sardonic comments on IRC about the "+" characters sprayed through Launchpad URLs seemingly at random. I've also experienced question URLs breaking because they included the project ID (bug 112990). Maybe I just hang out with the wrong people. But the common element in all these complaints is unnecessary elements, especially changeable or retargetable IDs, being included in URLs and making them *already* baroque. Weeding out those unnecessary elements would reduce 404s as well as making URLs shorter for everyone — not just for those people willing, able, and prescient enough to use a Launchpad-specific tinyurl system.

Matthew gets my vote for Best Comment Of The Year in the Thoroughness Category.

For a counterexample (i.e., a situation where a tinyurl would really help, and where the URL often cannot be otherwise shortened while keeping its in-built semantics), see bug #325982, and in particular this comment:
https://bugs.edge.launchpad.net/malone/+bug/325982/comments/3 .

2009/9/10 Karl Fogel <email address hidden>:
> Matthew gets my vote for Best Comment Of The Year in the Thoroughness
> Category.
>
> For a counterexample (i.e., a situation where a tinyurl would really help, and where the URL often cannot be otherwise shortened while keeping its in-built semantics), see bug #325982, and in particular this comment:
> https://bugs.edge.launchpad.net/malone/+bug/325982/comments/3 .

To me this is an example of where URL shortening is an accommodation
of a bug. If I want the default bug search, the URL should be short.
Deleting these fields from the URL gives the same results.

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

http://pad.lv/317136 now redirects you to bug 317136. Suggestions for short but meaningful urls for other types of objects welcome.

This bug can be accessed with:
https://bugs.launchpad.net/bugs/317136
But in the berowser's URL bar appears only long notation:
https://bugs.launchpad.net/launchpad/+bug/317136

It will be useful to offer a "short" link somewhere to ease using them on plain e-mails.