CMS-Usability: Wie intuitive Interfaces aussehen können

CMS-Usability: Beispiele für intuitive Interfaces

Vor einiger Zeit bin ich über ein paar Seiten gestolpert, die eigentlich Paradebeispiele für ein gutes und vor allem auch INTUITIVES Autoreninterface sind. Gerne stelle ich Euch diese kurz vor. 

CMS-Usability – Was heißt eigentlich „Usability“?

was-ist-usability-cms-usability-namics-150x100

In meinem letzten Beitrag „CMS-Usability – Die Basis für das Schaffen von digitalen Erlebnissen” habe ich darüber geschrieben, wie wichtig eine gute CMS-Usability für das Erstellen von digitalen Erlebnissen ist. Doch was heißt „Usability” eigentlich? Wenn man das Wort „Usability” … Weiterlesen

Endnutzer und Redakteur – Wer pflegt die Web-Site?

Je mehr Benutzerdaten und Interaktion auf einer Web-Site verarbeitet werden, desto gefragter werden Web-Applikationen, die in ihren Datenbanktabellen Benutzerbeiträge (auch bekannt als User-Generated-Content UGC) speichern und die Web-Site lebendiger machen. Weiterhin bildet jedoch das Content-Management-System (CMS) des Unternehmens die Grundlage für den darzustellenden Content der Web-Site, sowie dessen Struktur. Redakteure und Endnutzer erstellen nun gemeinsam die Inhalte. Wie können die Vorteile von beiden Welten auf den jeweiligen Web-Seiten vereint werden?

Die Redakteure legen die Content-Struktur im CMS an und verfügen über Seitenvorlagen (auch Templates genannt). Die Seitenvorlagen beinhalten ein Layout und ggf. spezielle technische Funktionen. Die Seitenvorlagen sind somit als Teil der CMS-Lösung bereitgestellt und können meist nur durch technische Implementierung erweitert werden. Durch Anlage einer CMS-Seite, basierend auf einer der Seitenvorlagen, kann der Redakteur nun beliebige Seiten erstellen, Inhalte pflegen und deren Anordnung bestimmen. Die verschiedenen Inhaltstypen, die als Block platziert werden können, nennen wir Komponenten. Für statische Seiten, wie z.B. ein Impressum, sind diese Mittel auch ausreichend.

Mit dem User-Generated-Content erhält man nun eine starke Vervielfachung, da die vielen Endnutzer auch entsprechend viele Beiträge über Web-Applikationen erfassen können. Um nicht für jeden Beitrag eine CMS-Seite anlegen zu müssen, möchte man die Beiträge einbetten, so dass eine CMS-Seite wieder als eine Art Vorlage für viele (dynamische) Web-Seiten dienen kann. Dies erreicht man über individuell angefertigte Komponenten, welche den passenden User-Generated-Content für die zu erzeugende Web-Seite darstellen. Um die richtigen Datensätze auswählen zu können, braucht die CMS-Seite zusätzliche Parameter, die in der URL enthalten sein sollten. Dies kann ein Query-String sein wie „?id=00012324“ oder auch ein Bestandteil des URL-Pfades „/immobilienanzeige/Das+Haus+am+See“. Durch die Definition entsprechender URL-Muster und –Regeln können aus der angefragten URL die CMS-Seite und mögliche Parameter hergeleitet werden.

Mit diesem Ansatz können Redakteure und Endnutzer die Web-Site gemeinsam bereichern.

 

Zentrales Multisitemanagement mit dem TYPO3 CMS

Manchmal gibt es Anforderungen an ein Content Management System (CMS) welche lauten: Das System soll OpenSource sein, also frei von Lizenzkosten Das CMS soll in der Lage sein, mehrere eigenständige Webauftritte innerhalb einer Instanz zu verwalten Es muss möglich sein, … Weiterlesen

Agile Migration

Auch für Migrationsprojekte ist klassische Projektplanung mit Meilensteinen, Aktivitäten und deren Abhängigkeiten unerlässlich. Man sollte sich jedoch bewusst machen, dass hier ein neues System entwickelt wird, während das Alte noch läuft und Veränderungen unterworfen ist. Da i.d.R. das neue System … Weiterlesen

CMS-Migration – Das Projekt planen

Content-Freeze und Code-Freeze Wie bei den meisten IT Projekten bestehen bei einem Migrationsprojekt ebenfalls viele Abhängigkeiten und Rahmenbedingungen, die eine sorgfältige Planung erfordern. Hinzu kommt jedoch, dass bei Live-Gang des neuen Systems ein Zeitraum entsteht, in welchem keine Änderungen an … Weiterlesen

Mandantenfähiges CMS oder Multi-Site?

Können Sie sich noch an meinen letzten Beitrag zum Thema Multi-Site Management erinnern? Dort habe ich versucht, das Thema zu umreissen und eine Definition dafür zu geben.

Das Stichwort „Multi-Site“ taucht aktuell in fast allen grösseren Implementationsprojekten für ein CMS auf, aber es wird häufig unterschiedlich interpretiert und oft auch mit dem Konzept der „Mandantenfähigkeit“ verwechselt. Auf den nächsten Zeilen möchte ich deshalb den Unterschied erklären.

Ein CMS ist mandantenfähig, wenn auf derselben Infrastruktur viele Websites betrieben werden können. Eine wichtiger Aspekt ist, dass die Sites – abgesehen von der Codebasis – unabhängig voneinander sind. Das heisst Struktur, Inhalte, Design, Statistiken, Benutzerprofile, Einstellungen etc. können individuell eingestellt werden.
Der treibende Gedanke hinter einer solchen Architektur ist der Wunsch nach Kosteneinsparungen, die man sich durch die Zusammenlegung erhofft: Entwicklung und Betrieb sollen klar günstiger sein als wenn für jede Website ein eigenes CMS betrieben wird.

3339-mandanten-thumb-500x171-3338.jpg

Ein typischer Vertreter dieser Gattung ist eine CMS-Plattform, welche das VBS, das BFS und Swisstopo gemeinsam nutzen: Jeder Mandant ist Herr über Inhalt und Erscheinung (innerhalb der CI/CD-Vorgaben des Bundes) der eigenen Website(s), bei der Entwicklung von Funktionalitäten können aber Synergieeffekte realisiert werden.

Das Wunsch zur Kostenoptimierung in Entwicklung und Betrieb ist auch bei einer Multi-Site präsent, allerdings nur sekundär. Im Vordergrund stehen nämlich Qualität, Konsistenz und die effiziente Pflege der Inhalte. Dies möchte man durch eine zentral orchestrierte Erstellung und die Wiederverwendung von Content erreichen – z.B. sollen Texte nur einmal übersetzt werden müssen.
Im Unterschied zur mandantenfähigen CMS-Plattform besteht eine Multi-Site Umgebung also nicht aus Content-Silos, sondern aus „porösen“ Töpfen mit durchlässigen Grenzen und definierten Workflows.
Häufig setzen grössere oder „internet-lastige“-Unternehmen auf eine Multi-Site. Das Web-Team dieser Unternehmen muss (oft mit wenig Personal) nicht nur viele Websites effizient betreiben, sondern eben auch für gute und konsistente Inhalte sorgen.

3341-Multi-Site-thumb-500x209-3340.jpg

Obwohl sich die beiden Konzepte auf den ersten Blick gleichen, stellen sie ganz unterschiedliche Anforderungen an das Content Management System. Es ist darum sehr wichtig, vor der Evaluation und Konzeption eines CMS die „Business“-Anforderungen und den Unterschied zwischen einem mandantenfähigen CMS und einer Multi-Site zu kennen.

Fachtagung Next Generation Content Management. Alle Referate im Überblick.

Heute hat die Namics Fachveranstaltung „Next Generation Content Management“ im SWX Convention Point mit über 100 Teilnehmern stattgefunden. Sämtliche Referate sind auf unserem Slideshare Account oder auf Prezzi verfügbar. Hier die gesamte Übersicht.

Keynote. Next Generation Content Management. Gestern und heute.
Markus Tressl und Marcel Albertin gewähren uns einen Einblick in die Vergangenheit und die Zukunft des Content Managements.
Markus Tressl, Senior Consultant, Namics AG
Marcel Albertin, CTO und Partner, Namics AG

Download im PDF Format

Collaboration mit Wiki – klappt im Intranet und Extranet.
Repower AG Confluence Intranet
Die Ansprüche an das neue Intranet der Repower AG waren gross. Anforderungen wie die Zusammenarbeit zwischen Ländern, ein personalisiertes Dashboard, fein steuerbare News für die interne Kommunikation konnten in einem Confluence Wiki als Arbeitswerkzeug für die tägliche Arbeit vereint werden.
Roman Zollet, Business Unit Manager, Namics AG


Ypsomed Confluence Extranet

Vom einfachen Dokumententenaustausch via FTP Server zur Kollaboration im Confluence Wiki. Mit der Einführung von Confluence als Extranet Tool stellt die Ypsomed AG, ein international tätiger Schweizer Hersteller von Injektions- systemen, die Kommunikation mit ihren Austauschpartnern radikal um.
Raphael Joss, Consultant, Namics AG

Download im PDF Format

Nationale Suisse – Multisite-Management Konzept.
Mit Multisite-Management lassen sich Corporate-, Länder-, Marken- und Mobileauftritte über dieselbe CMS Infrastruk- tur verwalten. Die Herausforderungen liegen bei solchen Projekten in der Vereinheitlichung von Inhalten, Funktionen und Redaktions-Prozessen bei gleichzeitiger Flexibilität für die spezifischen Zielsetzungen der einzelnen Webauftritte. Am Beispiel der Nationale Suisse wird ein auf die Marketingstrategie ausgerichtetes Multisite Konzept mit Sitecore vorgestellt.
Troy Lüchinger, Senior Manager, Namics AG
Steffen Engeser, Consultant, Namics AG

Download im PDF Format

Mobile und Trends.
Optimale Auslieferung der CMS-Inhalte für mobile Endgeräte.
Immer häufiger wird Ihre Website mit sehr heterogen mobilen Endgeräten (iPad, iPhone, Android, etc.) aufgerufen. Bei der Implementierung stehen zwei Varianten zur Verfügung. Der Einsatz von «liquidem Design» oder die Konzi- pierung einer «eigenen» mobile Website oder Applikation. Zur Qualitätssicherung ist eine gute Vorschau, welche die mobile Website schnell und einfach in einer Vielzahl von mobilen Endgeräten zeigt, essentiell. Diese Aufgabe erfüllt ein Emulator. Anhand konkreter Beispiele zeigen wir Vor- und Nachteile auf.
Johannes Waibel, Senior Consultant, Namics AG
Marcel Albertin, CTO und Partner, Namics AG

Download im PDF Format

Online Marketing Suite (OMS).
Eingebundene Web Analyse, Kampagnen Management, Lead Scoring, Content Targeting oder Live-Personalization sind nur wenige Features, welche die Sitecore Online Marketing Suite zu bieten hat. Erfahren Sie, wie man die Darstellung von personalisiertem Content anhand des Surfverhaltens von Usern steuert.
Steffen Engeser, Consultant, Namics AG

Download im PDF Format

Ergebnis der CMS Evaluation, Showtime!

**Für mich kommt nun der spannendste Teil der CMS Evaluation, schliesslich haben in den vorangehenden Schritten Theorie, teilweise abstrakte Anforderungen und viele Zahlen in Bewertungstabellen das Bild geprägt.**

Das Bedürfnis nach einem neuen CMS, Workshops zur Erhebung von funktionalen, nicht-funktionalen und Business Anforderungen sowie die eigentliche Bewertung und Evaluation der CMS haben wir bereits in den vergangenen Posts behandelt. Nun haben wir eine Rangfolge von Produkten und deren Erfüllungsgrad der Kundenanforderungen.

Wie weiter?
Die Rangfolge der Systeme kann nun interpretiert und erklärt werden. Aufgrund der Standardabweichung in den Ergebnissen lassen sich die Ausreisser-Systeme identifizieren und die Stärken und Schwächen der einzelnen Produkte argumentieren.

2602-Ranking-thumb-500x329-2601.png

So kommen wir zu einer Short-Short-List von maximal drei Produkten, welche die Kundenanforderungen nahezu optimal erfüllen. Auf dieser Basis lassen sich nun durch uns und den Kunden TCO Berechnungen erstellen, was die Einführung des einzelnen CMS über 3 Jahre hinweg unter Annahme eines bestimmten Projektvolumens kostet. Hier kommen nun zum ersten Mal auch die Lizenzkosten der einzelnen Content Management Systeme ins Spiel. Das Bild der Short-Short-List kann sich also auch sehr schnell wieder ändern, falls Lizenzkosten schlussendlich den Ausschlag für oder gegen ein Produkt geben.

Nach der TCO Berechnung ist die Evaluation eigentlich abgeschlossen. Es gibt aber noch zwei Variablen, die wir bisher noch nicht näher berücksichtigt haben: Die Projektkomplexität und den Hersteller an sich.

Warum also nicht anhand eines konkreten Lastenhefts für das vorliegende Projekt den Hersteller sein Produkt präsentieren lassen? Und zwar auf Basis von konkreten (und möglicherweise komplexen) Anforderungen, welche später durch das gewählte CMS erfüllt werden müssen? So lernen sich unser Kunde und der Hersteller bereits kennen, und man erhält einen detaillierteren Einblick in das System. Und zwar auf Basis von echten Anforderungen.

Gerne möchte ich an dieser Stelle zur Diskussion auffordern: erkennt sich jemand anhand des gezeigten Vorgehens oder der gezeigten Situationen wieder? Wer steht vor der Entscheidung für ein neues Content Management System? Hat jemand diesen Prozess bereits durchgemacht und was waren die Erfahrungen?

Vielleicht können meine Kollegen und ich an der einen oder anderen Stelle in Zukunft bei konkreten Fragestellungen helfen!

Sie haben einen Teil unserer Serie ‚CMS Evaluation‘ verpasst? Hier finden Sie nochmals alle Beiträge dazu:

* Ein neues CMS?
* Business Requirements an ein CMS
* Funktionale und nicht-funktionale Requirements an ein CMS
* Bewertungs-Prozess einer CMS Evaluation

Opensource CMS: Drupal und TYPO3 – Ein Vergleich

Namics hat in der Vergangenheit im Opensource Content Management Umfeld verschiedene CMS Systeme wie TYPO3, Drupal, Magnolia sowie Webapplikationen mit dem Framework Ruby on Rails erfolgreich umgesetzt.

Bekanntester Vertreter im Opensource CMS Umfeld (LAMP Architektur) ist dabei oft TYPO3. Neuerdings erreichen uns aber auch vermehrt Anfragen für Drupal. Die Auswahl des „richtigen“ Systems ist eine Kernkompetenz von Namics und basiert auf einer Systemevaluation – in diesem Falle einer sogenannten CMS Evaluation. Auf eine genauere Erläuterung des Vorgehens verzichte ich in diesem Post explizit. Mein Ziel ist es, die Systeme Drupal und TYPO3 bezüglich 3 Punkten zu vergleichen. Eines vorneweg: Beides sind „vollwertige“, freiverfügbare Opensource Content Management Systeme.

1 Community Sites vs. Corporate Websites
TYPO3 wie auch Drupal verwalten im Kern Inhalte von Websites. Drupal fokussiert dabei klar auf Community-Sites, also überall dort wo User aktiv mit Kommentaren oder eigenen Beiträgen den Inhalt einer Website beeinflussen.

Bei TYPO3 handelt es sich im Gegensatz dazu um ein „klassisches CMS“. Speziell ausgelegt auf das Verwalten grösserer Corporate Websites (selbstverständlich auch denkbar für Intra- oder Extranets). Es bestehen umfangreiche Möglichkeiten, eine oder mehrere Sites zu verwalten. Am Beispiel des Energieproduzenten Repower sind „Sites“ als eigene Länderauftritte zu verstehen . Also jeweils 1 unabhängiger Seitenbaum für Schweiz (ch), Deutschland (de), Gruppe (group) und Mittel- und Osteuropa (cee):
repower.com/de/ch
repower.com/de/de
repower.com/de/group
repower.com/de/cee

In jedem Land können Inhalte beliebig verwaltet werden. Dies gilt natürlich auch für Sprachen und Funktionen.

2 Wo werden Inhalte erstellt und editiert? Frontend vs. Backend
Wie bereits erwähnt ist Drupal massgeschneidert für Community Sites, d.h. ein Grossteil des Inhalts entsteht in der Regel durch die User selber. Demnach gibt es eine Verschmelzung zwischen Front- und Backend, wie man dies von Community Sites wie Facebook und co. gewöhnt ist. Ein Backend sucht man bei Drupal in der Basisinstallation vergebens: Alles spielt sich im Frontend ab, was für einfache inhaltliche Anpassungen sehr angenehm ist. Backend Themes für Autoren können bei Bedarf installiert werden.

TYPO3 unterscheidet deutlich zwischen einem Front- und Backend. Autoren verwalten Inhalte zu einem grossen Teil direkt im Backend. Neuere TYPO3 Releases folgen dem Trend, Inhalte direkt auf der Seite, also im Frontend zu editieren.

3 Hierarchische Seiten vs. kategorisierter Inhalt
TYPO3 basiert auf Seiten (Pages) die in einer hierarchischen Strukur einen Seitenbaum (=Site) ergeben. Am Beispiel einer Versicherung wären dies beispielsweise einzelne Produktseiten. Hier am Beispiel Page „Hausrat-Versicherung“. Einzelne Pages können wiederum Seitenelemente wie z.B. eine Spalte für Teaser im rechten Randbereich umfassen. Ein Seitenbaum sieht in TYPO3 wie folgt aus:

2684-Typo3-backend-thumb-500x508-2683.jpg

Drupal fährt einen stark modularen Ansatz. Im Gegensatz zu TYPO3 kommen sogenannte Nodes zum Einsatz. Zurück zu unserem Beispiel der Versicherung: Für die Abbildung der Produktseite „Hausrat-Versicherung“ wird ein Node „Hausrat“ eingesetzt. In diesem Node sind relevante Informationen wie der Titel, Produktinformationen, Bilder, Preisinformationen etc. gespeichert. Nodes sind nicht hierarchisch angeordnet. Die Struktur ist flach resp. ergibt sich über die Kategorisierung einzelner Nodes, Eine Seitenbaumansicht gemäss TYPO3 gibt es demnach nicht, vielmehr werden Nodes über Filter kategorisiert (siehe Screenshot).

2681-Drupal_kategorisierung-thumb-500x358-2680.jpg

Im Kern geht es also darum,

> wer (User oder Autoren) hauptsächlich die Inhalte eines Webauftritts erstellt,
> wie oft Inhalte an verschiedenen Stellen wiederverwendet werden und natürlich
> welche Art von Webauftritt (Tendenz zu vielen Community Features oder Corporate Website mit weniger dynamischen Inhalten) realisiert werden soll?

Fahren Sie lieber Mercedes oder BMW?