Link to Neighbors

We consider fine points on the behavior of Collaborative Link first discussed in chat. post

Collaborative Link issue. When an internal link is available somewhere in the neighbourhood other than the current site - the link shows a choice of options in a ghost page. If the number of links is only one - would it not be better to navigate directly to the link?

No. The ghost page is there for the same reason high value sites will notify you when a link takes you away from that site. For federation authors the risk of confusion is even worse since the "in the neighborhood" links are not visible to the author.

One might argue that the author has relinquished control over the reader's browsing by including a broken link. But the link may have broken after the author finished writing due to a source site being offline.

Jon Udell argued that links weren't "idempotent" when he thought our collaborative links worked as you suggest. Idempotent in this case meant producing consistent results upon subsequent clicks. We aspire to provide authors control over their works. An author who links to other's content to complete an idea should fork enough of that content to make the case.

As the author finds forked content diverging from their own story then they can rely on the collaborative links so as to not leave their readers disconnected.

Skilled authors will write pages with focus so as to make their own work more reusable and thereby engage in the collective conversation.

These reasons are sound, but then call for an additional feature - Interwiki Links.

While idempotent linking is a good idea (I thought that wiki did not aim to preserve this with regard to the neighbourhood concept), it now has significant pragmatic disadvantage for an author working in wiki with multiple sites.

An advanced author will soon move to creating multiple sites, and even progress to having a wiki farm locked to their identity. This enables the author to keep content in a namespace of their choosing reflected by the domain or subdomain of their choice.

For instance an author working on a book may have multiple subdomains - one for each chapter. This same author will want to link between chapters of their own writing in many ways, and wishes to provide an experience for their readers in which these links are transparent.

This can be achieved in many ways (for instance by pre-seeding the neighbourhood or by providing a suitable roster, or even by judiciously forking the home page.

However this is now not possible (was it ever?). The reading experience is interrupted, and the only way to alter this is by forking every page linked to in another subdomain. This quickly becomes unmanageable. I presently have many sites that are suffering from having to fork pages multiple times, when I would far rather rely on controlling the neighbourhood to achieve the same result.

An interwiki link option would allow control over this. personally if I would turn off idempotent links if I had a choice as an author as i would not want to have the complexity of interwiki markup. But I certainly don;t want to be forced to duplicate scores of pages simply to provide a semaless wiki-farm based reading expereince.

Perhaps the Future plugin can be usefully extended.

Collaborative links always only looked at the current context when rendering internal links in a page. Context comes from the Journal and can be extended by the plugin doing the rendering as it is with Reference plugins.

Aside: I have seen malformed contexts constructed by some path that I have not diagnosed. The context is stored in a global and they are subject to malfunction especially in an asynchronous environment.

The ghost Future page appears as an unnecessary intermediate step in Bovill's scenario. If this step were to be made optional, the option could be presented as a check-box as one finds in many informational dialogs.

The memory of this choice would most naturally be local to the browser tab as it would then carry through all pages of all sites from that point forward. Reloading the tab would clear the option.

It is possible that the Future plugin could implement this shortcut at the point that it becomes aware of the neighborhood. Some interaction with the core javascript might be required to make this flicker-free.

The context being defined by the Journal and manipulable by plugins would point to the way. I was thinking of creating a Transporter that would add a fork action to the Journal, but I think this would need to be done for every page in the site.

The "don't show me" check-box is certainly possible, but it does not satisfy the readership criteria that I would like to aim for. This brings up an interesting point, one that we may call mode preference. See User-mode Preeminence.

The Future Plugin is perhaps not the solution here. I feel we want instead to hook into a Roster mechanism / interface / idea in order to allow authors to customise the experience on a per-page or per-site basis.

URLs not Idempotent from the location bar?