Wikis need a customized Design

Siehe auch den deutschsprachigen Artikel zum Thema.

Whenever we speak with clients and go through possible services with them, they often have questions regarding why we offer services such as “Layout Design” or “Executing the Design in HTML and Implementing within the Wiki”.

In this article, we will offer you a couple of arguments and explanations to answer why it is worth having your wiki professionally designed.

“Seeing is believing” – just take a look
In our opinion, the best of arguments is still trumped by taking a look yourself. Here is a standard layout as offered by TWiki in version 4.2.:

Standard-TWiki-Layout in der Version 4.2

These are layouts designed by //SEIBERT/MEDIA using the same software and page content:

Images: The wikis of SnowTrex and ReiseBank AG, both of which were implemented by //SEIBERT/MEDIA

Arguments for professional and customized Wiki designs
High opportunity costs can be incurred if the application layout isn’t customized. Reasons include the following:

  • The standard version of TWiki has usability problems
    TWiki has – in its standard version – many usability problems and, to an extent, extreme problems regarding its functionality, problems which must be fixed through layout adjustments. Otherwise, you may expect a large amount of negative feedback from the users. (N.B.: TWiki is one of the best wiki software systems. This criticism is directed only at its “standard skin”.)
  • Increase the Joy of Use & acceptance of the wiki
    Professional, high-quality design strengthens the users’ acceptance of the systems and promotes “Joy of Use”. The effect of these measures and their sustainability cannot be judged highly enough. In addition: In 2008, we ran user tests regarding an intranet application for the German Post (Deutsche Post). The customized version of the layout conforming to the CI received by far the most positive comments.
  • Send a message about the high relevance of the wiki
    An uncustomized layout sends the wrong signal to the employees who are expected to work with this system. This could give the impression that the wiki is neither highly valued nor considered to be important. The rolling-out of the system is an extremely important phase and could easily and unintentionally be damaged by not having a customized layout. Finally, if you don’t clearly communicate that the wiki is important, your employees will also see it as unimportant. However, a wiki can only thrive on participation.
  • A professional print- and PDF-export function saves time
    Within the framework of the design customization there is also usually a customization of the print versions of the wiki documents. Within this context, it is also normal to prepare a PDF generation of contents that makes possible the direct exporting and sending of documents. Now briefly consider that without this work, much work from the wiki will have to be copied into MS Word templates. Why? Just so the layout matches? This is nothing but a waste of time.
  • The standard TWiki design clashes with your design
    In its standard design, TWiki just doesn’t match the corporate design of your company. This results in the biggest problem: TWiki will be seen as a foreign object, an external software system, and not as a unique corporate wiki. This is due to the simple psychological phenomenon of people treating the strange and the new with skepticism and maintaining their distance; they have far fewer reservations when dealing with the familiar.

This list could be continued and should not be seen as complete. It does, however, give an excellent first look at how risky it would be to go “live” with the standard design of TWiki. In the past, we have had many bad experiences with this and therefore no longer offer it as a matter of course. Thus, customizing the design should in any case occur before the piloting phase; an uncustomized system is – at best – only interesting for becoming acquainted with the software, and this should only be executed with a few participants.

Further information:
Management dashboards in an intranet
Wikis are the glue holding intranets together
Seven ways to achieve successful corporate wikis

Die Wiki-Broschüre von //SEIBERT/MEDIA

Download Download (1,1 MB): Our wiki brochure in English (PDF)

Mehr über die Creative-Commons-Lizenz erfahren

Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

One thought on “Wikis need a customized Design”

  1. With your interest in wikis, I thought you may be interested in Wikidsmart for Confluence. It turns Confluence into a semantic wiki so that you may contextually capture information in a structured way. Here’s a bit more about it:

    plus you can see an example in action with this video:

    We will have an example up soon of semantic search too but here’s a rough version on youtube:

    Also, it’s open source so you can download and use it free, just plug into Confluence. And it integrates with Jira, Subversion, Perforce, etc. in a very deep, contextual way Any other applications may be integrated as well for example a CRM.

    Please feel free to contact me if you have questions.

    Best regards,

Schreibe einen Kommentar