Geschrieben am 16. November 2010 um 23:49 Uhr von Arne.
Katharina hat mit ihrem Tumblr-Blog und der Zersplitterung ihrer Blogs zu kämpfen und das, denke ich, nicht nur auf technischer Ebene, wie sie in ihrem Beitrag fragt, sondern auch auf konzeptioneller Ebene. Bei Tumblr ist es nun zum Glück so, dass es darauf ausgelegt ist, dass ein Nutzer mehrere Blogs führen kann – allerdings ist es, gerade als Einzelperson, sehr schwierig mehrere Blogs zu führen und möglichst oft zu füllen, wie ich auch aus eigener Erfahrung weiß. Daher bin ich der Meinung, dass man seine Output-Kanäle, wie Blogs, reduziert halten sollte und nur dann aufteilt, wenn eine sinnvolle Trennung wichtig oder nötig ist.
Ich selbst führe mittlerweile mehrere Blogs (zwei bis drei, wenn das eingeschlafene jarne Film-Projekte dazu gezählt wird), darüber hinaus bin ich bei Twitter aktiv, lese E-Mails und andere Blogs und habe vor allem ein Leben und ein Studium. Es ist mir daher leider gar nicht möglich in allen Kanälen und Blogs jeden Tag etwas, möglichst sinn- und gehaltvolles, zu veröffentlichen und so kommt es, dass meine Blogs von Zeit zu Zeit leider etwas, mehr oder weniger lang, einschlafen.
Das ich überhaupt zwei Blogs führe, ist aus dem Wunsch meines ersten Blogs entstanden, gestalterische und technische Themen von meinen persönlichen oder politischen Themen zu trennen; zumal die technischen Themen, die ich auch ab und an in meinem privaten Blog anschneide, für das Publikum dieses Blogs eher schwer verständlich und langweilig sind – wobei ich wegen der geringen Veröffentlichungen hier im Blog schon darüber nachgedacht habe, die beiden Blogs wieder zu vereinen, mich aber aus den eben genannten Gründen doch nicht dazu entschieden habe.
Wenn sich allerdings die Themen der eigenen Blogs sehr ähneln, ist es nicht immer ganz einfach zu entscheiden, an welchem Ort ein Beitrag besser aufgehoben wäre. Und wenn ein Thema in mehrere Blogs passt, kommt es zu Cross- bzw. Doppel-Postings (und somit zu Redundanz).
Bei Katharina ist es nun so, dass sich ihre Blogs, meiner Meinung nach, sehr ähneln: Sie führt ein Foto-Blog, kattitu.de, als eine Art Online-Portfolio (auf WordPress-Basis); einen Tumblr-Blog, kat’s log, als privaten Blog; und einen weiteren Tumblr-Blog, heartcrazed’s iPhone shots, auf dem sie direkt Fotos von ihrem iPhone veröffentlicht. Im Prinzip alles ähnliche Blogs, zumal es bei ihr überall viel um Fotografie geht, aber dennoch hat jedes Blog seinen besonderen Akzent. Trotzdem habe ich das Gefühl, dass sie ihre Blogs zu sehr zersplittert hat: Der iPhone-Foto-Blog könnte auch sehr gut, in eine Kategorie oder Tag abgelegt, im privaten Blog funktionieren. Es ist natürlich legitim und auch, besonders am Anfang, sehr verlockend und motivierend, für einzelne Projekte Blogs anzulegen und dort Dinge zu einem Thema, wie z.B. iPhone-Fotos, zu sammeln, leider wirken solche Blogs immer sehr verwaist, wenn das Interesse für das Projekt nachlässt oder sich der persönliche Themen- und Projekt-Fokus verlagert (oder, wie in diesem Fall, technische Probleme bzw. Umstände das regelmäßige Veröffentlichen behindern). Mir sind deshalb diversifiziertere aber aktivere Blogs lieber, als sporadisch geführte Blogs zu speziellen Themen und Projekten (auch wenn ich selbst diesem Anspruch manchmal leider nicht gerecht werde).
Leider ist mir auch die Grenze zwischen Katharinas Foto-Blog kattitu.de und ihrem privatem Blog kat’s log zu unscharf, was aber vielleicht nur daran, dass sie Fotos aus einer Session nochmals auf ihrem Tumblr-Blog veröffentlicht (wo wir bei der angesprochenen Redundanz wären) und an meiner Wahrnehmung, liegt.
Was nun der beste Weg für Katharinas Blogs wäre, kann ich nicht entscheiden, dass hängt von ihren Zielen und Ansprüchen, an und für die einzelnen Blogs, ab. Wichtig ist nur bei der Blog-Zersplitterung, dass man nicht außer Acht lässt, dass jeder Blog gepflegt und gewartet werden will (was unter Umständen, einen erheblichen Arbeitsaufwand bedeutet) und dass vielleicht die Aufmerksamkeit von Besuchern zerstreut wird, da nicht jeder Blog-Leser bzw. -Besucher unbedingt die anderen Blogs auf dem Schirm hat und deswegen vielleicht nicht die, für ihn interessanteren, Dinge findet und man ihn so deshalb nicht als regelmäßigen Leser gewinnt oder aber wegen mangelnder Aktualisierung verliert.
Zufällig hab ich heute ein sehr interessantes Interview mit dem Erfinder von Rivva, Frank Westphal, gelesen, der nicht direkt etwas zu diesem Thema sagt, aber etwas allgemeines über die Qualität von Blogs, durch den Einfluss von Twitter; und eine ebenfalls sehr Interessante Aussage zu Zeit und Aufmerksamkeit trifft:
Die Leute streuen ihre Aufmerksamkeit immer breiter, gemäß dem »Law of Raspberry Jam«: »The wider any culture is spread, the thinner it gets.« Mittlerweile buhlen diverse web2.0-ige Dienste um deine Aufmerksamkeit … Xing, Facebook, Twitter und so weiter, da hat man weniger Zeit für das eigene Blog. Viele Dinge, die vorher in einem Blogpost gelandet sind, landen heute bei Twitter. Das hat teilweise dazu geführt, dass die Qualität auf Blogs wieder zugenommen hat, weil das witzige Youtube-Video eben bei Twitter landet und nicht im Blog.
(Hervorhebung von mir.)
Update, 18. November 2010: Stephan May, der Frank Westphal interviewte, bat mich die Original-Interview-Texte zu erwähnen, weil es sich bei dem Text bei den Netzpiloten um ein Crossposting handelt: Teil 1 und Teil 2 des Interviews in seinem Blog.
In einem Google Tech Talks-Vortrag stellt Paul Bakaus die, mit seinem Start-Up Dextrose AG entwickelte, Game-Engine Aves Engine vor, die nur auf Web-Standards wie HTML5, CSS3 und JavaScript (im Front- wie Backend) basiert.
Durch die genutzten Web-Technologien laufen die, mit dieser Game-Engine entwickelten, Spiele in jedem aktuellen Browser und somit (theoretisch) auf jedem Endgerät, wie PCs, Smart Phones oder Tablets; und zwar ohne zusätzliche PlugIns wie etwa Flash.
In seinem Vortrag zeigt Bakaus anhand seines Projekts, was mit den offenen Web-Standards möglich ist, was uns in naher Zukunft erwarten und auf uns zu kommen wird. Zudem zeigt er auf, welche Probleme bei der Entwicklung der Game-Engine aufkamen und wie sie, ohne Performance-Einbußen oder gar mit Perfofmance-Verbesserung, gelöst wurden. Denn Performance und die, quasi endlose, Skalierbarkeit, bei Spielewelten und Spielern in einer Welt, sind zwei Probleme, die bei der Spiele-Entwicklung sehr schnell an die Grenzen der technischen Rahmenbedingungen stoßen; dafür zeigt Bakaus einen, für Browser-Games, interessanten Lösungs-Ansatz.
Geschrieben am 30. Oktober 2008 um 21:44 Uhr von Arne.
Eigentlich mag ich WordPress ganz gerne. Seit Version 2.0 arbeite ich (fast) durchgehend damit; mittlerweile betreibe ich zwei Weblogs mit der aktuellen Version 2.6. Da ich mich im Moment intensiver mit WordPress auseinandersetze, fallen mir natürlich auch Dinge auf, die mir nicht so gefallen.
Bevor ich mich den zwei konkreten Punkten widme, die mir Ärger machen, ein kleiner Gedanke zum Konzept von WordPress: Ich finde WordPress mittlerweile für ein Blog-Software ziemlich fett: Mit fast 5 MB ist es leider kein Leichtgewicht mehr. Als CMS kommt es sicherlich schlank und komfortabel daher; aber als Blog-Software ist WordPress schon reichlich aufgeblasen und fett. Dafür ist es sehr flexibel, kann sehr vielseitig verwendet und erweitert werden; es gibt eine große Community die Erweiterungen und Themes entwickelt.
Dies ist aber ein generelles Problem bei der Software-Entwicklung: Große Gegensätze, die schwer gemeinsam zu erreichen sind (klein und simpel gegen flexibel und anpassbar); in der Wirtschaft wird so etwas auch Zielkonflikt genannt.
Auch wenn heute Webspace in rauen Mengen verfügbar und erschwinglich ist, sollte man sich überlegen ob eine große, Speicherplatz-fressende Anwendung sinnvoll ist oder ob man lieber auf etwas schlankeres zurückgreift. Gerade wenn sich Web-Applikationen auf einem Server häufen, so wie bei mir, sollte man über Alternativen nachdenken: Im Moment laufen auf über meinen Webspace zwei WordPress-Installationen, jede mit ungefähr 5 MB und die dritte steht kurz vor der Tür …
Zwei große Ärgernisse verderben mir leider im Moment etwas den Spaß mit WordPress:
Seit Version 2.6 gibt es ein Versions-System für Artikel, wie man es aus Wikis (wie Wikipedia) oder auch aus Content Management Systemen kennt. Dieses Version-System ermöglicht einem, einen veränderten Artikel zu einer früheren Version zurückzusetzen, falls einem die veränderte Version aus irgendeinem Grund nicht gefällt.
Dies kann sehr sinnvoll sein, wenn ein Weblog von mehreren Personen betrieben wird oder wenn man seinen Lesern erlaubt, eigene Artikel zu verfassen.
Für mich ist diese Feature allerdings ein Ärgernis, denn es müllt meine Datenbank mit Einträgen zu. Jedes mal wenn ich einen Rechtschreibfehler korrigiere oder ein Stichwort hinzufüge, wird ein neue Version in der Datenbank angelegt. Und das leider nicht in einer eigenen Tabelle, sondern in der Tabelle für die generellen Blog-Einträge.
Im Moment überarbeite ich gerade diesen Blog (dot.PsiLab alias PsiLab Journal) und meinen rein privaten Blog (»aber aber Arne …«) von Grund auf; ich bin dabei alte Einträge aus alten Blog-Versionen, die hier einmal liefen, wiederherzustellen und aufzuarbeiten. Dabei müssen zum Teil einzelne Beiträge öfters überarbeitet werden. Auf »aber aber Arne …« komme ich bei knapp 90 Blog-Einträgen (inklusive Unterseiten) auf fast 800 Datenbank-Einträge!
Zudem verwässert dieses Versions-System einen Weblog mit fortlaufender ID für Beiträge. Früher waren Beiträge in diesem Weblog über dot.psilab.de/42 erreichbar. Wenn ich dies in der neuen WordPress-Version machen würde, würden sich bei einem regulären Blog-Betrieb (Eintrag erweitern, korrigieren, etc.) zum einen die IDs ständig ändern, weil ein Eintrag immer die ID der letzten Version bekommt. Und zum anderen können die IDs, die auf die alten Versionen verweisen, nicht mehr verwendet werden! So sind fortlaufende IDs nicht mehr möglich. Jetzt würden sich quasi die IDs 60, 42 und 327 aneinander reihen, statt 41, 42 und 43 … Update: Mit automatischem Speichern und Artikel-Speichern/-Vorschau habe ich für diesen einen Eintrag alleine schon 45(!) Versionen in der Datenbank. Und das bevor ich ihn überhaupt veröffentlicht hatte!
Kategorien, Link-Kategorien und Stichworte sind dasselbe. Ein Umstand der mich in den letzten Tagen des öfteren die Haare raufen lies: Wenn ein Stichwort der Name einer Kategorie ist, wird die Kategorie als Stichwort hinzugefügt. Da bei mir die Stichworte aber nur klein geschrieben sein sollen/dürfen, ist dieses Feature wirklich ärgerlich.
Das Problem rührt wohl daher, dass diese drei Kategorie-Arten in einer einzigen Tabelle in der Datenbank liegen. Was vielleicht auch noch kein Problem wäre, wenn in dieser Tabelle zweimal die gleiche URL-Form erlaubt wäre. Dies ist aber leider bei der Standard-Installation von WordPress nicht der Fall. Zwar wird bei der internen Verarbeitung von Kategorien und Stichworten unterschieden, aber nicht in der Datenbank und an der Benutzer-Oberfläche.
Ein konkretes Beispiel, um das Problem etwas zu veranschaulichen: Ein Blog-Eintrag soll in die Kategorie »Foo Bar«, diese Kategorie hat die URL-Form foobar. Im Blog kann man diese Kategorie durch /category/foobar erreichen. Nun soll dieser Beitrag mit dem Stichwort »foobar« versehen werden. Das Stichwort soll ebenfalls die saubere URL-Form foobar haben; später soll sie dann über /tags/foobar erreichbar sein. So simpel dies klingt, so unmöglich ist dies im aktuellen WordPress. Man kann dies, mit Standard-Bordmitteln, nur erreichen, indem man entweder der Kategorie oder dem Stichwort eine unsaubere URL-Form gibt (z.B. für das Stichwort die URL-Form foobar-tag). Das ist leider, wie bei vielen Workarounds, nicht schön gelöst und sauber.
Schön wäre es, wenn es spätestens in WordPress 2.7 für das erste Problem eine Lösung gibt, die schon einige Plugins bereitstellen: Ein- oder Ausschalten des Versions-Systems oder dieses auf eine bestimmte Anzahl an alte Versionen für die Artikel limitieren. Dabei würde ich mir dann auch noch weitergehend wünschen, dass es ein Aufräum-Tool gibt, dass alte, nicht benötigte Versionen löscht und die IDs wieder aufräumt.
Für die Lösung des zweiten Problem muss wohl die Datenbank oder zumindest die Kategorie/Stichwort-Tabelle angepasst werden; was wirklich wünschenswert wäre, denn der oben angerissen Workaround ist wirklich hässlich.