Tags:
create new tag
view all tags

Organizing Principles

This topic is intended to further the discussion of OrganizingPrinciples that can be made available to make TWiki more useful. This discussion started with the concern about MultipleWebs.

I would like to direct the discussion toward desired function, not on how to implement or migrate from where we are today. That second topic is best left until after consensus is gained on the organizing principles desired.

Background

TWiki currently provides some organizing principles in the base distribution:

  • Webs, which allow topics to be grouped into separate namespaces.
    • benefits:
      • can improve ease of upgrading and maintenance by putting read-only and admin functions into separate webs.
        • current implementation uses separate directories for each web.
      • can improve performance by limiting searches to applicable webs.
      • Provides settings for initial Topic Templates, forms, notifications, default colors, etc.
    • drawbacks:
      • Some limitation exists in terms of the default topic templates that are available in response to Go box or famous ?
      • Separate namespace decreases usability as user must prefix web name prior to WikiWord.
      • Serendipity Linking possibility decreased.
      • Hard to remember web designation as WikiWord that is displayed does not include Web designation.
      • Go Box searches are limited to current web.
      • Topic can be member of only one web at a time, unless it is duplicated.
      • "You are here" concept is user-unfriendly.
  • Search mechanisms allow topics from webs or site to be listed according to name or content.
    • benefits:
      • search is a mechanism that many people prefer to use as it allows content to be viewed in many ways.
      • can handle any underlying concept and transcend it, i.e. webs or folders can be disregarded or respected.
      • in-line searches are extremely handy and a killer-app aspect of TWiki.
    • drawbacks:
      • search by keyword has not been supported, resulting in literal searches for simple strings that are found in many topics, making the results less usable. This is up for correction in the next release.
      • structure, such as form fields are available to be used but no standards way of setting up any structure is imposed, resulting in the need for a great deal of understanding of a given installation to add to it, and difficult to provide for InterWikis support.
      • search does not encourage collecting similar topics according to their semantic concept.
      • many people prefer browsing to searching, according to studies of user habits. As a result, all professionally designed sites include both a search approach as well as a browse approach.
  • Embedded Links: The web and particularly Wiki, and TWiki encourage embedded links, i.e. WikiWord organization.
    • benefits:
      • puts the page in context of a larger discussion.
      • The concept of TWiki and Wiki makes the creation of in-line links easy to make and suggest. It takes no time to decide where to put the topic as it defaults to the current web unless the writer remembers to append the web qualifier to the beginning of the WikiWord, or if the create dialog offers to help the user to place the topic into a larger OrganizingPrinciple.
    • drawbacks:
      • difficult to know if similar pages exist that may be of interest as well to the proposed topic. If the user has to place it into a browse tree or other OrganizingPrinciples, then the user may note other topics that are similar.
      • Refactored pages may result in a page becoming an orphan, with no way to access it except for a search.
  • Name Conventions: By remembering topic names, or perhaps having some naming conventions, it is possible to directly access the topic. This is the concept of the Go Box.
    • benefits:
      • immediate access of the intended topic.
      • great for people who are intimately aware of the site and have great memories.
    • drawbacks:
      • requires memory of topic name and web that it is probably in.
      • currently, Go Box does not span webs.
      • naming conventions not standardized across sites, difficult to guess topic names.
      • generally user-unfriendly as there is no hand-holding.
      • lousy for people with poor memories, like most people.

Other OrganizingPrinciples

In addition to the background of the existing TWiki, the following organizing priciples can be considered:

  • Browsing "folders". This facility is envisioned as a means to organize content so that it can be browsed by users within the same namespace, i.e. in the same web. Such a facility is typically viewed as a tree or heirarchy. This is already provided in TWiki in terms of manually organized topics that summarize other topics using embedded WikiWord links, however, the settings for defaults and notifications is not part of this concept.
    • benefits:
      • Many users assume a method of browsing content will be available, organized according to some logical concept.
      • Browsing can be the fastest means to obtain results across a limited set of topics if the organizational concept of the topics matches the needs of the browsing user.
      • Easiest for new users to understand.
      • However, would want to have facilities in terms of settings, notifications, etc. that are available for Webs.
      • could be automatically generated in "google" fashion, based on the child tags in the topic.
    • drawbacks:
      • more work to add a topic as you must also decide where it should lie in the browse heirarchy. (Yahoo takes longer than Google).
      • Browse heirarchy may be appropriate for some uses but completely inadequate for others -- heirarchy may be "wrong".

  • Threads. Available with some plugins.
    • benefits:
      • conceptualizes a discussion.
      • suppresses details of comments that don't seem appropriate.
      • friendlier and similar to chatting. Well understood.
      • easiest to integrate with email.
    • drawbacks:
      • discussion sometimes winds up with lots of worthless comments
      • difficult to refactor into larger concepts and topics that conceptualize the information.
      • contributors don't necessarily work on their contributions very long.
      • can be difficult to go back and edit the contribution (esp. when integrated with email).

  • Expert-System Tagging. A great deal of thought has been applied to the organization of the www in general, to allow for better results. Usually, these concepts are based on a set of Meta data tagging (Not the same concept as the META tags used in TWiki today, but they could be used for this purpose). The "classical" work on this topic is the ResourceDescriptionFramework (RDF), which is a W3C recommendation. See TaggingRelatedTopics.
    • benefits:
      • supports the concept of expert-system organizational structures.
      • standards-based concept means that it will be suitable for InterWikis or general interfacing with other WWW components.
      • RDF is used today for tagging BLOGs for syndication, for example, and would encourage syndication concepts.
      • Clean logical concept which is XML based is blessed by ivory-tower pundits, but could be implemented using HTML META fields.
    • drawbacks:
      • garbage-in/garbage-out: people lie. tags are only useful if they are correct, and frequently they are not. This is why google does not rely on meta tags, but instead only on content and linkage information.
      • takes an expert to tag, and structures can be a pain to work with unless they are really very simple, flat structures.

That's enough to start some discussion, I hope.

-- RaymondLutz - 15 Dec 2003

There's also Categories from http://www.c2.com/cgi/wiki

  • benefits:
    • single topics can exist in multiple categories
    • avoids hierarchy hell
    • categories can double as webrings
    • categories are themselves categories, allowing categories of categories
    • can be auto-generated (see Expert System Tagging, above)
  • drawbacks:
    • sometimes topics don't get put in the right category, or too few or too many
    • the number of categories increases very fast
    • one man's category is another man's confusion

I think the key is to find organising principles that are user focused i.e. "your organising principle is not mine". Organisation is all about helping you see patterns; some people solve anagrams by writing the letters out randomly, but other people group the vowels and the consonants separately. Neither approach is wrong. So I'd like to be able to slice in ways that are not simple searches or simple hierarchies.

Actually google already does this, because it orders the search results it presents to you; the difference is, I want to be able to control how that ordering is done. For example, I should be able to state:

  • I am most interested in topics where I said something that has since been answered,
  • Then I'm interested in topics that have changed since I last visited them,
  • Then I'm interested in topics that I've marked as "interesting",
  • Then in new topics,
  • But I'm not usually interested in Windows.
  • I'm vaguely interested in how recently a topic was modified,
  • and I don't like long topics.
These organising principles are then applied whenever I do a search, or whenever I look at recent changes, or whenever I visit (one of) my "interesting topics" page(s). Anyway, the nub of this is that I want a default organising principle, but I want to be able to define my own, as well. Kind of like mail filters.

Here's my current favourite: http://www.c2.com/cgi/wiki?IncreasingBoredomOrder

Hope that all made sense. So far a combination of categories and searches is as close as I have got to this, and multiple webs get in the way.

-- CrawfordCurrie - 16 Dec 2003

The Categories concept overlaps significantly the Tagging concept. Again, it is subject to garbage-in/garbage-out problem. Your search scenario using very complex criteria should be at least partially supportable, although something like "vaguely interested" is difficult for even humans to understand what to do. This is great for viewing TWiki as a discussion platform, which is how many people use it. But it is not sufficient for a knowledge repository. Then, you want other criteria that are based more on not what you have done recently, but what the content of the topic is, such as

  • Find topics that deal with changing the Search.pm module, so I can gather all changes that I will need to make at one time.
  • Show me relationships amongst the topics, in terms of a Site Map that is actually more than just a Web List.

Of course, we always want to order results in terms of applicability, not the usual alphabetical. Most recent is a weak attempt at that, but your Boredom Order is the inverse of InformationOrdering. There is an information theory that attempts to specify exactly how many bits of information are in a given piece of data. According to that theory, the amount of information is precisely the inverse of the expectation that it will occur. For example, saying "The sun came up today" has very little information in it, since we expect it to occur. However, saying "The Sun didn't come up today" has a lot more information in it, as the expectation of it occuring is certainly much less. The same with boredom ordering. Seeing

   #include <stdio.h>

has very little information in it as it is certainly expected at the top of any C program, and therefore the level of boredom is high.

The actual amount of Information is defined as the natural log of the inverse of the expectation value, i.e. probability that the event would occur.

So for our purposes, we would like to know about unusual terms used -- searching for "the" does no good as all topics probably contain it. However, searching for "Supercalafragilisticexpialidocious" (From Mary Poppins, I probably spelled it wrong) is unlikely, and therefore will provide better results.

Regarding the term Boredom, I don't think it is the inverse of expectation. I define boredom as times when you mind is not being led around by some input of some kind, like a TV show, radio program, or computer task. In those times, your mind is free to do whatever it wants to, and therefore, boring times are something I look forward to. My mind is free to think of anything it wants to. Sorry, I want my life ordered starting at Boredom. (At bit if philosophy leaking in as usual.)

Note also the topic TaggingRelatedTopics.

-- RaymondLutz - 16 Dec 2003

Raymond,

Thanks for the interesting account of information as a function of expectation. Can you recommend resources where we could go for more information?

I also enjoyed your attempt at a rehabilitation of boredom. In particular, the idea that stimulation involves being led by some input implies that boredom--in contrast--is a state of mind that actively selects it's input, a state of mind that you claim deserves to be privileged. I also tend to privilege attentiveness to our ever-present capactity for selection above other moral principles (selective principles). I'd like to claim that it's the principle by which submission to other moral principles is even possible, but have to defer to logic: it's obviously a chicken-and-egg kind of question.

If I may, I think your account of boredom could benefit from the notion of "exhaustion". Even an active (selective) state of mind becomes bored when it fails to invest its context with value--when it exhausts its choices. Conversely, if the mind is passive but alert, the experience can still be very stimulating.

-- LewenShao - 27 Feb 2005

Philosophy is fun, isn't it? Regarding information theory, any communications theory text will have this explained.

If you want to have a lot of fun, read Claude Shannon's original paper: http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf

See section 7 regarding information entropy and expectation.

Regarding boredom vs. exhaustion, these are vastly different things, and are orthogonal. You may be bored and not exhausted, exhausted and not bored, bored and exhausted, neither bored nor exhausted. My kids would say: "Dad, I'm bored." My response is "That's great! You can think of anything you want to!" They hated that.

-- RaymondLutz - 15 Mar 2005

A few notes:

  • On Webs:
    1. Drawback: if the user perceives the wiki site as a normal site, the webs are regarded only as a way to categorize site content (like site categories). So the user will expect to use search on the site, not in a web. Also naming and finding topics by browsing is made counter-intuitive.
    2. Benefit: as a way to protect content from site-wide browsing and searching webs are indispensable. For an extranet I create a web for each client with a create-web-form. Each client is restricted to his own web.
    • The two approaches are greatly contrasting: open vs. closed. Most public websites and intranets would be open.
      • So webs are useful when you have segregated user groups: the users of one web won't find much useful in another web. -- ArthurClemens - 24 Mar 2005
  • On browsing:
    • In a unstructured web like twiki.org, browsing is made very hard: there are almost no (subject) overview pages that bring order in the chaos. Compare this to the way Wikipedia organizes subject matter.
  • On searching:
    • Although intuitively every site designer would think of adding site search, user research indicates that sites with a prominent search box actually perform worse. What happens? The user cannot find the content immediately, enters a search term in the search box, finds too many or no results and leaves the site disappointed.
    • Drawback: The current Go box looks like a search box, which is bad. If there is a go box, it should be made visually not so prominent.
  • On embedded links:
    • Benefits: The quoted user research above also shows that links make good scent: they are indicators for information hunters that follow an information trail.
  • On naming conventions:
    • It is often implied that WikiSyntax enforces a particular way to think up (and find) topic names. It is even used as an argument to keep WikiSyntax. For me, [[Wiki syntax]] would be just as clear.
  • On tagging:
    • Keyword tags in a wiki site is an interesting but undeveloped principle. The main drawback with tags for public websites is that different people come up with different words to describe their content. On a wiki site the tag list could be scrutinized, and the tags applied to topics would be changed/developed in time by the writers and readers.
  • On categories:
    • See the wikipedia link above as a good example.

I would add another organizing principle: TopicMaps.

Crawford mentions the various dimensions of information: authorship, last visited, publishing date (newness), subject matter. Will think about this later.

Clustered search results is a great way of browsing in a set of related topics or search result. Northern Light used to have this, now Vivisimo makes software for this - example search set.

-- ArthurClemens - 19 Mar 2005

In one sense I agree with ArthurClemens and in another not.

About webs:

Agree
The word "web" is not descriptive of the partitioning and segmentation. Terms like "Forum" or "Board" might be more familiar to many users.

Agree
Having the list of webs down at the bottom of the LeftMenuBar isn't particularly intuitive and isn't very obvious. There's no prompt to someone visiting, say Codev, for the first time having followed a URL in E-mail that this is about how the site is organized. By comparison, MattWilke has some skins with "tabs" across the top for the webs. The "tabs" are more obvious sicne many applications use that style for differnet views, different segments or (in late model MS-word) different documents. I suppose one could experiment with the web menu being tabs in the TopBar, making it look a bit like the KoalaSkin. Round edge tabs in colours to match the webs, ToolTip pop-ups.

Disagree
Once you get the idea of the segmentation, its a powerful tool. The TWiki.org site demonstrates this with the Codev/Plugins/Support separation. If we ever get HierarchicalWebs it will apply even more.

Agree
Browsing a completely unstructured, unfocused web such as TWiki is a pain. Sven has code to convert Dakar sites to have Configuration and Documentation webs, which will make things a bit more understandable, although na\ming them "TWikiConfiguration" and "TWikiDocumentation" may not be the most obvious to the new users.

Disagree
How much do we have to accomodate the user who is new and unwilling to explore and learn what the conventions are? Yes, there are many "industry stadnards", and many of them are alternatives to one another. But anyone visiting a foreign country or even an unfamilar city is going to have to learn the local conventions. To take an automotive analogy, all of the USA drives on the ... right. But driving is San Francisco feels very different from driving in the suburbs of Boston, in Washington, or in Beautiful Downtown Tonnawanda - to mention just three examples of my own experience. Wikipedia is a nice user interface, but it has its own conventions. So do other wikis. Call them "personalities". Trying to make Twiki look like Wikipedia is unfair.
  • My point is not to copy Wikipedia. But TWiki should be ready to be accomodated to different environments. If TWiki is used in an intranet, you would need overview pages. These can be created manually, or automatically using categories or other classification principles. If you maintain the stance of "the user should adapt", big chance you will loose users, or your users will choose a different communication platform that is better suited to their information seeking habits. -- ArthurClemens - 20 Mar 2005

About searching:

Disagree
Whatever you come up with someone will dislike it. This applies to both the specification of the search and the presentation of the results.

In fact tagging in the sense of categorization is a form of searching. If you scroll down on my home page you will see how I've set up a search for topics I've contributed to. In effect, my name is a tag.

Disagree
In my time I've worked with many formal databases. A wiki is in effect a full text search engine on a database of topic pages. The limitation with conventional databases is that you search by the key. Where libraries or newspaper clipping services try to "index" books and articles they run into this same problem. Some human has to categorise that book. What is it? A thriller? SF? A mystery? A romance? I have many books on my shelves that could have all four of those "tags". Often librarians categorise by how the publisher or label is marketing the book. Maybe if you are lucky the library has a computer index system that can support more than one category 'tag' for a book.
  • The public library simplifies categorization because the physical location (shelf browsing) is all important there. But professional libaries (businesses, universities) have very elaborate classifications to describe the materials as precise as possible. Often based on a hierarchical thesaurus or faceted classification system. A wiki site could be in the middle: easy enough for users/contributors to co-tag, and elaborate enough to make precise tagging possible. -- ArthurClemens - 20 Mar 2005
  • One way to make tagging easier is to not have to edit a page to tag it, with an editable form (specialized entry interface probably). The keyword/category values should be hierarchical, but not too deep, and be maintained in a separate keyword list topic. On some sites this topic should be editable only by the keyword maintainer, with room for suggestions. To be elaborated on in EasyTagging. -- ArthurClemens - 20 Mar 2005

Hmmm. I think I will experiment with "tabs" in the top bar. I wonder how to get rounded top edges without having to resort to graphics.

  • Only Mozilla lets you create rounded graphics in code. But what's wrong with images? If you provide us with the originals we can change the graphics to the local styles. -- ArthurClemens - 20 Mar 2005

-- AntonAylward - 19 Mar 2005

See also MenuIdeas.

-- ArthurClemens - 22 Apr 2005

Very interesting discussion here that I've been wanting to give deeper thought to myself as I think it's so important for how we present TWiki. Just a couple of quick thoughts for now.

First, I think we should try to ground this discussion as much as possible in user's perspective - as in imagining use cases of how users will 1) navigate when visiting a twiki site and 2) organize their own newly installed twiki site. With a tool as flexible as twiki, exploring all possible "philosophical" options for organizing seems to me like a map to no-where land.

Secondly, I'm most interested personally in how we assist/empower folks setting up their new twiki to create a framework for ordered growth. That's why I designed TopicClassificationAddOn. While I'm clear that this particular solution has a ways to go in terms of eloquent transparency, I feel strongly that the usability of twiki for normal users would be greatly enhanced by including structured categorization scheme like this as part of the core distribution.

Lastly, one of Author's comments above brought something into focus for me regarding TWiki's use of Webs, which has troubled me for a long time. Conceptually, I've never be able to make a logical case for the TWiki's use of Webs. However, practically, I use webs all the time. What just struck me is that, in practice (again, from users perspective), I believe that TWiki webs are mostly about groups. I create webs for different groups. This may be largely a function of TWiki's notification mechanism, which is based on Webs, but then that fits well with groups also. WebNotify gives me one email a day summarizing changes in topics relevant to my group. And when I explain that to new or prospective TWiki users, they immediately understand and like it. From this perspective, I think that for most users, a good alternative name for Web would be "Group."

The problem with this is that it does not jibe conceptually with how Webs are used on TWiki.org and I think that may be the the source of confusion around our ideas about webs. I've concluded recently (based on good discussions around separating out configuration and documentation), that our confusion around webs is the result of TWiki.org's (and default distrubutions) using webs to refer to functional components of the TWiki system. From a usability perspective (and from software design perspective too I suspect) it makes little sense to have configuration and documentation on the same visual (and hence conceptual) level as the webs folks actually use on day-to-day basis. The intuitiveness of a TWiki site is immediately enhanced when, as some folks have done on their installations, these administrative "nuts and bults" are tucked away under some less-visible menu item called something like "system." Never mind what "storage unit" these elements are packaged in. Although on that point, I've also concluded that configuration and documentation might be better served by packaging them is a less-wiki-like format. Why should documentation be editable on local installations? Wouldn't configuration be easier if it were more form-based as has been discussed in SupportFormsForSettingPreferences?

In short, I've concluded both user and system would be better served if configuration and documentation weren't "packaged" as a web at all. Remove these from the picture and I think we can come up with an readily understandable rationale (and name) for "webs."

-- LynnwoodBrown - 22 Apr 2005

I have been reviewing organising pronciples, which have been developed considerably since this topic was written. Here is a PresentationOnSiteOrganisation which I gave to my development team recently, to start a discussion about how we would organise our site. It may be useful to new admins going through a similar excercise.

-- TamsinTweddell - 05 Nov 2007

Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2008-08-25 - TWikiJanitor
 
  • 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-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.