Web Site
Content Management
konzipiert und entwickelt von Kohlhaas & Kohlhaas, Weimar und netz-meister, Erfurt
Akira-Websites
Entwickler & Designer
Akira ist nicht frei verfügbar. Fragen zum Einsatz bitte an info@akira-cms.de.
… ein System, um Ihren Internetauftritt selbst zu aktualisieren. Grundidee ist die Aufgabenteilung zwischen Redakteur und Gestalter/Programmierer. Akira passt sich der Komplexität Ihrer Anforderungen an. Automatische Updates halten alle Installationen auf einheitlichem Entwicklungsstand, technische Wartung inklusive. Besonders elegant im Einsatz für mehrsprachige, internationale Angebote.
Module
Das modular aufgebaute System besteht aus Administrationsmodulen, Basismodulen, die für den Betrieb einer "normale" Website bereits ausreichen und zusätzlichen individuell programmierten Modulen für Spezial-Inhalte und -bedürfnisse unserer Auftraggeber.
Projekte/Kunden
Besuchen Sie die Websites, die mit Akira verwaltet werden (siehe Bilderleiste) und sehen Sie, wie individuell die Anforderungen und Lösungen sind. Unsere Auftraggeber kommen aus ganz Europa. Wenn Sie Ihr Projekt mit uns und Akira umsetzen möchten, dann wenden Sie sich an info@akira-cms.de.
Login
Informationen zu neuen Modulen, Aktualisierungen, Hilfen und Anleitungen
Warum ein eigenes CMS?
Akira ist das Ergebnis aus mehr als 15 Jahren Programmierung und Gestaltung von Websites. In dieser Zeit gab es viele Änderungen in der Art der Website-Erstellung. Angefangen vom Texteditor, über Dreamweaver, GoLive, Frontpage, Userland Frontier bis hin zu heutigen CMSsen war da alles dabei. Von den ersten einfachen Kontaktformularen (Perlskripte via CGI) über kleine Redaktionslösungen (z.B. Editoren für Pressemeldungen) bis zu komplexeren Anwendungen (Mitgliederverwaltung mit Zugang für jedes Mitglied einer Organisation) haben wir eine Menge Quelltext geschrieben.
Und das bei jedem Projekt auf einer anderen Codebasis, mit anderen Variablennamen, anderen – dem Kenntnisstand oder Trend der Zeit geschuldeten – Besonderheiten.
Daraus entstand dann das Bedürfnis nach
- Vereinheitlichung der Codebasis für eine effizientere Arbeit,
- Formulierung von eigenen Interface-Standards für die Gestaltung von Abläufen und Funktionen und der
- effizienten Möglichkeit zur Aktualisierung
Ein größeres Projekt, forderte die Integration vieler vorhandener Funktionalitäten und hatte spezielle Anforderungen an Internationalisierung. In Recherchen hielten wir keines der gängigen CMS für geeignet – Der Start für unsere Eigenentwicklung.
1
Datenmodell
Unser Datenmodell orientiert sich streng an der Trennung von Inhalt und Form. Die Grundidee besteht darin, jede Art von Inhalt getrennt von anderen Inhalten zu verwalten (Module). Adressen, Meldungen, Bilder, Produktinformationen unterscheiden sich z.B. in der Art und Menge der Informationen die zu einem Datensatz gehören. Die werden deshalb in getrennten Datenbanktabellen gelagert. Die zweite wichtige Idee besteht in der Verknüpfung dieser Inhalte untereinander. Die getrennte Verwaltung bietet flexible Möglichkeiten, jedes Element beliebig oft und in unterschiedlichen Kontexten zu verwenden, also z.B. eine Adresse immer wieder an verschiedene Meldungen anzuhängen, Meldungen mit Produkten oder mit anderen Meldungen zu verknüpfen usw. Diese Verknüpfungen sind im CMS zunächst nur struktureller Art. Die Frage der Darstellung wird im Template definiert.
Neben dieser Datenabstraktion werden im CMS Seiten verwaltet. Hier besteht eine direkte Beziehung zwischen der internen und der öffentlichen Erscheinung. Jede Seite kann mit Hilfe vordefinierter Template-Bausteine (pagesection) mit statischen Inhalten gefüllt werden. Zudem können in jede Seite website-spezifische Code-Bausteine (pagescript) eingefügt werden, die bestimmte Funktionalitäten bereitstellen (z.B. Kontaktform, News-Liste/Detailseite).
Das folgt dem Grundgedanken, in das CMS nur die Funktionalität zu bringen, die dort auch von den entsprechenden Nutzern (Administratoren, Hauptbenutzer) benötigt wird.
2
Arbeitsteilung
Nicht nur in der Webseiten-Entwicklung auch in der langfristigen Betreuung lassen sich hervorragend die verschiedenen Aufgabenbereiche trennen. Die vier großen Gruppen sind Besucher, Redakteure, Entwickler und Designer. Dabei spielt es keine Rolle, ob diese Gruppen alle beim Seitenbetreiber angesiedelt, oder als externe Dienstleister eingebunden sind.
Jede dieser Gruppen verfügt über unterschiedliche Ziele, Kenntnisse und Arbeitsabläufe. Alle Aufgaben für alle Gruppen innerhalb eines CMS abzubilden (Template-Editor, Script-Editor, Redaktionsfunktionen) halten wir nicht für sinnvoll. Das CMS hat neben der Bereitstellung der Informationsarchitektur rein den Sinn, dem Redakteur zur Verwaltung der Inhalte (Content-Management) zu dienen.
Der Designer kann Templates und Stylesheets mit den Editoren und Frameworks seiner Wahl bearbeiten. Der Entwickler sowieso. Beide sind in der Lage ihre Daten per FTP auf den Webserver zu laden, Versionen zu verwalten, etc. Entwicklungsfunktionen innerhalb eines CMS anzubieten ist daher eher Funktionalität für den semiprofessionellen Kleinanwender (siehe Wordpress, Joomla), der bestehende Templates minimal anpassen möchte. Letztendlich führt das jedoch nur dazu, dass man eine Joomla-Website schon von außen erkennt, weil niemand die Templates individuell für die jeweilige Website entwickelt.
3
Interface
Bezogen auf den Gedanken der Aufgabenteilung hat das CMS-Interface ganz bestimmte Aufgaben für eine ganz bestimmte Zielgruppe zu erfüllen. CMS-Anwender sind Administratoren und Hauptredakteure, die eher organisatorische als redaktionelle Aufgaben zu erledigen haben. Die breitere Basis der Redakteure und Website-Benutzer mit eher redaktionellen Tätigkeiten werden in internen Bereichen der öffentlichen Websites mit speziellen Front-Ends unterstützt (Mini-CMS).
Das Akira-Interface basiert - abgesehen vom Anmeldebildschirm – auf nur drei unterschiedlichen „Screens“. Der Startscreen gibt Zugriff auf die Seitenstruktur und die installierten Module. In jedem Modul können über die „item table“ alle Inhalte organisiert und gefunden werden. Von hier aus gelangt man in den Bearbeitungsmodus, der je nach Modul in unterschiedliche Formulare aufgeteilt ist.
4
Updates, Codebasis, Sicherheit
Mit Akira setzen wir auf eine „Mothership“-Lösung. Es gibt eine aktuelle zentrale Systeminstallation. Diese Version wird bei jedem Update auf alle installierten Projekte ausgespielt, so dass alle Websites auf der gleichen Codebasis laufen. Durch die Trennung von system- und websitespezifischen Bestandteilen kann der gesamte Systemcode im Hintergrund ausgetauscht werden. Auf diese Weise können wir Bugfixes sehr schnell auf alle Systeme anwenden, aber auch neue Funktionen sind immer sofort in allen Installationen aktivierbar.
Die Updates finden auf drei Ebenen statt: dem tatsächlichen Quellcode, der Datenbankstruktur und den „Labels“, die das Interface lesbar machen und mehrsprachig vorliegen.
Als proprietäres System sehen wir Akira nicht den großen Angriffsattacken wie Systeme mit größerer Installationsbasis ausgesetzt. Dennoch mehmen wir Sicherheitsaspekte nicht auf die leichte Schulter. Durch die einheitliche Codebasis ist es uns sehr schnell möglich, auf Sicherheitslücken zu reagieren und diese in allen Installationen zu schließen.
Nutzung, Übergabe
Eine oft gestellte Frage im Zusammenhang mit einer eigenen CMS-Lösung ist die nach der Übergabe an zukünftige Dienstleister, falls das Geschäftsverhältnis beendet wird.
Unsere Erfahrung zeigt hier folgende Situation: Websites haben eine durchschnittliche Lebensdauer von etwa 2 Jahren. Danach macht eine Überarbeitung hinsichtlich der Technik Sinn. Dabei kann die Website gleichzeitig neu auf die aktuellen Bedürfnisse und Ziele des Seitenbetreibers ausgerichtet werden. Dies ist der Punkt an dem jeweils ein Dienstleisterwechsel zur Debatte steht.
In aller Regel geht mit einem Dienstleisterwechsel ein Systemwechsel des verwendeten CMS einher. Selbst wenn die Plattform beibehalten wird (z.B. Typo3), dann hat es in diesen 2 Jahren so viele Versionssprünge gegeben, dass eine Aktualisierung auf das neueste System einer Neuinstallation gleich kommt. Jede in Ausschreibungen und Pitches angefragte Agentur bevorzugt ihre eigenen Systeme (Typo3, Redaxo, Contenido, Joomla, RedDot, Magento, etc.) und bietet stichhaltige Gründe, warum nur dieses System das Richtige ist. Da bei einem Dienstleisterwechsel in der Regel die Gesamtstrategie in Frage gestellt wird, führt dies auch zu einem Komplettumbau der Inhalte und damit spielt die Systeminstallation im Endeffekt eine untergeordnete Rolle.
Kurz gesagt: Wenn wir gebeten werden ein Projekt zu übernehmen, werden wir dahin beraten, Akira als CMS einzusetzen. Wird ein anderer Dienstleister ein Akira-Projekt übernehmen sollen, dann wird dieser Dienstleister seine eigene bevorzugte Lösung mitbringen.
Aufgrund der sauberen Datenhaltung ist eine Konverierung der Rohinhalte aus den Datenbanken in andere Systeme immer möglich.