Skip to content

Google Seiten- und Artikel-Wertungen ::: Pagerank

Über Sinn und Unsinn des Pageranks kann man vortrefflich diskutieren und philosophieren. Ich sehe das nicht so verbissen wie manche, aber manchmal ärgere ich mich schon auch, oder freue mich über eine Entwicklung. Beispielsweise habe ich mich gefreut als im Februar erstmals eine unserer  Seiten bei dmoz.de gelistet wurde. Mir sind Statistiken und Werte nicht so wichtig, dass ich bereit wäre zusätzliches zu installieren, wie z.B. Google Analytics, bei dem auf jeder Seite ein Javascript mitläuft. Manches probiere ich aus oder nutze es mal im ein oder anderen Fall, wie z.B. blogoscoop auf uteles Blog. Die grobe Richtung von verschiedenen Webauftritten, Blogs und ähnlichem schaue ich mir jedoch schon an. Der Pagerank ist ein Hinweis darauf, wie gut oder schlecht eine Seite von der großen Suchmaschine wahrgenommen wird. Auch bei Kundenseiten schaue ich, wie sie sich entwickeln, dort setze ich häufig auch die lokale Suche ein. "Google Seiten- und Artikel-Wertungen ::: Pagerank" vollständig lesen

Webdesign ::: Checkliste um Webauftritte und Blogs zu testen

Wer Webseiten erstellt oder verschiedene Themes in Blogs einsetzt, sollte vor allem bei neuen Layouts, aber auch bei Änderungen testen. Es gibt die unterschiedlichsten Arten das zu tun, wir bei miradlo nutzen dazu eine Checkliste, um nichts zu vergessen. Einer der wichtigsten Punkte bereits während des Erstellens neuer Webseiten sind die regelmäßigen Prüfungen in den Validatoren, Validator-Links siehe Glossar zu Validatoren. Wir passen unsere Checkliste immer mal wieder an, der ein oder andere hat sich auch weitere eigene Punkte notiert oder diese Liste ergänzt. Unsere Liste ist aufgeteilt in Gruppen von Tests:

Benutzerfreundlich

  • nur soviel Pflichtfelder wie nötig, nicht gleich den Stammbaum, nur um Kontakt aufzunehmen
  • nicht eindeutige Linktexte mit zusätzlichem title, klar unterscheidbare verschiedene Namen für Links (nicht zehnmal "mehr" oder "weiterlesen")
  • spezielles CSS für print und handheld (klappt aus Zeitgründen grad noch nicht immer)
  • Sitemaps sobald der Auftritt eine umfangreichere Navigation hat (bei einem 10-Seiten-Auftritt ohne Unternavigation halte ich eine Sitemap für überflüssig)
  • Fehlerseiten mit vollständiger Navigation (error und forbiddeen für 404, 401 und 403)
  • favicon zur Orientierung
  • fremdsprachige Texte bekommen z.B. ein <div lang="en"></div> (allerdings bei "denglischen" Begriffen spare ich mir das)
  • Links haben verschiedene Auszeichnungen für ihre Zustände (visited, hover, focus, active sind unterscheidbar definiert, so dass sich besuchte Links unterscheiden und auch bei Tastaturnavigation erkennbar ist, bei welchem Link man grad steht)

"Webdesign ::: Checkliste um Webauftritte und Blogs zu testen" vollständig lesen

Teil II ::: WordPress seine Plugins und Updates...

Im Artikel WordPress Plugins - nicht immer problemlos hatte ich von einem Pluginproblem berichtet. In den Kommentaren entwickelte sich mit Dieter eine ausführlichere Diskussion zu den Plugins und dem Weg, den WordPress gerade nimmt. Statt dieser Diskussion jetzt einen weiteren recht ausführlichen Kommentar hinzuzufügen, fand ich es sinnvoller, dem einen eigenen Beitrag zu geben:

Philosophie von Firefox und WordPress

Zitat Dieter ^:
Zurück zum Thema ;-) Zum anderen wird WordPress dadurch aber auch immer umfangreicher und fehleranfälliger.
Im Grunde ist der Firefox gerade ein gutes Beispiel. Denn genau das war ein Grund für den Erfolg des Firefox. Firefox hat in seiner Grundinstallation genau das was ein Browser unbedingt können muss, aber nicht mehr. Im Gegensatz zum Netscape (Mozilla, Iceweasel...) in der gleichen Zeit. Während Netscape alles enthielt und unzählige Funktionen hatte, die ihn unübersichtlich machten, war Firefox schlank und einfach. Jeder kann sich jedoch aussuchen, was er oder sie zusätzlich haben möchte. Ich nutze bei meinem Standard-Firefox eben 14 Plugins, weil ich einiges, aber nicht alles, damit mache, du deine 67, weil du sehr viel mit Firefox machst. In anderen Installationen, die ich nur zum Testen brauche, z.B. unter Windows habe ich genau ein Add-On, die Webdeveloper-Toolbar und das war's. WordPress begann mit ähnlicher Philosophie ein einfach gehaltenes System, welches vor allem das tut, wofür es gebaut wurde, das Bloggen zu unterstützen.

WordPress als CMS

Zitat Dieter ^:
Mein Eindruck ist, dass sich WordPress immer mehr von einer Blogsoftware zu einem Content Management System (CMS) entwickelt. Das finde ich grundsätzlich ok, da die Bedürfnisse häufig mit der Zeit wachsen.
CMS ist auch meines Erachtens in Ordnung, jedoch denke ich, damit fangen manche Probleme an. Je mehr das System kann, desto fehleranfälliger wird es.
Etwas lästig finde ich aber, dass dabei auch ständig das Erscheinungsbild (Look and Feel) des Backends (Administrationsbereich) geändert wird. Der Mensch ist ein Gewohnheitstier und damit kommt der Spieltrieb der Entwickler in Konflikt. ;-)
Das Erscheinungsbild allein finde ich ebenfalls schon lästig, ich nutze deshalb Adminize, weil ich weder mir und noch viel weniger anderen, die seltener damit arbeiten zumuten möchte, sich an eine völlig andere Oberfläche zu gewöhnen. Über den Unsinn eine Adminoberfläche mit Spielkram zu füllen, habe ich mich ja auch schon unter: Adminize WordPress ausgelassen. Ich möchte mit einer Adminoberfläche arbeiten, ich möchte nicht, dass da irgendwelche gemütlichen JavaScript-Funktionen irgendeine Spielerei übernehmen.

WordPress Icons

via Perun kam ich zu der Umfrage der WordPress-Icons. Ich habe teilgenommen. Im Grunde könnte ich bei WordPress ganz auf die Icons verzichten, aber nun gut. Besonders erschreckend fand ich jedoch Hinweise am Ende der Umfrage, dass manche Icons auf keinen Fall genommen werden. Nicht, weil sie nicht schön sind, oder eindeutig, nein: "System XY nutzt bereits das Symbol eines Gabelschlüssels für diese Funktion, deshalb nutzen wir es auf keinen Fall."
Wie bitte?
Das ist so ziemlich die dämlichste Begründung, die mir in solch einem Zusammenhang jemals begegnet ist. Denn gerade solche Quasistandards erleichtern es den Anwendern sich schnell und einfach zurechtzufinden. Etabliert haben sich ein paar dieser Standards, wie ein Haus für die Startseite eines Auftritts, oder in einer Anwendung eben für die Adminstartseite. Ein Gabelschlüssel für Tools, ein Stecker für Plugins usw. Nutzt man diese Standards, so macht man es vielen Nutzern leichter sich in einer neuen Umgebung zurechtzufinden. Wo ist das Problem, wenn ein Icon bereits von einem Konkurrenzsystem genutzt wird, nur weil ein Icon gleich ist, werden die Anwender die Systeme nicht verwechseln.

Adminoberfläche anpassbar

Für mich wäre eine konfigurierbare Oberfläche sinnvoll. Von mir aus, sollen sie Bildchen und Spielkram reinpacken, wenn ich es abstellen kann, ohne größere Eingriffe machen zu müssen, gut. Unsinnig finde ich, dass mit Adminize ein Plugin brauche, um einen Zustand herzustellen, der normal sein sollte. Nahezu alle anderen mir bekannten Programme sehen bei einem massiveren Oberflächenwechsel vor, dass man die alten Einstellungen behalten kann. Dass im Lauf der Zeit die ein oder andere Funktion Teil des Systems wird, ist normal und auch gar nicht schlecht. Allerdings erwarte ich eben, dass diese Funktionen dann ebenso konfigurierbar sind, wie es bei den vorherigen Plugins möglich war.
  • Selbst die integrierte Tagfunktion ist jedoch noch weit von dem entfernt, was Simple-Tags leistete.
  • Trotz deutscher Sprachdateien sieht das System noch immer nicht vor, dass Umlaute in den Links sinnvoll umgewandelt werden...
Überdies sind die Aktualisierungsintervalle in letzter Zeit kein Spaß, und nur wenige kommen in dieser Geschwindigkeit mit. Durch die Häufigkeit geben immer mehr einfach auf und bleiben bei Uraltversionen stehen, die tatsächlich eine einzige Sicherheitslücke sind. Denn gerade wenn auch noch einige Plugins genutzt werden, dann müssen diese ja erst abgeschaltet, dann wieder aktiviert werden. Bei den neuen Versionen mit dem Hinweis auf die jeweils neuen Pluginversionen, könnte man fast täglich aktualisieren.

Automatisch aktualisieren

Der Grundgedanke, der bei den Plugins inzwischen eingesetzt wird, nämlich diese automatisch aktualisieren zu lassen, der ist im Grunde ja sehr schön. Einerseits erhöht das die Chance, dass Plugins nicht einfach vergessen werden und die Pluginversion irgendwann viel älter und unsicherer ist, als das System selbst.
Es gibt jedoch zwei Probleme:
Einige Plugins lassen sich einfach nicht automatisch aktualisieren. Nun gut, das ist ein lösbares Problem und wird wahrscheinlich besser, je länger es diese Funktion gibt. Das größere Problem ist, dass man damit auf dem echten System die Aktualisierung per Knopfdruck durchführt und falls etwas schief geht, dann nur wesentlich mühsamer das Ganze im Livesystem korrigieren kann. Je einfacher solche Funktionen eingebaut werden, desto weniger nützen die Beschreibungen und Hilfeseiten, die empfehlen erst zu sichern und dann erst... Ich löse es inzwischen so, dass ich bei manchen Autoren weiß, wenn einen Tag nach Veröffentlichung keine weitere Aktualisierung kommt, dann gibt es kein Problem und man kann recht gefahrlos das Update durchführen. Bei anderen Autoren warte ich ein paar Tage, teste dann lokal und probiere erst nach Sicherung des Systems aus, was bei der Aktualisierung passiert. Wie schon mehrfach erwähnt, ich bin eher übervorsichtig mit Plugins und nutze nicht so viele. Mein Vorgehen ist jedoch kaum praktikabel für diejenigen die 30, 40 oder noch mehr Plugins nutzen und womöglich noch mehrere Blogs betreuen. Unterm Strich wird ein Großteil der Blogs dann jedoch auf Dauer immer unsicherer, weil der Aufwand zu groß ist, in sicherem Rahmen alles aktuell zu halten. So ganz allmählich verstehe ich dann immer besser, warum manche bei irgendwelchen großen Anbietern mit vollständig vorgefertigten Paketen bleiben, auch wenn die Blogadresse nicht schön ist, die Möglichkeiten eingeschränkt und vieles nicht konfigurierbar. Denn manchen geht es womöglich in erster Linie ums Schreiben und nicht ums Aktualisieren ihrer Software... ;-)

WordPress Alternativen

Andererseits gibt es natürlich auch einige Alternativen. Es gibt ja mehr als eine Software, die Bloggen ermöglicht und zumindest die üblichen Funktionen ermöglicht. Schwierig ist dabei, dass ich kaum von jemand gehört oder gelesen habe, bei dem eine Migration von einer zur anderen Software problemlos funktioniert hat. Für mich würde das bedeuten mehrere Blogs umzuziehen, teils eigene, teils betreute Blogs, das ist bei mehr als einigen wenigen Beiträgen nicht ganz trivial und mal eben bei einem Kaffee erledigt. Im Moment habe ich für mich beschlossen, mir mal die 2.7 genauer anzusehen, inwieweit sich da manches so zeigt, wie ich das möchte. Im Moment habe ich beim ein oder anderen Blog auch noch Probleme, die so nicht bleiben können.
  • Dashboard nur über die Adresszeile erreichbar, weil der Link wohl nicht mehr stimmt
  • Blog in einem passwortgesicherten Bereich
    • keine Beiträge nach Termin möglich, zwar geht der Feed raus, nicht aber der Artikel selbst
    • kein automatisches Backup möglich (wäre noch kein Killerkriterium, da auf dem eigenen Server anders lösbar, aber trotzdem nervig)
  • Funktionen im Adminbereich sind langsam, weil mit zuviel Spielerei realisiert, die nicht abgestellt werden kann
  • Updatezyklus fürs Blog und die Plugins in den letzten Monaten unzumutbar, falls es so bleibt

Unterm Strich

Einerseits habe ich grad wenig Lust mich in ein anderes System einzuarbeiten, denn auch das kostet Zeit. Allerdings habe ich bei solchen Aktualisierungszyklen wie in der letzten Zeit soviel dafür aufgewendet, dass ich mich auch ebensogut in ein anderes System einarbeiten könnte. Andererseits bin ich nicht bereit mich regelmäßig über ein System zu ärgern. Ob CMS oder Blog oder beides finde ich nicht ganz so wichtig, ich denke die Nutzung geht immer häufiger in die Richtung, dass beides gefordert wird. Insofern ist im Grunde ganz praktisch, wenn die Systeme das auch berücksichtigen. Für mich ist es kein Kriterium, ob ich jetzt ein CMS vom Bloggen überzeugen möchte, oder eine Blogsoftware davon, dass sie als CMS funktioniert.

Was ich tun werde?

Schaun wir mal, wenn es noch ein bisschen so läuft, wie im Moment, werde ich zumindest mal noch was anderes ausprobieren, z.B. im internen Mitarbeiterblog. Läuft das dann gut, dann werde ich sicherlich nach und nach wechseln. Noch hat WordPress bei mir einen Stein im Brett, und sei es nur weil ich ein Gewohnheitstier bin...
tweetbackcheck