Skip to content

Windows Vista ::: Bild hochladen per FTP

Es gibt Tage, da wünscht' ich, ich wär' mein Hund... oder so ähnlich...
  • nur halbe Bilder werden hochgeladenBildhochladeversuche abgeschnittene Bilder
Eigentlich wollte ich nur ein Bild hier im Blog hochladen. Das Problem war:
  • ich war in Palästina
  • das WLAN ließ auf meinem Rechner mit den aktuellen Einstellungen nicht für Linux konfigurieren (wird dringend geändert)
  • deshalb musste ich Windows Vista für Internetverbindungen nehmen
  • hier im Blog lade ich sonst nicht über den Editor hoch, deshalb ging das wegen fehlender Rechte nicht
  • FTP wäre nett, es kostete mich 17 Versuche, bis ich aus dem Gedächtnis die Zugangsdaten gekramt hatte (unter Linux habe ich sie gespeichert, ich brauche sie sonst also selten)
  • Rechte ändern per FTP klappte nicht
  • also wollte ich per FTP dahin hochladen, wo ich sonst Bilder habe, da stimmen die Rechte ja bereits
  • vor einigen Monaten hatte ich sowas schon mal, deshalb wusste ich, dass FTP über die DOS-Eingabeaufforderung möglich ist
  • wie immer, fand ich die erst einmal nicht... /Start/Alle Programme/Zubehör/Eingabeaufforderung öffnet ein DOS-Fenster
  • für FTP sollten es keine Backslashes sein, also wollte ich direkt in das passende Verzeichnis wechseln, aus dem ich kopieren könnte
  • natürlich kenne ich die DOS-Befehle nicht so richtig und musste also wieder suchen
    • Verzeichnisinhalt ist nicht ls sondern dir
    • cd geht dann, um Verzeichnisse zu wechseln...
    • dir, weil mein spezieller Freund das Vista selbstverständlich intern die Ordner anders nennt, als im Explorer angezeigt, statt Bilder musste ich Pictures eingeben
  • zwischendurch hatte die Datei mal an der falschen Stelle, klar, dass es bei FTP kein mv gibt sondern nur rename, darauf kam ich auch nicht von selbst...
  • nach einigem Gefluche - beim ständigen Wechsel von FTP-Kommandos und DOS-Befehlen wird es ja nicht besser... - hatte ich die Datei oben, nur angezeigt wurde sie nicht
  • nach den Rechten schauen, ist der Standardfall für Fehler, aber da passte alles
  • gut, vielleicht der falsche Modus, statt ascii, wäre binary nicht schlecht, wieder Suchmaschine, wieder fragen: binary eingeben genügt, dann stellt er um
  • jetzt nochmal mit put hochladen, diesmal unter einem anderen Namen, nun, erstmal stürzte jetzt die Eingabeaufforderung ab
  • also nochmal, erst den richtigen Pfad, dann per FTP mit binary, wieder keine Reaktion mehr...
  • dieses Mal, habe ich erstmal abgewartet...
  • huch, es bewegt sich was, da war immerhin der Anfang eines Bilds, ich hatte die Hoffnung es habe geklappt, nur sei es halt ein bisschen langsam, wie die Verbindung hier immer mal wieder
  • doch auch nach einigen Minuten war da nicht mehr, laut Grafikinformation der Web-Developer-Toolbar hatte das Bild auch gerade mal 18 kB von den 44 kB, die es hätte haben sollen
  • noch ein Versuch...
  • zwischendurch hatte ich mal noch die Idee, WordPress halt ein anderes Verzeichnis für den Upload beizubringen, aber das hatte denselben Effekt...
    • Trotz des Browseruploads schien da gar nichts zu klappen.
    • Genaueres Hinschauen zeigte mir auch, dass es da sehr wohl schon einmal ein Bild hierüber gab und dass es da wohl geklappt hatte... Nun, dieses Mal jedoch nicht...
  • auch nach einigen Minuten waren da wieder nur die 18 kB und nur gut ein Drittel des Bildes sichtbar
  • klar, habe ich auch mal kurz noch den IE aufgemacht, um auszuschließen, dass ich ein Cache-Problem mit dem Firefox habe, aber auch da derselbe Effekt, ein noch nicht einmal halbes Bild... :-(
  • beim nächsten Versuch kam ich noch nicht einmal mehr auf 18 kB, sondern nur noch auf 1 kB auch nach einigen Minuten...
  • ich gab erstmal auf. Irgendwann dachte ich, ich bin einfach ungeeignet, um mit Windows umzugehen. Jetzt hatte ich also zwei Teilbilder...
  • Klar, so stehen lassen wollte ich das natürlich auch nicht, deshalb machte ich am nächsten Tag einen erneuten Versuch:
und siehe da! Auf Anhieb, ohne irgendein Problem, klappte es das Bild hochzuladen, es war einfach da und vollständig. :-) Ich weiß es nicht genau, was da am ersten Abend schief ging. Ich vermute, es war eine relativ langsame Verbindung, die auf dem Server jeweils zu einem Time-Out führte. Passiert ist mir das so bisher noch nie. Tja, mal wieder was dazu gelernt... ;-)

Zoom im Browser ::: Textzoom ::: Seitenzoom ::: Bilder

Dieses Mal mit deutlicher Verspätung, sonst gibt's ja neue Artikel um kurz nach Mitternacht... Gestern reichte es einfach nicht mehr und heute vormittag gab's hier kein Netz. Heute abend wollte ich eigentlich erst noch ein Bild hochladen, bevor ich diesen Artikel veröffentlichte, ich habe irgendwann aufgegeben... Dazu ein anderes Mal mehr, hier ist es bereits eine Stunde später (2:14 Uhr) und morgen früh wollen wir ans Tote Meer... Inzwischen gibt es ja bereits einige Monate den Firefox mit Seitenzoomfunktion, nicht nur mit dem Textzoom. Der Internet Explorer 7 hat diese ursprünglich zuerst bei Opera angebotene Funktion ja ebenfalls, allerdings in einer Form, die völlig unsinnig gelöst wurde.

Wozu überhaupt Seitenzoom?

Nun, den Textzoom gibt es ja schon lange, selbst im Internet Explorer 6, lässt sich die Schrift zweimal vergrößern, falls die Angaben zur Schriftgröße in Pixeln angegeben wurden. Die anderen Browser vergrößern schon lange unabhängig davon in welcher Einheit die Schriftgröße angegeben wurde. Auch gibt es keine Beschränkung des Zooms, falls das Layout es zulässt kann unbegrenzt der Text vergrößert werden.

Ist Seitenzoom dann nicht überflüssig?

Das kommt drauf an. Je nach Layout vergrößert sich mittels Textzoom ja tatsächlich ausschließlich der Text, eine, z.B. auf - 800 Pixel Breite beschränkte - Seite kann somit nicht breiter als eben diese 800 Pixel werden. Das heißt, selbst wenn auf dem Bildschirm genug Platz wäre, um mittels Textzoom vielfach zu vergrößern, so klappt es häufig nicht, weil der vergrößerte Text keinen Platz mehr hat. Siehe auch die Unterschiede zu festem und flexiblem Layout. Andererseits lassen sich flexible Layouts entwerfen, bei denen die Angaben für die Breite, in Abhängigkeit der genutzen Schriftgröße, gemacht werden. In diesem Fall lässt sich eine Seite bei höherer Auflösung auch entsprechend vergrößern. Wäre die Grundbreite bei etwa 800 Pixel, aber in 'em' angegeben, dann ließe sich bei einer Auflösung von 1600 die doppelte Breite nutzen, die Schrift könnte also extrem vergrößert werden und noch immer müsste nicht gescrollt werden.

Warum entwerfen also nichthref="http://miradlo.net/bloggt/index.php?136-s"">festem und flexiblem Layout. Andererseits lassen sich flexible Layouts entwerfen, bei denen die Angaben für die Breite, in Abhängigkeit der genutzen Schriftgröße, gemacht werden. In diesem Fall lässt sich eine Seite bei höherer Auflösung auch entsprechend vergrößern. Wäre die Grundbreite bei etwa 800 Pixel, aber in 'em' angegeben, dann ließe sich bei einer Auflösung von 1600 die doppelte Breite nutzen, die Schrift könnte also extrem vergrößert werden und noch immer müsste nicht gescrollt werden.

Warum entwerfen also nicht alle solche flexiblen Layouts?

Es wäre doch perfekt grundsätzlich flexible Layouts anzubieten, damit alle Besucher genau das einstellen können, was für sie am besten passt. Warum tun das also nicht alle Webautoren? Der Hauptgrund ist, dass damit die pixelgenaue Kontrolle verloren geht. In einem festen Layout mit fixer Breite können Webautoren beispielsweise Hintergrundbilder nutzen, die auf den Pixel genau zueinander ausgerichtet werden. Insbesondere Grafikdesigner, die sich auch mit Druckerzeugnissen befassen, wollen häufig auch bei Webseiten ein absolut exaktes 'Bild' erhalten. Entworfen wird daher meist ein Bild, so als wäre es für ein Plakat oder eine Broschüre. Das Problem ist jedoch, dass Webseiten keine Druckerzeugnisse sind. Im Druck weiß man ganz genau welche Größe das Endprodukt haben wird, der Entwurf wird genau dafür optimiert. Das Web ist jedoch kein Druck und hier gibt es unzählige Variationen Für den Designer ärgerlich, für die Besucher von der Idee her traumhaft, kann ich im Web, an meinem Rechner aussuchen, was für mich persönlich am besten ist. Die einen haben zwar einen großen Monitor, aber eine niedrige Auflösung, andere nutzen einen kleineren Bildschirm, z.B. am Laptop mit einer höheren Auflösung. Mancher kann auch sehr kleine Schriften noch gut lesen, andere wollen am eigenen Rechner nicht mit der Lupe arbeiten und stellen sich ihre Schriftgrößen deshalb mehrfach vergrößert ein.

Flexibilität von Webseiten

Grundsätzlich schätze ich die Flexibilität, die Webseiten bieten, die Möglichkeit eine Seite eben je nach Wünschen und Voraussetzungen des Lesers anzuzeigen.

Bilder skalierbar einbinden

Für diejenigen, die sich alles vergrößert anzeigen lassen, wären daher höher aufgelöste Bilder ein Vorteil. Leider hat das jedoch auch Nachteile:
  • übertragene Datenmenge
  • Ladezeit
Die übertragene Datenmenge wäre bei hochauflösenden Bildern, dann ja auch für diejenigen größer, die die Bilder in kleinerem Format betrachten. Da sich häufig gerade die, die eine schlechtere Verbindung haben, nicht aussuchen können, ob sie eine bessere und schnellere Verbindung möchten, mag ich schon das nicht. Die Ladezeit ist das nächste Problem. Sie vergrößert sich logischerweise schon mit der größeren Datenmenge. Hinzu kommt noch, dass ich den Bildern, um sie skalierbar zu halten auch nicht die Größenangaben mitgeben kann, sonst skaliert da nichts. So schön die Idee also einerseits ist, so schwierig finde ich die Entscheidung. Bei Websites mit sehr wichtigen Bildern, beispielsweise bei der Seite einer Malerin war der Kompromiss jetzt Galerien einzubauen, die Vorschaubilder aus den eingebundenen Bildern zeigen. Diese Bilder sind noch immer stark fürs Web optimiert. Es gibt jedoch eine zusätzliche Galerie, die Bilder in recht hoher Auflösung anbietet, aber erst wenn sich jemand auch dafür entscheidet. Diese Lösung gefällt mir ganz gut, denn so werden die mit sehr langsamer oder schlechter Verbindung nicht zu hochauflösenden Bildern gezwungen. Diejenigen, die jedoch interessiert sind und genau schauen wollen, die haben die Möglichkeit, das zu tun.

Skalierbare Hintergrundbilder

Je nach Größe eines Hintergrundbilds besteht für mich dasselbe Problem, wie bei im Quellcode eingebundenen Bildern. Klar, manches Hintergrundbild wäre auch in skalierbarer Version klein genug, um das Problem zu umgehen. Im Moment bevorzuge ich Layouts mit sich wiederholenden Hintergrundbildern auch im Kopfbereich, z.B. henss.eu damit muss das Hintergrundbild nicht skalierbar sein, um trotzdem mit verschiedenen Auflösungen noch gut zurechtzukommen. Beides sind trotzdem natürlich rein dekorative Bilder, bei denen es nicht so wichtig ist, ob sie in optimaler Qualität sichtbar sind, mit zweifacher Zoomstufe im Firefox sah es bei meinen Tests auch noch ganz gut aus. Was ich nicht mag, sind feste Layouts, optimiert, z.B. auf 800*600, bei denen ich dann mit meiner Auflösung einen zu zweidrittel leeren Bildschirm habe.

Unterm Strich

Die Möglichkeit Hintergrundbilder zu nutzen, statt Bilder in den Quelltext einzubinden finde ich gut. Denn, ich finde es klasse, dass sich inzwischen die rein dekorativen und nur fürs Layout nötigen Bilder, im Hintergrund einbinden lassen und eben nicht im Quellcode.

Das bietet ja mehrere Vorteile:

  • die Ladezeit ist geringer, weil - zumindest die meisten - Browser ein Layoutbild dann auch mehrfach nutzen
  • bei geschicktem Einsatz, lässt sich oft sogar ein und dasselbe Bild für mehrere Bereiche des Layouts nutzen, weil es passend verschoben wird
  • aufs Laden von Hintergrundbildern kann bei langsamen Verbindungen verzichtet werden
Deshalb meine ich, auf Dauer muss es da noch bessere Wege geben, und wie auch Dieter in seinem Kommentar schon schrieb, die Möglichkeit auch Hintergrundbilder zu skalieren, sollte geschaffen werden. Denn sonst führt es irgendwann wieder zu Murks. So wie Tabellen für Layouts genutzt wurden, weil es nichts anderes gab, werden sonst womöglich irgendwann wieder Bilder in den Quelltext eingebunden, um sie skalierbar anbieten zu können. Das halte ich jedoch, aus den genannten Gründen, für eine schlechte Lösung.href="http://miradlo.net/bloggt/index.php?46-s"">Dieter in seinem Kommentar schon schrieb, die Möglichkeit auch Hintergrundbilder zu skalieren, sollte geschaffen werden. Denn sonst führt es irgendwann wieder zu Murks. So wie Tabellen für Layouts genutzt wurden, weil es nichts anderes gab, werden sonst womöglich irgendwann wieder Bilder in den Quelltext eingebunden, um sie skalierbar anbieten zu können. Das halte ich jedoch, aus den genannten Gründen, für eine schlechte Lösung.

...auf dem Weg nach Palästina

Auf uteles Blog bin ich näher darauf eingegangen... Relativ spontan, mit nur einer Woche Vorlauf habe ich mich entschieden nach Palästina zu fliegen. In Anbetracht der Reisevorbereitungen, diverser Projekte und unserer Baustelle, wurde mein Zeitplan ein bisschen sehr eng.
  • Jerusalem bei NachtUte vorm Damaskustor in Jerusalem
Ich habe zwar den ein oder anderen Artikel vorbereitet, aber keiner ist ganz fertig. Deshalb, sorry an die Stammleser, dieses Mal nur diese Kurzmeldung. Heiligabend bin ich wieder zurück, spätestens dann gibt's wieder den gewohnten Rhythmus. Falls ich in Palästina dazu komme, vielleicht auch schon eher. Antworten auf Kommentare können daher im Moment auch etwas dauern...

Aktualisiert von Palästina aus

Bis ich das Bild drin hatte, war eine längere Geschichte, deshalb dazu demnächst ein eigener Beitrag. Hier nur mal als Zwischenmeldung ein Bild, in diesem Fall nicht aus Palästina, sondern aus Israel. Selbst mit dem Bus, dem Checkpoint und Wartezeiten dauert die Fahrt kaum mehr als eine Stunde nach Jerusalem, da bot sich der Ausflug dorthin natürlich an.

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

...Webseiten ::: Webapplikationen ::: miradlo

Häufig arbeiten wir an Projekten, die kaum öffentlich sichtbare Bereiche haben. Unsere Webapplikationen arbeiten meist im Hintergrund. Hier schreibe ich deshalb auch kaum mal über Projekte. Wer von euch hier öfter mitliest, weiß bereits, dass miradlo Informatikdienstleistungen, ein kleines Unternehmen in Konstanz ist. Wir, das sind bei miradlo zur Zeit fünf Menschen, hier im Blog lest ihr entweder von mir oder von Roland. Ab und zu machen wir jedoch auch mal sichtbares, seien es Webauftritte, oder Webapplikationen, die man ausprobieren kann, wie unsere
  • Demoversion einer Terminverwaltung für Mietervereine auf www.miradlo.biz.
Wer also mal schauen oder was ausprobieren mag...

RPM auf Gentoo oder anderen nicht-RPM basierten Distributionen nutzen

Mal so kurz am Rande... Vor einiger Zeit wollte ich für Scribus die AdobeColorProfiles einsetzen. Das Problem war, dass es die Dinger nur als RPM (Red Hat Package Manager) gab. Gentoo ist keine RPM-basierte Distribution, ein RPM lässt sich nicht installieren und hilft mir zunächst einmal nicht. Aber das lässt sich ja ändern (übrigens tacita heißt mein Rechner):

Schritt für Schritt ein RPM für nicht-RPM-basierte Distribution umwandeln

Hilfe zu rpm2targz:
  • ute@tacita ~ rpm2targz -h
  • rpm2targz: Converts RPM archives to tar archives
  • Usage: rpm2targz [options] <rpms>
  • Options:
  • -h, --help This help screen (imagine that)
  • -O, --stdout Write tarball to stdout
  • -v, --verbose Verbose output
mittels rpm2targz umwandeln:
  • ute@tacita ~/uhDownloads/AdobeColorProfiles-end-user.rpm $ rpm2targz adobe-color-profiles-1.0-1.noarch.rpm
ergibt ein ein .tar.gz
  • ute@tacita ~/uhDownloads/AdobeColorProfiles-end-user.rpm $ ls -l
  • insgesamt 7611
  • -rw-r--r-- 1 ute ute 3881452 3. Nov 2005 adobe-color-profiles-1.0-1.noarch.rpm
  • -rw-r--r-- 1 ute ute 3902247 12. Nov 22:17 adobe-color-profiles-1.0-1.noarch.tar.gz
*.tar.gz entpacken
  • ute@tacita ~/uhDownloads/AdobeColorProfiles-end-user.rpm $ tar -xzvf adobe-color-profiles-1.0-1.noarch.tar.gz
ergibt ein Verzeichnis welches weder .tar noch *.rpm ist
  • ute@tacita ~/uhDownloads/AdobeColorProfiles-end-user.rpm $ ls -l
  • insgesamt 7611
  • drwxr-xr-x 3 ute ute 72 12. Nov 22:17 adobe-color-profiles-1.0-1.noarch
  • -rw-r--r-- 1 ute ute 3881452 3. Nov 2005 adobe-color-profiles-1.0-1.noarch.rpm
  • -rw-r--r-- 1 ute ute 3902247 12. Nov 22:17 adobe-color-profiles-1.0-1.noarch.tar.gz
in das Verzeichnis wechseln und mal sehen, was da so liegt:
  • ute@tacita ~/uhDownloads/AdobeColorProfiles-end-user.rpm $ cd adobe-color-profiles-1.0-1.noarch
  • ute@tacita ~/uhDownloads/AdobeColorProfiles-end-user.rpm/adobe-color-profiles-1.0-1.noarch $ ls -l
  • insgesamt 0
  • drwxr-xr-x 3 ute ute 72 12. Nov 22:17 usr
  • ute@tacita ~/uhDownloads/AdobeColorProfiles-end-user.rpm/adobe-color-profiles-1.0-1.noarch $
In diesem Fall lag einfach die passende Verzeichnisstruktur um die Profile abzulegen /usr/share//color/icc/Adobe ICC Profiles, die an die passende Stelle legen und das war's auch schon. :-) Der Weg an sich ist natürlich auch in anderen Fällen nutzbar.

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...

...Advent, Advent... auch bei den Webstandards

  • Adventskalender der Webkrauts
Prima, wie schon in den vergangenen Jahren wird es bei den Webkrauts wieder den Adventskalender geben. Heute geht's los! Für diejenigen, die den Adventskalender noch nicht kennen, noch die Hinweise zu den Adventskalendern der Vorjahre: Ähnlich wie bei den Sonnenseiten im Sommer wird täglich ein Artikel von einem der Mitglieder der Webkrauts veröffentlicht. Über manchen Artikel habe ich ja bereits geschrieben, beispielsweise zum Thema Progressive Enhancement, welches bei den Sonnenseiten angesprochen wurde. Nicolai Schwarz schreibt dazu unter anderem:
"Ab dem kommenden Montag geht es dieses Mal rund um Best Practice in allen Webbereichen. Wir schreiben über Performance, JavaScript, Suchfunktionen, Barrierefreiheit, nützliche Tools, den Umgang mit Kunden, Navigationen oder auch Suchmaschinenoptimierung, um nur ein paar Themen zu nennen."
Ich freue mich bereits auf die Serie, mir gefällt es gut, wenn es über einen begrenzten täglich einen Artikel gibt. Die Zeit nehme ich mir dann meist, diese Serie jeweils sofort zu lesen.
tweetbackcheck