-10

This is related to my previous suggestion, where the following was mentioned, but not elaborated on.

In short:

Stack Exchange could store bookmarks, linked to an internal ID. When linking to these bookmarks from posts, you don't link to the bookmarks directly, but to the SE IDs.

Whenever link rot occurs, all a moderator has to do is change the bookmark associated with the ID, and the link would be updated across the entire SE site.

Link IDs could be associated with keywords, which could trigger link suggestions as specified in my previous suggestion.

When entering an URL which is already linked to an ID, you could automatically change that link to the 'managed' SE link.

6
  • What does this have to do with "integrated social bookmarking"?
    – user229044
    Nov 4, 2011 at 21:38
  • Are you suggesting that SE store every page that was ever linked to from SE?
    – John
    Nov 4, 2011 at 21:51
  • @meagar: It's social bookmarking as e.g. delicious, but by integrating it tightly into SE you have a lot of added advantages (like the link suggestions, fixing link rot in a central location, ...) Nov 4, 2011 at 21:55
  • @John: No, not the page, only the link to the page. Also, these links should be moderated so only important (very often linked to pages) are stored. (MVC pattern, API documentation, ...) Nov 4, 2011 at 21:59
  • So you're suggesting that SE have special links where linking to them really links somewhere else?
    – John
    Nov 4, 2011 at 22:01
  • @John: Yes and no, as in my reply on maegar's answer. Visually the links are plain ordinary links, but when editing the question, yes you link to a SE link instead. This can be automated. This has all the look and feel of ordinary links, but allows for all the possible advantages as in this (and my linked) suggestion. Nov 4, 2011 at 22:02

2 Answers 2

1

The last thing we need is yet another layer of indirection surrounding hyperlinks. The whole point is to link thing A directly to thing B, and layering more complexity on top of this is a bad idea and needlessly overcomplicates the entire system.

I want to be able to tell at a glance exactly what a link is and where it is taking me, and replacing all out-going links with a SO-link+redirect sounds awful.

You're also assuming there is a problem. I would assume the number of "unstable" links that are posted repeatedly across several answers is small. For example, links to the PHP documentation are reposted constantly, but the odds of a page of PHP documentation going away are pretty slim. Links to somebody's blog might go away, but the odds of such a link being posted in many questions is much smaller, so there isn't a need to make sweeping updates for every instance of that link.

2
  • My suggested solution still allows to link things directly from point A to B (from the point of view for the user). (See the last point in the suggestion.) It's not more complicated for the user. Adding extra abstraction layers isn't 'overcomplicating' things, but is the basis of any scalable more advanced design. Nov 4, 2011 at 21:26
  • "I want to be able to tell at a glance exactly what a link is and where it is taking me" ... the link could be rendered as to display the actual link, but could be stored with the SE ID. Nov 4, 2011 at 21:28
0

This proposal goes against all the efforts to replace shortened URLs with their true destination.

Also, it becomes the moderators' responsibility to clean up link rot (by changing the bookmark) instead of the community's (by editing). I am not a moderator, but I am opposed to putting further burdens on them.

EDIT in response to OP's comments

Ok, so you could avoid the link-shortener issue by still showing the true URL. But I don't think this proposal meets the test of a useful new feature for a site like SO. I think about this by asking myself a few questions.

  1. What problem does this solve? Linkrot - and only linkrot.
  2. Are there any other tools to solve the same problem? Editing, which we can also do to improve posts in other ways. Advantage to just editing.
  3. What advantages does this proposed solution have over existing solutions (editing)? If a broken link is found, all instances of that link are fixed at the same time.
  4. Is this advantage material? That depends on whether links that break are likely to have been cited multiple times. I have no idea if there is a database-querying way to work this out, but I suspect the answer is "no". Linkrot is more likely on less-common links, rather than frequently cited links such as documentation to particular languages or products. So most of the time, editing one post will probably fix the problem for that broken link. As noted below, I expect there is a power law distribution in number of times a URL is linked to, so in most cases, a given URL only receives one or two links.
  5. Who would have to do the work if this solution were introduced? In the proposal, moderators and/or high-rep users would be responsible for changing the bookmark - other users would not be able to merely edit that post. So the work would be concentrated on a small group who already have a lot to do.

So in summary, instead of all users editing broken links as they find them, only a small proportion of users would have to either find and redirect the broken links, or deal with a user flag requesting the link to be fixed. Given that there is probably a power law distribution of links from the site, most destination URLs will only appear once or twice and a simple edit will fix up a broken link. This concentrates work on a smaller group for a small material benefit.

Making it a user choice to put a link in the database or not would make things worse: first, we have to decide something (more cognitive load); second, broken links would then have to be dealt with two different waves.

Further on the cognitive load issue, I do not think it is a good idea to encourage the community to edit posts to improve them, and then make that not work for linkrot - possibly only for certain URLs! That would just be confusing.

8
  • Again (as in my comments on the other answers), the visible link would/could remain the same. Managing links could be another right you can gain by rep. Nov 5, 2011 at 1:52
  • @StevenJeuris - but it still makes clean-up work a job for the moderators, not the community.
    – Verbeia
    Nov 5, 2011 at 1:55
  • Sorry, you must have answered that before I updated the comment. Nov 5, 2011 at 1:56
  • @StevenJeuris - no worries, I must have answered before you edited. I didn't mention this in the answer but I don't see how this is "social". It's a central database of all the links posted on SE/SO.
    – Verbeia
    Nov 5, 2011 at 1:59
  • Isn't SE social? :) I also wouldn't gather 'all' links. Perhaps an opt-in approach, where links have to be added explicitly, along with some keywords is a better approach. Nov 5, 2011 at 2:03
  • So every time I put in a link in a post, I have to decide whether to add it to the central database?
    – Verbeia
    Nov 5, 2011 at 2:05
  • You would be able to, yes. That's kind of the idea. I can't recall how many times I linked to 'MVC' or 'reflection' or 'encapsulation', ... etc. So the added advantage is it can suggest a link, before you even have to go look for it, and it will be managed from a central place. Nov 5, 2011 at 2:08
  • Querying the database every time someone posts a link? "Do you mean this link"? I don't like to think of the performance hit that implies. Or the system nags me to add a link everytime I answer a question? And the system is supposed to guess that link? Even Siri can't do that.
    – Verbeia
    Nov 5, 2011 at 2:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .