Funktionsumfang von Blogsystemen
1. September 2009 Roland
Wir (Ute, Dirk und Roman) haben nach dem Podcast aufnehmen wieder einmal über unser Lieblingsreizthema, was eine Blogsoftware wirklich benötigt, gesprochen.
Wenn alles klappt, werde ich am nächsten Barcamp in Stuttgart ein bisschen über dieses Thema diskutieren. Vielleicht können wir ja die absoluten Muss- und Kann- Kriterien an eine Blogsoftware etwas genauer eingrenzen.
Die heutigen Blogsysteme haben alle ihre Vor- und Nachteile und einige von ihnen ersaufen in nicht mehr überschaubaren und verwaltbaren Features. Ich glaube dieser Trend ist gefährlich und führt zu einem Stillstand den wir im Netz nicht nötig haben.
Funktionale Anforderungen an ein Blogsystem
Wenn man ein Blogsystem mal ein bisschen abstrakt anschaut, besteht es aus:
Texteingabe
Eine Texteingabe mit der man seine Überschrift, seine Tags, seine Beschreibung und den eigentlichen Text eingeben kann.
Kategorie / Serienverwaltung
Dann wäre es noch schön wenn man seine Kategorien und eventuell, wenn man Roland heißt 
, seine Serien pflegen kann. So ein bisschen Ordnung im Blogsystem hat schon was.
Kommentarfunktion / Zitieren
Der jeweilige Blogeintrag muss kommentierbar sein. Sonst ist der Blog ja nichts weiter als eine weitere Seite die nur Texte verteilt und die Community kann nichts dazu beitragen. Wäre mehr als saudoof gelle?
Diverse Präsentationsmöglichkeiten
Wenn dann mal ein Artikel getippt wurde, sollte der auch in einem ansprechenden Design den Lesern zur Verfügung gestellt werden.
Und wir haben heutzutage nicht nur 3270 Emulationen, sondern schöne bunte Webbrowser.
Weiterhin haben wir noch:
- Feedreader
- E-Mail Clients
- Braile Leser
- Mobile Endgeräte (Ichfons, Telefon, Mikrofon…
) - …
Also bietet es sich doch an, für jedes dieser Wunderwerke den nötigen Output zu erzeugen.
Mit XSLT und anderen steinalten Technologien kann man das ja schön erzeugen.
Für die Großgrundbesitzer unter uns könnten wir ja sogar ein ETL Werkzeug einsetzen und richtig viel Geld ausgeben
Trackbacks und Co
Ein Blogsystem soll sich mit anderen Blogssystemen austauschen können. Ansonsten klappt die Vernetzung mit der Welt wohl nicht ganz so gut. Also wäre es doch schick, wenn wir noch die Trackbacks, Pinbacks und was es da so gibt zur Verfügung hätten.
Strukturierte Texteingabe
Nicht jeder ist ein Purist und tippt gerne Plain HTML
Gut, ich hab mich daran gewöhnt und es geht bei mir schneller als wenn ich Klicki-Bunti-Editoren verwende. Aber vielleicht bin ich alter Konsolenjunkie auch nicht die beste Referenz für so was…
Vielleicht muss man ja auch gar keine HTML Eingabe machen. Die Götter des Netzes haben bei den Wikis eine andere Strukturform erfunden. Diese soll für nicht so gewiefte Menschen einfacher zu erlernen sein. Also gibt es auch hier einige Möglichkeiten die man nehmen könnte. Vielleicht könnte man auch schnelle WYSIWYG Eingabewerkzeuge erstellen. Bei Serendipity war ich z.B. von der Geschwindigkeit auf meinem Asus Eee 900 wirklich begeistert…
Das wars dann auch schon. So ein Blog soll meiner Meinung nach zum Kommunizieren anregen. Er soll nicht durch hundert Verwirrknöpfe und Superdefinit-Label-Manager-Ich-Habe-Keine-Ahnung-Wozu Features den Anwender abschrecken. Und wenn dann jemand doch alle Knöpfe und Features haben will, dann kann er oder sie ja Blogsysteme nutzen die dies bieten.
Nichtfunktionale Anforderungen
Es gibt auch eine ganze Menge Anforderungen, die mit der eigentlichen Funktion des Blogs nichts zu tun haben.
Ohne diese Anforderungen funktioniert zwar das System als solches nicht, aber der Nutzen des Blogsystems wird hierüber nicht definiert.
Spamfilter
Leider werden Blogsysteme, vor allem Kommentare, für unsere Freunde von der Spamfraktion gerne und reichlich genutzt. Wir Blogger mögen das gar nicht und sind nicht einmal davon begeistert, dass wir dann mehr Arbeit mit dem Putzen zu tun haben. Und manchmal passiert es dann, dass sogar vernünftige Kommentare (Siehe letze Woche Imbo Sims Kommentar) auch im Spam landen. Das ist einfach nur doof, aber Spamer haben irgendwie ein anderes Weltbild.
Userverwaltung
Ich habe den Verdacht dass der Trend sehr massiv zur Multiuser Instanz geht. Überall sprießen Social Network Plattformen aus dem virtuellen Boden. In Firmen will jede Abteilung einen eigenen Blog und der Verein fühlt sich auch nur wohl, wenn der Vorstand seinen eigenen Blog hat. Also sollte der Blog auf diese Bedürfnisse eingehen.
Erweiterungsmöglichkeiten (Plugins)
Der Featurismus kennt heute keine Grenzen. Für jedes Themengebiet gibt es einen tollen Plugin. Also soll ein Blogsystem sich nicht verschließen sondern eine saubere Schnittstelle für Plugins zur Verfügung stellen.
Bei WordPress gibt es für jedes Thema gleich mehrere Plugins. Bei Serendipity gibt es für jedes Thema exakt einen Plugin.
Beides hat seine Vor- und Hinterteile.
Was mir aber auf alle Fälle sehr wichtig erscheint ist, dass die Plugins nie auf die Coretabellen schreibend zugreifen. Will heißen, wenn ich eine Erweiterung mache, dann soll diese auch in ihrem eigenen Bereich stattfinden. Updates usw. werden ansonsten ein wahrer Horror. Noch geiler ist es, einen Plugin gegen einen anderen auszutauschen und alle Abhängigkeiten, die vom alten Plugin her vorhanden sind, dann noch gerade zu ziehen. Naja, wir basteln ja gerne…
Stabil
Tolle Anforderung! Aber wahr. Ein Blogsystem muss meiner Meinung nach auf einem Stück Holz laufen und darf keine Probleme machen. Es muss einfach funktionieren.
Schnell
Wenn ich z.B. die Eingabe von Serendipity mit WordPress vergleiche, möchte ich sofort von WordPress umsteigen. Ich hasse es zu warten. Klar, meistens schreibe ich meine Artikel mit Quanta im Zug offline und kopiere den Text nur noch ins Blogsystem. Aber das ist ein Würgaround und sicherlich nicht das was eigentlich angedacht war.
Sicher
Jeden zweiten Tag ein Sicherheitsproblem finde ich auch nicht gerade schön. Das System sollte im Idealfall nicht angreifbar sein. Diese Anforderung ist nicht umzusetzen, jedoch sollte es möglich sein eine stabile Software zu erstellen, die dem Stand der Technik entspricht und Scriptkiddies einfach nicht reinlässt.
In diesem Fall sollte man sich den gesamten Stack anschauen.
Angefangen beim Betriebssystem (oder gar den Firewalls) über den Webserver, bis hin zur Datenbank und eingesetzten Programmiersprache.
Wenn man ein bisschen “unsicherer” unterwegs sein will, sollte wenigstens die Architektur des Blogsystems so sauber sein, dass keine unnötigen Fehlerquellen sich darin verstecken können.
Sauber strukturierte Architektur und Coding Styleguides
Damit das System sauber bleibt, muss dafür Sorge getragen werden, dass die Architektur strukturiert und aufgeräumt ist. Ein Framework (muss) eingesetzt werden, mit dem eine saubere Vorgehensweise möglich ist. Wie immer ist Seperation of Concerns und Design Patterns nicht nur toll zum Malen sondern wichtig um die Software stabil zu halten.
Testszenarien
Jede Funktionalität muss regressiv testbar sein. Falls ein Sicherheitsloch gestopft wurde, muss dies getested werden. In einem Jahr kann das gleiche Loch sonst wieder auftreten.
Installierbar
Das Blogsystem muss installierbar sein. Das bedeutet, dass mit einfachen Scripts oder Oberflächen die Installation schnell und einfach vonstatten gehen soll.
Sinnvolle Releaseplanung
Patches, Releases usw. sollen planbar sein. Ein altes Blogsystem sollte auf alle Fälle noch eine Weile (z.B. ein Jahr) supported werden. Ich finde es vollkommen dumm, wenn man jede Woche ein Update, Patch, Flick, Fummel am System durchführen muss. Das ist nicht wirtschaftlich und führt dazu, dass steinalte Systeme mit dicken Löchern im Netz herumstehen.
Sinnvolle Feature Planung
Erweiterungen, neue Features usw. müssen in die neuen Versionen eingebaut werden können. Hier halte ich es für wichtig, dass die Planung klar kommuniziert wird und jedem Anwender klar sein muss wann welches Feature zur Verfügung steht.
Support
Wenns mal nicht klappt sollten Foren, Newsgroups und/oder Bugtracker vorhanden und gepflegt werden.
Dokumentation
So ein Wiki hat was. Wenn man die Dokumentation finden kann, dann können die Fehler der Vergangenheit ruhen und durch Neue ersetzt werden Im Ernst, es ist doch ziemlich dumm ein gutes System zu haben und niemand weiss davon.
Migrationsfähigkeit / Upgradefähig
Gibt es was nervigeres als ein neues Release einzuspielen und dann alle bisher vorhandenen Datensätze nicht mehr verwenden zu können?
Immer diese rethorischen Fragen
Wenn ein neues Update vorhanden ist, soll das ohne manuelle Eingriffe und ohne Datenverlust einspielbar sein. Sowas haben wir in der IT schon seit Jahren eigentlich im Griff. Wieso also nicht auch bei Blogsystemen?
Stellt euch mal vor, nur weil ein neuer Release vorhanden ist, müsst ihr mit eurer Bank nochmal einen neuen Vertrag abschließen. Klingt ziemlich ungeschickt gelle?
Na was sagt ihr dazu?
Ich gebs ja zu, ich hatte mir überlegt eine Blogparade anzustoßen. Aber im Moment bin ich noch zur Hälfte mit der Baustelle daheim beschäftigt und möchte daher nur mal hier ein bisschen rumdiskutieren.
Habe ich noch was wichtiges Vergessen oder bin ich schon wieder übers Ziel hinausgeschossen?
Gibt es Blogsysteme, die diese Anforderungen abdecken?
Sollten wir (die Internetcommunity) ein weiteres Blogsystem erstellen, dass diese Anforderungen abdeckt?
Fragen über Fragen. Ich bin echt gespannt was ihr dazu meint.
Artikel mit ähnlichen Schlagwörtern
Der Beitrag wurde am Dienstag, den 1. September 2009 um 08:29 Uhr veröffentlicht und wurde unter IT abgelegt.
Dir gefiel der Artikel? Dann abonniere doch den RSS Feed
Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.
Eine Sache bezüglich der Eingabe.
Es gibt mittlerweile wirklich gute und WYSIWYG HTML-Editoren für den Browser. In s9y kommt Xinha zum Einsatz, wenn man ihn möchte, der FCK-Editor ist ein weiterer guter Vertreter für diese Gattung.
Das ist ein gutes Beispiel für eine sinnvolle Plugin-Infrastruktur.
http://www.fckeditor.net/
http://xinha.webfactional.com/
In Summe erfüllt s9y einen Grossteil Deiner Forderungen. Allerdings gibt es kleinere Überdeckungen bei den Plugins, so dass manchmal zwei Plugins eine Aufgabe ähnlich lösen. Die Tendenz ist aber, eher ein bestehendes Plugin zu erweitern als ein neues bereitzustellen.
Für mich ist es unsinnig eine weitere Blogsoftware zu erfinden. Noch ein Rad…
Wenn s9y einen Großteil erfüllt, wäre es sinnvoller die Zeit in die Pluginentwicklung zu stecken und die fehlenden Features so hinzuzufügen.
Selbst wenn daraus kein offizielles Plugin würde, weil es sonst niemand braucht, wäre das aus meiner Sicht sinnvoll.
Der Punkt mit den Editoren kommt ja meiner Traumversion der Module nahe, wenn ich mir aussuchen kann welcher Editor mit dem System arbeitet wäre das ja auch schon nicht schlecht…
Das denke ich auch, deswegen bleibe ich auch bei s9y auch wenn andere Blogsoftware vielleicht mal ein Feature hat, was ich vermisse.
Bei s9y kommt man aufgrund der übersichtlichen Grösse schnell dazu, sein Plugin in den Hauptrepositories zu sehen.
Ok, also kann das Teil auch noch die nichtfunktionalen Anforderung abdecken?
Über Testszenarien kann ich nichts sagen, ansonsten wird alles erfüllt, sogar die Dokumentation in Buchform: http://tinyurl.com/5rjc3m
Eine Serie ist nichts anderes als eine (Unter-)Kategorie, die über Vor-Zurück-Buttons verknüpft ist. Das kann Serendipity.
Serendipity erfüllt auch sonst die Anforderungen. Wobei: Bei “Sinnvolle Releaseplanung” kann man über das “sinnvoll” diskutieren, denn die alten Versionen werden nicht gepflegt, die neuen aber nicht so häufig, dass dies ein Problem wäre. Es ist ja keine Distro. Die Coding Styleguides sind wahrscheinlich nicht wirklich erfüllt, auch wird kein Framework benutzt, aber diese letzte Anforderung lass ich auch nicht durchgehen – die eigentliche Anforderungen sind Erweiterbarkeit und Sicherheit, die wiederum erfüllt zu sein scheinen.
Gruß
Also wenn ich euch so richtig verstehe funktioniert bei Serendipity auch der Upgrade von einer alten auf eine neue Version ohne größeres Gewürge?
Lustig finde ich im Moment unseren Diskussionsverlauf.
Ich fragte nach den Grundanforderungen an ein Blogsystem und jetzt sagen wir “nur” noch, dass Serendipity das alles erfüllt.
Sind nun meine Grundanforderungen für euch abschließend und richtig oder sollte ein Blogsystem andere Anforderungen befriedigen?
Grüßle
Roland
@Roland: Den Umschwung hat Ute mit Kommentar Nummer 2 eingeläutet.
Updates funktionieren bis jetzt ganz ohne Probleme, einfach neue Version entpacken, Blog-URL aufrufen, die Datenbankupdates (via Web-Frontend) ausführen, fertig.
Du hast schon mehr Anforderungen genannt, als ich für wichtig halte, damit “Ja, Deine Grundanforderungen sind abschliessend”. Zum Beispiel “installierbar” würde ich nicht als Anforderung aufnehmen, das klingt eher so als ob Du “Zähne putzen” auf Deine persönliche Tages ToDo-Liste aufnimmst.
“Schnell” ist auch abhängig von der Hardware, der Konfiguration des Betriebssystems und der Server-Software und der Anzahl der Zugriffe. Damit ist “schnell” kein objektives Kriterium. Gleiches gilt in ähnlichem Mass für “stabil” und “sicher”.
Huhu,
stimmt, schnell, stabil und sicher sollte noch richtig ausformuliert sein.
Installierbar ebenfalls. Denn damit meine ich dass das System so einfach aufzusetzen sein sollte dass ein nicht Profi es auch nutzen kann.
Woher weisst du, dass ich “Zähne putzen” auf meiner persönlichen ToDo Liste habe
Falls ich eine hätte wäre das sicher drauf
Welche weiteren Anforderungen, ausser installierber, schnell, stabil und sicher siehst du als “überflüssig” an?
Vielleicht kann man da was kürzen…
Ich muss mir im Laufe des Tages mal die ganzen Punkte untereinader schreiben, um den Überblick zu behalten.
“Sicherheit”, “Schnelligkeit” und “Stabilität” könnte in “Codequalität und Architektur” einfliessen, wenn dann zusätzlich noch “gutes Daten(bank)design” dazu kommt, hätten wir das abgefrühstückt …
“Installation” -> “Benutzerfreundliche Installation” mit vernünftigen Standard-Einstellungen
“Schlagworte” (Tags) habe ich mal ergänzt
Subjektive Beschreibungen sollten raus: Sauber und sinnvoll
Funktionale Anforderungen an ein Blogsystem
- Texteingabe
- Kategorie / Serienverwaltung / Schlagworte
- Kommentarfunktion / Zitieren
- Diverse Präsentationsmöglichkeiten
- Trackbacks und Co
- Strukturierte Texteingabe
Nichtfunktionale Anforderungen
- Spamfilter
- Userverwaltung
- Erweiterungsmöglichkeiten (Plugins)
- Strukturierte Architektur und Coding Styleguides
- Testszenarien
- Benutzerfreundliche Installation
- Releaseplanung
- Feature Planung
- Support
- Dokumentation
- Migrationsfähigkeit / Upgradefähig (von wo nach wo soll migriert werden?)
“Spamfilter” und “Userverwaltung” würde ich aber als funktionale Anforderungen betrachten. Das sind doch jeweils konkrete Funktionen, noch nichtmal Mate-Punkte, die die Software unterstützen muss. Oder?
Ich bin direkt auf Serendipity eingegangen, weil die Diskussion schon in die Richtung ging. Es ist halt auffällig, dass es sich so liest, als wäre die Anforderungsliste so geschrieben worden als sollte Serendipity passen
Gruß
Hi,
manchmal ist es schon bemerkenswert wie genau eine bestehende Applikation auf Anforderungen passt. In dem Fall ist wenigstens klar, wer bei einer Auswahl gewinnen würde
Wenn wir schon so nah an Serendipity entlangschrammen möchte ich noch eine Frage in den Raum werfen:
Kann man mit Serendipity eigentlich ein Multiuser Blog erstellen?
Wenn ich die bisherigen Anforderungen an die Kundenbedürfnisse von miradlo anschaue ist dies eine wichtige Frage.
Und falls das so nicht geht, was glaubt ihr wie massiv der Umbau von Serendipity wohl wäre um dahin zu kommen?
Bei WordPress ging es ja mit der Anlage von weiteren Tabellen pro Blog. Diese Vorgehensweise ist vielleicht ein bisschen gefährlich, was die Übersichtlichkeit angeht.
Und das von Dirk beschriebene Datenbankdesign ist damit auch nicht sehr schön gelöst. Immerhin ist das nur eine Duplikation und weit entfernt von einer Normalform.
Ok bei online Datenbanken ist die Duplikation wohl nicht so entscheidend, da ist Performance schon wichtiger. Aber dennoch macht man so schon ziemlich fest wie die Skallierung der DB stattfinden soll. Ich würde die Skallierung jedoch lieber dem DBMS überlassen als der Applikation…
Ich muss mal eben nachfragen, was für Dich ein Multiuser-Blog ist. Falls Du damit meinst, dass viele Autoren mit eigenem Login an einem Blog schreiben, ja das geht.
Wenn Du ein Multisite-Blog meinst, bei dem mit einer Programminstallation verschiedene URLs versorgt werden, dann kann ich nur sagen, dass ich davon gehört habe, ich aber dem nicht traue. Vielleicht täusche ich mich auch kolossal.
Die Frage ist vielleicht im Forum gut aufgehoben.
Skalierung muss sowohl vom Datenbankdesign als auch vom DBMS unterstützt werden. Ich kann Dir auch ein schlechtes Design zeigen, das eine Datenbank, die komplett im Speicher liegt, langsam macht.
Ich würde in jedem Fall noch Dotclear, das im französischen Sprachraum sehr verbreitet ist (ich kenne es aber nicht) und die abgespeckte Wordpresvariante Ha… (kann mir den Namen nicht merken) in die engere Auswahl nehmen.
Gehen muss es das wirklich, denn es gibt ja auch supersized.org. http://s9y.org/41.html klingt aber wirklich nicht nach keinen Aufwand.
@Dirk: Ich meine einen Multisite-Blog wie bei Buddypress oder so.
@onli: Ich schau mir das bei Gelegenheit mal an.
Vielen Dank für eure Infos!
Es macht immer wieder Spass mit euch über Dinge zu diskutieren.
Die Grundanforderungen finde ich schon sehr gut. Wenn man daraus eine Matrix bildet, kann man bestehende Systeme dahingehend prüfen und so eine Übersicht schaffen, welches System was bietet und sich wie gut eignet.
Letztlich erhält man damit die Basis für die Entscheidung, ob man ein bestehendes System erweitert oder gar von Grund auf neu anfangen muss.
Bzgl.MultiUser Blog. Ich denke, beides kann interessant sein! Warum soll ein Blog nur von einem Autor gepflegt werden? Können nicht mehrere User sich ein Blog teilen oder mehrere Autoren eigene Blogs haben, die aber letztlich auch zusätzlich in eine Timeline laufen?
Teilen geht auf jeden Fall ohne weiteren Aufwand.
Eigene Blogs zusammenführen ist natürlich auch machbar. Im einfachsten Fall setzt man dazu mehrere Blogs auf und startet einen Sammelblog, der dann die RSS-Feeds auf der Startseite anzeigt. Das in Kategorien und in eine einzelne Installation zu pressen ist der interessante Teil.
Tabellarisch die Systeme gegenüberzustellen wäre sicher mal interessant zu sehen. Sowas wird zwar oft der Realität nicht gerecht, der Grobüberblick schadet aber bestimmt auch nicht.
@Frank: Am Barcamp (BCS2) haben wir ziemlich viel über dieses Thema gesprochen.
Ich werde das Barcamp Feedback demnächst mal in einen weiteren Artikel giesen. Dabei geht es darum, die Anforderungen nach z.B. “minimal” , “mittel” und “maximal” aufzuteilen.
Es hat sich wie zu erwarten herausgestellt, dass die einzelnen Anwender auch unterschiedliche Bedürfnisse haben. Diese Bedürfnisse kann man nicht in einer Konfiguration unterbringen. Ich melde mich auf alle Fälle nochmal zu diesem Thema.
@onli
Ich werde mir da was einfallen lassen, wie ich die Priorisierung und die Kategorisierung der Anforderungen sinnvoller ordnen kann. Der Grobüberblick hat geholfen das Thema mal anzukratzen. Da ziemlich viel Interesse vorhanden ist (Barcamp und hier) werde ich das nun noch etwas vernünftiger aufbereiten.
Grüssle
Roland
[...] “Was für Funktionen braucht eine Blogsoftware?“: Eine anregende Diskussion, die zwar mit WodPress-Bashing begann, bei der es dann aber [...]