MeatballWiki

Please log in to access this page.
Please log in to access this page.
Please log in to access this page.

MeatballWikiSuggestions

This page was created in the hope that suggestions here will be moved to MeatballWikiFeatures once they are implemented.

Suggestions that appear on this page:

  • Minor-edit help
  • Automatically-generated Named Anchor Summary
  • ALL-CAPITAL LinkPatterns
  • Rewriting URLs to help search robots
  • Add META tags describing page content
  • More user-friendly link bar
  • More consistent banner
  • Community banner in link bar
  • Limiting searches by proximity to a given base page
  • Page neighborhood
  • Popular referrers for page (see UseMod:WikiPatches/GetReferersBar)
  • Create an auto-generated RecentAuthors page (analogous to RecentChanges)
  • User prefs: specify (by URL) a CSS stylesheet to use
  • User prefs: specify (by URL) a JavaScript file to use
  • UnWantedPages
  • Syntax to mark inline "code" text (i.e., combined functionality of the <tt> and <nowiki> tags)
  • Syntax to disable auto-parsing of LinkPatterns, without affecting other markup
  • Syntax to mark text as stricken
  • Place "edit this" link at top of page
  • Use the <label> tag in the HTML source for the "minor edit" checkbox

Suggestions that have been placed on their own separate pages:

(Some suggestions on other pages may be found through CategoryMeatballWikiSuggestion.)

Please add new requests to the end of this page.

Miscellaneous comments (always welcome)

Cliff, thanks for taking the time to do all of this. I think it is useful to experiment with changes that may make Wikis easier to both read and write. I like conducting these experiments on a site where these discussions are on-topic. Perhaps if people on WardsWiki see them when you have made the changes, we could get Ward to do something similar on his Wiki.

Minor-edit help (being considered)

You might want to change the minor-edit checkbox text to be "This change is a MinorEdit" and link to the MinorEdit page.

I'm considering this, but I'm also thinking of a general "help" page for the edit-form. A help page could also give a brief overview of formatting and describe the purpose of the summary, minor edit, and edit-copy functions. --CliffordAdams

You might also want to make a help page for the whole of the wiki. Just splat something else on the link row at the bottom of the page. "MeatballWiki | RecentChanges | UserPreferences | WikiHelp" -- SunirShah

Orientation towards the bottom could be called anal, BTW. ;) Man, I just HATE scrolling for the links. -- JürgenHermann

Sounds like another UserPreference to me. I'll probably keep the links on the bottom, and add an option (default off) to also display the "Goto Bar" on the top. (Personally, I don't like having a lot of interface stuff at the top. I like having just the title followed by the text. Even the logo will probably become optional (default ON).) [See the preferences to enable/disable the top link bar.]

Putting things at the top of the page strongly suggests making them small, so I recommend setting "font size=-1" and using a format like Link | Link | Link (with no additional text). ((Editor's note: I can't tell who originally wrote this line. --JustinMcMurtry, 2006-06-04))

I've been experimenting for a while with various layouts for lists of links. I believe in unobtrusive sidebars. Here are some examples:

Notice how with the booklist I list them first on the left and again on the bottom. This is much more LynxFriendly than only listing them once. -- SunirShah

ALL-CAPITAL LinkPatterns

One possibility is to support an all-caps pattern, for words such as PHP or WIKI.

One of the few wiki "traditions" I like is the restriction of the LinkPattern. Even relatively generic terms like PhpLanguage, WikiServer, or UglyLink give more information than bare PHP, WIKI, or Wiki:UgLy words. (The "UgLy" term is beautifully self-referential, however.) Several wikis have chosen free-form links like [link text here], which also allows links like [PHP] or [wiki]. I don't think I'll follow that example, but I can understand the reasons for allowing such links.

The current UseModWiki does allow UseMod:SubPages to be single words (with the first letter capitalized). This is allowed because the main page name provides a context for the subpages (like UseMod:SubPage/Discuss). Also, the current LinkPattern allows pages like "UglY" (or even "UGlY"), since it doesn't require the trailing any-letter region (regex * instead of +). After a lot of thought, I now consider this a feature. One use of this feature (on another UseModWiki) was UserNames like JohnS for John Smith. (That wiki is for a small group where most people know each other.) --CliffordAdams

I'm even hazy on the current MeatballWiki pattern. I'm still not sure whether InterNIC or InterNic is the better choice, but I went with the correctly spelt one as you can see. LinkPatterns need to be chosen with care. They really can set the tone for the wiki. Just consider the horrors (or benefits!) of a freeform LinkPattern. -- SunirShah

I've been reading and occasionally writing to public wikis for about a year now, and have been running a company-internal wiki for software development for a few months (UseMod, of course). Although I originally liked the LinkPattern concept, I have changed my mind since running the internal wiki. Our wiki discussions are mostly about the software that we work on, and is thus replete with references to files, classes, functions, etc., many of which match the LinkPattern. So a page often ends up with dozens of unwanted question marks. (We have no intention of documenting such code details on the wiki -- we are starting to use doxygen for source code documentation.) I'm even considering turning off the traditional wiki LinkPattern, if I can find the time to rename the existing pages (or update their links to free link form). I also think it's easier for users to understand the free-link notation.

The "<nolink>" suggestion farther down this page would have been another possible solution to our problem, but really not as convenient, since so much of our text contains incidental LinkPatterns.

This is not really a suggestion, just an observation. Obviously, the LinkPattern lends a distinctive flavor to a wiki, and for more general text it does not cause these kinds of problems. - DanMuller

Rewriting URLs to help search engines

It would be nice to see URLs rewritten in the form http://www.usemod.com/mb/RecentChanges.

[Comments about browser caching removed; no caching problems observed on MeatBall for quite some time.]

I've been meaning to look up this kind of thing, but I guess I don't have much excuse now. I will probably make these behaviors options (Cliff likes options ;), and default them to the old way (at least at first). I don't want to make <tt>.htaccess</tt> and <tt>mod_rewrite</tt> access a requirement for using UseModWiki, but it seems like a useful option. Another idea I've considered is allowing the cache behavior to be a per-user option. This would require an accurate Last-Modified date taken from the page being viewed. (Pages like RecentChanges would be an exception.) I'm not sure this will make it into 0.90, since KeptPages, the database upgrade, and a planned code-reorganization are making the next few weeks seem rather busy. --CliffordAdams

Any chance we'll see this done with MeatballWiki itself? -- anon.

The problem turns out not to be quite so simple in practice, especially if you have subpages turned on. With subpages, a URL like http://www.usemod.com/mb/FooBar/Discussion would cause the browser to think that all relative references are actually in /mb/FooBar/, instead of /mb/. This can be worked around in the mod_rewrite rules though.

Second problem is that there isn't much point in supporting that simplified URL format if no one knows about it (or remembers the fact), which would likely be the case if the wiki engine is spitting out the usual /cgi-bin/mb.pl?parameter links. Thus, the wikiengine needs to be hacked to generate the simplified URLs. That much is simple to do ... but then you now have a wiki engine that's generating static-looking URLs for lots of extra links that shouldn't be static (and shouldn't be tempting to webcrawlers). Inserting an extra parameter into the ScriptLink subroutine is easy enough, although it then requires patching all the calling instances to include that parameter.

For an example of a usemod wiki which has been modified in this manner, come visit the IaWiki http://IAwiki.net/

-- EricScheid

Add META tags describing page content

The site would index better if the search engines were aware that WordsSmashedTogetherLikeSo were really "Words Smashed Together Like So" (so to speak). To that end, I recommend adding some META tags during the page generation:

  • <META NAME="KEYWORDS" CONTENT="WikiName Wiki Name">
  • <META NAME="DESCRIPTION" CONTENT="WikiName Wiki Name">

This will fail for pages like InterNIC, but it would definitely improve the average search case from Google. (Consider <tt>theoryofrelativity</tt> vs. <tt>theory of relativity</tt>).

I'm considering this--it might go into 0.90 or 0.92. (Adding the feature is easy. Testing it is another matter.)

When I wrote my WikiEngine (within Emacs), I decided to use the first paragraph with at least two sentences as the meta description tag. This works astonishingly well. In a second step, I've pulled all these "summary paragraphs" together into one huge site summary page http://www.geocities.com/kensanata/wiki/SiteSummary.html. Take a look at the page. All the paragraphs read like decent summaries / suitable meta descriptions.

More user-friendly link bar

I'd like to make it easier for new users to get into MeatballWiki, which is nearing 1,000 pages of disorganized splendor. I think a big and shiny "StartHere" link on the link bar would be helpful, and baking CategoriesAndTopics into the site just a little more would also be helpful. Especially since it encourages the further use of categories. Consequently, I'd like to make the following patches (in bold):

sub GetGotoBar {
  my ($id) = @_;
  my ($main, $bartext);

  $bartext = '<strong>' . &GetStartLink() . '</strong>';
  $bartext = ' | '  . &GetPageLink($HomePage);
  if ($id =~ m|/|) {
    $main = $id;
    $main =~ s|/.*||;  # Only the main page name (remove subpage)
    $bartext .= " | " . &GetPageLink($main);
  }
  $bartext .= " | " . &GetPageLink("RecentChanges");
  $bartext .= " | " . &GetPrefsLink();
  $bartext .= " | " . &GetCategoryCategoryLink();
  if (&GetParam("linkrandom", 0)) {
    $bartext .= " | " . &GetRandomLink();
  }
  $bartext .= "<br>\n";
  return $bartext;
}

sub GetStartLink {
    return &ScriptLink( "StartHere", "StartHere" );
}

sub GetCategoryCategoryLink {
    return &ScriptLink( "search=CategoryCategory", "Categories" );
}

You may want to replace the magic string literals with variables in the <tt>config</tt> file. -- SunirShah

Why not make it HelpPage? -- CliffordAdams

The reason why I want to call it StartHere in <STRONG/> tags is because it is a big loud suggestion to START HERE! It can be used as a help page. People will get that idea after they START HERE! -- SunirShah

How about simply changing the "home page" of Meatball? I could also make an option to wrap the homepage link in strong tags. After all, what's the purpose of a (separate) home page if you want people to start somewhere else? --CliffordAdams

Category Link:

I don't think the category index searches are common enough to be worth putting on every page. I think it would be much better to create a linkbar along the top of RecentChanges with a few common indexing methods. You could even create a kind of category-bar with the most common categories like:

Categories: [Home Pages] [Wiki Technology] [Interface Design]

-- CliffordAdams

I'd like the category system to be used more, so I'd like to encourage it explicitly. A little CommunityExpectation magic. Further, there are a lot more common categories out there that haven't been created. CategoryWebLog for instance. I don't want to limit it to what we've created so far despite our laziness. -- SunirShah

I'd rather keep the common interface simple. The RecentChanges page should be sufficient exposure for now. Using RecentChanges also makes it easier to present multiple different methods of organizing pages, like the existing StartingPoints. (Personally I think that using a wiki page like StartingPoints with described links is far superior to a raw dump of categories.) --CliffordAdams

More consistent banner

Please make the following patch:

sub DoEdit {
      ...
      $header = "Editing " . &GetSearchLink($id);
      ...
      print &GetHeader("", $header, "");
}

so that the edit page has BackLinks too. (I removed &QuoteHtml($header). Is this bad?) -- SunirShah

The edit page is supposed to be different from the ordinary browse page. I also don't know if it's really valid to have links in the page title (in the HTML header). (You could work around that with a bit more code.) -- CliffordAdams

The patch I submitted changed the <H1/> title, not the <HEAD/> section. This is useful when defining one of the WantedPages that you've stumbled upon and you want the other contexts in which it has been used. I certainly use this feature when it's available on other wikis. Currently, I just punch in the search= URL manually, but that's not really intuitive. -- SunirShah

The patch changes the $title in GetHeader, which is used for both the HTML header and the H1 title. Still, the search does sound useful, so I may add a search link to the editing page. --CliffordAdams

Community banner in link bar

In addition to the static contents of the link bar (MeatballWiki | RecentChanges | Preferences | Random Page), have a community-editable chunk of text inserted there ... it would thus appear on all pages and not rely on the visitor going to MeatballWiki or RecentChanges. Limit it to the first N words before the first horizontal rule (thus leaving a place for discussion below). Have it do LinkPattern changes (but not style formatting, and definitely not image URLs).

Pro: This could be used to organise BarnRaisings, to highlight discussions important to the community (like "pay up or we shut down"), or even to display MOTD inanities.

Con: Open for abuse (but then, that's what SoftSecurity is for).

--EricScheid

See FortuneCookie, specifically ZWiki:AnnoyingQuote

UseModWiki 0.92 allows the admin to add arbitrary HTML at the end of the linkbar. If users want to annoy the entire community, editing RecentChanges should suffice. --CliffordAdams

Limiting searches by proximity to a given base page

Rationale: More-directed searching provides more-relevant results.

Example: Go to SoftSecurity and try finding "role model" in the text of that page—fail. Now try searching for "role model" using the search function built into wiki—fail for a different reason.

Suggestions:

  • Offer the ability to "Search this page and all directly-linked pages".
  • Indicate in search results the number of "hops" between the current page and each found page

Questions to consider:

  • How would this feature affect the evolution of pages in the wiki? If one were to search only proximal pages for a term and then not find it, would one be tempted to create a new page (instead of linking to an existing but distant page)?
  • Is this feature technically feasible to implement? Would it be too computationally intensive to find the "hop" count between each of many pairs of pages?

Compare: Page neighborhood (below)

--EricScheid

Page neighborhood

(Is there something similar to this already?)

This feature would allow a user to input a page name, or a list of page names resulting from a more general search, and then return a list of all the pages that are linked from those pages, sorted and grouped (with "hop" counts).

The collation could be done in either direction:

  • Remote pages grouped under the input page(s) — This resembles the "from here to there" perspective. It could be used to show those pages that link to many useful-looking pages. However, it could be cluttered with lots of distracting links, such as signature links.
  • Input pages grouped under the remote pages — This would be useful for finding the referenced pages which have a high relevance. It would also show up those signature links which appear on most pages.

Now that I've written this, I'm more convinced this would be a useful navigation tool. Not all searching and navigation needs to be global (site-wide), and this short-range navigation would assist the information scent foraging instincts. (dang it, I need to learn more perl)

--EricScheid

Popular referrers for page

Similar to clicking the title of the current page to reveal all of its backlinking pages, include an option (possibly on that backlinks page) to reveal the top X referrers to that page, including perhaps even non-wiki referrers.

A first patch implementing this concept is in UseMod:WikiPatches/GetReferersBar. This patch tracks both referring and referred-to pages.

Pros:

  • Popularity implies relevance—more directed browsing, or more viewpoints for determining where to go next
  • Oddities arouse curiosity—if some mundane page is generating a lot of referrals, what's the story?
  • Off-wiki referrers are identified—allowing the referrers' context to be explored, thus feeding more information into the wiki-mind

Cons:

  • This would take even more data-logging and CPU power (but that's what computers are good for, right?)

See also:

--EricScheid

Create an auto-generated RecentAuthors page (analogous to RecentChanges)

Grep the RecentChanges and RecentEdits, extract the UserNames, sort and collate ... might work to generate greater sense of community ... sometimes I feel like some lonely ghost wandering the corridors of wiki, not seeing the other ghosts, not knowing who else is there.

--EricScheid

User prefs: specify (by URL) a CSS stylesheet to use

A user preference to specify a URL to a CSS stylesheet for this wiki. Improve the experience for community members. Not thinking about stylesheet vs wiki content, just the whole page viewpoint. -- EricScheid

I believe CliffordAdams is working on it. BTW, CSS doesn't work with IE for PocketPC. --DaveJacoby

CascadingStyleSheets are an option for the site administrator, but not the users. I'm considering a user option for stylesheets, but I may wait until I implement an "Advanced Preferences" page (since the current Preferences is already a bit larger than I like). --CliffordAdams

I've looked into UserStyleSheets in the meantime, but have found that they are not site specific - they apply to every site you visit. So, unless the wiki you visit goes to the trouble of tagging their pages with a class attribute you could key off, your user style sheet will apply everywhere. Ugh.

I've installed UseMod 0.92 on a linux server and have hacked up the code to store a stylesheet setting in the user preferences. So far it [seems to be working], even at this basic level. I'm getting lots of ideas of how to extend the functionality by adding class attributes to different logical elements on the page (eg. being able to classify the link types) -- EricScheid

Update - I've further cooked the 0.92 source to provide semantic meaning to parts of the page. Try going there and setting your stylesheet preference to "/wiki.css" -- that stylesheet says anchors of class "UnknownWikiPage" should be small red links, for example. I've also defined a class for WikiPageLinks.

Do we like to vote, if the CSS implementation should be made as at IAwiki.net. My vote: YEA!!

Couldn't the CSS in fact be saved in wiki, too? like JuhaKrapinojaCss, for example?

--JuhaKrapinoja

User prefs: specify (by URL) a JavaScript file to use

Similar to the user preference for a stylesheet URL, a user preference for a JavaScript URL. The brave could go across to [my wiki] and set the URL to "/clippings.js" to see one possibility.

Raw output, not just naked

Unlike the NakedWiki concept, which strips off the site-context but still wikifies the content into an html page, raw output would simply provide the raw unwikified original text. Why would this be useful? Think of setting your stylesheet preference to a URL of a wikipage, one which anyone could edit.

UnWantedPages

Say there was a page named UnWantedPages, and on that page people copied various link patterns which currently show on WantedPages, and by virtue of appearing on that special page those link patterns would become demagicked ... no longer appearing on WantedPages, and no longer creating the action=edit link everywhere that link pattern appears. Like any page, there could exist other comments, if debate is required. Any page which does actually exist maintains its manna.

This could be used to deactivate UserNames of past visitors with no home page who are no longer active in the community, and to deactivate example link patterns without the tedium of </nowiki>.

Cons: if you're not aware of it you could get mighty frustrated when smashing words together to make a new link pattern.

This violates the PrincipleOfLeastAstonishment. The less magic, the better.

Simple syntax for inline "code" text

Now that I'm coding again, I find myself writing <tt><nowiki></nowiki></tt> a lot and it's a pain in the butt. At the minimum, it would be nice to use a tag to shortcut the two, like <code>. And the best, I'd like easier syntax. MoinMoin uses {{{ }}}, for instance.

The full rules of MoinMoin are that {{{...}}} on the very same line is inlined non-wikimarkup text, and on different lines it's a source display. Since using even six characters was annoying in developer wikis, this is now extended by ... (backtick characters) being inline verbatim typewriter too, which also is similar to reStructured text. -- jhe

Whatever it is, the syntax should distinguish between matching in a single paragraph and the whole document. In the former case, it should act like <tt><nowiki></nowiki></tt>; in the latter case, it should act like <pre></pre>.

-- SunirShah

I think the <code> tag does that. -- AlexSchroeder

Syntax to disable auto-parsing of LinkPatterns, without affecting other markup

Similar to <nowiki>, except that the only thing it suppresses is the LinkPatterns. Most useful for code blocks wherein you want to bold or italicize certain lines/symbols. Suggested tag for this purpose: <nolink>.

Syntax to mark text as stricken

HTML 3.2 includes a <STRIKE> tag pair, which draws a horizontal line through the tagged text, striking it out. This would be useful in editing/refactoring content ... for those occassions when the plain english explanation [of edited text] is just way too long winded. Its a conventional editoring technique/markup, and bridges the gap between incorrect content and corrected content.

example
on the MeatballWikiBugs page I just inserted a correction and comment regarding the KuroshinSubmissionQueue page being too long to edit. It would have been simpler to just <STRIKE> the "currently" and insert "no longer". Would've been easier to read, and less clumsy.

What should the text formatting rule look like though?

  • \stricken text\ ...?
    • ... won't work if the trailing \ is the last character on the line (is interpreted as meaning join with next line)
  • --stricken text--
    • ... nope, too much like legitimate usage of dashes/hyphens
  • --\stricken text\--
    • ... a fair compromise, by the looks of it

This turns out to be easy to do - insert these two lines into sub CommonMarkup, inside the if block which does the substitutions for '''''

   s/-+\/(.*?)\/-+/<strike>$1<\/strike>/g;   #   --/stricken-text/--
   s/-+\\(.*?)\\-+/<strike>$1<\/strike>/g;   #   --/stricken-text/--

This will actually match -/stricken/- and also -\stricken\-, and even ---/stricken/---, which makes the stricken text easier to read in the edit form.

While I was there, I also inserted the following two lines:

   s/\*(.*?)\*/<strong>$1<\/strong>/g;     #   *bold text*
   s/_(.*?)_/<u>$1<\/u>/g;                 #   _underline text_

mostly to support the conventions used in email.

Place an "edit this" link at top of page

The Edit text of this page link is a very important one... So important that it might be well-placed on the top link bar. There ought to be some easy patch for making this change. (BTW - I'm not suggesting that this wiki do this here. I'm simply putting this suggestion here because someone posted a statement saying that this suggestion page was very big on MeatBallWiki... and maybe even getting more attention than UseMod:UseModWiki/Suggestions... I'm desperate) --MatthewSimpson

If you are desperate and looking for a patch -- go for the source. Look at the sub GetFooterText. GetFooterText adds GetGotoBar and the edit link. Take that piece of code and add it to the GetHeader sub, right there at the end, where GetGotoBar is called as well. Don't be afraid to hack the UseModWiki script. Also note how I "faked" the link on my own homepage on this wiki. -- AlexSchroeder

Thanks for the ideas, Alex. And I gave it my best try... I get aborted because of compilation errors. I have no clue what's happening in the code. I did manage to change "Edit text of this page" to "EDIT THIS PAGE" which is some small success. So...... still looking for a way to add an edit link to the top bar.

It has been suggested elsewhere that the position of the Edit link at the very foot of the page forms part of the SoftSecurity: you need to know where to look.

Use the <label> tag in the HTML source for the "minor edit" checkbox

Fix the HTML output of MeatBall so the "This change is a minor edit" becomes part of the checkbox it refers to - currently it is violating good design!

You can do that with the label tag:

<input type="checkbox" name="recent_edit" value="on" id="recent_edit"/><label for="recent_edit">This change is a minor edit.</label>

See [the reference on htmlhelp.com] for details. -- EarleMartin

Here are two feature requests:

  • Split the words in the displayed titles on pages (e.g. above it would say "Meatball Wiki Suggestions")
  • Render links in change summaries as actual links on RecentChanges.

-- EarleMartin

An alternative to splitting the words in displayed titles or using a META tag in the header, one which should still have Google understanding the Meatball in MeatballWikiSuggestions, is to use the <tt>title</tt> element in inter-wiki links, e.g. <a href="mb.pl?MeatballWikiSuggestions" title="Meatball Wiki Suggestions">MeatballWikiSuggestions</a>. Might help out screen readers, too. -- ChrisPurcell

CategoryWikiTechnology CategoryMeatballWiki

Edit this page | History