Responsives Design als Alternative zur separaten mobilen Website →

Vor einigen Tagen hatte ich mit einem Kollegen eine Diskussion, welche Vorgehensweise für die Darstellung einer Website auf mobilen Endgeräten die bessere ist: eine separate Website mit eigenem Content und eigenem Template oder nur eine Website mit einem Design, das sich dem Endgerät anpasst. Ich befürworte letzteres, also das responsive Design. Ich will hier gar nicht groß ins Detail gehen, sondern auf einen hervorragenden Artikel von Karen McGrane zu diesem Thema verweisen.

A separate mobile website: no forking way

Responsive design is often held up as a solution that saves you from having to maintain multiple separate codebases for your front-end code. Put the effort in to developing one set of code that will adapt to different screen sizes and progressively enhance for different device capabilities, and you’ll save time in the long run. You’ll also get out of the arms race of having to support dozens of different devices and form factors.

Link zum Artikel »

Tägliches WordPress Backup in die Cloud für 0,20 € im Monat

Dass der Speicherplatz in Amazons Simple Storage Service (Amazon S3) sehr günstig ist, dürfte bekannt sein. Ich habe es jetzt mal selbst getestet und einen Monat lang täglich ein Backup dieser Website (gepackt ca. 60 MB) mit dem WordPress-Plugin PressBackup in die Amazon-Wolke geschoben. Kosten: 0,26 $. Entspricht aktuell ca. 0,20 €.

Wer die Kosten für ein Backup seiner eigenen Website wissen möchte, findet hier eine gute Übersicht: Amazon S3 Preise. Ein Monatsrechner ist dort auch verlinkt.

WordPress-Artikel von Startseite und RSS-Feed ausschließen

Manchmal kann es erwünscht sein, dass Artikel einer bestimmten Kategorie nicht auf der Startseite und/oder im RSS-Feed eines WordPress-Blogs angezeigt werden. Diese Aufgabe kann man relativ einfach über eine zusätzliche Abfrage im Index-Template oder in der functions.php erreichen (siehe  z.B. Exclude Categories From Your Home Page oder Category Exclusion im WordPress Codex).

Wenn man es aber etwas komfortabler und flexibler haben möchte, greift man am Besten auf dieses Plugin zurück: Simple Exclude. Mit diesem Plugin kann man als Ausschlusskriterium nicht nur eine Kategorie wählen, sondern z.B. auch einen bestimmten Autor. Darüber hinaus kann man wählen, wo die betreffenden Artikel ausgeschlossen werden sollen: auf der Startseite, im RSS-Feed, in Archiven, in Widgets und in der Suche.

3 Anwendungsbeispiele:

  1. Für neue Instagram-Fotos sollen automatisch WordPress-Artikel erstellt werden. Der Übersichtlichkeit halber sollen diese aber nicht auf der Startseite des Blogs sondern nur auf einer Kategorie-Archivseite erscheinen. Wie “Instagram to WordPress” funktioniert, habe ich in diesem Artikel beschrieben und ein Beispiel für die von der Startseite ausgeschlossene Kategorie “Instagram” zeigt Uli auf ulinder.de.
  2. Über ein Formular können Besucher Inhalte einreichen (z.B. Bilder), die automatisch in Artikel umgewandelt und von einem Benutzer “Besucher” veröffentlicht werden. Diese Artikel sollen aber nicht auf der Startseite und nicht im RSS-Feed erscheinen, sondern nur auf einer Archivseite oder in einer Galerie. In diesem Fall müsste man nur den Benutzer “Besucher” ausschließen.
  3. Zu Archivierungs- oder Sicherungszwecken sollen alle Posts eines oder mehrerer sozialer Netzwerke (Twitter, Facebook etc.) über ifttt.com im eigenen WordPress-Blog als Artikel erfasst werden. Diese Artikel sollen natürlich nicht auf der Startseite oder im RSS-Feed erscheinen, da die meisten Netzwerk-Kontakte ja den Inhalt bereits im jeweiligen Netzwerk gelesen haben. Für diese Anwendung würde man für jedes Netzwerk eine Kategorie anlegen, diese Kategorien im jeweiligen ifttt-Rezept ansteuern und über das Simple Exclude Plugin von Startseite und Feed wieder ausschließen.

Der Kreativität sind eigentlich keine Grenzen gesetzt. Nutzt von euch jemand das Plugin? Gibt es noch weitere interessante Einsatzmöglichkeiten?

Diskussionsanregung: Kommentarsystem verwenden? →

Auf meinem Blog Kurz nach spät. habe ich ein paar Gedanken geäußert, ob ich hier auf matthiaspabst.de das Livefyre-Kommentarsystem verwenden werde und welche Konsequenzen die (nachträgliche) Aktivierung hätte. Ich habe die Frage bewusst auf “Kurz nach spät.” gestellt und nicht hier im Blog, weil ich dort besagtes Kommentarsystem bereits verwende.

Freue mich über konstruktives Feedback.

Link zum Artikel »

Jetpack 1.3 bringt Kontaktformular, Kommentarsystem soll folgen

Das Jetpack Plugin ist eine Sammlung von Features, die Automattic in seinen WordPress.com-Blogs anbietet. Den Unterschied zwischen einem Blog bei WordPress.com und einem selbstgehosteten WordPress.org-Blog hatte ich vor langer Zeit hier mal dargestellt.

Die neue Version des Jetpacks bringt neben Bugfixes für die Sharing-Funktion und die Youtube-Einbettungen auch eine neue Funktion: ein Kontaktformular. Das scheint im ersten Moment sehr erfreulich, da man jetzt auf ein zusätzliches Kontaktformular-Plugin wie ContactForm verzichten kann, wenn man das Jetpack ohnehin nutzt. Die erste Freude wird leider etwas getrübt, wenn man ins Detail geht. Zur Spam-Abwehr nutzt das Jetpack-Kontaktformular nämlich derzeit ausschließlich den hauseigenen Antispam-Dienst Akismet. Wer diesen aus datenschutzrechtlichen oder sonstigen Gründen nicht nutzt, hat leider das Nachsehen. Es lässt sich kein anderweitiges Captcha einbauen. Sehr Schade! Bin gespannt, ob es in der nächsten Version diesbezüglich eine Nachbesserung gibt.

Für die Zukunft kündigt Automattic neben Verbesserungen noch ein weiteres neues, von vielen Usern gewünschtes Feature an: das WordPress.com-Kommentarsystem. Mit diesem können Besucher der Website sich zum Kommentieren mit ihrem Profil bei WordPress.com, Twitter oder Facebook anmelden. Ich befürchte jedoch, dass auch das Kommentarsystem nur die hauseigene Spamabwehr Akismet unterstützen wird. Warten wir’s ab.

Wer aktuell nach einem guten Kommentarsystem sucht, dem kann ich Livefyre empfehlen. Es unterstützt diverse soziale Netzwerke und hat durch das Kommentieren in Echtzeit schon fast Chat-Charakter. Wer es in Aktion sehen will: ich nutze es zur Zeit auf meinem kleinen Neben-Blog Kurz nach spät.

Nutzt ihr das Jetpack? Wenn ja, welche Features nutzt ihr?

Mit der Alfred App im WordPress Codex suchen

Ich mag Alfred. Er ist einer meiner fleißigsten Helferlein auf dem Mac. Und bei meiner Arbeit mit WordPress durchsuche ich oft den WordPress Codex. Nichts liegt also näher, als Alfred die Suche zu übertragen. Möchte ich nach einem bestimmten Begriff suchen, rufe ich mit alt+space das Eingabefeld von Alfred auf (Hotkey frei wählbar) und gebe dann “wp”, ein Leerzeichen und den zu suchenden Begriff (z.B. “exclude”) ein.

Weiterlesen

Meine TOP 10 E-Mail-Fehler

Vor einiger Zeit bin ich auf den Artikel Mails mir! – 77 Tipps für bessere E‑Mails aufmerksam geworden. Viele der 77 Tipps kenne ich bereits und versuche sie auch täglich zu beherzigen. E-Mail ist für mich das wichtigste Kommunikationsmedium im Job, gefolgt von Twitter, Chat und Telefon. Von meinen Gesprächspartnern erwarte ich deshalb auch, dass sie sich an die üblichen Gepflogenheiten bei der Kommunikation per E-Mail halten. Ich muss zugeben, dass ich bei diesem Thema ziemlich empfindlich, wenn nicht sogar pingelig bin. Nachfolgend meine TOP 10 der absoluten No-Go’s inkl. Begründung.

  1. Leerer oder nichts sagender Betreff: Ziemlich unpraktisch für die laufende Kommunikation und vor allem für die spätere Suche.
  2. Mehrere Themen in einer E-Mail: Bei längeren Kommunikationen geht meist mindestens ein Thema verloren und die Nachverfolgung der einzelnen Themen gestaltet sich äußerst schwierig. Besser für jedes Thema eine eigene Mail.
  3. Gruppen-E-Mails bzw. Nicht-Nutzung von An, CC, BCC: Niemand fühlt sich angesprochen und verantwortlich. Und die Spambots bedanken sich auch, wenn sie wieder ein paar Adressen mehr auf der Liste haben.
  4. Antworten “an alle”, die mich nicht betreffen: Wenn ich nicht gerade der Projektleiter bin, muss ich nicht jedes Detail wissen, das andere Projektteilnehmer diskutieren.
  5. Anhänge größer 5 MB: Wofür gibt’s Dropbox & Co?
  6. Zu lange Signaturen (mehr als 5 Zeilen), Signaturen mit Bildern (Logos) und Signaturen in allen Antworten: Wie soll man da noch den relevanten Inhalt finden?
  7. Facebook-Mail: Darf man das überhaupt “E-Mail” nennen? Ist für professionelle Kommunikation für mich jedenfalls völlig untauglich.
  8. Chats: E-Mail ist kein Chat-Programm. Twitter übrigens auch nicht.
  9. Schrift oder Hintergrund farbig: Die beste Lesbarkeit bietet immer noch Schwarz auf Weiß.
  10. Comic Sans: ohne Worte.

Wer sich jetzt ein klein wenig angesprochen fühlt, dem kann ich nur nochmals diesen Artikel empfehlen: Mails mir! – 77 Tipps für bessere E-Mails. ;)

Mein liebster E-Mail-Client ist übrigens das Webfrontend von Gmail mit sortiertem Posteingang. Was Besseres gibt es derzeit nicht.

Und was bringt euch in Sachen E-Mail auf die Palme?

(via t3n.de)

WordPress 3.4 Beta 1

Heute wurde die erste Beta-Version von WordPress 3.4 veröffentlicht. Wie immer ist diese Beta-Version nicht für den produktiven Einsatz geeignet, da sie noch Bugs enthalten kann. Die finale Version von WordPress 3.4 soll im Mai erscheinen. Bugs in der Beta-Version können wie immer hier gemeldet werden.

Die offizielle Release-Meldung findet ihr hier:
WordPress 3.4 Beta 1

Neue Features

  • Theme Customizer mit Vorschau im Frontend
  • Flexible Größe für Kopfzeilenbild
  • Kopfzeilenbild kann aus der Mediathek ausgewählt werden
  • Bessere Suche für Themes
  • HTML-Support für Captions

Den Theme Customizer zeigt Perun in einem kleinen Video. Ein neues Theme “Twenty Twelve” wird es erst in WordPress 3.5 geben. Wer den aktuellen Stand des Themes testen will, kann es sich aber bereits jetzt bei GitHub herunterladen.

Unter der Haube

  • Neue XML-RPC API für externe und mobile Anwendungen
  • Neue Theme-API für Kopfzeilenbilder und Hintergrundbilder
  • Bessere Performance für WP_Query
  • Bessere Internationalisierung
  • Child Themes können vom WordPress Theme Directory installiert werden

Wer sich für die Entwicklung von WordPress interessiert, kann ja mal in meinem kleinen WordPress-Museum stöbern. WordPress 3.4 werde ich natürlich ergänzen, sobald die finale Version erscheint.

Mobile Safari auf neuem iPad verkleinert für Retina Display optimierte Bilder

safari

Dass das neue iPad ein Retina Display hat, welches mit einer Auflösung von 2048 x 1536 Pixeln daher kommt, ist ja nun nichts Neues mehr. Für Websitebetreiber bedeutet dies, dass sie eigentlich alle Grafiken und Bilder nun doppelt so groß auf ihre Websites laden müssen, wenn sie auf dem neuen iPad genauso groß und schön wie auf dem alten iPad und ohne qualitätsmindernde Skalierung dargestellt werden sollen. Davon will ich an dieser Stelle aber erst einmal abraten, da man sich hier zunächst mal Gedanken machen muss, ob die größeren Bilder die damit einher gehenden längeren Ladezeiten und den höheren Traffic für mobile User rechtfertigen. Interessante Ansätze, ob und wie Websites nun unterschiedliche Bildversionen ausliefern sollen, findet ihr in einem Artikel von Jasons Grigsby.

Mir ist jedoch in diesem Zusammenhang etwas anderes aufgefallen. Beim Testen der Darstellung von Bildern auf dem neuen iPad bin ich über das Problem gestolpert, dass die iOS-Version des Safari-Browsers Bilder ab einer bestimmten Größe verkleinert und dann wieder hoch skaliert und damit die Bildqualität natürlich dramatisch verschlechtert. Über einen Artikel von Duncan Davidson bin ich auf den Abschnitt iOS Resource Limits in der Safari Developer Library aufmerksam geworden, in dem Apple unter anderem beschreibt, dass JPEGs ab einer Größe von 2 Megapixel aus Resourcengründen herunter gerechnet werden.

Weiterlesen