I now use CommunityLocalNames / OddMuse’s concept of LocalNames almost exclusively.

That is, I now rarely actually inline hyperlinks!

I am seriously considering that we rethink a little bit, our expectations of how new pages should be handled.

Instead of:

 == FooBar ==
 This page is empty.
 [Edit this page]

…we might want this:

 == FooBar ==
 This page is empty.
 * [Edit this page.]
 * Point FooBar to a URL:  [http://                              ]

Another thing we might want to consider is, leaving everything as it is now (UI-wise,) but: If the first line of text on a page is a URL, make that page name a LocalName for that URL.

The problem I am trying to answer is this: “How do I make it easier to fill out these Local Names?”

Right now, I:

  • click on the URL at the top of the page
  • edit it to read “CommunityLocalNames” & press enter
  • hit “Edit this page”
  • click in a good place for putting a URL
  • go find the URL I want the LocalName to point to, on the Internet.
  • write out:
 * [http://example.net/ ExampleLink]
  • scroll down to the bottom of the page
  • think up a summary, or ignore
  • check “minor edit”
  • click on “Save”
  • refresh the original page (another tab) to make sure the link text matches what I just did

I’m thinking, “How can I make this easier?”

Your example reminds me of the “replace this page with a file” option…

Yeah, I guess you’re right. Instead of using a central page to maintain links, we might as well have an edit page, use Replace this page with a redirect and have the user save an URL.

As for the implementation: Are you suggesting that doing this adds a line to the CommunityLocalNames page? That would work, even though it would not really be the most transparent solution for newcomers.

The alternative is not pretty, either. If the raw text of the page is changed to #REDIRECT http://example.com/ so it matches the other redirect directives, we’re left with one problem: How do you edit these redirects? It reminds me of the problem I had with redirects between namespaces in the Oddmuse:Namespaces Extension. There, I rewrote the code to only redirect within namespaces, and thus the target page made it possible to link back to an edit page. This won’t work for external redirects.

Sticking with the CommunityLocalNames page would solve the user interface issue (in a suboptimal way). Replace this page with a redirect would just offer an easy way to add a line to the page.

I like the #REDIRECT.

Whenever I want to edit a #REDIRECT, the way I do it, is to start editing one page, and then I edit the URL to say “id=PageName.” I would think that would work for the URL redirects as well.

that saiiiiid…

One thing I like about having all the names on CommunityLocalNames, is that I can just copy and paste all of them, and paste them to another wiki. (I have done this before.)

Then again- perhaps the PageIndex will show up our redirects? In which case, it would work with LocalNames, and NearLink mechanisms, so I wouldn’t have to copy a list of links over.

URL editing is a lousy interface. :)

I’ll think of something. We also solved a similar NearLinks usability issue by having the EditNearLinks section at the bottom of the page using them…

Honestly, I’ve never seen anybody uses the ‘edit near links’ functionality, and several (2 is several, right?) persons even requested to remove those links with CSS.

Just to add confusion, I’ll mention the “redirector” approach that some sites use – for example SourceForge. When you click the link, you are presented with the “redirect page” that explains it’s a redirection, says that if it doesn’t work you can click on the link manually, and redirects you to the external page after certain timeout.

The good thing about this approach is that you can edit the page using the standard mechanisms, you are presented with an explanation what is happening and the page appears normally in your browsing history (so the back button works).

The bad thing is that it requires additional waiting or click, so it slows you down, the time of redirect is hard to get right, and the whole thing is time-dependant, so people who are not proficient using keyboard and mouse might be unable to edit it. It can also be jarring when you try to read the explanation and suddenly the page reloads.

Another possible solution would be to leave the LocalNames page as it is, but use a slightly different syntax to link to local names. Of course, this is only good for wikis that don’t use WikiWords, unless you want to go with something ugly like ->WikiWord.

Maybe I am missing why it would be a bad idea to just have a(n) (optional?) form space in the editing region (perhaps below summary?) that has example text like Lion suggests above, that allows a person to fill in LocalNames, but still writes those to a LocalNames page?

That form could be part of the LocalNames module, or could even be optional in the config (allowing the old way, or “form” way, like "$LnForm = 1;")

I could very well be overlooking something, of course, but that is what my imagination conjures up when I read this page…

Sam, yes, this is a good interface for adding new LocalNames, but has one disadvantage: removing or changing the LocalNames is performed in a completely separate place, not connected in any way with the LocalName or the interface.

In other words, it’s a one-way change: once you do it, there is no way for you to figure out how to undo it. You need additional knowledge for that: you have to know about the LocalNames page.

Putting a link to that page next to the form, with text “to remove that link, edit this page directly” might help, but it has another problem: you see that text when you don’t need it, and when you actually need it, it’s gone.

I think we have three use cases here:

  • I make a new LocalName, try it out and notice I entered a wrong address. Now I want to correct it.
  • I read some page and follow a LocalName link from it, but the page doesn’t exist any more or the address have changed – so I want to correct it.
  • I want to discuss something that is linked as LocalName, so I want to make a normal page with the same name, and put the link on it, instead of keeping it linking directly.

Of course, there is a fourth case, where a spammer makes near links that have to be removed, but I think the mechanisms that are good for the above three cases would be good for that case too.

I don’t have a sufficient understanding of all of the LocalNames implications, much less all of the possible interactions with InterMap and NearMap processes, but I feel that this whole area of Naming is incredibly important. A few Observations drawn from my limited experience and current understanding…

  • Now that I am trying to “inter-link” pages among several WikiHive(s), I find it helpful to…
    • ensure that there are common InterMap blocks in the inter-linked hives.
      • I’ve even gone so far as to incorporate the …action=… in some of the InterMap entries and then mask that with an apparent standard PrettyLink? entry so that users that traverse several hives see the same “hwoDotCommand”(s).
    • since PrettyLinks? are rendered effectively at oddmuse destination sites, when they are part of an “<include…”, its been relatively effective to create a central version of this “microContent” and then propagate it via “…copy:http:…” commands. This is a bit slow, especially when two or more destinations are specified, but that doesn’t seem to be too big a problem since these saves are relatively infrequent and can be done in a separate browser window as a ‘background’ task.
  • I’ve been doing as lot of work with Tags and I can’t help but feel that there is a compelling need to consider Tag names in this deliberations too. I feel particularly strongly about this given the work that I’m doing with TiddlyWiki (in particular Eric Shulman’s adaptation) that provides a “tagGrid” plugin which generates a 2D matrix of page names for any pair of Tag vectors.
    • I’d be happy to explain this further if anyone is at all interested; but will certainly understand a “deafening silence” response since this quickly moves into my views on scalable EnDimensionalArray? processing (something that I’ve only managed to discuss with APL aficionados so far).

Define external redirect: PrettyLink PrettyLinks EnDimensionalArray

EditNearLinks: WikiWords SourceForge WikiWord