Übersicht Letzte Änderungen Letzte Änderungen in der Umgebung KurzAnleitung Blog RSS

CommunityWikiPageLayout

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.

Overview

CommunityWikiPageLayoutImage

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.

Layout

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 ===
 
 blah
 
 === Baz ===
 
 blah blah blah
 blah blah blah
 
 blah blah blah

Reworking

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

Quotations

Oddball Conversation & Ideas

Possibilities & Facts

See Also

CategoryThisWiki

[::Discussion]

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:
  intro
  intro
  see also
  == first section ==
  bla
  == discussion ==
  bla

or:

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

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?

Bayle:

  • 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!

L2

L3

L4

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.

Diese Seiten lokal erstellen: PatrickAnderson InterWikiLinks WikiWords DocumentMode

Sprachen: