frogpond

Usability innovativer Intranet-Werkzeuge: Einfachheit, Schnelligkeit, Klarheit

Hier kurz die Zusammenfassung meines Vortrags an den Intranet.days 2008 (“Usability innovativer Intranet-Werkzeuge: Einfachheit, Schnelligkeit, Klarheit”)

– Meine These: Usability ist Erfolgsfaktor für breite Akzeptanz unter den Mitarbeitern
– wir brauchen diese Akzeptanz um die bestehenden Anforderungen an effiziente Zusammenarbeit zu erfüllen

Vorteile Wiki
– Wikis stehen für Einfachheit, Schnelligkeit, Klarheit, sind aber nur ein Element des Enterprise Social Software Werkzeugkastens
– Fokus auf Content (barrierefrei, auch mobil zugänglich)
– einfaches schnelles Publizieren mit Wikis – alle sind Editoren, nicht nur eine ausgewählte (professionelle) Gruppe
– Wiki als Verschlankung des Publikationsprozesses
– Wiki als Chance die Beteiligung auf viele Köpfe zu verteilen

Usability
– Usability ist wichtig weil wir mehr Beteiligte im Intranet haben wollen – diese sind aber keine professionellen Informationsarbeiter …
– Fünf Elemente von Usability: Learnability, Efficiency, Memorability, Fehlertoleranz, Joy of Use/Satisfaction
– Twitter als Messlatte für Einfachheit

Herausforderungen
– Strukturen, insbesondere Prozesse der Wissensarbeit müssen angepasst werden
– Change Management – wird durch “persuasive technology” erleichtert
– Pick battles big enough to matter, small enough to win
– Der Nutzen von Wikis kann den Nutzern in der Regel schnell klargemacht werden
– Small is the new Big – Wikis als kleine Lösung, die aber potenziell sehr groß sein kann
– People designing their own experiences – bspw. in Form von Subportalen im Wiki für Projektgruppen, individuelle Wissensarbeiter etc.

Diskussion
– Inwiefern kann das Wiki-Konzept auch in großen Unternehmen eingesetzt werden?
– In Deutschland ist noch viel Zurückhaltung zu spüren, dies ist u.a. in global agierenden Unternehmen anders
– Rechtliche Fragen und Ängste bestimmen in Deutschland noch die Diskussion
– Die ersten Unternehmen, die Wikis verstehen und umsetzen können (Effizienz-)Vorteile haben – vor der langsameren Konkurrenz
– Es ist ratsam Experimente zu machen – Pilotprojekte in kleinen Einheiten konzipieren, von den Erfahrungen lernen und dann “skalieren”
– Gute Use Cases für den Einstieg sind bspw. Glossare, FAQs, …
– Von Design-Paradigmen lernen – Prototypen, Experimente, Nutzerbeobachtung, Perpetual Beta …”Instead of arguing, we should be iterating”.

Wiki – Gegenargumente und Gegengegenargumente

KoopTech hat eine Liste von Wiki-Gegenargumenten vorgestellt. Nicht alles davon ist stichhaltig. Manche Punkte benötigen schon einer Relativierung – oder auch direktem Widerspruch. Aber ich will nicht überkritisch sein, denn Kooptech hat ja auch 10 Gründe für den Wiki-Einsatz gefunden.

Johannes Moskaliuk hat die 8 Gegenargumente analysiert – unterteilt in funktionale und psychosoziale “Lösungsmöglichkeiten”. Gefällt mir sehr, und ja, es geht hier nicht um absolute “Wahrheiten” sondern mehr um Gefühle, Einschätzungen und eben auch alternative Umsetzungs- und “Lösungsmöglichkeiten”. Also erweitere und kommentiere ich Johannes’ Ideen aus meiner Sicht:

1. Die krude Wiki-Syntax ist oftmals ein Akzeptanzproblem.

Psychosozial: Neue Software erfordert neue Kompetenzen. Ohne Schulung der Mitarbeiter, Supportfunktion und eine Beteiligung der Nutzer bei der Entscheidungsfindung geht es auch im Wikizeitalter nicht.

Funktional: Mit dem Einsatz eines WYSIWYG-Editors ist das Problem lösbar. Technisch möglich ist auch die weitergehende Integration ins Betriebssytem, wie z.B. beim TWiki mit dem Kupu-Add-on (Linux) oder beim der Confluence-Software mit MS Office (Microsoft).

Zum einen: WYSIWYG-Editoren sind kein Allheilmittel und weisen nach jetzigem Stand der Technik auch gewichtige Nachteile auf. Es ist kein Zufall dass Enterprise Wikis wie Socialtext beide Editor-Alternativen parallel anbieten. Eine ausführlichere Analyse von Pro und Contra findet sich hier (“Simplicity, adoption and WYSIWYG editors”).

Zum anderen: Eine Einschätzung als krude Syntax (sic!) gilt nicht für jeden Markup-Dialekt, man vergleiche einmal die Auszeichnungsalternativen von bspw. Mediawiki für kursiv und bold (” und ”’, bold und kursiv sieht dann so aus: '''''fett und kursiv''''' – eingängig nicht wahr?) mit denen von Wikicreole, an die sich u.a. DokuWiki anlehnt.

Aber die eigentliche Aufgabe liegt natürlich im Bereich “psychosoziale Akzeptanz”, und es ist zweifellos richtig, dass Markup ein Akzeptanzproblem hat. Letztlich gilt das für alle Werkzeuge, die nicht wie Word aussehen (interessanterweise werden manche andere Werkzeuge und Systeme nicht so stark hinterfragt was Usability und Akzeptanz angeht, sie werden Mitarbeitern aufgezwungen und diese müssen damit mit SAP R/3 arbeiten – auch wenn die Usability bescheiden ist). Pragmatisch gesehen liegt die Antwort daher meist in einem “sowohl als auch”, in Verbindung mit einer gewissenhaften Analyse von Anforderungen und Zielgruppen, die Frage ob WYSIWYG sein muss, sollte dabei ergebnisoffen und vorurteilsfrei angegangen werden.

2. Kategorien und Hierarchien lassen sich zwar aufbauen, doch eine entsprechende Navigation kann nur über einen Eingriff im Backend eingerichtet werden.

Funktional: Über den Einsatz semantischer Technologien oder – einen Schritt vorher – die konsequente Anreicherung von Informationen mit Metadaten (z.B. Tags, Projektzuordnung, Themen, Inhaltsklassen) sind die Inhalte letztlich schneller über eine Suchfunktion als über eine Navigationsstruktur zugänglich.

Psychosozial: Dieses Gegenargument ist gleichzeitig ein Pro-Argument: Die Navigation wird eben nicht „von oben“, vom Admin oder Chef festgelegt, sondern wird von der Community kollaborativ erstellt.

Hmm, Navigation nur über einen Eingriff im Backend? Gilt nicht für die Wiki-Engines zu denen ich rate. Und Navigation über Kategorien oder Hierarchien? Es muss eben evaluiert werden, ob es nicht Wiki-Engines gibt, die so etwas von Hause aus mitbringen (bspw. TWiki-Webs, eigentlich alle gängigen Enterprise Wikis oder auch DokuWiki mit dem Namespace-Konzept).

Johannes – großartiger Punkt bei psychosozial. Dieser Aspekt des emergenten Entstehens von Struktur wird zu oft vernachlässigt, obwohl er viel für die flexible Anpassung an veränderliche Aufgabenstellungen (und die Motivation der Mitarbeiter) tun kann. Arbeitsgruppen, einzelne Mitarbeiter, einzelne Projektgruppen etc. können sich situativ angepasste Arbeitsumgebungen, Portal- und Übersichtsseiten einrichten. Das habe ich mit großem Erfolg auch schon begleitet, und es war eine Freude zu sehen wie die Möglichkeiten von den Nutzern aufgenommen und schnell genutzt wurden.

3. Die Kategorisierung spielt bei den Suchergebnissen keine Rolle bzw. sorgt nicht für eine Priorisierung von Suchergebnissen.

Funktional: lösbar, siehe oben

Psychosozial: Kompetenz bei der Anwendung der Suchfunktionalität muss bei den Nutzern vorhanden sein, oder geschult werden. Außerdem kann das Finden von Informationen, nach denen eigentlich nicht gesucht wurde, Prozesse der Wissensemergenz fördern (Serendipity).

Ich würde noch ergänzen, dass wir auch die zunehmende Einbindung von Wiki-Inhalten in Enterprise Search Ansätze sehen werden. Von Social Bookmarking in the Enterprise ganz zu schweigen. Das Problem ist erkannt, daran wird gearbeitet und Wikis sind eigentlich hierbei das kleinste Problem, viel mehr wird zurzeit damit gekämpft relevante Suchergebnisse aus den vielen, verteilten Office-Dokumenten zu generieren …

4. Suchergebnisse zeigen nicht an, welche Unterthemen es zu einem Oberthema gibt oder ob es in einer anderen Sprache einen Artikel zum gesuchten Thema gibt. Die Semantik drückt sich nicht in Wiki-Strukturen aus. Ab einer gewissen Textmenge ist das nicht mehr praktikabel.

Funktional: lösbar, siehe oben. Schlagwort: Semantic Wiki.

Ja, Semantik drückt sich auch nicht in Office-Dokumenten aus. Tagging, Kategorisierung, redundanzfreie Datenhaltung – alles wichtig, das Semantic Web wird auch manches davon lösen. Psychosozial gilt Punkt 3, Informations- und Medienkompetenz ist nicht immer gleichverteilt und gut ausgeprägt. Coaching und Schulung (und Learning-by-doing) kann hier helfen.

5. Die Suche erstreckt sich nur auf Wiki-Inhalte, andere Quellen können damit nicht erschlossen werden.

Funktional: lösbar. Beispiel ist das Confluence Wiki, dass auch zum Durchsuchen von externen Quellen, z.B. Austauschordner oder Servern genutzt werden kann.

Ja, siehe auch oben die Anmerkungen zu Enterprise Search. Enterprise Wikis bieten mittlerweile fast durchgängig die Möglichkeit bspw. hochgeladene Dokumente in die Suche aufzunehmen.

6. Das Rechtemanagement für ein Wiki muss mühsam eingerichtet werden, insbesondere wenn ein nach Personen und Gruppen differenzierter Zugang für verschiedene Bereiche eingerichtet werden soll.

Funktional: Lösbar zum Beispiel durch den Einsatz von Windows Active Directory. Für das Wiki können bestehende Rechtestrukturen übernommen werden.

Psychosozial: Ein Erfolgsfaktor für den Einsatz von Wikis ist eine flache Hierarchie und der freien Zugänglichkeit von Inhalten. Idealerweise ist die Einführung von Wikis in einer Organisation verbunden mit einer Änderung der Organisationskultur im Bezug auf den Umgang mit Wissen und Informationen zwischen Hierachieebenen.

Hmm, was heißt mühsam? Ist in den meisten Wikis nicht aufwendiger oder anspruchsvoller als die Benutzer- und Rechteverwaltung von Windows Server etc. Eine LDAP-Anbindung ist oft vorgesehen, damit ist dann selbst SSO machbar.

7. Nach etwa ein, zwei Jahren kann es für Unternehmen problematisch werden, wenn die entsprechende Pflege fehlt.

Funktional: Tools können die Pflege unterstützen, zum Beispiel das Finden von toten oder falschen Links, das Ändern von falschen Kontaktdaten etc.

Psychosozial: Das Problem tritt bei allen Systemen zum Wissensmanagement auf. Neben der Einführung einer Technologie, müssen sich deshalb auch Arbeitsabläufe, Arbeitsaufgaben und Rollen (Wikigärtner) anpassen, so dass eine ständige Pflege und Aktualisierung von Inhalten gewährleistet bleibt. Anders als bei anderen Werkzeugen kann die Verantwortlichkeit für die Aktualität der Inhalte auf alle Mitglieder einer Organisation verteilt werden.

Ohne Pflege geht es nicht, nicht umsonst werden die Rollen des Wiki-Gärtners oder des Wiki-Gnoms so wichtig eingeschätzt. Und ja, auch in einem klassischen Intranet kann ohne strukturierende Pflege Wildwuchs, wie bspw. veraltete, widersprüchliche oder redundante Inhalte entstehen (ich gebe aber zu dass ich die Möglichkeit an veröffentlichte Seiten ein “Verfallsdatum” zu knüpfen manchmal vermisse). Aber diese Schwäche kann man durchaus auch zum Vorteil wenden, siehe Punkt 8:

8. Wikis eignen sich für Projekte. Über die Jahre werden jedoch immer mehr Wikis eingerichtet, der Überblick geht verloren – man weiß nicht mehr, in welchem Wiki man suchen muss.

Funktional: Lösbar durch eine Suche, die über mehrere Wikis ausgedehnt ist.

Psychosozial: Klassischerweise wird ein Projekt in einem Abschlussbericht dokumentiert. Auch das lässt sich auf ein Wiki übertragen: Am Ende eines Projekts werden die zentralen und wichtigen Inhalte des Projekts in ein zentrales Wiki übertragen und bleiben dort zugänglich. Das Projektwiki wird gelöscht.

Wenn im Zeitverlauf mehrere Wikis entstanden sind (oder Projektunterbereiche etc.) ist es aus meiner Sicht auch eine Chance Inhalte rückschauend zu strukturieren, und dabei positive und negative Erfahrungen zu dokumentieren. Ein After-Action Review mag zwar zeitraubend erscheinen, aus meiner Erfahrung lohnt sich die Mühe aber. Eine Zusammenfassung der wesentlichen Punkte schafft einen Überblick, der bei anderen ähnlich gelagerten Projekten hilft. Ein paar Ideen zum Einsatz von Wikis im Projektmanagement habe ich hier, hier und hier zusammengestellt.

Zusammenfassend: Einige der Punkte entstammen meiner Meinung nach einer weitverbreiteten (aber unüberlegten) Gleichsetzung von Wiki mit Mediawiki bzw. Wikipedia. Die Wikipedia ist aber kein archetypisches Wiki, und Mediawiki ist auch nicht stets die beste Wiki-Engine. So weisen bspw. Enterprise Wikis wie Socialtext oder Confluence einen Großteil der oben vermuteten Angriffspunkte überhaupt nicht auf, sprich es bestehen bereits funktionale (technologische) Lösungen.

Zudem beziehen sich viele der Kritikpunkte der originalen Liste von Kooptech auf potenzielle Nachteile, d.h. mögliche Schattenseiten von Wikis, die erst durch eine “ungeschickte” Einführung und ungeignetes (Wiki-)Management* zutage treten. Die Auswirkungen auf Strukturen und etablierte Routinen etc. können ja groß sein – das ist auch das eigentliche Motiv von Enterprise 2.0. Aber um diese Potenziale heben zu können braucht es auch ein schlüssiges Konzept, sowie die Anpassung an die Unternehmensgegebenheiten und -ziele. Aber wenn etablierte Vorgehensweisen und Erfolgsfaktoren der Implementierung nicht beachtet werden, kann es durchaus schon mal schiefgehen.

<werbung>Deshalb bietet es sich ja auch an professionelle Unterstützung ins (Projekt-)Boot zu holen. Berater wie wir bringen zum einen spezifische Erfahrungen ein, aber auch

einen Überblick über bewährte Vorgehensweisen und

Ideen, d.h. innovative, kreative Problemlösungsstrategien.

Davon kann die organisationsseitige Einpassung – sprich das Change Management in Bezug auf die eigentlich spannenden sozialen und unternehmenskulturellen Aspekte – profitieren. Und weil es bei Enterprise Social Software wie Wikis meist weniger um Technologie, denn um diese weichen Faktoren geht ist eben weniger Technologieberatung denn Organisationsberatung notwendig.</werbung>

* ich lese gerade das Buch Wikimanagement von Prof. Komus, Review folgt.

Focusing on people and work relations, usability and more …

Socialtext has announced version 2.20, with improvements to the user experience and added Dashboard and People modules. Besides the “Facebook for the enterprise” approach, that puts people and work relations at the center of interest, I particularly like the focus on integration and usability (yes, this is important): Ease-of-use can be a dig differentiator in this market of “enterprise collaboration suites” (wikis are a central part still) – corporate users don’t want to spend days of training to learn “systems”: It’s better to spend the time (and consulting budget too, you know) on coaching and implementation, supporting early users, building up internal support (and use cases) etc.

Here’s a video demo of the newly added capabilities (via Jon Grorud and Socialtext Customer Exchange):

In this context, Scott Schnaars explains the direction and goals of Socialtext along four business use cases:

Collaborative Intelligence for sales and marketing
Participatory Knowledgebase for service and support
Flexible Client Collaboration for professional services
Business Social Networks for partners and customers

Disclaimer: Jon pointed me to this video, alas – I am subscribed to Ross Mayfield and the Socialtext news and feeds anyway. Consultants need to stay up to date … and that’s where this is apt:

Disclaimer 2: I know there are other players in this market too, like Jive’s Clearspace, XWiki, BlueKiwi, MyWorkLight – even Lotus Connections might stand the test and integrates well (I don’t have to link the IBM guys – do I?).

Wikibility of Innovation oriented Workplaces

This is the networked professional’s web 2.0, via Sebastien Sauteur I found Vincenzo Cammaratas master thesis, called “Wikibility of Innovation Oriented Workplaces – The CERN Case” (pdf). Here’s the abstract, I have skimmed through the +100 pages over the weekend and recommend it basically:

[…] Wiki systems and other social networking applications
represent an important shift on the way in which people work: at the opposite of other previous IT technologies in this field, the Enterprise 2.0 is not about simple devices of office automation, but requires (and brings to) a dramatic organizational culture shift. In particular Wiki offers new possibilities and opportunities in order to exploit in a more effective way the entire potential of the collaborative work coming from the active participation of all the individuals that are present in a workplace.

This dissertation wants to contribute to the current debate on the cultural shift that the introduction of this tool in a workplace is able to produce: we will see that, for a Wiki – or any Enterprise 2.0 tool – being effective it has to activate a virtuous circle able to create new knowledge.

The peculiarity of this work is that it focuses on this particular cultural
aspect and aims to define the features of the ideal workplace that can optimize wiki use in order to be innovation oriented and “hence” competitive.

Once identified these “cultural key drivers” and defined Wikibility as the
cultural attitude of an environment able to make the Wiki use in a workplace effective, the further scope of this thesis is to measure the presence of this Wikibility mind-set and to propose a new tool (not yet validated). This sort of cockpit could be useful for the management that, interested to promote a better and true collaborative approach to work, wants to be sure on the effective support in order to produce true innovation.

I like the goal of his work and am absolutely sympathetic (hmm, wikibility, yes, a neologism but I dig it) – but I am also a bit cautious. “Measuring” organizational culture and designing a cockpit or “dashboard” that enables management to steer (and control) processes of organizational change sure is attractive, as is the vision of an “ideal wiki situation” where implementation of enterprise 2.0 is naturally, but I doubt that the CERN situation nor the learnings made there can be replicated in “normal organizations”. And I sure don’t buy the idea that a fitting organizational culture must be present in advance, as “a preliminary workplace attitude”, put forth here (see slide 15):

Of course it helps if the people “grok it”, and it helps a lot if management gets it too, but otherwise I side with Mike Gotta (“Enterprise 2.0: Culture Required?“)
and Michael Idinopulos (“Culture is a destination not a starting point“).

Mike, (who referred to Michael’s post) says:

You can be very successful in use tools associated with E2.0 (blogs, wikis, tag and social bookmarks, etc) even in situations where culture is “unhealthy” – and when participation is more or less “directed” by role, workflow, and functional duties

Michael entering stage too:

[…] There is a view out there that an organization needs to have a “culture of collaboration” culture in order to successfully employ wikis and other Enterprise 2.0 tools.

That view is dead wrong. I’ve seen wikis thrive in un-collaborative cultures. I’ve seen wikis fail in collaborative cultures. I’ve seen wikis thrive in an organization alongside failing wikis in the same organization.

Even within “non-collaborative” cultures, people have to work with other people. We’ve seen lots of examples of wikis being introduced into those cultures in very safe ways – to streamline and simplify existing business interactions within existing organizational silos.

He also elaborates on an example of how social software inside an organization can act as a change catalyst – yes, the way I see it is that social software is both a driver and an enabler (or infrastructure) of organizational change.

Some recent enterprise social software notes …

Thomas Van der Wal ponders the uses of social software in mergers and acquisitions, referring a recent post by Stewart Mader on the opportunities of getting new employees up to “working speed” quickly (“Onboarding: getting your new employees cleared for takeoff“).

Ken Thompson on the relation between collaboration, teams and business process management:

It’s the human-to-human interactions of teams that count when it comes to innovation and agility. … you and everyone you work with must be able to function in and through internal and multi-company teams, and must also grasp what the latest concept of “team” really means

Matt Moore interviewed James Dellow about the Enterprise RSS Day of Action, here’s the mp3

Armin Karge tells us the story (in german language) of a tangible method of change communication:

Das “Cockpit” muss vor allem zwei Anforderungen gerecht werden: Einerseits soll es Alarmanlage und Kontrollinstrument sein. Andererseits soll es durch Offenheit und Transparenz zu mehr Akzeptanz der Beteiligten führen. Im Idealfall sind die Mitarbeiter beteiligt und identifizieren sich.

Stewart Mader and the team from Atlassian are sharing insights on wiki functionality, use cases and adoption (and they are giving away free copies of Stewarts Wikipatterns book, my review is here) at the Web 2.0 Expo this week, see what’s on the slate and drop by if you’re in San Francisco.

And finally Andrew McAfee reminds us of the importance of all this:

Enterprise 2.0 is not a hype, but it is also not easy, and it will serve to separate the winners from the losers

Andrew will keynote Heliview on May 7th, looks promising, I am thinking of going too – want to meet up?

Simplicity, adoption and WYSIWYG editors

I was having several conversations at re:publica on wiki adoption (and consulting) topics. Over time, we (that is Andreas Gohr, Christian Kreutz, Tim Bartel, me and sometimes innocent bystanders and fellow twitterati) covered wiki technology, design and a wide array of social software adoption issues. One of the central topics was the question of WYSIWYG editors and their relevance for wiki adoption.

This was triggered by this blog post of Tim Wang (which I found via Tim Schlotfeld), that referred to a short wiki comparison, culminating in this:

Regardless, lack of a WYSIWYG editor continues to scare off most users and therefore wikis lacking one should be eliminated from contention.

This unsettled me, and while I am hearing this argument again and again, I think that this line of reasoning misses some important points. It’s not only about leaving out many able and well-kept wiki engines by restricting evaluation to those with a WYSIWYG editor, and it’s not only about an obvious lack of real research with real users (sure, wiki syntax scares off people and Wikipedia is a miserable failure) – it’s about a fundamental misunderstanding of both efficient knowledge work and user interfaces. While WYSIWYG is supposed to offer clarity, simplicity and easy adoption I hold that this is exactly what wiki markup is good for.

– Wiki markup editing and its restricted user interface makes it easier to focus on content, much like the “dark mode” some people choose for real editing – basically because WYSIWYG editors distract attention.

– We want employees to focus on content, edit it quickly and use the wiki (and the intranet) in an efficient way – we don’t want our employees to fiddle with nice looking but irrelevant eye candy or with overblown full-featured editors like this:

– Antoine de Saint-Exupery, author of The Little Prince, once said, “Perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away.” Simplicity doesn’t equal low functionality, and is more important than comprehensiveness (and complexity). Smart web applications need to employ intuitive ways of interaction. Just look at these different user interfaces (by Eric Burke), showcasing common but different approaches to user interface design:

– People with relevant knowledge in the organization (yes, we’re talking about the “empty quarter“, often these are people close to retiring) need simple and clean user interfaces. User interface design ideas like usability, simplicity and clarity suit these people.

– WYSIWYG editors aren’t perfect yet – if you’re just trying to format text you’ll be OK, but for more advanced stuff like tables etc. you need wiki markup editing anyway. Going the WYSIWYG way is risky too – think of initial user acceptance, that will suffer when people get disappointed by their efforts at wiki editing. Yes, even when it looks like MS Word it ain’t the same, and becoming frustrated because the wiki obviously scrambles the nice looking word document you just copy-pasted makes for a really bad start. Granted, you can coach and explain this to your users, but then – why not teach them simple markup rules in the first place. Combine this with an explanation why dragging a picture into Word works but won’t (for now) work with a web-based application.

– Advanced users are going to use wiki markup language anyway, beginning wiki users may start with WYSIWYG but will learn soon that the other way is more efficient. When they have grasped a few simple techniques, such as putting ** around a text to make it bold or putting [[ ]] around text to create links, they can create great looking content with minimal fuss, and the look and feel of the wiki pages is consistent throughout the wiki. Providing the choice between both ways, allowing for quick changes between both modes of editing, is one solution. And yes, it’s no big wonder that both Confluence and Socialtext are offering both alternatives in parallel, simple and advanced (yes, that one’s wiki markup mode). Try both modes at the Socialtext WikiWednesdayStuttgart page. So the argument that adoption hinges on the existence of a WYSIWYG editor is flawed – wiki markup can be easily explained and adding some coaching efforts to an implementation project doesn’t hurt, explaining the rationale behind wiki usage etc. I have had decent successes with 15 minute short introductions, followed by “train the (peer) trainer” coachings, after all editing wiki markup editing is neither programming nor rocket science.

– What wiki users really need are standardized wiki markups (like wikicreole). This would make it both easier to export/import content between different wiki engines (and document processors like Word), and to write powerful and easy-to-use WYSIWYG editors. Until then we need to rethink some of our assumptions – especially about what end-users want and need. I see that people want to do their job easily and efficiently and that user interface information overload is a problem. So wiki markup is a solution, not a problem.