Our pages are getting a bit complicated; We regularly have:

We are making a regular form, just so things are a little more consistent. That said, these are just guidelines.



Issues under Discussion

“The Table.”

For anything that we haven’t agreement between at least two people about, I’m putting: “under discussion,” in bold.


The section leading up to the first division is general overview text, or a teaser text, because that’s what ends up on the FrontPage.

Divisions within the DocumentMode are level 2.

 == Division Within the DocumentMode ==

After the last division, if there are categories, tags, see also’s, or backlinks, there is a section called: “See Also.”

under discussion: Should we instead place “See Also” at the bottom, because it’s easier to find it there?

 == Last Divison Within the DocumentMode ==
 blah blah blah blah blah
 == See Also ==
 [[tag:A]] [[tag:B]] [[tag:C]] ... [[tag:N]]
 CategoryFoo, CategoryBar, CategoryBaz
 * link  -- explanation
 * link  -- explanation
 * link  -- explanation
 * link  -- exaplanation

The links can be WikiWords, InterWikiLinks, or links to web sites. Please include a friendly explanation, telling why it is linked, why it matters, whatever.

under discussion: It should be roughly one sentence long. Lower case first letter, (unless it’s a proper name, or whatever,) no period at the end.

under discussion: If you’d like multiple lines to explain a link, then capitalize the first letter of each sentence, and end all sentences with periods. Push the link down to the very bottom, because it’s “heavier,” and we don’t want to lose the one line explanations amidst the weight of the long explanation. And consider making it a section in it’s own right, or perhaps even it’s own page.

Ordering the See Also's

This entire section is under discussion.

The links and explanations can be roughly grouped into categories:

All of these appear in that last links list, within the “See Also” section. If you want to normatively order them, order them as written above.

Disclaimers: This issue of ordering them is just a suggestion, and we haven’t talked much about it yet. This is not to be overly pedantic. You can actually do whatever you want. This is just to help build consistency, if that is your interest.

Discussion Division

The Discussion header is the grand division in the page, between the DocumentMode and the ThreadMode.

It is a level 2 header.

 == Discussion ==

The discussion section appears just after the DocumentMode and it’s See Also’s.

Different sections of the discussion can be segregated from one another with level 3 headings.

 == Discussion ==
 blah blah blah
 === Discussion about Foo ===
 blah blah blah
 blah blah blah
 === Bar ===
 === Baz ===
 blah blah blah
 blah blah blah
 blah blah blah


We’ve been reworking the page, here are things we’re keeping.


Oddball Conversation & Ideas

Possibilities & Facts

See Also



I think:

Where do tags and see alsos and other metadata go?: I don’t like having them before the “discussion” because they’re really hard to find. I guess if the discussion heading was an H1 and if that H1 was really big, so that it would be really easy to scroll quickly down a page and find it, then that would be okay. But if the “discussion” heading is just another heading, then I don’t think it makes sense to put the tags and see alsos in the middle, and I’d rather have them below the discussion, the very last thing on the page (having them the very first thing on the page would be perfectly usable for me, but too confusing for newcomers).

Tags vs. categories: been meaning to mention this, so may as well do so now; right now tags are better than categories in that the software assigns extra semantics to them, which makes them more powerful (you can talk about the tag without tagging the page) and easier to use (new users don’t have to figure out the whole backlinks thing).

But I think they are missing something; there is no page for every tag like there is for each category. I like the way that category pages can help the community come to a consistent meaning for each category, and how they can point to a few “starting points” for people interested in that kind of thing.

I don’t think every tag should have to have a page named after it; one nice thing about tagging is that you don’t have to spend the extra time to create a new category page before you can use the tag. But I think it should be possible to do so. And I think the software should support it somehow so that new users realize that some of these tags have associated pages. An idea: when you search on a tag, the software gives you search results but also, at the top, the first segment of the associated TagPage?, if any (allowing us to associate an “introduction/definition” with each tag), and a link to that page (whether created or not) in case the user wants to go edit it.

After this, tags will be able to do everything that categories do, but will be better than them, so we should abolish categories. But right now I still like categories better.

Heh! Alex & I chatted in Gmail, and came to agreement. Now we have a 3rd party, with radically different concerns..! Ha! But it’s not your fault I didn’t bump into you.

I’m neutral on categories.

Actually, I prefer the TimeStampedMap, like the PublicWebJune2004Map, or the concept of “paths,” which I think are much more useful.

The reason being is that they create a meaning out of showing how ideas are connected, in a graph, either expressed in diagram (TimeStampedMap) or in words.

All our pages on wiki tell about how ideas are connected, the major difference is that these pages tell how pages are connected; How the pages on our wiki, in some subject, are connected. They form a memorable story out of the CommunityWiki pages.

The HiveMind page sort of does this, and I think it’s been a good thing.

Categories, on the other hand, seem more like a location mechanism, a means to find a page. And that location mechanism has been far surpassed by tagging.

Categories do tell that ideas are connected, on the wiki, but do little in the way of telling how they are connected. We get into that bucket problem again, where everything inside the bucket is just blanket connected with everything else in it, and we don’t really gain much insight into how.

I’m also concerned that the space of keeping Categories is particularly ripe for ChangeFailure. That’s why I want something that tries to be less comprehensive- a roadmap on some subject is not trying to be comperehensive. And, because it’s “just a page,” it’s much clearer that it’s tied to a point in time. Same with the TimeStampedMap.

And tags, … Well, tags are the Zerg hive, hoards of little guys, just… Swarming all around. They’re just magic, they just work.

Am I helping any? Are there any insights here?

I should probably write some of these arguments into separate pages, and I think I see a glimmer of rewrite into the venerable WikiNow

Well, first, I think the “page to discuss the tag’s meaning” is the more important point. But when I said that category pages give you some starting points, I don’t mean that category pages give you a map, or a ForwardIndex. I just mean, like, if you had CategoryCollectiveIntelligence?, then it would say, “and if you don’t have a clue what CollectiveIntelligence is, start at the page CollectiveIntelligence” (this particular example may seem obvious, but what about when you have one-word tags; then the tag won’t correspond to a page name even if there is a “canonical intro page” for that sort of topic).

So category pages do 2 things that tags don’t:

  • They help the community use the tags more consistently by providing a place to discuss the semantics of each tag
  • They provide a little bit of space to tell a newcomer what to read first, in case they have stumbled on this tag for the first time and are interested in it (what, you want them to look through the raw search results and try to find the canonical intro?).

And tags, … Well, tags are the Zerg hive, hoards of little guys, just… Swarming all around. They’re just magic, they just work.

Just like categories do. Categories and tags are the same thing as far as I’m concerned. I’m not saying that we should force ourself to make unified maps of the entire wiki (I’m the one who used to argue for CategoryCategory because I thought ForwardIndexs wouldn’t be maintainable, remember?). I’m just saying that wikis can allow us to, as a community, build an understanding of what each tag means. That is, where do you use the HiveMind tag, and where do you use the GlobalBrain tag, and where do you use the CollectiveIntelligence tag? In other systems, each tagger would have their own interpretation of the differences between these terms, but on a wiki, we have a chance to make tags less ambiguous by providing some of them with a corresponding wiki page.

I disagree with most of the things you just said, but it seems clear to me that you’d like to preserve the Category system, and I don’t see much point in trying to stop you from using categories. :)

So, I guess the disagreement is now between you and Alex.

Alex, do you care enough to argue a point here, or are you okay with including Categories in the page layout, or, … (both?)

I don’t really need “cateogry” pages per se. But incidentally they have a property I like very much on this wiki: They act as a ForwardIndex in most cases: Commented link to the various pages in the category – and links back to the index from the various pages. I like that.

Thus, if we have these kinds of pages, they don’t necessarily need to have a “Category” prefix as far as I am concerned, as long as they are used to list commented links to pages belonging the particular topic.

Okay! It sounds like you don’t mind them, so, we’ll keep them in the CW page layout. :)

So the remaining big ones are:

  • the “Discussion” divider- L1 or L2. I’m happy to conceed an L2, but I still have the question: “how do we segregate threads?” Perhaps “== Discussion About Foo ==” ..?
  • “Where is the == See Also ==?” Lion & Alex think “above discussion,” Bayle thinks “at the very end.”
  • Use L3 for the various discussion threads?
  • I hate stuff at the very end, because then I need to find the correct place to add my comments – I want to add my comment “at the very end.” How about in the first section, or just before the first section:
  see also
  == first section ==
  == discussion ==


  == see also ==
  * link
  * link
  == second section ==
  == discussion ==

L3 for sub-threads: Fine. It looks just like bolded text, but fine. (corrected, later on: L4 is bolded text, not L3.)

“See Also” near the top: ew, gross. ( sarcastic: ) How about at the very top?


  • More often than not, I’m attaching comments, rather than attaching tags or links.
  • I’m going to automate attaching tags and links.
  • When comments are reworked in (in theory?) then the See Also’s go back to the bottom. :) But if See Also’s are put at the bottom, they are always there, and don’t go anywhere else, meaning perpetual struggle with comments.
  • It’s more important to me that we are able to converse, than to attach see also’s. If I had to live with just one, (a false constraint,) I would choose conversation, over the See Also’s.

L2 and L3 look different!




OK! That allays my feeling about that.

But won’t having tags and see also at the top be really confusing for newcomer readers?

Although I prefer it that way, I understand not having metainfo at the bottom. How about putting it in the middle, and ensuring that there’s a named anchor for it so that a reader can jump directly to it? We could put some junk in the CSS to make a link to that anchor. The link could be at the bottom of the page. Then it’s really quick to scroll all the way down, hit the link, and be warped up to the metainfo.

We don’t have a wiki markup syntax for defining named anchors like this yet, right? We don’t want to just do [::Discussion] because we want that same anchor to be on lots of pages.

Heh heh, I just realized that Lion and Alex and I are split three ways on categories and tags:

  • Lion likes tags
  • Alex likes categories for their ForwardIndex properties
  • I like categories for everything except their ForwardIndex properties; but would prefer tags if they got a little more functionality

So Lion and Alex talked over IRC and satisfied each other but not me. I expect the TagGlossary? proposal on the page UsingTags will satisfy Lion and I but not Alex. To complete the symmetry, Alex and I should find something that would satisfy us but not Lion :) .

But won’t having tags and see also at the top be really confusing for newcomer readers?

At the top? Are you talking about at the top of the “See Also” section, or at the top of the page?

Because- we threw out the concept of putting them at the top of the page. We both agreed that they should go in the “See Also” section. (At the top of the See Also section, it so happens.) Or is that what you’re talking about?

Alex and I should find something that would satisfy us but not Lion :) .

Go ahead- test my mighty powers of compromise! I challenge ye!

I thought you meant top of the page, sorry

Okay! So, Bayle, are we okay with “See Also” just before “Discussion”..?

Well, what did everyone think of my “named anchor” suggestion? To reiterate, if it’s gotta be in the middle of the page, I’d like the metainfo section to have a named anchor and for the bottom of each page to have a link to that anchor (the link would be in CSS, not in the page source or in the OddMuse code):

“…a named anchor for it so that a reader can jump directly to it? We could put some junk in the CSS to make a link to that anchor. The link could be at the bottom of the page. Then it’s really quick to scroll all the way down, hit the link, and be warped up to the metainfo.
“We don’t have a wiki markup syntax for defining named anchors like this yet, right? We don’t want to just do [::Discussion] because we want that same anchor to be on lots of pages.”

Well, there’s Oddmuse:Local_Anchor_Extension, which I could install.

Boy, I really would like this! (It would really help me with the way I design pages.)

Currently adapting a french translation on GabaritPageCommunityWiki. Interested to know more about any recommended PageTranslationPattern? (a PageTranslation layout) which should be included in any page translated.

This has been previously a bit discussed on MeatBall:PageTranslation but I’m not sure for the new adaptation of a GabaritPageCommunityWikiImage.

How about adding in the top section :

    ''Cette page a démarré sur OriginalPageName - seul lien original de référence''
    * MainteneurPage : (the name of the PageMaintainer)
    * Traducteur(s) : (name of translator(s))
    * Relecteurs : (name of reviewers)

and just before discussion, as that has been discussed, a footer like :

    LangueFrançaise PageTranslation OriginalPageName

Any ideas welcome. Thanks.

My comment on OddmuseReallyIsTheBest resulted in Lion putting forward a number of points:

FrontPage & SiteMap & Blog seem redundant. I remember some of the original ideas we had at the time. All of these ideas were more or less experimental. Maybe the time has come to draw conclusions and revert some of these changes we made.

FrontPage was going to be for the occasional visitors – that’s why the XML link actually points to a feed reflecting changes to the front page. Personally, I’m not convinced that this worked. Do you think there are many people who are subscribed to that feed? Is there a way to find out via Feedburner? If nobody subscribed to it, then I think we can assume that the front page doesn’t work too well as an indicator of “what’s hot” – we’re better of with a commented list of starting points – a ForwardIndex of what we think is cool (and timeless). No inclusion of the page content, no extra RSS feed. Just a list of recommendations.

SiteMap was going to be the navigational hub, the über-hub that enables HubAndSpoke navigation of the entire site. I rarely visit site maps – not here, not on my own site, nor on EmacsWiki. I find that search works much better. If at all, SiteMap should end up as the bottom third of the new front page.

Blog was going to be a tool for internal communication. Stuff that was interesting now but possibly of no lasting value. In a way it was supposed to be a mix of administrative news and LionKimbroNamedIdeas, I guess. I can’t see any other way to put them on the wiki. Perhaps we should just call it something different and not link to it from the page header?

The XML link can probably be linked from RecentChanges. I agree. These days people should be smart enough and no longer need feed links at all. All decent browsers support the feed meta information that Oddmuse provides. I think we should just get rid of the link. And as explained above, the feed should not be fed by FrontPage but by RecentChanges.

RecentNearChanges? can probably be linked from RecentChanges. Does anybody ever use them? Why not use a generic feed aggregator? I never use them. My suggestion is to just get rid of it. UnifiedRecentChanges is dead.

Other ideas:

Move away from Google again. I’m not very happy with our Google search. How about trying to revert back to something built-in?

Search box in the header. I often feel we should have a search box in the header.

Sidebar and list of contributors too prominent. I guess we planned to give the wiki a more human face. But with our portrait support it already looks pretty human to me. Do we really need the list of contributors on every page? I think we don’t.

Lately, I’ve been making a lot of use of the “<aggregate…” module to build pages that are made up of the first section(s) of sub-pages. I’m not sure this will work for others, so I’m uncormfortable recommending it here, but I’ve found it to be a very efficient way of building up some very large pages.

Oh, no doubt that it can be useful. But I think that our front page needs a process to keep the aggregation up to date, and it doesn’t work. People don’t think of adding pages to it, people hesitate to take something off it, etc.

re: FrontPage, SiteMap, Blog – anything to simplify these, is great today. I don’t even particularly care how it is done, since I never use any of them..!

RecentNearChanges? – I use it daily. The reason I don’t use a generic feed aggregator is because I only keep up with CW & MB; Pretty much nothing else. When I check your blog, it generally is because it shows up in my gmail, or something in Twitter. I don’t use aggregators because… My whole effort is to read less online, not more..!

But if you want to get rid of RecentNearChanges?, it’s fine by me.

Google search – agreed: I don’t like it’s search. Built in is great, and I especially love tag sensitive search. Constructing indexes by hand is, of course, the greatest, but that is called “Category” in our system.

I still think the answer to all categorization and indexing woes is simply mass operation by download and then upload, which I have not worked on. :(

“Search box in the header” – what does that mean? I don’t understand – in what header?

SideBar – I still absolutely love the sidebar – it gives super-easy access to all the contributors, their websites, and so on, … If you want to toss it, “okay,” but it’ll substantially detract from the “home” quality of CW, to me.

Ok, so we have some priorities: improve search, think about FrontPage, SiteMap, and Blog.

And some contested issues that we don’t need to touch anytime soon: Sidebar, RecentNearChanges? (although we might remove it from the top of every page, as long as it remains accessible somewhere).

Regarding mass upload and download: It’s possible to download many pages as plain text, work on them, and upload them again using shell scripts as described on BackupThisWiki. If you upload a page unchanged, it doesn’t even register as a change, so no problem, specially since activity on this wiki happens only on a small number of pages on any given day. All of that without actually needing a version control system.

Search box “in the header” refers to putting it at the top of every page (header vs footer of a page). Right now it says “FrontPage SiteMap RecentChanges RecentNearChanges? HowTo Blog Matching Pages: __________ XML” at the top. I’d suggest “FrontPage RecentChanges HowTo SiteMap Matching Pages: __________ Search: __________” instead, I guess.

In other words:

  1. Add “Search: __________” to the top
  2. Move RecentNearChanges? to RecentChanges
  3. Make SiteMap less prominent

I’d also rewrite Front page to be a simple welcoming message.

Define external redirect: CategoryCollectiveIntelligence RecentNearChanges TagPage TagGlossary PageTranslationPattern

EditNearLinks: HubAndSpoke DocumentMode WikiWords EmacsWiki InterWikiLinks