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.

Artikel auf matthiaspabst.de lesen →

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.

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?

Freue mich über konstruktives Feedback.

Artikel auf matthiaspabst.de lesen →

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?

Nach der Eingabe bekomme ich dann alle Ergebnisse der Suche auf wordpress.org angezeigt, und zwar nur die Ergebnisse im Codex und nicht der gesamten WordPress.org-Website. Dies erreicht man mit der Suche mittels “inurl”.

Und so funktioniert’s:

In der Alfred-App im Bereich “Features” die “Custom Searches” aufrufen.

Einen neuen Eintrag erstellen mit dem Keyword “wp” und folgender Search-URL:

http://wordpress.org/search/inurl%3Ahttp%3A%2F%2Fcodex.wordpress.org%2F%20{query}

Speichern. Fertig!

Wer möchte, kann auch noch Titel und Logo nach eigenem Geschmack anpassen. Hilfe zu den “Custom Searches” findest du hier auf der Alfred-Website.

Und was sind eure liebsten Hotkeys?

Artikel auf matthiaspabst.de lesen →

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)

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.

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.

Als Test habe ich mal ein 2048×1365 Pixel großes Bild (100% Breite des Retina-Displays) mit dem Safari auf dem iPad angeschaut. Dieses Bild hat also ca. 2,8 Megapixel und wird somit vom Safari herunter gerechnet und sieht dementsprechend grauenvoll aus. Der folgende Ausschnitt aus dem iPad-Screenshot zeigt links das reduzierte Bild und rechts das Bild, wie es eigentlich aussehen sollte. Man beachte die Stufen in den Oberleitungen und die allgemeine Unschärfe auf dem linken Bild (Klick macht groß).

Wer sich das Ganze direkt auf seinem neuen iPad anschauen möchte, kann das gerne auf dieser Testseite tun. Achtung, sind ca. 9 MB! Folgende Bilder sind zu sehen:

1. Ein ganz normales JPEG, aus Lightroom exportiert. Maße 2048 x 1365 Pixel (resultieren aus 2:3 Format der DSLR). Hier sieht man die Qualitätsminderung deutlich! Vor allem in den Oberleitungen.
2. Ein JPEG, das ich aus Lightroom mit der Option “In Bildschirm einpassen” –> “2,0 Megapixel” exportiert habe. Dieses hat nun natürlich nur noch 1731 x 1154 Pixel und füllt das iPad-Display im Landscape-Modus nicht mehr ganz aus. Dafür ist die Bildqualität aber Retina-like und wirklich beeindruckend. Keine Stufen in den Oberleitungen und alles superscharf.
3. Wie Nr. 2, nur im Format 1:1. Will man unter den geforderten 2 Megapixel bleiben, kann man immerhin 1414 x 1414 Pixel bei bester Qualität darstellen.
4. Wieder ein JPEG mit 2048 x 1365 Pixel, wie unter Nr. 1. Dieses Mal aber nachträglich noch in Photoshop mit der Option “progressive” gespeichert. Diese Art der Speicherung lässt offenbar zu, die ganze Größe des Retina-Displays zu nutzen und keine Qualitätseinbußen zu riskieren, obwohl die 2-Megapixel-Grenze überschritten wird. Warum diese JPEGs größer sein dürfen, ist nicht ganz klar. Weitere Quellen hierzu findet ihr im bereits oben genannten Artikel von Duncan.
   Leider kann Lightroom Bilder nicht direkt so speichern und es ist immer der Umweg über Photoshop nötig.

Noch mal der Hinweis: der Unterschied ist nur auf dem neuen iPad zu sehen! Und damit wir hier nicht Äpfel mit Birnen vergleichen, sind die JPEGs auch nicht komprimiert.

Fazit: Mir scheint das Ganze noch nicht so richtig ausgereift und im Moment weiß ich noch nicht, wie ich zukünftig die Anzeige von Fotos auf (WordPress-)Websites gestalten werde. Auf der einen Seite will ich Fotos und auch Grafiken natürlich in möglichst guter Qualität und möglichst groß anbieten. Auf der anderen Seite soll die Website aber auch noch gut bedienbar sein und nicht an geringen mobilen Bandbreiten scheitern. Wenn mal ein Großteil aller Displays (also Desktops, Notebooks, Tablets usw.) so hochauflösende Displays haben wie das iPad, sieht die Welt sicher schon wieder anders aus. Bis dahin dürfte dann auch die mobile Bandbreite oder Volumengrenzen für Traffic keine Rolle mehr spielen.

Eine Tatsache, die man übrigens auch nicht außer Acht lassen sollte ist, dass man Retina-optimierte Fotos mit 2048×1536 Pixel schon einigermaßen gut drucken kann. Nur so als kleinen Warnhinweis zum Thema Bilderklau.