Tags:
findability1Add my vote for this tag create new tag
, view all tags

Thesis: Webs, and more specifically MultiLevelWikiWebs, are a bad idea.

TWiki presents itself as "The Wiki for the Enterprise". Over the last few years I have worked with TWiki and other Wiki implementations in a range of enterprises, from very small to very large, in a wide range of business domains. This experience has reinforced my perception of a problem that Kevin Rutherford first pointed out to me, but it has taken a long time for me to understand why he was so right.

TWiki (in my experience) is introduced in three ways in the enterprise

  1. As a document repository
  2. As an application platform
  3. As a synergy builder (The Wiki Way)
Wikis sell themselves on the promise that you can break down barriers, improve communication, and find new business opportunities by following the Wiki Way. There are usually better solutions to 1 and 2 available. But 1 and 2 are the most prevalent applications of TWiki, by far. In practice, TWiki rarely delivers on the promise of 3. So why doesn't it work that way?

When any new technology is introduced to an organisation it usually has to be adjusted to fit the organisation; it is rare that an organisation will flex to accomodate a new technology during adoption. That's OK, adoption always has to be managed and that involves compromise. This usually means casting the wiki as a mirror of the organisation, by organising the data in the wiki along familiar, comfortable lines. The promise is that synergy can grow later, as people come to understand the power of their new tool.

A Wiki has to adjust to the existing environment, or it will never be adopted.

Organising your data is a Good Thing. Any reasonable sized organisation has diversity within it. Sales, finance and enginineering all have different world-views. The sales force is rightly only interested in increasing sales. Engineers rightly get indignant if they have their faces rubbed in all the corporate entertainment events they miss out on (I'm an engineer; can you tell? ;-)).

But these differences don't mean that sales and engineering can't share a common namespace. Synergy is all about finding links in unexpected places. If you constrain your data along expected lines, don't expect to find the unexpected!

There is a huge difference between organising your data and subdividing it. Synergy doesn't grow well in subdivided data.

Of course, there is data that must be private to a domain - for example, no-one thinks that performance reviews or detailed sales data should be public throughout the organisation. Similarly there is data that probably should be private to a domain; very few people care about the meeting minutes of the coffee-club in the Tristan da Cunha regional sales office. But these are special cases, and do not - or should not be allowed to - reflect the norm.

If you got your wiki to help you find synergy, everything else must be public, or you will never find any.

Anyone in any large organisation is aware of the incredible confusion and discomfort caused by the regular hierarchical re-shuffles, They will also be well aware of theprevalence of "dotted line" reporting that exists in such environments, as people try to defeat the imposed hierarchy and formalise the relationships that really exist. Further they must be aware of how necessary those reshuffles are, and how often business opportunities grow from parts of the organisation suddenly being put in contact with new peers - and how they can wither and die, as they are taken out of the context in which they were successful.

Re-orgs can be healthy, cathartic processes. But they often break things badly, as the data "belonging to" an organisation that no longer exists gets orphaned. And existing synergies often get lost in the shuffle.

Corporate hierarchies are not a good organising principle for the data in your wiki

The reality is that every individual has a unique world-view. Further, every team has a unique world view. And every discipline can have a shared world view. These world views need to be able to overlap, intermix, and synergise. Trying to impose just one world view on everyone else has caused more and bloodier wars throughout history than anything else, and for good reason. Instead of finding new and better ways to force a single world view down people's throats, we should be finding more efficient ways to allow every individual to have their own.

Embrace diversity

In summary, I have nothing against organising information spaces; it is essential to any organisation. However I am strongly against building the sort of "one world view" hierarchies, as they devalue and marginalise other world views that have equal value.

Organise your data, and you allow the bees to work and carry pollen between the flowers. Subdivide them, and the only things that will grow are mushrooms - best kept in the dark and fed on shit. Your choice.

-- CrawfordCurrie - 01 Jul 2005

Interesting (and compelling) thesis.

It would be possible to re-jig twiki to work more like http://del.icio.us - doing away with the implementation detail that webs are file systems, and rather use the path's between the cgi-script and the TopicName as a classification (meta-data?), which would allow twiki to have multi-homed topics, and makes twiki more wiki-ish.

the biggest fear that I have come across with this suggestion, is "what happens when 2 disparte groups use the same name for something" - which i have little sympathy for - as i recon thats a fine reason to talk about both on the one topic, and then link to more specific things from there - but is this realistic?

when you talk about individual world views, i start wondering about seperating topicnames from topics, and having topic aliases and other overly-complex organisational tools

-- SvenDowideit - 01 Jul 2005

The implementation detail has been a major driver in people's thinking, unfortunately. I see this as laziness.

I love the idea of common paths to a topic. I have no problem with organisational hierarchies, I only have a problem with there being only one. That /view/NiceWorld/FluffyAnimals/Sheep/Lamb and /view/NastyWorld/Butchery/Mutton/Lamb lead to the same topic is very sensible, IMHO.

I'm not too concerned about topic names; I'm more concerned about flexible ways to build relationships between topics. What we were discussing in InterestingChanges is an example.

-- CrawfordCurrie - 01 Jul 2005

I tend to agree with CrawfordCurrie, although the axample might be a bit awkward (I would expect the NiceWorld Lamb topic to deal with very different aspects compared to de NastyWorld one. Of course its all about using a very specific topic title.)

One very elegant way to common paths to a topic is to implement FacetedNavigation as in this demo. With this, one web with a flexible classification system (+ decent search engine) would be all I need... (now if someone would only implement it... smile )

-- JosMaccabiani - 01 Jul 2005

The example was deliberately chosen to illustrate the finding of a synergy between the world of Fluffy Animals and the world of Butchery. That they see lambs differently is the whole point. The two groups may be able to learn something from eachothers view of lambs.

-- CrawfordCurrie - 01 Jul 2005

I still think a page should be specific, i.e. either on

  1. the properties that make a sheep be classified as a Fluffy Animal (with discussion of course smile )
  2. The best butchering practices for sheep.
This gives focus to the topics helping both information sharing and retrieving. Again, this depends on the purpose of the wiki.

The synergy can be obtained by automagically create lists of pages about sheep, where both pages could be close together based on certain criteria. (again the example can be in a FacetedNavigation type thing, where a search for 'mammal' and 'stomach' would, among others, list pages about the WorkingsOfSheepStomachs as well as the CorrectMannerForRemovingSheepStomachs.)

I think synergy is about enticing people to look outside their usual surroundings for knowledge or expertise. Actually editing the same topic is not necessary.

That's where I see room for less traditional infromation retrieval schemes that overcome the limitations (in terms of enabling synergy) of classical 'either do a full text search of navigate down a hierarchy' file store scheme.

-- JosMaccabiani - 01 Jul 2005

How about putting a synergy detector linked icon after a linked topic if the system detects synergy with other topics in other webs for such a link? Something like WhyWebsAreABadIdeasynergy!. This example only searches for WhyWebsAreABadIdea in all topics, but we should have it do something more intelligent. We really need a fast ConceptBasedSearchEngine or none of Crawford's wonderful ideas are going to work.

I do agree with Crawford's mushroom comment; I've had many MultiLevelWikiWebs wither and die away due to malnutrition; The only thing it buys me is flexible namespaces, faster search times in individual webs, and easy (read lazy) protection for stuff under NDA. Until we come up with more automagic (e.g. much better and faster than current) mechanisms to expose synergistic relationships between topics and to protect topic clusters which need protection due to corporate non-disclosure agreements, we are left with Subdivision as a mechanism to classify and protect our work. Maybe we could come up with a way to do TWikiAccessControl based on TopicClassification (or SecurityClassification) rather than specific settings in topics and webs.

I can't stress this enough: ModerateYourNavelGazing, and start working to provide an obvious, elegant, flexible, tool-driven and namespace-driven way to do what you're proposing. You'll gain more Corporate acceptance that way.

-- PeterNixon - 01 Jul 2005

I agree completely with the webs don't work arguments. As Crawford points out, they do have their uses. They can work if each web has a segregated user group. But even here on twiki.org one might argue that Support and Codev and Plugins are quite related, as are Main and TWiki.

About a synergy detector (icon): this assumes there is only one topic with synergy. Why not use FacetedNavigation and suggest the whole lot of possible related (synergy) topics? Such as "Related topics" or even "People that read this page also read ...".

However I doubt that this will work without a database.

-- ArthurClemens - 01 Jul 2005

Agreed. A database and some background processing will be essential to speed up concept mapping/mining. Is that a limiting factor with TWiki? I suppose it could be implemented entirely as an Addon to a flat TWiki.

-- PeterNixon - 01 Jul 2005

Faceted navigation is a great idea, but it has all sorts of implementation problems associated with it. No harm in dreaming, but in the more immediate sense I had in mind something more like google. Click on a word (or phrase) in a topic, and get a google-like result, filtered and sorted according to your preferences, and able to recognise and acknowledge access controls. Something like that is well within the capabilities of even a simple search engine, especially given the relatively small number of pages in the average wiki (< 1M I would guess). if anyone wants to give it a try, I have a basic implementation of a search engine that could be pounded into TWiki given a big enough hammer.

-- CrawfordCurrie - 01 Jul 2005

Counterpoint:

"The Synergy Myth: And Other Ailments of Business Today" by Harold Geneen
ISBN: 0312147244
Geneen is the former head of ITT. He debunks many corporate "fashions". Yes, I say "fashions". Business gurus from Peter Drucker to Robert Rownsend (of Avis "We Try Harder" fame) have pointed out that a lot of what published in the B-Shcool rags is no different from other parts of the media like "Oprah's Picks", clothes, cars, or anything else. It come in waves - fashions - and when the mind-space has been saturated, along comes another fashion. It doesn't matter if they are effective or not, "its time for something new".

Synergy is an obvious sell, but isn't always meaningful. A lot of business isn't about brainstorming but about doing a job well, not changing whenever the wind blows.

Synergy, like "outsourcing", "downsizing", "re-engineering" doesn't always make sense.

The trouble is that in this "new media" a lot of people forget fundamentals of business. "New Media" synergytic mergers have never worked out - Look at the AOL -- Time-Warner one.

That's an interesting case in point: Last year, Goldman Sachs sponsored a contest for B-school groups - "How owld you fix AOL/Time-Warner?" Most groups played the synergy card, but when their models were run they all failed. The winning group, the one whose model came out to actually improve business efficiency and shareholder value , was based on the ITT model. Abandon synergy and operate as a holding company and let each business prosper in its own fashion.

In effect, the TWiki model of a wiki is a holding company and the webs are the individual ventures. The efficiencies of scale only apply to HR - there's one 'payroll' and administration -- %MAINWEB%. Now acquisitions (webs) can be incorporated and given a common "look and feel". But each can do business - content and applications, organization, classification, access control, etc - in their own way.

-- AntonAylward - 01 Jul 2005

Crawford, people don't call me a Tool for nothing wink I have a hammer. Let's try it.

-- PeterNixon - 01 Jul 2005

FacetedNavigation is a filter on things. Perhaps your search engine could also be enhanced with some sort of persistent filter?

So a search set would be all pages of let's say "Support questions". Then I would like to browse and search within that set.

-- ArthurClemens - 01 Jul 2005

When ever this question comes up, "to web or not to web," I find myself thinking of a passage from one of my favorite thinkers, Gregory Bateson. So I decided to look it up and thought I'd share it here for whatever edification might be gained, or at least entertainment.

This is an exerpt from what Bateson called a "metalogue" which he structured as conversations with his daughter. The title of this piece is "Metalogue: Why Do Things Have Outlines?" which was included in Steps to an Ecology of Mind (1972, Ballentine Books, New York).

Daughter: Daddy, why do things have outlines?
Father: Do they? I don't know. What sort of things do you mean?
D: I mean when I draw things, why do they have outlines?
F: Well, what about other sorts of things—a flock of sheep? or a conversation? Do they have outlines?
D: Don't be silly. I can't draw a conversation. I mean things.
F: Yes—I was trying to find out just what you mean. Do you mean "Why do we give things outlines when we draw them?" or do you mean that the things have outlines whether we draw them or not?
D: I don't know, Daddy. You tell me. Which do I mean?
F: I don't know, my dear. Theere was a very angry artist once who scribbled all sorts of things down, and after he was dead they looked in his books and in one place they found he'd written "Wise men see outlines and therefore the draw them" but in another place he'd written "Mad men see outlines and therefore they draw them."
D: But what does he mean? I don't understand?
F: Well, William Blake—that was his name—was a great artist and a very angry man. And sometimes he rolled his ideas into little spitballs so that he could throw them at people."

So should wikis have outlines? I don't know. I do know that I find webs very useful in the following use cases:

  • When I have a discret project with a beginning and end. A web allows me to neatly archive the whole shebang when it's done.
  • When there is a distinct group that's interested in following a particular "bounded" conversation and not be bothered with other topics. (This is, or course, partially a function of the design of TWiki's notification system.)
  • When I want a particular set of topics to be protected and/or invisible to general browsers.

I could imagine other organization schemes that might serve these use cases equally well. On the other hand, I can also imagine how alternative search and tagging systems could overcome the objections to webs restricting synergies.

In the end, I'm left wondering if an either/or arguement is really that productive. As a user, I am not concerned with the underlying data structures. As long as you let me draw circles around my conversations to create web-like-things that I can manipulate as discrete "things," I don't care whether the circles "really" exist or not.

Practically speaking, my hunch is that something like "webs" are going to prove useful/essential for some time to come.

And clearly, sheep are a essential part of the solution. (I'll take mine with a little mint-chipotle jam, if you please.) smile

-- LynnwoodBrown - 01 Jul 2005

On one of my webs I have made use of a modified form of LynnwoodBrown's TopicClassificationAddOn. I don't know if this is the kind of thing that is meant by 'faceted' sicne the explaiantion at FacetedVavigation doens't illuminate me. What I do like about Lynnwood's scheme is that a topic can be in multiple categories.

I've also implemented a more basic classification scheme similar to the one for this topic - BasicForm - with pages that do a %SEARCH to pull things together.

The problem with both these schemes is getting the users to classify the topic. SOme users are goo and some are bad.

Let me illustrate another point.

You are using a browser to read this. The browser has a bookmarks facility. You can create folders in the bookmark file to categorise the pages you save references to. BUT DO YOU?

Many people don't. As it happens I do, sometimes. But I don't have the time to clean up the ones I haven't.

Bakc in my Windows days I used a too called Powermarks. This ignores the cateories or lack of them in your bookmarks file and builds a full text index from them, then presents an interface with a incremental QUIK index search. You don't have to remember where you filed the bookmark, what category, only that you did.

[[Main.CrawfordCurrie][CC]'s argument for a single web makes sense if you have tis kind of suport and search function. The devil, though, is the details of making the user interface for the search manageable. For a web as rich as Codev it would still be overwhelming.

TWiki has a full text search capability. Its not called that, but it is. Reality is the "find word within the same paragraph as word" is not an easy type if interface to use. By comparison, one that says "I know Martin someone-or-other wrote something about a toolbar for firefox sometime" IS managable.

What's wrong with TWiki in this regard is that the interface is poor. Compare the seach interface with that of something like Mozilla Thunderbird or Firefox with their plugins

The Thunderbird interface offers the ability to add and remove search criteria, date ranges and negation of conditions. So I could even look for Firefox toolbar artciles that are not by Main.martinCleaver.

-- AntonAylward - 01 Jul 2005

Question: The Origignal C2.org wiki seems to have at the bottom of each page:

  • See also
  • Category links, more than one in many cases
  • Browse Like Pages

are these automatically generated?

While I admit they are great if you are a wikibrowser with time to spare, are they actually useful in a more business-like setting?

-- AntonAylward - 01 Jul 2005

Probably not, but they'd be useful in a development setting while the development target is in architecture or microarchitecture phase. Once the product hits deployment, the users are in a more non-interactive documentation push mode, but they are in bug-filing mode, so it might still be useful there (highlighting inter-bug relationships, surfacing behavior patterns, etc). In other business settings I think it'd be tough to get anyone to do anything other than post documents (LiveLink). You could market it as an "organizational brain mapping" tool, but it'd probably be viewed as a fad.

-- PeterNixon - 01 Jul 2005

Anton: i've included a link to a faceted navigation site above. look at that and it'll become clear what is does. the core is that there are different paths to the same document.

Peter: i think that many R&D businesses would love a good organizational brain mapping tool. That's why we'll use it. Document management doesn't cut it. So the extra investment in getting people to add topics in stead of word documents will be earned back by shorter time-to-market or more competetive tenders.

-- JosMaccabiani - 01 Jul 2005

I felt that the FacetedNavigation topic needed some examples. I've also rewritten the text.

What Anton brings up is another idea to spice up the advanced search page. We need some ideas that are applicable to TWiki. I'll have a throw at it too.

-- ArthurClemens - 01 Jul 2005

The best way to have several pages linked by tags/concepts/categories/whatever and search them in a very fast and efficient way is to have an index.

The index implementation can be quite simple, a heaviweight like Plucene is not needed.

-- RafaelAlvarez - 01 Jul 2005

"Where's my stuff?" or "Navigation matters"

There's one thing which always confuses me on someones portal site: leading me to navigate in cycles, like I just want to buy this damn peace of hardware crap and don't get to the entry page again and again and again when I search related crap that fits well to what I've already got on my shopping card. Most online shops suck because they are a navigation maze. You know, not only are online shops a pain in the butt: wikis can be so even more.

Navigation helps to find things if these are organized properly. But don't expect any dynamic hyper navigation will help because the more specific it is the more probable it is that it conflicts with my personal picture where things are: we build up a kind of topological map in our mind along which we hope to find things. This process of remembering where things are is encumbered by fluctuation in resemblance and location, or to say it positively: you will find your stuff if it's there: you can rely it to be at a certan place (e.g. on this old bookshelf under some layers of dust).

These arguments can both supply the hierarchy or the facet approach.

It realy has both its value. But please remember: location matters in navigation,at least for me. A fluctiating navigation scheme tends to produce navigation mazes which are todays online horror.

A fortiori in Wikis. Synergy aka refactoring does happens far too infrequent. Old stuff isn't erased and lingers in the knowledge base while rottening (twiki.org).

Webs help: it give's things a handle to throw them away.

Completely dumping stuff is also a way of refactoring.

Frankly, webs are so usefull at the NatsWiki: for example teaching courses are organized in webs where students build up a knowledge base during one semester. They upload their solutions to the wiki peer-reviewing those of there colleagues. After half a year these webs are closed. The next semester new students shall start over from scratch and find their own new solutions. Refactoring is only wanted for the teachers that design the courses to improve the starting material given to the students.

Believing in Synergytm is altruism. We need altruism but it is unhealthy if you don't open you eyes.

"Let me do my stuff ... don't disturb me ... give me some place where I can test that out ... we'll see ... if its worth it then I'll publish that in the production web ..."

Most of the time people don't cooperate. They don't want to, even if the say something different. Synergy threatens them in their personal integrity. People want to sit on a throne of knowledge that they don't want to share to make themselves indispensable. Surely, they are on the oposite site of light. But you can't change them. You are all smacking that. Wikis threatens them more so. Give them a web where they can hide. I know this is diametrically opposed to the wiki way. But TWiki can even support these guys.

-- MichaelDaum - 02 Jul 2005

A case in point. Let's say you have two teaching courses; one on European History, an one on Religion. Both courses converge on many points; the Diet of Worms being a prime example. A student in one or other course can use the common relationship to put their study in context of the other subject, allowing them to develop a greater depth of understanding. This is the power of Wikipedia, the automatic cross-linking of a tremendous range of what are - at face value - unrelated subjects.

Let me reiterate; I do not propose to force my world view on you, but I ask that you respect mine and provide me with the tools that allow me to interact with our shared data in the way that I choose, not the way you choose.

BTW Synergy™ is not altruism; they are completely separate concepts. It is the synergists role to find synergy in the business and advise business leaders on how to exploit it. For example, a motor vehicle manufacturer employs people who look for opportunities to optimise on re-usable components used in many models of car. There's nothing altruistic about that, it's just good business sense. If empires and hierarchies exist within the business that prevent that from happening, they are damaging the business.

Anyway, enough navel-gazing, as Peter calls it. From the lively discussion above I can see that there are some interesting new avenues of research on the table. The important point that clearly comes across in this topic is that no one way is right - which in itself is a perfect justification of the original thesis.

The following are all of interest to people who use TWiki, and should be part of the menu of tools available to a TWiki user:

  1. ImprovedSearchInterface that allows you to interactively specify a richer range of search constraints, such as searches in specific form fields only and searches constrained by date and contributor.
  2. GoogleLikeSearching - fast search across huge data, irrespective of how it is structured but always respecting access controls,
  3. FacetedNavigation. This could be important in aiding data-mining,
  4. MultipleInterleavedHierarchies, which is where I started from, so you can present different, fixed, world views, depending where you started from,
  5. MultiLevelWikiWebs - single world view, frozen structures, have their place. They can be important in helping manage you data in a highly structured environment as well - for example, project planning and control.

At some point I will make an effort to refactor this topic to capture all the inputs. I think it is an important discussion from the perspective of helping new TWiki users to make choices, and plan their deployments. Right now, I'm off to focus on DakarRelease.

-- CrawfordCurrie - 02 Jul 2005

I'll try to keep this coherent, but the ideas are blossomming and morphing before I can put them into words, so if I meander a bit, feel free to ask me to refactor. I've already deleted far more than I've left in, so I am making the attempt.

I could happily spend a year playing with the idea of a wiki fully driven by FacetedNavigation and have nothing to show for it at the end of the year, despite still being happy with the journey.

First, I don't see where FacetedNavigation conflicts with WikiWebs, provided that it's integrated properly. Realistically, the web and the title of a document are just metadata themselves, special only in two regards. Every document must have a single value specified for both properties (no more, no less), and no two documents can have the same value for both values. Certainly, we could devise a method of storage that doesn't require this, though it would break just about every part of TWiki. However, when I thought about it, having these special properties is actually a good thing for one reason. Without them, WikiWord links would be far more difficult to specify.

It seems to me that what we really need that we don't currently have is the general ability to browse by facets, an easy way for users to categorize a node, and, closely linked to the first, the ability to link to a FacetedNavigation result set, something like [FN:author=CrawfordCurrie;classification=TWikiDeployment]

The first issue would probably involve some changes to the datastore, to make facet searching more efficient, a cache of metadata at the very least, and storing the metadata seperately in an easily searchable manner at the other extreme.

The second issue is the real sticking point in my opinion. The clasification has to be simple and beneficial, otherwise users won't do it. Some metadata exists because it is provided by the system (author, modification time, etc), other metadata exists because it is required (Web, Topic). Here we come to my weak point, designing something that someone ELSE will find easy to use. I must also say that while I'm good at designing so that there's a non-javascript fallback, I can't see any way to make this really useful without javascript.

The third item is just a matter of syntax, so it's really not an issue per se.

It's easy to see some of what we could gain by doing this, with the ability to do a FacetedNavigation search most obvious. We could also have automatic links on every page to view closely matching facets, though we'd probably want something more sophisticated than "count how many metadata values match and sort," perhaps having a weighting system. However, all this comes at the cost of much work and further raises the bar on what it takes to contribute, because now we're expecting the users to be able to work with whatever classification system that wiki is using.

The facets themselves obviously have to be wiki dependant, beyond those that are system-provided or manditory. However, who defines the facets and the values for the facets? I think the best system would be the one that allows for the wiki (or even the web) to provide some facets, as well as specifying if users can add facets, or values for established facets. Much of this could be done using forms, though I think allowing users to define totally new facets might stretch that a bit. Then again, Daisy's facets seem rather inflexible from the user's point of view anyway, since they're defined in XML outside the wiki.

No true bursts of genius so far, but definitely a fertile enough field for them to occur. I need to play around with Daisy to see how it handles some of this.

-- EricSchwertfeger - 03 Jul 2005

I'm sorry, I don't get it. I've read and re-read and re-reaad the Facetednavigation stuff and don't see what's so special about it. It doens't seem to offer anything we can't already do with TWiki.

Arthur gives some examples from various shopping sites, but he omits a very important point. The ffort that has gone into ;taging; each item.

If you visit Ward Cunningham's original C2 wiki wou can see tt the botom of each page a 'category' link and a 'link' link.

Categories are easy, we call them classifications here. We do use them. I use them on my sites. I also use LynnwoodBrown's TopicClassificationAddOn which can tag a topic as being in more than one category.

But all this depends on the fact that the people creating the topics, or an editor or web maintainer have to be diligent in using the classification scheme. And even then, it may all boil down to a matter of opinion.

As Eric says:

  • They are wiki & web dependant
  • Who defines them
  • You have to be able to define new ones..
    • ... but that can lead to chaos
  • XML has nothing to do with it

But ultimately, and ona web and wiki like this, it is up to the diligence of the topic creator to specify the category.

Oh, and then it gets worse!

The problem is really one of WikiMastering - or lack of it. Here in twiki.org we have never encouraged or sought to develop WikiMasters, and to some degree we have developed a culture of fear that prevents people refactoring the work of others. Attempts to reclassify are frowned upon. At best, a topic might be split when it gets, like this one has, off topic.

Wikis should encourage such actions. Someone should make use of thigns like TopicSumamry and it should be what's reported in searches and topic listings. But we don't fill that in.

Would it be impossible to make TopicSummary a mandatory field in the WebCreateNewTopic? Would it be a brain-buster to automatically add the original author to "InterestedParties"? Would it take much effort from contributors to add themselves?

Obviously it would.

-- AntonAylward - 03 Jul 2005

Isn't this a chicken and egg problem? Of course, diligent classification is very important for any classification system to work. And users will only do that if it's very obvious that correct classification is important. At the moment, that's only the main classification and InterestedParties is not used anyway.

FacetedNavigation will not be for everyone. It's just a (possible) navigation mechanism that will especially benefit synergy, maybe only in certain application fields such as knowledge management.

In a corporate setting, there might be people that are not WikiMasters but who are (more) responsible for the knowledge management in the company than others. They can monitor new pages (or pages that were changed > 3 months ago) and check the classification. Most classification (as in the shops example) is 'static' anyway, so getting it right once is probably good enough.

Note that while Twiki.org is a great example of the possibilities of TWiki use, it's not the only one.

-- JosMaccabiani - 03 Jul 2005

I think what it comes down to is that

  1. Twiki.org doens't use FacetedNaviation
    • because it desn't need to
    • because no-one is interested in taking the time and effort to carry out the needed classification ... or at least not until it gets painful
    • many of us think that spliting the web or having subwebs would be more appropriate. After all gross and fixed classification such as "Documentation" "Configuration" "Athens" "Bejing" "Cairo" "Dakar" "Support" "Development" and so forth are clear and hard boundaries and are quite intelligible and usable
      • ... and using webs means that users DO classify the topic just by putting it in the web.

  1. Shopping sites don't need to have end users redefine, refine and recategorise
  2. TWiki has facilities and plugins and add-ons that can achieve much of what is described in FacetedNavigation
  3. TWiki has FullTextSearch capability. As I say above, this probably needs to have the user interface refined, but it is very powerful. We often forget how powerful it is. I wish Amazon had it!
  4. It wouldn't be that difficult to add a 'links to' summary at the bottom of each topic
  5. It wouldn't be that difficult to add a 'links from' summary at the bottom of each topic
  6. If someone could define the algorithm in meaningful terms and we can get agreement, a plugin to do the "like topics" association we can see at C2.org shouldn't be that difficult.

FacetedNavigation is not some kind of pancea. In many cases webs are better. In some cases heriarchical webs make more sense.

-- AntonAylward - 03 Jul 2005

mmm, i'm starting to think seriously about implementing the dynamic web idea that i mentioned above - then you'd be able to use the 'Cairo' web, even though it doesn't actually exist on the file system.... - i'd be quite curious to see a FacetedNavigation experiment - and i'm wondering how we can best provide a twiki.org dataset for testing out ideas

-- SvenDowideit - 03 Jul 2005

For those of you with long memories we have already tried (several times) to classify topics in twiki.org. First, there is the topic classification field that exists in many forms, and second, there are WikiBadges all over the shop. These attempts failed for a number of reasons:

  1. There is no culture of categories in twiki.org, and never have been AFAIK.
  2. There are very few people prepared to tidy up; nowhere near as many as are prepared to litter; refactoring just takes too long; and people are not encouraged to refactor by their peers.
  3. The category support relies on SEARCH, which is slow and unwieldy, so it puts people off using categories.
  4. Webs (IMHO) get in the way.
Whether you call it faceted navigation, slicing, dynamic webs, or categories, they are all essentially the same idea; categorise topics statically so that fixed relationships can be uncovered quickly. Technology can address problems 3 and 4, but 1 and 2 are cultural. I would like to think that if the indexes were fast, natural and intuitive that a culture of linking would develop. The experiment is well worth doing; if we can make it happen on twiki.org, we can make it happen anywhere.

BTW on a related topic, I was thinking of changing CommentPlugin so it can add to form fields. Then you could have a comment box against the 'related topics' form field, where you put the name of another topic and hit 'relate'!

-- CrawfordCurrie - 03 Jul 2005

Actually, I first wanted to read some of that literature before pointing y'all to AutomaticDocumentClassification. Go google for it.

-- MichaelDaum - 03 Jul 2005

Here's another interesting link on Information Architecture (nice buzzword) and a related piece of opinion: "Is Navigation Useful?" by Jakob Nielsen: "For almost seven years, my studies have shown the same user behavior: users look straight at the content and ignore the navigation areas when they scan a new page. ..." Do you know deja vue? Do you know deja vue? read more.

-- MichaelDaum - 03 Jul 2005

Which is one reason I like WikiBadges - they keep the navigation in the document content, without stealing screen real-estate.

I'll re-iterate; I'm not interested in navigation that someone else thinks I should use (unless I happen to be trying to psychoanalyse them). I'm interested in my own navigation paradigms and those of the societies I belong to.

-- CrawfordCurrie - 04 Jul 2005

CC's point about someone else's navigation is a very good oone.

It means FacetedNavigation makes sense for shopping sites because of things like ISBN, author's names, Dewey Decimal and the like. But that is no way to organise your own research notes for you book or doctorial thesis. That has to be your own classification and relationship scheme.

TWiki gives those tools. How you configure them is up to you.

-- AntonAylward - 04 Jul 2005

I can't see why FacetedNavigation wouldn't work with personal (subjective), changing content descriptors. Let's not focus too much on the ontology aspect, that is just one way of getting this categorized. Ontology has its merits if not applied too strictly (it is just an advanced hierachical thesaurus really, with relationsips between subjects independeny from the actual used words in texts), but I agree it is not reasonable to expect of TWiki users to add topic keywords from an ontology.

I am more interested in the navigation aspect, the progressive filtering.

This is no different that the principle of advanced search as shown in the Thunderbird screenshot above, except that it shows all the possible options for browsing. It is a way to avoid the zero or zillion hits syndrome: it lets the user build up a complex filter step by step.

Of course it is possible to use any keyword system, subjective or objective, for this kind of navigation.

Folksonomies

The mentioning of "someone else's navigation" reminded me of the folksonomy discussions going on in Information Architecture (no buzzword really!) land. See Wikipedia's definition on Folksonomy. http://del.icio.us is a famous example. See also a recent blog entry on OK/Cancel: Tagging for Fun and Finding.

-- ArthurClemens - 04 Jul 2005

See a link to an online faceted navigation browser for delicious in FacetedNavigation#delicious.

-- ArthurClemens - 06 Jul 2005

Perhaps what you are looking for is a Topic Map http://en.wikipedia.org/wiki/Topic_Map

-- EdYoung - 06 Jul 2007

CategoryOrganizingPrinciples

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng snapshot17.png r1 manage 28.4 K 2005-07-01 - 17:49 AntonAylward Thunderbird Search showing some optional added critera
Edit | Attach | Watch | Print version | History: r39 < r38 < r37 < r36 < r35 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r39 - 2007-07-06 - EdYoung
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.