WikiDesignPatternsDiscussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories

I started on the project of working on understanding the pattern language design of Wiki earlier this week.

My goal is to try to understand the Why's better.

: Why do you do this?

: A bit of why I'm doing this can be inferred from my home page at ChristopherAllen. Basically I use wiki's a lot, but am yet unsatisfied, so trying to reach a better understanding will be useful to me, and hopefully to the wiki community.

This is the first time I've attempted to do a PatternLanguage for a large meme. I'm finding it a lot harder then I thought it would. I suspect that what will happen is that when I'm done I'll have to start all over and refactor it. Only then can it really approach the quality of a ChristopherAlexander pattern language.

I wanted to do follow the pattern language format of http://www.designmatrix.com/pl/anatomy.html which is:

Title
Visualization
Parts/Context
Keywords
Predessor Patterns
Problem Summary
Analysis
Solution Summary
Successor Patterns
References/Sources
Author/Date

That has been too hard to do at my stage of understanding so I've found myself collapsing this down to:

Picking a name for wiki page (very hard to do!)
Visualization (which tries to include context, predessors, etc.)
Problem
Solution 1
- Issues 1
Solution 2
- Issues 2
Solution x
- Issues x
References

-- ChristopherAllen

The first place I've started is looking in depth at various facets of TextFormattingRules in:

CharacterFormattingRules
ParagraphFormattingRules
PageStructureRules?
LinkFormattingRules?

One interesting choice I made here was to separate LinkFormattingRules? from CharacterFormattingRules, and PageStructureRules? from ParagraphStuctureRules?. I felt that links, although a form of inline character style, were very different then things like emphasis. I also felt that formatting such as pagerules and headers were more about meta-content rather then content itself, so I separated that out too.

-- ChristopherAllen

One useful thing that I've discovered is that by surveying the features of different Wiki variants, I can get a feel for how successful different solution memes are, which can give some clues as to the problems, solutions, and issues to solutions. For instance, Ward's initial wiki had an approach to Definition Lists that basically failed to propogate into any of the variants, but his approach to Unordered Lists survived to exist in many variants.

However, this feature survey approach breaks down for features that were not in the original Wiki. For instance, Ward's first wiki didn't have headings, which means there is a huge amount of variation in how headings are done in Wiki variants.

-- ChristopherAllen

I've gotten kind of stalled on this project -- still need to do the rest of the PageStructureRules? and the hardest one, LinkFormattingRules?. Part of my stall is that I keep finding myself digging into various more 'modern' wiki variants and finding interesting stuff. For now I'm going to push these into a catch-all AdvancedWikiFeatures?.

-- ChristopherAllen

features aren't patterns. This page does really address neither of them.

I agree that features are not patterns, but a study of features is a great way to discover patterns. For instance, I'm facinated by the three major forces behind TextFormattingRules: having the text be readable (i.e. StructuredText), having the text be easily editable (original wiki), and have the output be powerful (every weird variant of table rules, for instance.) -- ChristopherAllen

: I'm not sure. If you study features, you may get feature patterns. But then the scope might be "interactive systems" or "groupware" including chat, forum, and all types of systems. The net effect might be to gather experience to construct the next best system, maybe the successor to wiki. But then it makes little sense to restrict yourself to "wiki design patterns".

: On the other hand, if we look at wikis - as whole systems of software, content, people and interactions - we have a chance to find patterns that help us create better wiki communities. That's what WikiPatternLanguage will be about. This is more a social problem than a matter of technology, and surely not a question of the markups. -- HelmutLeitner

But if I had not taken the time to understand the various TextFormattingRules, I'd not have understood the tension between the three patterns that conflict with one other. I have not seen anyone else articulate that there is EasilyEditableText? vs GoodLookingCanonicalText? vs GoodLookingWebPages?. I'm not saying that all patterns can be discovered this way, but many interesting hidden ones can be found. Also recognize that I'm focused on DesignPattern? rather then UsagePattern?. The SandBoxPattern is more of a UsagePattern?, and is currently independent of any design implementation. -- Christopher Allen

: I'm not sure about this separation of design and use. Patterns seem to be classes of individual things designed for good use. Doesn't design and use always go together? Alexander talks about his patterns reused over and over again in variations hating them being replicated identically. Would it be desirable to have thousands of wikis, each having different markups? When Alexander talks about architecture, he doesn't talk about bricks and mortar, although someone might find patterns in that too. But the interaction of people with the houses they live in doesn't depend on the bricks, so Alexander doesn't take it into account. Same way I wouldn't consider markup patterns, because they hardly influence what's interesting with wikis for its users. -- HelmutLeitner

I agree that patterns come from both design and use -- I just find that I come from the DesignPattern? side easier.

But I don't understand why you can't find patterns in the kinds and types of markup, and I think you are just wrong about "hardly influence what's interesting with wikis". I recently tried to set up a wiki for a group, and it was exactly these tensions between EasilyEditableText? vs GoodLookingCanonicalText? vs GoodLookingWebPages? that caused problems (among other things). Some people needed the text to be very easily editable (mainly new and inexperienced users). Others wanted the "text" to look good, and got frustrated by it (typically more programmer types), and others wanted the web pages to look good and were constantly trying to find various TextFormattingRules to get it to do what they wanted, but when they were done the other two types of people had problems. Studying TextFormattingRules is only a small start at looking at 100s of design elements of wikis, but without that study I think you are missing a major possible source of patterns.

In any case, please don't knock my approach to finding patterns -- I encourage you to keep working on yours. They don't need to be tightly integrated togehter yet -- first discover them, document them, then integrate them. -- ChristopherAllen

There is no harm in trying to improve our understanding of WikiSyntax, for that is the primary UserInterface to the wiki. Any means that promises to be logical is worth exploring. -- SunirShah

Yes, why not. I just think that the understanding of simple technical systems doesn't need a pattern language. Characters like "d" and "b" also seem to follow a "pattern". But a character pattern language - even if it were possible in the spirit of CA - wouldn't help us with creating arguments or literature. Sometimes I hate this MeatballMantra, but I predict: "that won't work". -- HelmutLeitner

CategoryWikiDesignPatterns