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:
* [http://example.net/ ExampleLink]
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:
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…
…” 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.