Knowledge Management Blog

Nach dem Vergleich der Rechteverwaltung hier nun Runde 2: das Content Management. Da es sich bei allen drei Systemen im weitesten Sinne um Werkzeuge für die Verwaltung und Strukturierung von Informationen handelt, sicherlich ein nicht ganz uninteressanter Aspekt.

Sharepoint (MOSS 2007)

Im Vergleich der Standardversionen bringt Sharepoint im Vergleich zu Liferay und Confluence den mit Abstand größten Funktionsumfang mit sich. Inhalte können hier sowohl als Dateien in Dokumentenbibliotheken abgelegt, als auch in Webseiten und Wikiseiten festgehalten werden. Der wesentliche Unterschied zwischen Web- und Wikiseiten besteht darin, dass Webseiten über Controls und Webparts mit zusätzlicher Funktionalität ausgestattet werden können, während Wikiseiten reine HTML-Seiten sind. Egal wofür man sich entscheidet - Sharepoint legt sämtliche Inhalte in Bibliotheken ab.  Die Inhalte einer solchen Bibliothek werden intern in Listen verwaltet, deren Spalten individuell ergänzt werden können. Auf diese Weise können z.B. Spalten für Tags, Beschreibungen oder Verantwortlichkeiten realisiert werden. Auch bei der Dokumentenverwaltung in Dateiform spielt Sharepoint seinen Microsoft-Trumpf aus: alle in Bibliotheken abgelegten Office-Dokumente können aus Word, Excel, PowerPoint & Co. heraus direkt geöffnet, bearbeitet und versioniert zurück in die Bibliothek geladen werden. Der Schritt über die Weboberfläche entfällt somit.

Inwiefern sich Inhalte zwischen Web-/Wikiseiten und Dateien aufteilen lassen, bleibt den Redakteuren des zu erstellenden Systems überlassen. Hierbei ist jedoch anzumerken, dass das Wiki meiner Meinung nach eher eine Verlegenheitslösung darstellt. Eigentlich sind Wikiseiten nichts weiter als leere Webseiten, die mit einem HTML-Rich-Text-Control bearbeitet werden können. Echtes Wiki-Markup sucht man vergebens. Positiv ist jedoch, dass Wikiseiten dadurch die gleichen Workflows wie Webseiten besitzen können.

Confluence

In Sachen Content Management geht Confluence einen komplett anderen Weg. Dokumentenbibliotheken sucht man hier vergebens - alle Inhalte werden auf Wikiseiten abgebildet, welche in Bereichen organisiert werden können. Je nach Einsatzzweck kann dadurch ein schlankes und leicht bedienbares Content Mangement System entstehen. Insbesondere wenn die Zusammenarbeit verschiedener Personen oder Teams an einzelnen Dokumenten im Vordergrund steht, kann Confluence seine Stärken als Enterprise-Wiki ausspielen. So funktioniert u.a. die Versionsverwaltung wesentlich besser als in Sharepoint: in Confluence können beliebige Seitenversionen miteinander verglichen werden; Unterschiede werden dabei farblich hervorgehoben. Diese Möglichkeit sucht man in Sharepoint vergebens. Auch die gesamte Arbeit mit Inhalten, wie das Erstellen und Bearbeiten von Wikiseiten oder das Hochladen von Seitenanhängen, funktioniert hier wesentlich intuitiver und leichtgängiger als z.B. bei Sharepoint.

Eine schlanke Wikilösung bringt allerdings auch Nachteile mit sich. Wie schon bei der Rechteverwaltung angesprochen, lassen sich Genehmigungsworkflows nur über teilweise kostenpflichtige Plugins realisieren. Bereits vorhandene Dokumente, wie Word- oder Exceldateien, müssen entweder in Wikiseiten migriert oder als Seitenanhang verwaltet werden. Eigene Bibliotheken für externe Dokumente existieren nicht. Auch die Menge der zu erstellenden Inhalte kann ein begrenzender Faktor sein: wenn mehrere tausend Inhaltsseiten erstellt werden sollen, sinkt die Performanz und Organisierbarkeit der Seiten deutlich.

Zusammengefasst ist Confluence die richtige Wahl für Szenarien, in denen die kollaborative Zusammenarbeit der Nutzer unterstützt, und ein leicht zu bediendendes Nachschlagewerk für eine überschaubaren Menge von Inhalten geschaffen werden soll. Darunter können z.B. Wissensdatenbanken oder Team- und Projektarbeitsbereiche fallen.

Liferay

Wie  bereits in “Liferay Portlets” beschrieben, sind die Standardportlets von Liferay eher als eine Art Platzhalter zu verstehen. Die Funktionalität in Bezug auf Informationsverwaltung sollte also idealerweise von Portlets vollwertiger Content Management Systeme, wie z.B. Alfresco, bereitgestellt werden. Trotzdem bringen die in der Standardversion mitgelieferten Portlets ausreichend Funktionen mit sich, um für kleinere Unternehmensszenarien in Frage zu kommen, und sollen daher an dieser Stelle mit verglichen werden.

Die Standardportlets lassen sich am besten als eine Art “Light-Kombination” von Sharepoint und Confluence beschreiben. Out-of-the-box sind sowohl Portlets für Dokumentenbibliotheken als auch für Wikis und HTML-Seiten enthalten. Demzufolge können Inhalte sowohl in Web- und Wikiseiten verwaltet, als auch in Dateiform in Bibliotheken hochgeladen werden. Letzteres funktioniert seit Version 5.2 noch komfortabler: Liferay benutzt freie Sharepoint Protokolle, die den direkten Zugriff auf die Dokumentenbibliothken aus Office-Produkten heraus erlauben. Zudem werden ausgecheckte Dokumente für die Bearbeitung durch andere Nutzer gesperrt und beim Hochladen automatisch versioniert. Eine Historie listet alle früheren Versionen eines Dokumentes auf und zeigt diese auf Wunsch an. Genau wie in Sharepoint können alle Dokumente mit Tags näher beschrieben werden. Freie Metadaten für z.B. Verantwortlichkeiten lassen sich allerdings nicht hinzufügen. Erwähnenswert ist auch der Open Office Converter, mit dem Dokumente aus zahlreichen anderen Formaten in das Open Document Format konvertiert werden können. Hierfür muss allerdings ein Open Office auf dem selben Rechner verfügbar sein, welches dann die eigentlich Konvertierungsarbeit übernimmt.

Problematisch bei Liferay ist meiner Meinung nach das Auffinden von gespeicherten Inhalten. Das standardmäßige Suchen-Portlet funktioniert zwar gut, die Tag-Navigation dafür weniger. Wenn man nun davon ausgeht, dass in einem “echten” Liferay-System Inhalte aus verschiedensten Systemen zusammengetragen werden, sollten dafür einheitliche und Portlet-übergreifende Such- und Explorationsmöglichkeiten zur Verfügung gestellt werden.

Fazit

Für mich lässt sich bei diesem Vergleich kein Sieger benennen. Jedes der drei Systeme bietet Vor- und Nachteile, welche je nach gewünschtem Einsatzzweck mehr oder weniger zum tragen kommen. Mit Sharepoint lassen sich auch sehr große Datenmengen verwalten, die Office-Integration funktioniert tadellos und über Webparts sowie administrative Änderungen kann das System zu großen Teilen an Benutzerwünsche angepasst werden. Dafür ist der initiale Aufwand, ein solches System aufzusetzen (Anpassen von Listen, Einrichten von Workflows und Genehmigungen), mitunter recht hoch.

Mit Confluence lassen sich schlanke und leicht bedienbare Nachschlagewerke realisieren, bei denen die Zusammenarbeit der Nutzer und die leichte Wiederfindbarkeit von Wissen im Vordergrund steht. Die Funktionsumfang ist wesentlich kleiner als der von Sharepoint, dafür hält sich auch der Einrichtungsaufwand in Grenzen und die Bedienung geht wesentlich leichter von der Hand.

Liferays Standardportlets bieten eine gute Mischung aus Funktionalität und Bedienbarkeit. Inhalte können in Webseiten, Wikiseiten und einfachen Dokumentenbibliotheken verwaltet werden, was für kleinere Unternehmensanwendungen bereits ausreichend sein kann. Damit ist Liferay eine gute Wahl für überschaubare Anwendungen, bei denen besonderer Wert auf Flexibilität und Erweiterbarkeit gelegt wird.

Nachdem der MS Office SharePoint Server 2007 (oder kurz: MOSS) inzwischen auch in einigen deutschen Bundes- und Landesbehörden Einzug gehalten hat, rückt das Thema Barrierefreiheit nun stärker in den Vordergrund. Grund genug, das MOSS Inhalts-Editor-Webpart an dieser Stelle etwas näher zu untersuchen und dessen Möglichkeiten für die Erstellung BITV - gerechter Inhalte zu beurteilen.

Zunächst die Voraussetzungen:

Annahme A: Der Benutzer ist Willens, barrierefreie Inhalte zu erstellen. Anders hat es sowieso keinen Sinn - kein Editor kann seine Nutzer dazu zwingen, sinnvolle Linktexte zu vergeben oder aussagekräftige Alternativtexte für Grafiken bereitzustellen. Ein Editor kann seine Benutzer aber sehr wohl in ihrer Arbeit unterstützen und ihnen Mittel an die Hand geben, auf möglichst einfache Weise zugängliche Inhalte zu erzeugen.

Annahme B: Der Quelltexteditor ist tabu. Natürlich kann man seine HTML-Inhalte auch als reines Markup eingeben und auf diese Weise barrierefrei machen - an dieser Stelle soll aber ausschließlich der Rich-Text-Editor beurteilt werden.

Grafiken

Hier schlägt sich der Inhalts-Editor recht wacker. Ein Alternativtext kann angegeben werden, die grundlegende Voraussetzung ist also schonmal erfüllt. Die Länge des Inhaltes ist zwar statt 80 Zeichen (Empfehlung der BITV) auf 130 Zeichen begrenzt - aber ob das nun gut oder schlecht ist, ist Ansichtssache. Pflichtfeld ist der Alternativtext nicht. Auch hier gilt jedoch: wir gehen davon aus, dass der Benutzer barrierefrei arbeiten will. Selbst wenn der Alternativtext Pflicht wäre - kein Automatismus kann beurteilen, ob der eingegebene Text aussagekräftig ist und z.B. bei einem Foto dessen Inhalt, bei einem Symbol jedoch dessen Aussage wiedergibt. Felder für eine ausführliche Beschreibung (Attribut longdesc) oder einen Titel (Attribut title) existieren nicht - diese werden von der BITV aber auch nicht vorgeschrieben.

Inhaltstabellen

Tabellen sind ja ein durchaus streitwertiges Thema - wann nimmt man z.B. für Überschriften th oder td und ab wann benötigt man scope oder id. Der MOSS Editor reduziert das Thema praktischerweise auf ein Minimum: er kann einfach gar nichts davon.

Dass ältere Rich-Text-Editoren kein scope und id beherrschen, ist ja irgendwo noch nachvollziehbar. Aber dass man eine Tabellenzeile nicht mit th korrekt als Überschrift deklarieren kann (BITV Priorität 1), ist schon bitter. Daher muss man leider sagen, dass mit dem Inhalts-Editor Webpart von MOSS keine BITV-tauglichen Tabellen erstellt werden können. Einziger positiver Aspekt: eine Beschreibung der Tabelle kann als summary angegeben werden - das reißt es allerdings auch nicht mehr raus.

Wäre noch interessant herauszufinden, wie viel Aufwand es bedeuten würde, das bestehende Tabellentool z.B. den Tabelleneditor von TinyMCE einzubinden. Aber dazu später mehr.

Links

Hier sieht der MOSS Editor gar nicht mal schlecht aus. Ok, es gibt auch nicht viel falsch zu machen, die Hauptarbeit ist ja von den Inhaltsautoren zu leisten. Hier können jedenfalls ein title sowie ein Dateiformat angegeben werden - BITV Priorität 1 steht also nichts im Wege.

Textauszeichnung

… sollte theoretisch auf ein Minimum beschränkt sein, Stichwort: Trennung von Inhalt und Layout. Trotzdem werden in Rich-Text-Editoren natürlich Textformatierungen angeboten. Das macht der MOSS Editor meiner Ansicht nach leidlich passabel. Zunächst das Positive: er verwendet strong und em statt b und i und bietet das automatische Entfernen von Inline-Formatvorlagen an. Verschiedene Listen (Nummerierungs-, Aufzählungs-, Definitions-, Verzeichnis-, Menülisten) werden sauber formatiert. Im Vergleich mit dem TinyMCE wird dann aber deutlich, was dem MOSS Editor fehlt um als barrierefreies Werkzeug durchgehen zu können. Am meisten vermisse ich dabei die Auszeichnung von Zitaten, anderssprachigen Wörtern und Absätzen sowie von Abkürzungen und Akronymen. Ebenfalls negativ: für den Texteinzug wird blockquote verwendet und es werden mitunter veraltete Elemente (z.B. font) und Attribute (z.B. align, u) verwendet.

Validität

Gemäß BITV Punkt 3.2 sind “Mittels Markup-Sprachen geschaffene Dokumente [...] so zu erstellen und zu deklarieren, dass sie gegen veröffentliche formale Grammatiken validieren” (Anm. des Autors: der Schreibfehler in “veröffentliche” ist unverändert aus dem Juris-Text übernommen). Der entsprechende Prüfschritt gilt als erfüllt, wenn das Ergebnis des W3C-Validators für das getestete Dokument positiv ist.

Meiner Ansicht nach ist es dabei unerheblich, ob man sein Dokument als XHTML oder z.B. als HTML Transitional auszeichnet und entsprechend validiert. Gehen wir also vom einfachen Fall - HTML 4.01 Transitional - aus.

Bei einfachen Dokumenten, die nur aus Text mit ein paar Grafiken und  Formatierungen bestehen, erzeugt der MOSS Editor durchaus valides HTML. Bei komplexeren Dokumenten oder zahlreichen “Bearbeitungen”, also Ausschneiden, Löschen, Kopieren usw., schleichen sich dann allerdings Fehler ein. Es kann dann z.B. passieren, dass eine Tabelle in eine nicht mehr existenten Liste eingefügt wird, weil der Editor beim entfernen der Liste zwar deren Inhalte gelöscht hat, nicht aber die öffnenden und schließenden Listentags. Damit besteht das Dokument den W3C-Test nicht mehr.

Fazit

Das MOSS Inhalts-Editor-Webpart bietet meiner Ansicht nach eine solide Grundlage, um einfach strukturierte Inhalte mit Texten, Bildern und Aufzählungen korrekt auszuzeichnen und zugänglich darzustellen. Kleinere Mängel, wie die mitunter veralteten Attribute, sind dabei - auch gemäß der BITV - zu verschmerzen.

Sollen jedoch komplexere Inhalte erstellt werden, kommt der Editor schnell an seine Grenzen. Als Stichworte seien dabei nochmal die fehlende Auszeichnung von Tabellenüberschriften, Zitaten, Abkürzungen und Sprachwechseln genannt, sowie der schnell invalid werdende HTML-Quellcode. Um also komplexe und trotzdem zugängliche Inhalte erstellen zu können, sind entweder Anpassungen am Editor selbst, oder Alternativen für den Editor notwendig. Dafür sehe ich bisher die folgenden Optionen:

Alternative 1: nachträgliches Validieren

Der vom Inhalts-Editor erzeugte Quellcode kann nachträglich auf seine Validität geparst werden. Dafür existieren bereits verschiedene Ansätze:

• Das Accessibility Kit for Sharepoint (AKS) bringt die “Compliant Code Engine” mit. Diese wird als Feature in MOSS installiert und validiert den kompletten Quellcode, bevor dieser an den Nutzer gesendet wird. Aber Achtung: die Engine funktioniert nur mit  WCM/ECM Seiten.
• Das ARF-Framework beinhaltet mit dem “compatibility panel” einen Container für MOSS-Controls, der den von Controls ausgegebenen HTML-Code nachträglich validiert.

Alternative 2: Einbinden eines anderen Editors

Warum das Rad neu erfinden, wenn mit dem TinyMCE und dem FCKEditor bereits exzellente Rich-Text Editoren zur Verfügung stehen. Eine Lösung könnte also darin bestehen, denn MOSS Editor durch einen der beiden genannten Editoren zu ersetzen. Dafür existieren bereits Anleitungen. Problematisch - und für den Behördeneinsatz leider ausschlaggebend - ist dabei allerdings der Umstand, dass der TinyMCE / FCKEditor dann nur für nicht-Internet-Explorer-Nutzer angezeigt wird. Im Internet Explorer wird weiterhin der MOSS-Editor verwendet.

Meiner Meinung nach muss der MOSS-Editor aber auch nicht ersetzt werden. Es reicht völlig, wenn der TinyMCE oder FCKEditor als barrierefreie Alternative angeboten bzw. in entsprechende Templates eingebunden wird.

… und ne kleine Cola bitte.

Wie u.a. Netzpolitik und Fefe berichten, ist der Bundestrojaner auf dem besten Wege, in der nachträglichen Strafverfolgung zum Einsatz zu kommen. Derzeit ist zwar noch von der Aufklärung “schwerer Verbrechen” die Rede. Die Betonung liegt dabei allerdings auf “noch”, denn es ist wohl nur eine Frage der Zeit, bis aus den “schweren Verbrechen” Schritt für Schritt “Straftaten” werden. Bei der Kontoabfrage hat es schon funktioniert: nach den Anschlägen vom 11. September 2001 wurde die Möglichkeit zur automatisierten Kontoabfrage bei der Bundesanstalt für die Finanzdienstleistungsaufsicht zunächst zur Terrorabwehr eingeführt. Später wurde diese Abfrage auch auf Steuerhinterziehung oder Sozialleistungsmissbrauch ausgedehnt.

Wenn die technischen Möglichkeiten einmal vorhanden sind, werden sie früher oder später auch genutzt.

Manche Dinge sollten nicht unerwähnt bleiben, so zum Beispiel der Blogbeitrag von Björn Grau zum Amoklauf in der vergangen Woche.

Während Spiegel & Co. in bewährter Tradition eine Brücke zu “Killerspielen” schlagen (letzten Erkenntnissen zu Folge hat Tim K. am Abend vor dem Amoklauf 2 Stunden lang “Far Cry 2″ gespielt - ein Schelm, wer hier nicht sofort einen Schuldigen findet), geht es hier um die Welt, in der Heranwachsende klarkommen müssen. Kinder und Jugendliche fühlen sich oft einsam und unverstanden; handeln mitunter grausam und irrational. Es ist immer so gewesen und wird vermutlich immer so sein. Einzig die Beigleitumstände ändern sich.

Sehr lesenswerter Beitrag.

http://www.graubrotblog.de/2009/03/14/unfassbar/

Nachdem ich mich auf der Cebit mit Dietmar Schmidt über Liferay und den Sinn der mitgelieferten Portlets unterhalten konnte, ist es an der Zeit hier einige davon vorzustellen. Zunächst sei jedoch gesagt, dass die Standardportlets nicht viel mehr als eine Art Demo-Platzhalter sind und dementsprechend auch keinen Anspruch auf “ausgereifte” Funktionalität erheben. Sinngemäß sollte die eigentliche Funktionalität eines Portals aus den Portlets externer Quellen kommen, die durch das Portal eine einheitlich Oberfläche erhalten. Trotzdem werden bei Liferay zahlreiche Portlets mitgeliefert - was aus Marketingsicht natürlich verständlich ist. Meiner Erfahrung nach weckt dieser Umstand aber häufig den Eindruck, dass sich mit einem Standard-Liferay ein unternehmenstaugliches Portal aufbauen lässt. Da muss man eigentlich widersprechen: es lassen sich zwar ansehnliche und auch benutzbare Portale  “out of the box” erstellen, aber wirklich firmentauglich wird so ein Portal weder aus funktionaler noch aus technischer Sicht.

Trotzdem möchte ich einige der Standardportlets ein wenig näher erläutern, um den Einstieg in Liferay etwas leichter zu gestalten.

Web Content

Der typische HTML-Platzhalter. Mit einem Rich-Text-Editor kann beliebiger HTML-Code angezeigt werden. Die Funktionalität reicht aus, um einfache Texte mit Grafiken zu erstellen, aber schon bei Tabellen wird es ganz schnell “hakelig”, wenn z.B. die Ausrichtung nicht richtig klappt oder die Tabelle nicht korrekt dargestellt wird. Positiv: ein Web Content Portlet kann mit einem Anfangs- und Verfallsdatum versehen werden, verschlagwortet werden, kategorisiert werden und ist mit einem einfachen 4-Augen-Genehmigungsworkflow versehen.

RSS

Nichts zu beanstanden. Beliebig viele Feeds können eingebunden und zusammengefasst werden. Allerdings würde ich immer nur einen Feed pro Portlet empfehlen, da die Einstellungen (Titel anzeigen, Beschreibung anzeigen, Datum anzeigen usw.) für alle Feeds in diesem Portlet gelten und damit oft eine etwas unschöne Optik entsteht weil jeder Feed etwas anders aussieht.

Summary

Hat seltsamerweise eine Doppelfunktion: innerhalb einer öffentlichen Community zeigt es deren Namen und einen Link zum verlassen an. Innerhalb einer Benutzerseite (-community) zeigt es eine Übersicht über diesen Benutzer mit Name, Foto, Jobtitel und Tätigkeiten in Liferay an. Wichtig: das Summary-Portlet ist eine der wenigen Stellen in Liferay, an denen man andere Nutzer als Freund hinzufügen kann.

Freunde

Kann nur auf persönlichen Seiten eingebunden werden, und zeigt die Freunde dieses Benutzers an. Achtung, die Bedienung ist nicht ganz intuitiv: damit man mit jemandem befreundet ist, muss man diesem erstmal einen Freundesantrag schicken. Das funktioniert am besten, wenn der andere Nutzer ein Summary-Portlet auf seiner persönlichen Seite eingebunden hat. Auf dem Wall-Portlet geht es auch - ansonsten sind mir bisher noch keine Stellen aufgefallen. Jetzt kommt allerdings der Trick: damit der andere Nutzer sieht, dass ihn jemand als Freund hinzufügen möchte, muss er das Anträge-Portlet bei sich einbinden. Dort werden Freundesanfragen aufgelistet und können bestätigt werden. Na wenn das nicht mal intuitiv ist….

Anträge

Siehe Freunde-Webpart, wird benötigt um zu sehen wer einen als Freund hinzufügen möchte.

Wall

Eine Gästebuch, nur einzubinden auf persönlichen Seiten. Schlicht und funktional.

Blogs

Wichtiges Portlet, fügt einen Blog in die aktuelle Community ein. Die Funktionalität ist ausreichend um erfolgreich zu bloggen. Einträge können als RSS abonniert, bewertet und direkt in Social Bookmarking Tools aufgenommen werden. Der Haken kommt allerdings, wenn man mehrere Blogs innerhalb einer Community betreiben möchte. Theoretisch kann man zwar jeden Blog über die Konfiguration einem Bereich zuweisen, in welchem er gelten soll. In der Praxis führt das aber zu nicht nachvollziehbaren Vermischungen zwischen verschiedenen Blogs einer Community. Wer herausfindet, wie man verschiedene Blogs sauber konfiguriert, kann mir das gerne mitteilen.

Wiki

Sehr schlichte Funktionalität. Die Startseite kann zwar festgelegt werden, allerdings besteht außer seiteninternen Links keine Navigationsmöglichkeit. Text kann als kreolischer Markup und HTML eingegeben und anschließend wie im Web Content - Portlet kategorisiert und verschlagwortet werden. Genehmigungsworkflow gibts hier keinen.

Dokumentenbibliothek

Bis jetzt gute Erfahrungen damit gemacht. Durch Ordner strukturierbar, Dokumente werden versioniert gespeichert und können verschlagwortet werden. Einziges Manko: Dokumente können nicht ins Hauptverzeichnis der Bibliothek abgelegt werden sondern benötigen immer einen Ordner. Jede hochgeladene Datei kann in andere Formate umgewandelt werden (PDF, DOC, ODT) - allerdings nur, wenn diese Programme irgendwo installiert sind und Liferay entsprechend eingerichtet ist. Dank der Integration eines Sharepoint-Protokolls kann seit Version 5.2.1 direkt aus Microsoft Office auf die Dokumentenbibliothek zugegriffen werden. Eher ungewöhnlich: jede hochgeladene Datei kann bewertet und kommentiert werden.

Tag Navigation

Gute Idee, schlechte oder zumindest unverständliche Umsetzung. Die Tags werden in Kategorien angezeigt, also z.B. untergliedert nach Schlagworten für Dokumente, Wikiseiten, Blogeinträge usw. Prinzipiell eine prima Idee. Leider kann man nur zwischen “Alle Kategorien anzeigen” oder eben nicht auswählen. Hier wäre eine einzelne Auswahl von Kategorien wesentlich hilfreicher gewesen. Eine weitere Unverständlichkeit ist die Anzeige der Suchergebnisse zu einem Schlagwort. Einzig wenn ein Wiki oder eine Wiki-Anzeige auf der gleichen Seite wie die Tag Navigation eingebunden ist, werden Ergebnisse angezeigt. Hat man z.B. eine Seite erstellt, auf der sich eine Dokumentenbibliothek + deren Anzeige sowie eine Tag Navigation befinden, werden zwar die Tags der Dokumentenbibliothek angezeigt - allerdings werden nach einem Klick auf ein Schlagwort keine Treffer angezeigt. Auch hier: wenn jemand herausfindet, wo da der Trick liegt (so es denn einen gibt), bin ich für Hinweise dankbar.

Nochmal ganz generell: Anmerkungen / Berichtigungen nehme ich jederzeit dankend entgegen. Ich lerne Liferay selbst erst kennen und bin noch kein Experte, von daher jederzeit für Anmerkungen offen.