Presentation On Site Organisation

At Max Fordham, we are moving on from usability issues to considering how to organise the site. It will be used as an intranet and engineering knowledge base.

I have been reviewing organising principles, which have been developed considerably since OrganizingPrinciples was written. Here is a Presentation which I gave to our Knowledge Management Working Group recently, to start a discussion about how we would organise our site. It may be useful to new admins going through a similar excercise.

Other useful topics:

• OrganizingPrinciples
• TagMeDiscussions

We have the following plugins installed that are relevant to this presentation:

• SearchSummaryPlugin
• TreePlugin
• TagMePlugin

Slide 1: The Objectives

The site organisation need to:

• Allow for browsing by subject area
• Collect related topics together for automatic notification of changes and reporting
• Encourage users to self-organise
• Minimise administrators role
• Be self-explainitory (simple)

Slide 2: Options for Organising the site

• Webs
• Search
• Embedded links
• Name conventions
• Hierarchical tree structure
• Categories
• Tagging
• Overview pages

Slide 3: Webs

Topics with related content are grouped into webs.

• Searches tend to be limited to a web - improves speed
• Notifications are organised per web.
• Various settings, templates, forms etc are organised per web

Slide 4: Search

Searching by keyword does not require knowledge of the site organisation.

• Results show keyword in context (like on Google).
• Search results are not ranked by relevancy.

Embedded searches are very powerful:

• They can be formatted into tables, bullet lists etc. Add links to examples on your site
• Allows topics with a common word in their name to be listed (see name conventions) eg *Intro

Slide 5: Embedded links

Embedded Links are easy with TWiki:
Just type the topic title with words joined together, eg FeedbackForum
or if separate words are easier to read, enclose in square brackets [[Feedback Forum]]

Manual links will only be set up to other topics the author knows about.

Slide 6: 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 Jump Box.

Topics with a common word in the title can be listed together and/or can have a common template. Examples:

• *Overview
• *Introduction

Slide 7: Hierarchical tree structure (1)

Topics have a parent-child relationship. This can be shown as a tree using TreePlugin. Add link to example on your site

Advantages:

• Allows users to browse for relevant topics.
• As the parent-child relationship exists anyway, you may as well make use of it.
• Hierarchy is shown at top of each page, allowing for easy upwards-navigation Show example
• Notification can be set up for all topics in a branch of the tree (grouping similar topics)
• Can search all topics in a branch of the tree. Add link to example on your site
• Child topics can be automatically listed on a page.

Comments

Each new topic created is either the child of the topic it was created from, or the creator is prompted to select a parent from the list of existing topics.

The tree may be made collapsable once it gets big.

Slide 8: Hierarchical tree structure (2)

Disadvantages:

• A topic can have only one parent so can appear in only one place in the tree, so the tree view only shows one possible relationship between the topics.
• Having to select a parent topic may be off-putting to new users.
• Users may not select an appropriate parent topic. This may need to be managed by the TWiki Admin, which could be time consuming.

This method needs to be combined with manual embedded links to ensure topics are linked up appropriately.

Slide 9: Categories (1)

Categories are entered as a form field. A topic CategoryCategory acts as an index to all the categories, and each category also has an index topic, such as CategoryOrganizingPrinciples. The index topics are automatically populated.

Example of category use on twiki.org

Advantages:

• A topic can exist in multiple categories.
• Report generation by category can be done.

Slide 10: Categories (2)

Disadvantages:

• Requires a form in each topic, which adds complication.
• Notification by category is not supported.
• May not be able to automatically generate a drop-down list of categories.

Slide 11: Tagging (1)

The larger a wiki gets, the harder it is to find content. TagMePlugin attempts to solve the issue based on these assumptions:

• Assertion 1: Intranet search does not work well due to inadequate ranking of search engines on intranets. This is because there are typically not many cross-links between pages.
• Assertion 2: Let the individuals build their own taxonomy to find content quickly
• Assertion 3: Let the users do the ranking to get an "human intelligence" ranking of important content

Slide 12: Tagging: benefits

There are clear benefits in tagging content in a large TWiki (10K or more topics):

• Find relevant content in a large system quickly,
  • by quickly accessing related topics via the tags on a topic Example
  • by quickly accessing related topics via related tags listed in a specific tag view
  • by quickly identifying important tags in the tag cloud Example
• Access my favourite topics quickly (assuming I tag topics of interest)

Slide 13: Tagging: design goals

The design goals of TagMePlugin were as follows:

• Any topic can be tagged by individuals -> create taxonomy for individuals
• Make it as easy as possible to add a new tag to a topic
• Encourage users to create new tags, but try to avoid use of similar tags for the same subject

Tag ranking principle:

• Encourage users to reuse the same tag on a topic -> get a "collective ranking", or "vote for a tag", or "tag count"
• Make it as easy as possible to increase the tag count
• Show tag statistics of all users on each topic -> show popularity
• Search for topic by tag, sorted by tag popularity

Slide 14: Limitations of TagMePlugin

TagMePlugin currently DOES NOT:

• Allow web-specific tags (ie the tag set is common to all webs)
• Allow for keyword searching within a tag set
• Support email notification based on tags
• List all non-tagged topics
• Allow personal tags to be hidden from other users (eg "to read").

Also, when selecting a tag to add to a topic, the tag list is shown in alphabetical order. There is currently no way to group tags hierarchically or into categories (eg all sustainability tags together).

Slide 15: Difference between tagging & categories

The tag count does not seem to be well used. In which case, tagging is similar to categories with the following differences:

• Tags are easier to add than categories because:
  • You don't have to go through an edit-save cycle.
  • You can select them from a drop-down list and don't have to remember them.
• Categories can be web specific (or not). Tags are common to the whole site.
• The number of tags tends to be much longer than the number of categories (but doesn't have to be)

Slide 16: Developing a tagging strategy

How fine grained should the tagging system be?

• Too few tags:
  • too many topics per tag -> hard to browse
• Too many tags:
  • categories may overlap and/or be interpreted differently by different users.
  • pick-list becomes too long (and is alphabetical so less browsable)

Slide 17: Overview pages

Each subject area (eg Heating, Fire Alarms, Daylight) has a SubjectOverview page with a common template.

This has standard sub-topics such as SubjectIntro, SubjectProjectExperience, SubjectManufacturers, SubjectCalcs.

More detail is created as subtopics, listed on the Overview page, so as to be a navagation portal to these subtopics.

The Overview page also contains the Helpline type lists of info (standards, reference sources etc)

Notes from discussion following presentation

1. The TagMePlugin has too many short-comings to be useful at present:
   • Tags can't be used in SEARCHES.
   • Tags can't be used for notifications
   • Tags can only be listed alphabetically
   • Tags cannot be different across different webs
   • Cannot search for the overlap between 2 tags.
2. The WG favoured a version of Categories using Web Forms. The different groups of category are to be separated, such as work sections, building sectors, management.
   • Tamsin to do a simple mock up to see how this can work.
3. Tamsin is keen on defining the first 2 topic levels in the topic hierarchy, with the second level acting as Overview pages on a specific subject (eg Heating ot Wind Energy) and manually listing all the related pages. The first 2 levels only will be shown in a topic tree.
   • This will be good for browing.
   • Will be more labour intensive for Site Administrator but may end up better organised than the category method.
   • Tamsin to do a mock up.
4. Following the 2 mock ups, will do some user testing to compare the 2 methods for usability and usefulness:
   • How easy is it to find pages?
   • How easy is it to add pages?

-- Contributors: TamsinTweddell - 05 Nov 2007

Discussion

You don't need forms in order to use categories! Guess it should be possible to develop a CommentPlugin template that works similar to the tagging interface but adds categories to topics. Hm. Interesting read.

• For the newcomers: by just inserting plain text - for instance with a prefix "Tags:" - that can be used in SEARCHes. -- ArthurClemens - 05 Nov 2007

-- FranzJosefGigler - 05 Nov 2007

Since categories are often based upon FomattedSearch, a plain 'ol comment field like this can "tag" this topic as CategoryPresentation.

-- DewayneVanHoozer - 06 Nov 2007