Wiki Wiki Suggestions

Suggested Pattern for a New WikiCitizen adding to this page: Read it before you write to it.

I moved some suggestions for WikiWiki that seem to have been taken care of, but still have information value, to WikiWikiSuggestionsResolved. I was pretty conservative, so there are probably more suggestions that should be moved. Maybe we should also have a page WikiWikiSuggestionsDismissed?, but it's for Ward to decide what goes there. -- FalkBruegmann

I considered removing the reasons from the suggestions, but felt that was too drastic. -- SomeoneElse

Oh WikiMasters, please bless this page with elegant touches, for it has been Thread Bane for many aeons. -- JamesCrook

See also: WikiInnovations, WikiWikiSuggestionsResolved, WikiFeatureIdeas.

Warning: Unattributed thready discussion on this page may get snipped. Sign it or lose it. -- WikiButcher

WikiWikiSuggestions categorized:

Numerous suggestions extracted to WikiWikiSuggestionsSimple, WikiWikiSuggestionsMedium and WikiWikiSuggestionsDifficult.

WHERE: Wiki Admin doesn't need to do anything. He relies on a WikiCitizen to deal with the suggestion.

Suggestions that have been implemented already

If pointing out that a suggestion has already been done, please mention it here and then delete the question-answer pair after a few months when it is likely to have been read. See also WikiWikiSuggestionsResolved!

Suggestions that solve a problem that isn't a problem:

WHERE: Wiki Admin waits for / joins in discussion

For the 'Less Concrete Proposals' the ideas would need discussing before / if they will become part of this Wiki. Some of that discussion may happen on the proposers home page, so it is worth looking at these people's home pages for interesting discussions too.

Places where ideas are/have been tried out:

AnswerMe: Can someone change these to hyperlinks?? Do we need to move this to WikiIdeasTriedElsewhere?

for a working prototype (of LikePages) -- JeroenMostert. LikePages is now standard. Cool.

With apologies, some words of wisdom, taken a bit out of context... -- TheRefactorer

Wiki's refusal to accept single words as concepts worth explaining often leads to increased precision in naming concepts. Consider replacing AComputer with a DigitalComputer? or a PersonalComputer. I recommend using singular names unless the concept is always plural. This can lead to awkward usage, for which I apologize. -- WardCunningham

Don't think the wiki heritage is being ignored. By studying the server logs, I have determined that WikiReadingHabits are diverse. -- WardCunningham

I don't think it would be good if wiki spent that much energy talking about itself. I'll remove the fluff. -- WardCunningham

New and unfiled suggestions

Gnomes: please help out by moving suggestions to WikiWikiSuggestionsSimple, WikiWikiSuggestionsMedium and WikiWikiSuggestionsDifficult as appropriate.

EditHint: Much of the rest of this page might benefit by moving to the proposers' home pages

Wiki Name Inheritance Schemes

Some of my wikis provide an inheritance scheme for name scoping. I've explored single-inheritance. I imagine a multiple-inheritance approach would be a win.

One Wiki per subject. New wiki are created with a back-pointer to the wiki from which it was spawned, so we have a tree of namespaces. These are searched in last-to-first order. For Lispers, a name space looks like a Lisp "environment". I define a CommonWiki? that has all the usability pages. Individual Wikis inherit the common pages.

-- TomStambaugh

Implementation Details

A couple of suggestions...in WikiBase you use $&. I don't know which version of Perl you have but there are performance penalties for using that - much better with recent perls (it used to add about 50% to the running time, now its about 10%) - anyway it still helps if you bracket your regexp and use $1 (say) instead.

In my own WikiClone I used [a-z]{3,}: as the protocol pattern - you'll find that (for example) 'https', 'ldap', 'javascript' and 'about' links don't work on this Wiki instance, and the above stops you worrying about the ever growing list of url protocols.

-- BrianEwins

Caching details

It'd be great if some kind of 'Last-Modified:' HTTP-Header could be added to the pages. This would solve most problems with webcaches.

It's not quite that simple. For one, most web servers don't honor the "If-Modified-Since" HTTP request header for CGIs. And if they did, there's another issue: If you base the last-modified date on the underlying database entry or file, you risk missing other transitions that effect the visual representation of the page, such as an embedded Wiki link transitioning from inactive to active.

One method I've thought of implementing in my wiki clone is a system of caching formatted pages to disk ...
  • if the file exists, serve it
  • if it doesn't, build it, save it, serve it
  • if a page gets created, delete all backlink files
  • if a page gets deleted, delete all backlink files
  • if the TextFormattingRules change, then delete all cached pages

Thus, only the first read of any page incurs the processing expense, and all subsequent reads come straight from disk.

It's assumed that
  • there are many more reads than there are creates or "deletes", even if weighted by the number of back links,
  • deleting a file is a trivial processor expense,
  • reading a pre-formatted page from disk is less expensive than reading the page from the database and then formatting it.

Thinking more .. if the wiki in question allows for customizable header/footer per user preferences, then what would be saved to disk would be NakedWiki which gets wrapped with a simpler cgi (still less expense than formatting each time).

(Is there a page to specifically discuss this idea of caching pre-rendered wiki pages? Perhaps FilesystemBasedWiki?)

WikiWiki email list

Set up an email list server for WikiOnWiki and other ephemeral content. Put a link at the bottom of every page that says something like: "Send comments to list" and opens a new mail to the list with the page name as the subject. The link could also be on the edit page. We'd also need a link in order to (un)subscribe to the list, perhaps on RecentChanges.

It might eliminate a fair amount of noise here. There are certainly conversations that go on that would be better suited to email.

This is one reason why people should sign what they write, and have an email address on their home page. I've received lots of email from fellow Wikians this way that has probably prevented quite a lot of noise content on Wiki. -- JohnPassaniti

Change the implementation of making FullSearch. Currently, all titles are linked to http://c2.com/cgi/fullSearch, which is unfortunate. They should instead be linked to http://c2.com/cgi/fullSearch?PageName, and this has several reasons:

I don't have any references ready, but I don't think opera has a bug when caching the page. Furthermore, I think a WebBrowser does not have to send the RefererHeader?.

WardCunninghams answer on this on the page WikiWikiSuggestionsResolved is: The search uses HTTP_REFERER. If you block this then it won't work. I use this obscure mechanism because it keeps dumb spider software from issuing zillions of searches. -- Ward

In this case, you should define RobotsDotTxt.

Didn't work. Email-sniffing spam-feeding spiders ignore RobotsDotTxt. The DenialOfService they caused is what inspired the current FullSearch implementation.

Here's one I wasn't able to find here already - A lot of pages are book/movie references without much discussion. It would be nice if they could be collected several to a page, but that would require a WikiName that referenced an anchor in a page of another name. Perhaps a CompoundWikiName? would work? -- PeteHardie

Being a RecentChangesJunkie, I think the personal home pages (CategoryHomePage) should be filtered out of, or put in a separate block at the end of the quickChange pages. -- AlainRavet

Suspend TextFormattingRules in <PRE></PRE> blocks. 

 re.sub(r"(.*)",r'<I>\1</I>',text)
This python RegularExpression to implement wiki italics is itself mauled in display by Wiki's text formatting. I noticed this kind of thing trying to read some of the code for ShortestWikiContest. -- AndyPierce

A special syntax for suspending text formatting would perhaps be better.

One that I can think of is integration with the navigation bar in recent builds of MoZilla? (back, next and up links). I dont know how they would be applicable, but hey... -- AluoNowu

Recognize URLs beginning with 'https' as links (or use the pattern suggested above [a-z]{3,}:) -- AlexChapman

Recently (in the last month or so), I've been unable to reach c2.com, after sitting down this afternoon and trying to figure out why, it appears the firewall between here and there sets the "TypeOfService?" bits for TCP's SYN packets. There is a firewall between here and c2.com that drops packets with the TypeOfService? bits set. As I can reach nearly every other website except c2.com, I presume that it's close to c2.com. I've fixed my end not to set the TypeOfService? bits at all when sending to c2.com, but how many other people are having the same problem? -- PerryLorier

Adding accesskeys (http://www.alistapart.com/stories/accesskeys/) to all the different links on a wiki page would be handy. We could then access EditText with Alt-E, QuickDiff with Alt-Q, BackLinks (the title) with Alt-B and the FindPage with Alt-F. There are still a few browsers out there that do not support accesskeys, but they would just ignore the attribute. -- JohannesGijsbers (incorporated comment by VickiKerr)

Anchors, inner links, PurpleNumbers etc

What I think missing in a Wiki is an easy way to create inner links (anchors). (<a name="#...">; <a href="#...">) For a kludge suggestion, see PageAnchor.

All inner links should result in a list at the top of the page. This feature is absolutely necessary in creating good access to larger pages!

My take on this is if a page is long and there's a clear subtopic worthy of an anchor, it's probably time to ExtractPage.

CategoryWiki

I respect most of you old farts, but I understand most of you aren't around any longer.

Furthermore, this wiki is still very much alive, and we should celebrate that by acknowledging precedent.

By precedent in these terms, I mean, we near to incorporate a date/time stamp into each additional comment produced.

I think at first thought that the benefit of having a time stamp on each subsequent comment far outweighs the possibility that any dildo can produce a comment that is completely irrelevant and may, for dexterity, not be eliminated as is the current, wonderful setup.

As I peruse these snippets of wisdom from the ages, I relate this experience to case law. And as much as I'd love to see some precedents vanish and others thrive, dates can be important in considering the weight of comments and the history of computer science.

I don't want to see a reddit jackass scenario, but I think if this is thrive and prosper and be relevant to future nerds, then we must do this. That is all.

- DM Grant

EditText of this page (last edited March 9, 2014) or FindPage with title or text search