MeatballWiki | RecentChanges | Random Page | Indices | Categories

Meatball runs on the UseMod wiki engine, which supports, among other things, the notion of a [subpage], which adds a little hierarchy to pages as an aid in refactoring. However, this mechanism appears to have been specifically disabled for this Wiki, which of course brings up the question of "why"?

There are all sorts of good arguments against deep hierarchical classifications, but subpages do no such thing -- they only ever go one level deep. Meanwhile, pages like SunirShah are becoming massive tomes one must scroll down to in order to see new changes. Changes made in the middle are hopelessly lost. It's ironic that in the modern age, we're moving back to bulky scrolls to put our text on. Using a homepage might not be the best example -- it's Sunir's prerogative how he wants to keep his page after all -- but others who want to keep large amounts of text readable to others are forced to come up with bigger and more cumbersome WikiNames for the pages, creating lots of sprawl and stretching something that was reasonably elegant into a clumsy kludge.


We were against SubPages because of usability issues as well as a desire to keep the namespace uniform to build a consistent PatternLanguage. Those decisions are open to questioning. My homepage is indeed a mess. Hmm.. -- SunirShah

On [1] Ward Cunningham explains why WikiWiki employs a simple namespace, in the context of a discussion on SisterSites:

I thought I'd mention why I don't do hierarchy on my wiki.

I see wiki as a place where people work out the names of things that they will say. Since our spoken vocabulary is small, we must struggle to find words that carry value commensurate with the space they consume in our brains. Where works collide in wiki they will also collide in our thoughts. Usually that is a happy circumstance.

Still, we often establish the context of a conversation so as to avoid or at least disambiguate many of these collisions. And we have to note the context switches we make in conversation. The analogy of context switching I've chosen for wiki is SisterSites. Two sites are candidates to be sisters if the collisions in their vocabulary are likely to be useful. The reader, like the listener, has to decide where to take the switch.

As a sister, you should feel just the right amount of pressure to call thing that we share by the same names. It is a subtle thing, but very powerful when scaled. -- Ward

That's an edifying quote from Ward, but SisterSites are orthogonal to the organization of a single page within a single wiki. As well, this is not WardsWiki; I wasn't asking about subpages on C2, but on Meatball. Presumably Ward does not do the thinking or deciding on all things Wiki-related. -- ChuckAdams

Yes, that was intended as a see-also, not an appeal to authority. (Delete at will.)

I find the use of subpages make linking much more difficult. I have experience with two wikis that used subpages: KnowHowWiki and WikiPedia (in the early days). For KnowHowWiki, I found it almost impossible to link pages together (was that [[Learn about the Internet/Use a search engine]] or [[Learn about the Internet/Use search engines]]?), and I gave up on it quickly. For Wikipedia, subpage usage was so wildly inconsistent that it produced similiar problems. They were generally used to segregate fantasy world topics from the rest of the encyclopedia, which wasn't too bad, but individuals would carve up topics into subpages seemingly following no conventions whatsoever.

Maybe you could give some specific examples of how subpages would help MeatballWiki? -- StephenGilbert

Off the top of my head:

As for the difficulties in linking, these become quite apparent with WikiWords as well (thankfully we at least have redirects enabled to solve some of those). Expressiveness always opens the way to ambiguity. Restricting expressiveness just leads to kludges and resentment. Incidentally, subpages are sub-pages, and usually aren't intended to be linked to except from their parent or each other (referring to a subpage from a subpage always refers to a sibling -- the hierarchy only goes one deep). Looking down a bit, perhaps we could simply leap ahead to WikiFractality and skip SubPages entirely, but that's hardly a conservative approach.

I certainly don't think Javascript is the answer -- I'd prefer more structured markup that could be left to GreaseMonkey? as a value-add, but once you start requiring JavaScript for some functionality, there's whole bunches that could be left to the client side, until you get TiddlyWiki at the end of all of it (which is nice, but completely different). Not trying to argue a slippery slope, but I think we need to keep focus on server-side solutions if we want to find a solution.


Just like WikiSyntax is a nice-to-have, unnecessary, yet gracefully degrades, Javascript also can make the site more usable, yet gracefully degrades to people who don't need/want it. Besides, it's more fun to say yes and try it out now that FireFox? has made it finally possible to build nice web interfaces, than still believe we are stuck in the mid-80s. I mean, I am also seriously advocating a return to the GopherProtocol (and also a telnet interface), but I also intend to keep a HTML 1.x version of MeatballWiki, as well as move beyond into rich content. The original motto was Hypermedia with sauce, after all. OtherHypermedia is not just a list, but inspiration. -- SunirShah

I think the ProWiki engine is most developed with respect to subpages (WikiFractality, WikiContextuality, AutoLinkStrategies) and a lot of its projects use it, one way or the other. There is increasing good use. It makes wikis more orderly but also more complicated to use (you have more options). There are situations with a clear benefit (projects within a wiki, collaborative story writing, extended homepage space) but also such without (straight encyclopedias). Anyway, it's not enough to have subpages, you need supporting features (various link support, list, search, page creation, ...). This is where experience only slowly builds.

I think that Meatball can do without subpages but it wouldn't hurt either. Consider http://www.wikiservice.at/dse/wiki.cgi?MarkusRechberger and his extended user space (b***sh*t, he is now at 93 personal pages!). At the end of his homepage there is a LRU subpage listing that is automatically generated by a CDML command. Looks like something that Sunir might come to like. At Gr├╝nderWiki we have an experimental "article subspace" thats organized in a similar way - maybe that's a development that we will see at Meatball and that would run smoother with technology that supports it. -- HelmutLeitner

I'm amenable to whatever everyone else wants. My namepage is out of control. -- SunirShah

Well, the question is, why SubPages and not SubSections?? With all this javascript flying around these days, it is easy to expand and collapse sections on a page, and one can certainly link directly to a section by making the section title an anchor. That is, build an outliner. Our TableOfContents is a beginning to that end. Subpages are just kludgy in comparison. -- SunirShah

TiddlyWiki has another feature to help page navigation. Clicking on the TOC entry will create a small rectangle at the click position that will expand and drift over until it lies above the section references from the TOC. No folding and unfolding, just a little help to lead the eye and help you find your place on a long page. -- AlexSchroeder

Extending SubSections? is possible and there are surely situations where it would be nice to have better SubSections?, but it also means:

The question is: what for? To avoid subpages as a principle? Let's assume someone wants to configure a "discussion" subpage as part of the user interface. It make no sense as a subsection. Let's assume someone want to use wiki for publishing: have a "Private" page, keep articles as subpages there until they are ready for publishing, then a "Publish" button copies the current page to the top level. Such functions make no sense with subsections. -- HelmutLeitner

I think a CommentPage is better done as a hidden & shown SubSection? rather than a separate page. This way, discussions can easily be refactored into the DocumentMode body. We've done this for years. DocumentMode AboveTheFold (a horizontal rule), discussions below the fold. No reason to not keep doing it. -- SunirShah

Having non-public editing is a different usage case than sectioned pages. Consider that non-public editing could be one consequence of AlwaysEditing? mode, which could be a consequence of a clean WysiwygWiki, which is finally feasible. Consider this usage case: you can save to your own personal inventory of pages. With Javascript, the system can do this automatically whenever you navigate away from an edited page. Even if the system only kept the three last buffers, that would be a fantastic change in the workflow of a wiki. -- SunirShah

Keeping discussions with the document is good if refactoring is part of the game. If you discuss an article (science publishing) it makes little sense. PeerReview seems more logical on subpages. Discussion may also grow out of bounds.

Subsections done right, WYSIWYG done right, may be wonderful. But. tiddly-wiki doesn't work e. g. with Opera - when I first went there, it displayed nothing - no reasonable fallback. Our ProWiki Javascript e-learning extensions don't work with Firefox, nor with older browsers. Javascript isn't portable and some people turn it off for security reasons. -- I've not yet seen a reasonable WYSIWIG that really works, except non-wiki QuickPlace? using an extremely slow and limited Java implementation, which made you long for text mode. ... What's the point? I think there is no either-or. There is subpage technology, subsection technology, WYSIWYG technology and you can go for any of them (or none). ProWiki also has subsection features (addressing, jumping and backjumping toc, displaying and printing &section=nr &section=name, using separate template, ...).

There are more twists. I think ChrisPurcell had subpages display as sections. What does that mean? For example you publish articles like an online newpaper. You need a frontpage displaying the intros of today's (or most recently written) articles. Where do they come from? From a category? From current articles subpages? -- How do you get at the intros? First subsection of article page? -- Where are the articles prepared and peer reviewed before publication? If you need meta data for a page, where do you keep it? Voting data? How do you control visibility and user rights? User rights management down to subsections? -- HelmutLeitner

Some questions:

I agree that using a namespace as a blog/messageboard is a bad idea, though my reason is different (it prevents StableCopy from working, and hence prevents the DigestedSummary from clearing; it also prevents linking to messages and blog entries). However, exactly the same objections to PageClusters apply to SubPages, and the former was rejected as "leaving detritus in the WikiNow". -- ChrisPurcell

I don't know about you, but I see WikiNames like SunirShahBlogFirstHalfOf?2005 as a symptom of a problem, not a solution to one. As for the solutions that "transfer all data", from the point of view of bandwidth consumption, this can hardly be considered a feature. It costs more in hosting for a heavily trafficked wiki, it causes more edit conflicts (since there's only one page to edit), and takes more time to render. Wikis usually render quite nicely on small screen browsers, but huge pages take forever. I don't even know how to respond to "leaving detritus in the WikiNow", either here or in the paragraph the PageClusters page. Lacking a concrete illustrative example, it simply didn't parse as anything but opaque PhilosoBabble to me. --ChuckAdams

Quoth Sunir: When you created the page 'WhyNoSubpages' that was not in proper style, since the page is deeply temporal and not a Pattern or concept that can stand alone. So, before you cast hard judgments, listen a little to what is being said.

Could you elaborate on this a bit more? And try to avoid a patronizing tone this time? -- ChuckAdams

Chuck, you've been talking aggressively. You have said "this is an extremely egoful wiki," and claimed that BarnRaising is WordMagic and PhilosoBabble--which, by the way, is a needlessly negative, unhelpful page. I'm sorry that I was patronizing. I was offended by your claim that we were 'extremely egoful' comment. I don't think we are more egoful or more full of ourselves than most places on the 'Net, so I don't see how we could be extremely egotistic. SlashDot is way more into themselves than we are into ourselves, for instance.

I didn't mean to be offensive, but I was offended, and so struck back. My apologies. Let's chalk this exchange to experience, and try to settle into a better rhythm.

Our goal is to build a high quality resource. I want to do this constructively, positively, and by helping each other. This is never going to be perfect, and as volunteers we do not often do work that is not fun, but it doesn't mean we're purposefully trying to be obstinate. However, we don't need to be put on a defensive, since we are not obligated, and have a good working attitude besides.

Also, iconoclasm is fine if you are an outsider, but you aren't (and no one else is) an 'outsider' within this space. I prefer people spend their time here teaching each other. Teaching begins with listening, though. Understanding the current frame of mind of the student, makes it possible to identify areas that are in need of development. We may have a good reason for doing something, or we may not but we may just like it. We can change our minds as a culture, but obviously only will do so when someone within our culture takes the lead. Setting yourself up as an iconoclast puts you outside.

As for this page, it's not a Pattern or Concept, and thus should be on SubPages, which is the Pattern in question, as a simple matter of information organization. Keep related information together. In relation to WikiNow, if we implement SubPages as a result of the discussion, this page will become obsolete. But if it were on SubPages, the page remains relevant (as it has no temporal context), and the discussion becomes at the very least an archive of how we made the decision locally. -- SunirShah

<snarky>I'd rather make this a subpage of SubPages</snarky>. The way I see it, it is already connected to SubPages by way of the backlinks mechanism. I consider the question and discussion of "why no subpages" to be logically distinct from the explanation of the subpage mechanism itself. As a separate page, it can be given separate categories -- does this discussion (and now metadiscussion) really belong in the WikiTechnology categories, after all? I hardly think you'll get everyone to agree on a single namespace, especially when it's flat.

I'm often abrasive, and often mean a lot of terms pejoratively (I do call PhilosoBabble when I see it), but "egoful" wasn't one of them, and certainly wasn't intended in any negative way. I merely meant that this Wiki doesn't demonstrate properties of being "Egoless", so I coined an alternate term to mean its opposite. I suppose that created something of a false dichotomy; after all, how egoful can a place be that lets anyone write on anyone else's home page? But there's subcultures within c2 that don't sign anything at all, and this is in fact the norm in places like WikiPedia (which admittedly has a different mission, so it's a lousy analogy). I would call such places far more egoless than the tacit encouragement practiced here to sign everything one writes. Frankly, I consider this "egofulness" a good thing. I prefer to stand by my words, abrasive and all. --ChuckAdams

Backlinks aren't as strong as forward links since they are so. Note that SubPages has oodles of backlinks.

I only meant to say that since I was offended by the term 'extremely egoful', I was snarky in response. It wasn't an excuse or attack. Just a connection of what might have seemed like a non-sequitor. re: egos, let's concentrate that on its own page. cf. AttachedEgo. -- SunirShah


MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions