Sharepoint Wiki-Extensions: Kwiz Com Wiki Plus – Pro Argumente

Für Sharepoint 2010 gibt es eine Menge Erweiterungen, so auch zu den Wiki-Funktionalitäten. Im Rahmen einer Recherche, was das Sharepoint-Wiki out of the box kann, und was die verfügbaren Wiki-Extensions darüber hinaus bieten, bloggte ich zum einen diese Übersicht der Wiki-Extensions, und hier meine skizzenhaften Spekulationen zu den Anwendungsszenarien. Eine der erwähnten Wiki-Extensions für Sharepoint 2010 war das Kwiz Com Wiki Plus. Im Folgenden möchte ich eine kurze – positive – Einschätzung  zur Verfügung stellen (hier die Contra-Argumente), mit ein paar Beispielen, aber ohne Vollständigkeit. Unsere firmeninterne Version ist 38 Seiten lang

***

Getestete Version: Version 12.1.50 > aktuell ab 22.9.2011

Funktionsübersicht: Habe ich schon in diesem Artikel tabellarisch erledigt

Meine grundsätzliche Einschätzung: Zum Kwiz Com Wiki Plus habe ich eine zwiespältige Einschätzung. Deshalb gibt es auch einen Artikel „Pro“, und einen zu „Contra“-Argumenten. Aber im großen und Ganzen gefällt es mir. Es würde nur nicht zu jedem passen.

***

Funktionsumfang: Das Kwiz Com Wiki Plus ist ein mehr als vollständiges Wiki – das es vom Umfang her auch locker mit Confluence oder FosWiki aufnehmen kann. Es gibt kaum etwas was es nicht kann – das Ding hat sogar einen Image Map Editor!!. Es erweitert das OOTB-Wiki von Sharepoint an fast jeder Ecke. Das gilt umso mehr, wenn man noch die anderen Bestandteile des „Kwiz Com Web 2.0 Bundle“ betrachtet, wie z.B. „Rating“ oder das „Discussion Board“ …

Reifegrad: Der Reifegrad des Kwiz Com Wikis war eine angenehme Überraschung. So ziemlich alles lief zuverlässig, Bugs konnte ich nur wenige entdecken. Das ist insofern bemerkenswert, als dass ein ehemaliger Kollege bei einem Test 2010 noch eine ganze Menge davon entdeckte, vor allem bei Formatierungen und im Umgang mit Bildern.

***

Editor: Grundlage ist der „Telerik RAD Editor“. Sehr schön daran ist, dass man über eine XML-Datei das Menü anpassen kann. Sprich, dass Elemente herausgenommen werden, und die Nutzer ausschließlich das angeboten bekommen, was sie nutzen sollen und dürfen (Stichwort: Governance / Usability):

Am Ende des Inhaltsbereichs finden sich dann noch weitere Eingabemöglichkeiten: Tags, Summary, Minor Change und Life Cycle-Einstellungen:

Der Editor verfügt auch über einen HTML-Modus. Dazu muss man in Editor einfach nur von „Design“ zu „HTML“ wechseln: Voila.

Der Editor bietet noch eine weitere, vertiefende Möglichkeit mit Code zu arbeiten: Den Programm-code-Editor „Format Code Block“ (HTML, XML, ASPX, Javascript, CSS, C#, CPP, VB, Php, SQL, Delphi, Phyton)

***

Life Cycle Management: Ein schönes Feature, Timer Job-getrieben, in den Settings einzustellen. Im Gegensatz zu SP ootb nicht nur für die Library, sondern für einzelne Seiten: Ja/Nein, ob Life Cycle Management erlaubt sein soll / Zeitraum für Versand der Benachrichtigung bis zum Löschen / Betreff, Textkörper, Platzhalter

***

Umgang mit Bildern I: Der Umgang mit Bildern hat mich sehr überrascht, war der Teil doch 2010 noch das „Sorgenkind“ – flüssig, frei von Bugs, umfangreich. Der Upload von Dateien ist mittlerweile grundsätzlich gut gemacht, auch die weitere Bearbeitung, wie z.B. von Dokumenten.

Um Bilder einfügen zu können, müssen sie erst in die Wiki Plus Image Library hochgeladen werden. Der Upload funktionierte im Test tadellos, mit vier Bildern. Die Möglichkeiten sind sehr vielseitig und funktionieren gut:

Umgang mit Bildern II, Image Map Editor: Der Image Map Editor ist ein mächtiges Instrument. Man kann damit Hyperlinks in eine Graphik einbauen – eine Prozesslandkarte würde sich anbieten. Oder ein Organigramm für ein Qualitätsmanagement-Wiki …

Der Image Map Editor kann nur Rechtecke, keine Polygone.

***

… Wie schon gesagt, das ist eine kleine Auswahl der Ergebnisse. Für einen Eindruck reicht es, mich überzeugt es, aber um ein Gefühl für die Usability zu bekommen muss man es sowieso selbst testen. Oder uns fragen.

Der Weg zur Vertrauenskultur: Bis zum „Enterprise 2.0″ dauert es noch etwas

(C) Microsoft

Von Alexander Stocker fand ich vor kurzem einen (Gast-)Artikel, an den ich nach einem Kundenworkshop letzthin wieder denken musste, als es sinngemäß um folgende Frage ging: „Welche Vorteile haben Mitarbeiter von Enterprise 2.0?“:  Diese Überlegungen teile ich in zwei Artikel auf, sonst würde es für das Format Blog zu lang.

Stocker bezieht sich auf die vorgebliche Marktdurchdringung von Wikis, Weblogs und sozialen Netzwerken im Kontext von Unternehmen (Enterprise 2.0):“Enterprise 2.0: Viele reden davon – wenige tun es auch“… Basierend auf einer Studie von McKinsey berichtet das CIO-Magazin von mittlerweile hohen Verbreitungsraten von Web 2.0-Werkzeugen in Unternehmen“. Stocker macht deutlich dass die vorgestellten Zahlen zum einen nicht repräsentativ seien, zum anderen – man muss es immer wieder sagen – das Vorhandensein der Technik nicht kausal deren (kompetente) Verwendung bedeutet.

„Haben“ ist nicht „Anwenden“. Stocker verwendet eine Art von dreistufigem Reifegradmodell:

1. Erste Experimentieren mit Social Media im Unternehmen [...]
2. Systematische Einführung und operativer Einsatz von Social Media im Unternehmen [...]
3. Strategischer und langfristiger erfolgreicher Einsatz von Social Media im Unternehmen [...]

Gut finde ich an diesem Modell, dass es ergebnisorientierten strukturierten Einsatz der Werkzeuge beinhaltet, und das Vorhandensein einer Strategie (das Wissen Wofür?, und wie das Ziel erreicht werden könnte).

***

(C) Wikipedia, "MTO-Modell"

Wenn ich im nächsten Schritt an das MTO-Modell denke (Gesamtsystem aus Mensch, Technik, Organisation), dann sehe ich in diesem Reifegradmodell die Ebene der „Organisation“ unter der Prämisse dass die „Technik“ vorhanden ist.  Was sie tatsächlich mittlerweile oft ist. Hier sehe ich auch viele Unternehmen. Was fehlt ist aber der Aspekt „Mensch“, den ich synonym zu „Kultur“ verstehe und verwende.

Ich für mich meine, dass „Kultur“ von diesen drei Aspekten der letzte und anspruchsvollste ist.

1. Die Technik ist relativ leicht besorgt und in den Griff zu bekommen.
2. Die Entwicklung einer prozessual-orientierten Strategie zu Einführung und Nutzung in die Organisation ist anspruchsvoller, aber auch noch relativ leicht. Denn der Anspruch ist eher handwerklicher Natur, aber sicher weniger auf mentaler Ebene.
3. Deshalb halte ich den kulturellen Aspekt für den anspruchsvollsten. Diese Ebene ist reflexiv, und verlangt vom Management die Auseinandersetzung mit der eigenen mentalen Grundeinstellung. Mit dem Weltbild, eigenen Erfahrungen, Wünsche und auch Ängsten.

***

Das bringt im nächsten Schritt die Frage mit sich, was denn mit „Kultur“ in dem Zusammenhang überhaupt gemeint ist? Welchen Unterschied der Umgang mit Menschen macht, in Bezug auf die erfolgreiche und nutzenstiftende Verwendung von Web 2.0-Werkzeugen? …

Für mich und mein Denken war ein Artikel von Stefan Hagen im Projektblog zur „Angst vor Fehlern!“ ein Schlüsseltext, der mein Denken beeinflusst hat. Aus leider auch ihm unbekannter Quelle zeigt er eine Gegenüberstellung von prototypischer „Misstrauenskultur“ vs. „Vertrauenskultur“:

Folgende Aspekte der Vertrauenskultur finde ich im Hinblick auf die erfolgreiche und nutzenstiftende Verwendung von Web 2.0-Werkzeugen besonders interessant, wenn wir „Technik“ und „Organisation“ als gegeben voraussetzen:

• Systemisches Paradigma, Organisation als lebendes System, Lernende Organisation
• Organisation zur Aktivierung des Leistungspotentials motivierter Mitarbeiter, Eigenkontrolle
• Flache Hierarchie, Typ Selbstorganisation
• Geringe Regelungsdichte, Beschränkung auf generelle Werte und Normen [in klarem Rahmen]

***

Meine These(n) dazu wäre:

• Erst unter solchen Bedingungen bieten Web 2.0-Werkzeuge im Unternehmen einen Mehrwert, der über eine Erweiterung des Bestehenden hinausgeht.
• Mitarbeiter werden Web 2.0-Werkzeuge nur dann effizienzsteigernder einsetzen, wenn sie für sich vom Potential überzeugt sind.
• Mitarbeiter werden Web 2.0-Werkzeuge erst dann mit Überzeugung nutzen, wenn solche Bedingungen gegeben sind.
• Wir entwickeln uns dahin, aber bis zur „Vertrauenskultur“ wird es noch etwas dauern.

***

->>> Die Ausgangsfrage aus dem Kundenworkshop, die zum Nachdenken in diesem Artikel geführt hat, war „Welches Potential hat Enterprise 2.0 für die Mitarbeiter?„. Dem gehe ich nach dieser Vorarbeit im zweiten Teil auf den Grund. [Veröffentlichung am 30.1.2012, ungefähr 17.00 Uhr]

***

[UPDATE 26.1.2012: Auf umsetzungsberatung.de fand ich noch einen wunderbaren Text darüber, was Vertrauen eigentlich sei, und in welchem Verhältnis Vertrauen und Kontrolle zueinander stehen]

Sharepoint 2010 Wiki-Extensions: bluebridge Wiki unter der Lupe

Für Sharepoint 2010 gibt es eine Menge Erweiterungen, so auch zu den Wiki-Funktionalitäten. Im Rahmen einer Recherche, was das Sharepoint-Wiki out of the box kann, und was die verfügbaren Wiki-Extensions darüber hinaus bieten, bloggte ich zum einen diese Übersicht der Wiki-Extensions, und hier meine skizzenhaften Spekulationen zu den Anwendungsszenarien. Eine der erwähnten Wiki-Extensions für Sharepoint 2010 war das bluebridge Wiki. Im Folgenden möchte ich eine kurze Einschätzung und eine Auswahl der Testergebnisse zur Verfügung stellen – unsere firmeninterne Version ist 15 Seiten lang :

***

Meine grundsätzliche Einschätzung: Ich mag das bluebridge Wiki. Es erweitert aus meiner Sicht das OOTB-Wiki sinnvoll, ohne optisch ins Gewicht zu fallen. Es fällt fast nicht auf dass man es mit einer Extension zu tun hat. Die Anleitung selbst sorgte für manche Verwirrung, da etliche Abbildungen nicht SP 2010, sondern 2007 zeigen – übrigens seinerzeit auch die Webseite.

***

Installation: Getestet habe ich die kostenlose Probeversion, Version „2-0-5216 (August 2011). Die Installation lief angenehm unproblematisch. Die Anleitung war ausführlich genug, der Wizard führte zügig durch den Installationsvorgang, und man muss es nicht einmal deployen.

Funktionsübersicht: Habe ich schon in diesem Artikel tabellarisch erledigt

***

Verwaltung / Management: Wie schlank die Extension eigentlich ist, merkt man am Blick in die Settings. Die sind übrigens nicht ganz leicht zu finden. Entgegen den Angaben in der Anleitung ist es kein Link in den Bibliotheks-Settings. Sondern ein zusätzlicher Button im Ribbon:

Die Editor Options sind mir z.B. angenehm aufgefallen: Es kann festgelegt werden, ob Schriftarten und -Größen angezeigt werden (nützlich, falls hier einheitliche Darstellung aller Wiki-Seiten gewünscht wird). Auf die Weise kann auch die Eingabe von HTML unterbunden werden.

Das unscheinbare Wiki Fields hat es z.B. auch in sich: Die Vergabe dieser Metadaten ist die Voraussetzung, um die interne Wiki-Struktur mit einem Webpart anzeigen zu können. „Insert WP“ > Wo-auch-immer > „Wiki List“ bzw. „Navigation WP“. Damit lassen sich lange Texte hervorragend übersichtlich anzeigen, da sich jedes (Unter-)Kapitel beliebig an- und ausklappen lässt.

***

Editor: Sehr angenehm, sehr aufgeräumt. Eigentlich gibt es zwei Editoren, einen für SP 2010, und einen für 2007. Bei der Installation hat man sogar die Möglichkeit den alten Editor zu installieren, um die gewohnte Struktur bei der Migration zu 2010 beizubehalten. Ich würde klar die Version SP 2010 empfehlen:

Eine erschöpfende Diskussion der Editor-Features ist hier natürlich nicht möglich. Exemplarisch nenne ich an dieser Stelle noch das …

Table of Contents (TOC):

• Das TOC ist mit einem Klick an einem beliebigen Punkt im Text einfügbar, und be-kommt die notwendigen Informationen zu Formatierungen durch „Format Text“ > „Markup Styles“. Die Inhalte des TOC funktionieren auch als Sprungmarken in den Text, an die entsprechende Überschrift. Umgekehrt finden sich neben den Über-schriften Links zu Sprung zum Seitenanfang („top“), allerdings nur neben Heading 1 und 2, darunter nicht. Auch nett: durch Klick auf die Überschrift „TOC“ lässt sich die Box ein- und ausklappen.

• TOC arbeitet aber nicht ohne Tücken: wenn man es in eine Zeile einfügt wird auto-matisch die dafür formatierte Schriftgrößte übernommen. Und es kam beim Test vor, dass die Zeile „Table of Content“ mit eingeblendet wurde – vermutlich ebenfalls, da eine ursprüngliche Formatierung der Zeile als Überschrift noch immer ausgelesen wird. Es empfiehlt sich daher eine neue Wikiseite mit dem TOC zu beginnen, und dann den Text folgen zu lassen.

***

Export: Der Export hatte im Test auf meiner VM … ganz gut funktioniert.

Auswahlmöglichkeiten bei „PDF Overview“:

• Ansicht/Views entweder über die Übersicht des PDF Exports, oder über die Settings
• Erlaubnis für multiplen Export
• Export Style, inkl. „Show authoring information“
• Cover ein/ausblenden

Beobachtungen bei Export einer Seite, plus Screenshot:

• Übersichtsseite mit Namen der Page-Library wird automatisch angezeigt – eine Möglichkeit das zu auszuschließen wurde nicht gefunden.
• Name der Library wird links oben durchgängig angezeigt, dann kommt der Titel der Wikiseite
• Unten: Name des Autors, Datum inkl. Uhrzeit, Seitenzahl
• Kein TOC aus der Wikiseite in der PDF
• Kein „top“ neben den Überschriften
• Übernommen werden interessanterweise die Links auf Dokumente, die per „Quick Upload“ eingefügt wurden. Die zeigen immernoch auf das Wiki bzw. das verlinkte Dokument
• Übernommen werden auch Emoticons und Formatierungen wie farbliche Unterlegung

Export von mehreren Wikiseiten: Die Auswahl der Wikiseiten, die gedruckt werden sollen, erfolgt nicht im Export-Menü. Die Auswahl entspricht exakt der ausgewählten Ansicht/View (z.B. all Documents), gegliedert z.B. auch über eine Auswahl von Metadaten:

• Alle Seiten – hier werden alle Wiki-Seiten exportiert
• Letzte Änderungen – nur die zuletzt gänderten Seiten werden exportiert
• Erstellt von mir – Exportiert alle Seiten, die vom aktuellen User erstellt wurde
• Nach Autor – Diese Ansicht sortiert alle Seiten nach ihrem Autor
• Von Editor – Hier werden die Seiten anhand des letzten Bearbeiters sortiert

***

… Wie gesagt, eine kleine Auswahl der Ergebnisse. Für einen Eindruck reicht es, aber um ein Gefühl für die Usability zu bekommen muss man es sowieso selbst testen. Mir gefällt es.