hasematzel.de http://hasematzel.de/blog webstandards, entwicklung, internet, kultur Thu, 24 Jun 2010 07:00:20 +0000 en hourly 1 http://wordpress.org/?v=3.0 51.1317347.211865 Ansprechbare Buttons mit visueller Reaktion und CSS3 http://feedproxy.google.com/~r/hasematzel/~3/TUkp9Qp24O0/ http://hasematzel.de/blog/2010/06/24/ansprechbare-buttons-mit-visueller-reaktion-css3/#comments Thu, 24 Jun 2010 07:00:20 +0000 Oliver http://hasematzel.de/blog/?p=875 Die HTML5- und CSS3-Unterstützung in den aktuellen Browsern und Surfclients dieser Welt ist sicherlich noch mangelhaft. Manchmal darf man jedoch Applikationen entwickeln, bei denen es auf eine flächendeckende Unterstützung nicht so sehr ankommt. Das gilt z. B. für manche Intranets oder Applikationen mit beschränkten Zugangsberechtigungen.

Ich habe in der letzten Zeit einige, sogenannte Backoffices gebaut (Messeclients etc.) und es hat mir enorm viel Spass gemacht, dabei neuere Elemente und CSS-Angaben verwenden zu können, weil ich mir über die korrekte Darstellung sicher sein konnte.

Wenn man z. B. Desktop-ähnliche Webapplikationen für Prism entwickelt, darf man auf den vollen Schwung von Properties zugreifen, die derzeit vom Mozilla-Projekt unterstützt werden. (Naja, zumindest fast)

Mit wenigen Zeilen CSS hat man so schnell einen feinen, ansprechenden Button gebastelt, der bei Interaktion mit der Maus brav ein reaktives Verhalten zeigt. Hier erstmal das HTML:

<!DOCTYPE html PUBLIC
    "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
        <title>XHTML 1.0 Transitional</title>
</head>
<body>
<div id="wrapper">
    <form>
            <button type="submit" class="save">Save</button>
            <button type="submit" class="cancel">Cancel</button>
    </form>
</div>
</body>
</html>

Das Formular ist nicht funktional und dient nur der Demonstration. Kommen wir lieber zum CSS. Zunächst geben wir dem #wrapper einen Hintergrund:

#wrapper {
    width: 400px;
    height: 200px;
    background-color: #ddd;
    padding: 50px;
}

Dann geben wir den Buttons mit ein wenig CSS3 ein bisschen Schick:

button {
    background-color: #ddd;
    background-image: -moz-linear-gradient(bottom center, #ccc, #ddd);
    border: 1px solid #999;
    border-top-color: #eee;
    border-left-color: #eee;
    color: #333;
    font-weight: bold;
    text-shadow: 1px 1px 1px #fff;
    padding: 3px 8px;
    cursor: pointer;
    -moz-border-radius: 5px;
    -moz-box-shadow: 2px 2px 3px #ccc;
}

Das erste Resultat sieht dann so aus:

Über das cursor: pointer lässt sich bekanntlich streiten. Ich mag es, weil es ein visueller Indikator dafür ist, dass hier eine Aktion erfolgen kann.

Visuelle Reaktion

Als nächste beschäftigen wir uns mit der visuellen Rückmeldung der Buttons, den verschieden states beim Überfahren und beim Klick. Zunächst die Pseudoklassen :hover und :focus. Der Abbrechen-Button erhält dabei ein eigenes Benehmen, die Schriftfarbe soll sich beim :hover ändern.

button:hover, button:focus {
    -moz-box-shadow: 2px 2px 3px #aaa;
}
button.cancel:hover, button.cancel:focus {
    color: #f60; /* Fast orange */
}

Der :hover-Status hebt den Button visuell an (über die shadow-Property):


Der Save-Button wird hervorgehoben.


Der Cancel-Button erhält noch einen Farbwechsel.

Der tatsächliche Klick nutzt dann die :active-Pseudoklasse, um die Aktion farblich zu unterstreichen. Der Save-Button bekommt eine grüne, der Cancel-Button eine rote Schrift:

button.save:active {
    color: green;
}
button.cancel:active {
    color: #c00;
}


Der :active-State für Save.


Der :active-State für Cancel.

Fertig! Wir haben keine Grafiken verwendet, die einen weiteren HTTP-Request notwendig machen würden. Findige Webdesigner können sicherlich die paar Zeilen für die Webkit-und anderen Browser-Abkömmlinge hinzufügen. Mit ein bisschen Bastelei hat man die Buttons sicherlich auch in älteren Browsern, die ggf. noch unterstützt werden müssen, ergänzt. Obwohl das reaktive Verhalten der Buttons für Menschen mit Wahrnehmungsschwächen nicht optimal ist, kann diese Lösung eingebaut werden. Ohne CSS und state-changes hat man immer noch zwei klassische Buttons.

]]> http://hasematzel.de/blog/2010/06/24/ansprechbare-buttons-mit-visueller-reaktion-css3/feed/ 0 http://hasematzel.de/blog/2010/06/24/ansprechbare-buttons-mit-visueller-reaktion-css3/ Bücherliste für den Urlaub 2010 http://feedproxy.google.com/~r/hasematzel/~3/QgnwLHKn8Do/ http://hasematzel.de/blog/2010/06/22/buecherliste-fuer-den-urlaub-2010/#comments Tue, 22 Jun 2010 21:35:40 +0000 Oliver http://hasematzel.de/blog/?p=867 Auch wenn der Sommer sich hierzulande vielleicht nicht im Wetter zeigt, so ist doch zumindest ein Urlaub angesagt. Damit die Weiterbildung nicht zu kurz kommt, hier meine Bücherliste für eine gepflegte Lektüre am Abend:

Es fehlen noch ein paar Bücher. The Cluetrain Manifesto habe ich noch nicht gelesen (mittlerweile in der 10-Jahres-Jubiläumsausgabe, tsts). Irgendwas Leichtes wäre auch nicht schlecht. Naja, ich werde die Liste wohl nach und nach aktualisieren.

]]> http://hasematzel.de/blog/2010/06/22/buecherliste-fuer-den-urlaub-2010/feed/ 0 http://hasematzel.de/blog/2010/06/22/buecherliste-fuer-den-urlaub-2010/ RSS-Feeds mit YQL aggregieren und abrufen http://feedproxy.google.com/~r/hasematzel/~3/CxFzWOqCfs4/ http://hasematzel.de/blog/2010/05/31/rss-feeds-mit-yql-aggregieren-und-abrufen/#comments Mon, 31 May 2010 11:01:47 +0000 Oliver http://hasematzel.de/blog/?p=848 YQL hatte sich innerhalb kürzester Zeit zu einem meiner Lieblingswerkzeuge gemausert. Schon seit über einem Jahr hatte Yahoo!s Developer Evangelist Chris Heilmann in regelmäßigen Abständen die Fähigkeiten der API für APIs unter Beweis gestellt. Die Yahoo! Query Language ist eine SQL-ähnliche Syntax, unter deren Verwendung man alle möglichen Dritt-Schnittstellen einheitlich abrufen kann. Die kleinen Beispiele in diesem Artikel sollen zeigen, welchen Einsatzzweck diese Schnittstelle haben kann. Werfen wir mal einen Blick auf einen einfachen Aufruf:

select * from html where url='http://mashable.com'

Diese Query ist relativ sinnfrei, liefert sie doch das gesamte body-Konstrukt der mashable.com-Startseite. Dennoch erkennt man schon das Potenzial, wenn man für den Zugriff auf Inhalte eine Art SQL anwenden kann. Öffnet man diese Query in der YQL-Konsole, kann man sich die Rückgabewerte anzeigen lassen.

Nehmen wir einmal an, mashable.com hätte keinen RSS-Feed, wir möchten aber gerne die neuesten drei News abrufen und in unserer Webseite zeigen. Mit ein bisschen xpath-Magie und einen Blick in den Quelltext ist das kein Problem. mashable.com verwendet WordPress und versteckt seine News in einem div-Element und dort in einem h2/a-Konstrukt. Eine Funktion reduziert die Resultate auf die obersten 3. In Verbindung mit einer XML-Query sieht unsere Abfrage also so aus:

select * from html
    where url='http://mashable.com'
    and xpath='//div/h2/a' | truncate(count=3)

Am besten schaut man sich das Resultat wieder in der YQL-Konsole an. Wählt man JSON als Output und ruft das Ganze über die API ab, kann man leicht durch das Resultat iterieren.

Abruf von mehreren Feeds

Wie der Abruf eines HTML-Konstruktes ist auch das Einlesen von RSS-Feeds überaus einfach. Nehmen wir an, ich möchte die letzten Einträge des Hasematzel-RSS einlesen – und zwar nur die Titel, Links und das Veröffentlichungsdatum der einzelnen Einträge. Die Query sieht dann so aus:

select title,link,pubDate from rss
    where url='http://feeds.feedburner.com/hasematzel'

Im Ausgabefenster der Konsole sind die Einträge nach Datum absteigend sortiert. Das liegt bei RSS in der Natur der Dinge. Bei der Aggregierung von mehreren Feeds bekomme ich aber die Feeds (nicht die Beiträge) nacheinander angezeigt. Ich rufe mal meinen delicious.com-Feed und meinen Twitter-Feed ab:

select title,link,pubDate from rss
    where url in (
        'http://twitter.com/statuses/user_timeline/818226.rss',
        'http://feeds.delicious.com/v2/rss/hasematzel?count=15'
    )

Bei zwei Feeds könnte man ja noch schnell ein bisschen Basteln, die Rückgabe auseinandernehmen und die Arrays/Objekte in der richtigen Reihenfolge wieder zusammenfügen. Je mehr Feeds man aber aggregiert, umso umständlicher wird das. Zusätzlich bürde ich meinem Code zusätzliche Arbeit auf, die auch YQL verrichten kann.

select title,link,pubDate from rss
    where url in (
        'http://twitter.com/statuses/user_timeline/818226.rss',
        'http://feeds.delicious.com/v2/rss/hasematzel?count=15',
        'http://oliverschwarz.tumblr.com/rss',
        'http://piepmatzel.de/feed/'
    )

Sortieren und Abschneiden

Für die Sortierung (und auch das Abschneiden) von Daten hat das YQL-Team spezielle Funktionen bereitgestellt. Die Funktionen werden einfach am Ende der Query positioniert. So ist es möglich, zunächst nach pubDate aufsteigend zu sortieren und das Resultat zusätzlich auf maximal fünf Einträge zusammenzuschneiden:

select title,link,pubDate from rss
    where url in (
        'http://twitter.com/statuses/user_timeline/818226.rss',
        'http://feeds.delicious.com/v2/rss/hasematzel?count=15',
        'http://oliverschwarz.tumblr.com/rss',
        'http://piepmatzel.de/feed/'
    ) | sort(field='pubDate',descending='true') | truncate(count=5)

So einfach ist das mit YQL. Der Spasseffekt kommt dann auf, wenn ich das nicht nur in der YQL-Konsole mache, sondern die Resultate über die API abrufe. Dazu wird es dann noch einmal einen zusätzlichen Beitrag geben. In Chris Heilmanns github-Account gibt es dazu auch schon jede Menge Beispiele. Vor dem Einsatz in produktiven Systemen sollte damit gerechnet werden, dass die YQL-API auch mal nicht da sein kann. Es empfiehlt sich, die Ergebnisse für einen gewissen Zeitraum zu cachen (Dirk Ginader hat dazu eine einfache Lösung).

]]> http://hasematzel.de/blog/2010/05/31/rss-feeds-mit-yql-aggregieren-und-abrufen/feed/ 4 http://hasematzel.de/blog/2010/05/31/rss-feeds-mit-yql-aggregieren-und-abrufen/ Variablen aus PHP per JSON in JavaScript übergeben http://feedproxy.google.com/~r/hasematzel/~3/ygKcdLJiexU/ http://hasematzel.de/blog/2010/02/06/variablen-aus-php-per-json-in-javascript-uebergeben/#comments Sat, 06 Feb 2010 20:32:24 +0000 Oliver http://hasematzel.de/blog/?p=757 Es passiert mir recht oft, dass ich in einer Applikation im JavaScript-Layer auf die Werte von Variablen zugreifen muss, die eigentlich nur in PHP existieren. Meist habe ich mir in PHP ein Wörterbuch angelegt, welches Standardbegriffe enthält, die an vereinzelten Stellen in der Applikation verwendet werden. Zum Beispiel werden Fehlermeldungen (“konnte nicht gespeichert werden”, “bitte Feld %s ausfüllen”) in einer einzigen Datei zusammengefasst und zum notwendigen Zeitpunkt abgerufen und angezeigt. Das ermöglicht mir unter anderem später eine Lokalisierung der Applikation.

Ich beginne im Normalfall immer mit dem Backend (PHP) und setze erst später den Client-Layer (JavaScript) um. Das meiste JavaScript ist dann eine Verbesserung der Usability. Nicht selten brauche ich an manchen Stellen im JavaScript auch eine Fehlermeldung, die aber nur in PHP existiert.

Der Holzhammer

Die einfachste Methode ist der print() der Variable direkt in das JavaScript:

<?php
$error = 'Es ist ein Fehler aufgetreten';
?><!DOCTYPE html>
<html lang="de">
<head>
...
    <script type="text/javascript">
    var error = '<?php echo $error; ?>';
    alert(error);
    </script>

Die Methode ist effektiv, hat aber gehörige Nachteile:

  1. Ich habe manchmal nicht die Möglichkeit, mit PHP noch im HTML/DOM rumzuwerkeln. Manchmal will ich sie auch gar nicht haben.
  2. Diese Lösung verursacht eine Sprach-Suppe, die nur sehr schwer zu betreuen ist.
  3. Bei grösseren Wörterbüchern kommt man hier ganz schön ans Schwitzen.

Etwas eleganter: Ein bisschen JSON

Die JavaScript-Objekt-Notation, kurz JSON genannt, bietet einen etwas eleganteren Weg, auch grössere Mengen von Variablen von PHP in JavaScript zu transferieren:

<?php
$errors = array(
    'errnosave' => 'Speichern fehlgeschlagen',
    'errunknown' => 'Unbekannter Fehler');
?><!DOCTYPE html>
<html lang="de">
<head>
...
    <script type="text/javascript">
    var errors = '<?php echo json_encode($errors); ?>';
    alert(errors.errunknown);
    </script>

Diese Methode hat schon einige Vorteile, aber immer noch ein paar Nachteile:

  1. Ich kann schon einige Daten an JavaScript übertragen. Das JSON-Format ist genial kurz und erzeugt für diese Aufgabe fast keinen Overhead.
  2. Nachteil: Ich muss immer noch direkt ins Dokument schreiben.

Erzeugen einer eigenen dictionary.js

Diese dritte Variante bemüht sich, einfach, aber so abstrakt wie möglich den Variablentransfer durchzuführen. Wir brauchen dafür drei Dateien und – wenn möglich – einen Cron, der regelmässig das Wörterbuch erzeugt.

Datei Nr. 1: Die dictionary.ini

In der dictionary.ini werden die Variablen abgelegt. Eine ini-Datei, weil man sie aus PHP heraus mit der Funktion parse_ini_file() so schön lesen und weiterverarbeiten kann. Eine ini-Datei ist ein einfaches Textdokument und kann so aussehen:

; Statische Meldungen
[authentication]
variable = 'Wert'
variable2 = 'Wert2'

[errors]
errnosave = 'Es wurde nicht gespeichert'
errunknown = 'Unbekannter Fehler'

Den Aufbau kennt man z. B. von den Smarty-Config-Dateien.

Datei Nr. 2: Der Parser create_dictionary.php

Ich kann meinen Parser in der Datei create_dictionary.php nun anweisen, die ini-Datei einzulesen und dabei die Sektionen (in den eckigen Klammern) zu berücksichtigen:

<?php
$dictionary = parse_ini_file('dictionary.ini', true);
$errors = $dictionary['errors']; // Sektion 'errors' ermitteln
?> 

Die dritte Datei: dictionary.js

Nun kann ich den Array $errors im JSON-Format in eine Datei namens dictionary.js schreiben:

<?php
$data = sprintf('var DICT = %s', json_encode($errors));
$h = fopen('dictionary.js', 'w');
fwrite($h, $data);
fclose($h);
?>

Diese dictionary.js-Datei kann ich nun ganz normal im <head>-Bereich meiner HTML-Seite einbinden und habe Zugriff auf das DICT-Objekt:

<!DOCTYPE html>
<html lang="de">
<head>
...
    <script type="text/javascript" src="dictionary.js"></script>
    <script type="text/javascript">
    alert(DICT.errunknown);
    </script>

Auch diese Methode kommt nicht ganz ohne Nachteile daher:

  1. Ich muss aus PHP in eine dictionary.js schreiben können, manchmal will man das aus Sicherheitsgründen nicht.
  2. Ich will eine solche Schreiboperation nicht bei jedem Request auf die Applikation durchführen. Ich muss das also per Cronjob oder immer in einem Build machen.

Dennoch ist die Variante “schön” genug, um in einzelnen Fällen und gerade in Web-Applikationen die Übermittlung von Variablen von PHP zu JavaScript zur Leichtigkeit werden zu lassen.

]]> http://hasematzel.de/blog/2010/02/06/variablen-aus-php-per-json-in-javascript-uebergeben/feed/ 2 http://hasematzel.de/blog/2010/02/06/variablen-aus-php-per-json-in-javascript-uebergeben/ Social Media heute und morgen http://feedproxy.google.com/~r/hasematzel/~3/ZpUjO03tTGM/ http://hasematzel.de/blog/2009/12/03/social-media-heute-und-morgen/#comments Thu, 03 Dec 2009 20:59:55 +0000 Oliver http://hasematzel.de/blog/?p=725 Zwei Beiträge über Social Media haben mich in dieser zweiten Wochenhälfte angenehm überrascht. Jeder Beitrag geht auf völlig unterschiedliche Situationen ein. Mike Schnoor beschreibt in seinem Blog, was aus seiner Sicht 2010 im Bereich Social Media passieren wird. Dabei erfasst er die Spitze des Social Media-Eisbergs, die Early Adopters, die Treiber und Erfinder. Im Grunde zeichnet er eine Fortsetzung der aktuellen Bewegung. Mehr Nutzer, mehr Bedarfe, weniger Kontrolle für herkömmliche Broadcaster usw. Ohne die Qualität seiner 10 Punkte einzeln bewerten zu wollen, kann ich mir vorstellen, dass sich der Bereich Internet so oder so ähnlich entwickeln wird. Gerade Unternehmen werden sich aus unterschiedlichen Gesichtspunkten mehr und mehr gezwungen sehen, auf Züge aufspringen zu müssen. Der eine oder andere Zug kann dabei für das eine oder andere Unternehmen durchaus zu schnell sein.

Nur ein neuer Marketing-Kniff?

Es wird noch lange dauern, bis der Grossteil der Unternehmen feststellt, dass es sich bei Social Media nicht um einen weiteren Marketing-Kniff handelt. Dass es nicht nur eine Marketing-Verantwortung ist, sich um das grosse Potenzial zu kümmern. Es wird stattdessen Zeit brauchen, zu erkennen, dass ein intensiver Wechsel in der Unternehmenskultur stattfinden muss, um sich auf Social Media einzulassen. Manche Unternehmen bringen das aufgrund ihres Produktes oder ihrer Dienstleistung mit, vielleicht auch aufgrund der Branche oder des Durchschnittalters der Mitarbeiter. Andere Unternehmen werden Schwierigkeiten haben, den Einstieg jemals in absehbarer Zeit zu schaffen. Persönlich halte ich den Denkansatz “Social Media/Crowd Sourcing/User Generated Content/Insert Buzzword Here ist ein Potenzial, welches abgeschöpft werden muss” für völlig falsch. Vorher muss der Komplex erst verstanden werden, dann muss eine Entscheidung erfolgen, ob man sich überhaupt auf dieses Internetz einlassen will. Vielleicht wird auch eine friedliche Koexistenz zwischen Klassik und Moderne angestrebt. Gibt es soetwas?

Der Zug ist weg, was nun?

Kommen wir also zum zweiten Beitrag. Seth Godin veröffentlicht die Aufgabenliste für den Fall, dass es schon zu spät ist: “Is it too late to catch up?“, fragt er. Damit richtet er sich an die Konservativen, die Langsamen, die Verweigerer und Ängstlichen. Was ist, wenn mein Unternehmen noch nicht dabei ist? Kann man den Rückstand mit GMail und 11 Punkten auf der Liste aufholen? Muss ich, wie er im letzten Punkt beschreibt, wirklich scheitern, um zu verstehen?

Unternehmenskulturen sehen sich neuen Herausforderungen gegenübergestellt. Klassische, starre Kommunikationswege werden aufgelöst. Das Internet als neuer Senderkanal für das Marketing ist in Wirklichkeit ein Bündel von Millionen Kanälen. Und diese Kanäle sind auf einmal keine Einbahnstrasse mehr. Resourcen sind ohnehin knapp und bei gegenwärtiger Arbeitslast ist die Bewältigung neuer Aufgaben kaum möglich. Es müssen sich erst ganze Prozessketten ändern, bevor Platz geschaffen wird für neuen Input, neue Kommunikation. Seths Artikel zaubert ein bisschen augenscheinliche Leichtigkeit in diese Aufgabe, meiner Meinung nach zu viel davon. Aber ein Kernsatz in seinem Artikel ist wichtig: “Mach doch einfach”. Eine schöner Vorsatz für das neue Jahr.

]]> http://hasematzel.de/blog/2009/12/03/social-media-heute-und-morgen/feed/ 0 http://hasematzel.de/blog/2009/12/03/social-media-heute-und-morgen/ Erste Schritte mit Microsofts Expression Web SuperPreview http://feedproxy.google.com/~r/hasematzel/~3/A3HG_5vOVwc/ http://hasematzel.de/blog/2009/09/18/erste-schritte-mit-microsofts-expression-web-superpreview/#comments Fri, 18 Sep 2009 10:15:06 +0000 Oliver http://hasematzel.de/blog/?p=717 Seit dem 2. September können Entwickler Microsofts Expression Web SuperPreview herunterladen. MEWSP ist ein Werkzeug zur Darstellung von Webseiten in mehreren Browsern, im Standard in den Internet Explorer-Versionen 6, 7 und 8. Entwickler sind ohnehin besonders bei der Gestaltung der Webseiten von den unterschiedlichen Interpretationen der Browserversionen gebeutelt. Microsoft versucht, mit MEWSP eine Unterstützung anzubieten.

Vor einigen Wochen hatte ich schonmal die Beta heruntergeladen, die ich aber dank fehlendem XP ServicePack3 nicht installieren konnte. Die aktuelle Version läuft nun auch auf XP ServicePack 2, benötigt aber ein installiertes .NET Framework 3.5. Um die IE8-Vorschau verwenden zu können ist zusätzlich eine IE8-Installation notwendig – verständlich.

Trotz vieler Ansätze (Virtual Machines, MultipleIE) im Internet habe ich für mich nie DAS Werkzeug zum browserübergreifenden Test finden können, dementsprechend gross war meine Hoffnung, vielleicht von Microsoft selbst mit einer Lösung versorgt zu werden. Und – nach den ersten Stunden mit dem Expression Web Super Preview – bin ich recht zuversichtlich, etwas gefunden zu haben. Zumindest die gröbsten Probleme lassen sich leicht mit der Software ermitteln und beheben.

Ein paar Screenshots

Nach einer reibungslosen Installation, wenig Konfiguration und dem ersten Start nimmt das Tool recht schlicht seine Arbeit auf. MEWSP startet mit einem geteilten Fenster und einer Browserauswahl. Am oberen Rand befindet sich eine Adressleiste, mit der öffentlich verfügbare Seiten aufgerufen werden können. Gibt man eine Adresse ein, wird die Seite in den beiden Browsern geladen.

Leider ist kein “browsen” möglich, d. h. geladen werden nur Abbilder der Seite. Das DOM ist da und ich kann Elemente analysieren, aber ich kann keine Links verwenden. Ein Klick auf ein Element oder einen Link führt nur zu einer Detailanzeige der Elementinformationen. Macht aber im Grunde nix, das ist ohnehin schon viel besser, als alle Lösungen, die ich bisher gesehen habe. Trotz korrekter Einstellung meines Internet Explorers habe ich es jedoch leider noch nicht geschafft, lokale Seiten aus einem lokalen Webserver (localhost) aufzurufen.

JavaScript scheint in diesem Rahmen auch nicht zu funktionieren, bzw. ausgeführt zu werden. Schade, auch JavaScript ist browserübergreifend manchmal schmerzhaft, aber dafür gibt’s ja jQuery ;)

MEWSP erlaubt zusätzlich einen Overlay beider Fenster, wodurch Unterschiede in den Layouts nun einwandfrei zu Tage treten. Sehr tolle Sache, das. Jede Menge weiterer Funktionen erleichtern den Überblick über das Layout: Zoom-Funktionen, ein Browser für das DOM, ein Lineal und Hilfslinien, die ich auf die jeweiligen Screens legen kann.

Ein erstes Fazit

Trotz einiger Schwächen (kein echter Browser, kein JavaScript) ist Microsofts Expression Web SuperPreview eine gute Alternative zum browserübergreifenden Test von Layouts – vorausgesetzt, man kann sich auf die IE6-Interpretation verlassen. Auf meinen Flickr-Account habe ich ein paar erste Screenshots hochgeladen.

]]> http://hasematzel.de/blog/2009/09/18/erste-schritte-mit-microsofts-expression-web-superpreview/feed/ 2 http://hasematzel.de/blog/2009/09/18/erste-schritte-mit-microsofts-expression-web-superpreview/ jQuery Anti-Patterns für eine bessere Performance http://feedproxy.google.com/~r/hasematzel/~3/0V1AsWXNH30/ http://hasematzel.de/blog/2009/09/15/jquery-anti-patterns-fuer-bessere-performance/#comments Tue, 15 Sep 2009 20:02:26 +0000 Oliver http://hasematzel.de/blog/?p=714 Das t3n-Magazin veröffentlicht einen Kurzbericht über die jQuery-Konferenz, die am vergangenen Wochenende in Boston stattfand (ein paar Fotos gibt’s natürlich bei Flickr). Neben vielen interessanten Präsentationen ist auch der Vortrag von Paul Irish zum Thema jQuery Anti-Patterns for Performance & Compression verlinkt. (Genau der Paul Irish, der vor kurzem den Artikel Bulletproof @font-face veröffentlichte, der durch viele Blogs ging).

Paul präsentiert in seinen Folien sehr wissenswerte Ansätze über die Optimierung des Codes beim Einsatz von jQuery. Manche Sachen sind offensichtlich – wenn man sie erstmal sieht, manche Ansätze sind neu, teilweise überraschend und sollten beim nächsten jQuery-Projekt dringend in Betracht gezogen und geprüft werden. Sehr lesenswert.

Hier geht’s zur Präsentation auf Slideshare und hier findet sich eine gesamte Auflistung der Präsentationen und Vorträge der jQuery Conference.

]]> http://hasematzel.de/blog/2009/09/15/jquery-anti-patterns-fuer-bessere-performance/feed/ 0 http://hasematzel.de/blog/2009/09/15/jquery-anti-patterns-fuer-bessere-performance/ Snow Leopard und Apache, PHP und MySQL http://feedproxy.google.com/~r/hasematzel/~3/eeTwzlB33uI/ http://hasematzel.de/blog/2009/09/10/snow-leopard-und-apache-php-und-mysql/#comments Thu, 10 Sep 2009 11:28:27 +0000 Oliver http://hasematzel.de/blog/?p=695 Die Veröffentlichung von Apples neuer Betriebssystem-Version Snow Leopard hat für Web-Entwickler auch einige Neuerungen mitgebracht. Unter anderem wurde auch der Apache und die PHP-Version aktualisiert. Wer wie ich nicht MAMP verwendet, hat eventuell ebenfalls eine böse Überraschung erlebt: Die angepasste Apache-Konfiguration und alle PHP-Einstellungen sind nach einem Update einfach weg, bzw. zurückgesetzt.

Nach wie vor lässt sich der docroot des Webservers über ein http://localhost/~username aurufen, aber PHP läuft dort nicht mehr und ein installiertes MySQL unter /usr/local/ ist auf den ersten Blick auch nicht mehr da. Was ist passiert?

Der neue Apache

Der Apache Webserver wurde auf die Version 2.2.11 aktualisiert. Damit wurden jedoch die Einstellungen in der httpd.conf und vor allem unter /extra/httpd-vhosts.conf zurückgesetzt. Das bedeutet, trotz eines mitgelieferten PHP 5.3 funktionieren PHP-Dateien im docroot unter /Users/{username}/Sites/ erstmal nicht. Eine Abhilfe schafft ein kurzer Sprung in die Konsole, um in der Apache-Konfiguration das Laden des PHP-Moduls wieder zu aktivieren (Bei solchen Sachen lohnt es sich, immer mal ein Backup der aktuellen Konfiguration anzulegen):

#~> sudo cp /private/etc/apache2/httpd.conf .
    ~/backup/httpd.conf.20090909.001
#~> sudo vi /private/etc/apache2/httpd.conf

In der Datei suchen wir nach der Zeile, in der das PHP-Modul geladen wird. Die Zeile muss etwa so aussehen:

#LoadModule php5_module    libexec/apache2/libphp5.so

Durch Entfernen des vorangestellten #-Zeichens und einem Neustart des Apaches wird nun das PHP-Modul geladen. Danach sollte eine im docroot des Webservers abgelegte PHP-Datei mit dem Aufruf der Funktion phpinfo() brav die nagelneue Version 5.3 anzeigen.

Aktivieren der php.ini

Bei einem Blick in die Aufstellung in der PHPInfo stellen wir fest, dass keine php.ini-Datei geladen wird. Stattdessen verwendet das Modul die Standardeinstellungen. Im Verzeichnis /private/etc/ finden wir aber mehrere inaktive Versionen, die wir schnell aktivieren können:

#~> ls /private/etc/php.in*
/private/etc/php.ini.default
/private/etc/php.ini-5.2-previous
/private/etc/php.ini.default-5.2-previous
#~> cd /private/etc/
#~> sudo cp php.ini.default php.ini
#~> sudo chmod u+w php.ini
#~> sudo apachectl restart

Jetzt können wir an der Datei Änderungen vornehmen. Eine wichtige Neuerung in PHP5.3 ist sicherlich das Date/Timezone-Objekt. Das wirft nämlich massenweise Kompatibilitätsfehler aus, wenn Applikationen noch mit den date()-Funktionen von PHP5.2 und kleiner arbeiten. Um diese Fehler zu verhindern, sollte in der php.ini zumindest die Standard-Timezone gesetzt werden. Die unterschiedlichen Angaben (für Europa) findet man in der PHP-Dokumentation. Man öffnet die php.ini, sucht die Definition für date.timezone im Abschnitt [date], setzt den Wert entsprechend (bei mir Europe/Berlin) und kommentiert die Zeile aus. Nach Speichern der Datei und eines Neustarts des Apaches sollten die Fehler verschwunden sein. Ich rate jedoch jedem Entwickler, sich die Definition des neuen Date/Timezone-Objektes anzusehen.

MySQL

Ich hatte vorher eine eigene MySQL-Installation unter /usr/local/mysql laufen. /mysql war dabei ein symbolischer Link auf die Bibliotheken unter mysql-5.0.1a-osx10.5-x86. Das Snow Leopard Update hat zwar die Bibliotheken wiederhergestellt, aber den symbolischen Link vergessen:

#~> cd /usr/local/
#~> sudo ln -s mysql-5.0.1a-osx10.5-x86 mysql

Nebenbei sollte ich die MySQL-Version vielleicht auch einmal aktualisieren – zunächst mal klappt aber wieder der Zugriff über den Client.

PHP kann aber noch nicht auf MySQL zugreifen. Zunächst sind in der php.ini die entsprechenden mysql-Module freizuschalten (im Bereich Dynamic Extensions). Danach erscheint der Abschnitt MySQL zwar wieder brav in der phpinfo, es konnte jedoch immer noch keine Verbindung zur lokalen Datenbank hergestellt werden. Das liegt daran, das in der php.ini.default der Wert für das mysql.default_socket auf /var/mysql/mysql.sock steht. In meiner Installation liegt das Socket aber unter /private/tmp/mysql.sock. Schnell den Wert ändern, Apache neu starten und der Zugriff auf die lokale MySQL-DB klappt wieder:

mysql.default_socket = /private/tmp/mysql.sock
mysqli.default_socket = /private/tmp/mysql.sock

Von meinen virtuellen Hosts hatte ich ausreichend Backups, darum war die Wiederherstellung der httpd-vhosts.conf nicht so schwer. Wer lokale TLDs verwendet und die Zugriffe durch Einträge in der /private/etc/hosts ermöglicht, muss übrigens die hosts-Datei nicht noch einmal anfassen: Die Einträge darin werden von Snow Leopard übernommen.

Danke für die Hilfe

Sehr viel geholfen haben mir dabei die Einträge von tady im WordPress-Forum und der Artikel Snow Leopard: Umstiegshürden eines Web-Entwicklers in Wookkies Blog. Danke dafür.

]]> http://hasematzel.de/blog/2009/09/10/snow-leopard-und-apache-php-und-mysql/feed/ 9 http://hasematzel.de/blog/2009/09/10/snow-leopard-und-apache-php-und-mysql/ Warum der Umstieg auf HTML 5 jetzt eine gute Idee ist http://feedproxy.google.com/~r/hasematzel/~3/udxUuBkMVfs/ http://hasematzel.de/blog/2009/06/30/warum-der-umstieg-auf-html-5-jetzt-eine-gute-idee-ist/#comments Tue, 30 Jun 2009 21:59:33 +0000 Oliver http://hasematzel.de/blog/?p=683 Gestern wurde der Firefox in der Version 3.5 veröffentlicht und zum Download freigegeben. Die neue Variante bietet interessante und sinnvolle Erweiterungen zur Unterstützung für benutzbarere Webseiten sowohl für Anbieter als auch für Benutzer. Letzte Woche schon publizierte Opera die Information zur zukünftigen Version 10 des beliebten Browsers, welche auch ein beachtenswertes Konzept enthält, welches den Aufenthalt im Internet bereichern könnte.

Über HTML5 wurde in der letzten Zeit ebenfalls extrem viel geschrieben. So viel, dass sich das W3C als offizielle Organisation zur Aussage genötigt sah, dass HTML5 derzeit noch kein Standard sei. In der Tat, wenn man sich die derzeitigen Massnahmen der grossen Browserhersteller anschaut, so wird es noch dauern, bis HTML5 in notwendiger Breite unterstützt wird – und darauf kommt es letztlich an. Trotzdem entstehen allerortens Dialoge zum Thema HTML5, sogar erste professionelle Webseiten entstehen auf der durchaus vielversprechenden HTML5-Basis. Hacks und Workarounds, um Webseiten abwärtskompatibel zu gestalten, sind zu genüge zu finden.

Warum jetzt auf HTML5 umsteigen?

Um diesen Aufruf zu erklären, muss ich gute 6 Jahre zurückblicken. Im Oktober des Jahres 2003 hiess der Firefox noch Firebird und war in einer frühen Version erhältlich. Flächendeckend war der Internet Explorer verfügbar und die Kommunikation zwischen Standard-Organisation (W3C), Browserherstellern und Webdesignern möchte ich einmal als dünn bezeichnen. Nielsens Alertbox war die Resource zum Thema Usability. Dennoch war es die Zeit in der Menschen wie Dan Cederholm von simplebits.com und Jeffrey Zeldman mit seinem Daily Report und viele andere durch die Verwendung von Weblogs Dialoge über Möglichkeiten und Notwendigkeiten transparent machten. Der CSSZenGarden entstand. Auf einmal bewegten sich Webseiten und deren Umsetzung über das oft (und leider immer noch) fälschlicherweise alleinstehend verwendete Merkmal Design hinaus. Die Trennung von Semantik und Layout wurde state-of-the-art – und zwar in erster Linie durch die Verwendung und damit der Erkennung der Vorteile in privaten und persönlichen Webseiten, vor allem Weblogs. Auf einmal traf man auf mehr und mehr Webdesigner, die ihren Schwerpunkt auf die Darstellungsebene ergänzten mit weiteren wichtigen Gesichtspunkten, unter der Haube, für den Benutzer auf den ersten Blick nicht sichtbar, im Code.

Diese Bewegung, die offene Kommunikation und die auf der Hand liegenden Vorteile, die an vielen Stellen dargestellt wurden, können durchaus als ein wichtiger Motivator angesehen werden, der vor allem auch Browserhersteller beeinflusste und insgesamt zu einer stabileren Grundlage von Webseiten und Technologien beitrug. Eine perfekte Lösung, die insbesondere bei grösseren Webseiten Usability, Barrierefreiheit, Corporate Design und Identity und Kundenanforderungen zusammenbringt, wurde (und wird) nie erreicht. Webdesign ist auch heute immer eine Annäherungswissenschaft, die – je nach Kompromissbereitschaft des Umsetzenden – mehr oder weniger Absicht und Umsetzung miteinander vereint. Welche “grosse” Webseite verwendet nicht auch heute sogenannte Hacks, Conditional Comments oder andere Helferlein, um die Darstellung in den Browsern aller Hersteller zu vereinheitlichen?

Der Browserhersteller in Zugzwang

Diese Entwicklung hatte eines erreicht: Die Hersteller mussten die Notwendigkeit einsehen, auf derartige Bestrebungen Rücksicht zu nehmen. Und obwohl die Implementierung der vom W3C empfohlenen Standards in den Browsern selbst heute noch zu wünschen übrig lässt, näherten sich Webdesigner (durch die massenhafte Verwendung der Webstandards) und Browserhersteller (durch Nachbesserung an den Render-Engines) immer weiter an. Man kann sagen, die Motivation, die ein Hersteller von sich aus zur korrekten Implementierung trieb, wurde durch die Webseiten-Ersteller und Designer ergänzt.

Heute, 6 Jahre später, ist man bei der Erstellung von Webseiten nach wie vor auf ein exaktes Wissen um die unterschiedlichen Render-Modelle der Browser angewiesen. Dies verlangt vom Webdesigner eine grosse autodidaktische Bereitschaft und mag vielleicht der Grund sein, warum Schulungsprogramme und Lehrpläne in Universitäten zu diesem Thema noch so absolut unterschiedlich ausfallen. Denn es gibt auch immer noch keinen XHTML-Standard und auch noch keinen HTML4-Standard. Ein Standard wäre grundlegend eine absolut identische Implementierung in jedem Browser dieser Welt. Das werden wir sicherlich auf lange Zeit noch nicht sehen.

Die HTML5-Implementierung ist entweder nicht da oder nicht perfekt – na und?

Wer sich also derzeit dem Umstieg auf HTML5 noch verschliesst und auf eine stabilere und flächendeckendere Umsetzung durch die Browserhersteller wartet, lässt sich zurückfallen in die (Stein-)Zeit von Tabellenlayouts und wird – wahrscheinlich – ziemlich lange warten. HTML5 wird kommen und bietet im Entwurf schon jetzt ein Funktionsportfolio, das uns befähigt, noch bessere, benutzbarere und barriereärmere Webseiten und -Applikationen zu bauen, als wir es jemals konnten. Wir müssen uns nur bewusst machen, dass wir nur durch den Einsatz von HTML5 in kleinen, persönlichen, aber auch grösseren, professionellen Projekten die Antriebskraft für die Hersteller liefern, HTML5 (und auch mal CSS3) früher oder später ausnahmslos zu unterstützen.

Machen wir uns nichts vor. Auch wenn dieser Zeitpunkt irgendwann kommen wird, wird es Unterschiede in den Browsern geben. Man wird mit abgefahrenen Hacks auch weiterhin für einheitliche Erscheinungsbilder von Web-Oberflächen sorgen müssen. Man wird weiterhin für bestimmte Einsatzzwecke auf proprietäre Lösungen wie Flash zurückgreifen. Man wird weiterhin aufmerksam Unmengen Entwicklerblogs lesen müssen, um auf Stand zu bleiben und man wird sich auch weiterhin aktiv an der Diskussion zur Erkennung und Behebung bzw. Vermeidung von Schwachstellen in den Umsetzungen in den Browsern beteiligen müssen.

Aber es gibt keinen Grund, nicht mit dem Einsatz von HTML5 zu beginnen. Im Gegenteil, jedes Projekt, was neu jetzt noch auf Basis von HTML4 oder XHTML online geht, ist ein Grund weniger für die Browserhersteller, sich zu bewegen.

]]> http://hasematzel.de/blog/2009/06/30/warum-der-umstieg-auf-html-5-jetzt-eine-gute-idee-ist/feed/ 0 http://hasematzel.de/blog/2009/06/30/warum-der-umstieg-auf-html-5-jetzt-eine-gute-idee-ist/ Meinungen zum Deutschen Multimedia Award http://feedproxy.google.com/~r/hasematzel/~3/6ubKegGIZEM/ http://hasematzel.de/blog/2009/06/15/meinungen-zum-deutschen-multimedia-award/#comments Mon, 15 Jun 2009 07:42:19 +0000 Oliver http://hasematzel.de/blog/?p=680 Jens Grochtdreis hat den prämierten Publizierungen des Deutschen Multimedia Award unter die Haube geschaut. Das Ergebnis ist ein ausführlicher Bericht, der Aufschluss gibt über den Stand der Dinge hinsichtlich der Webstandards.

Lesebefehl!

]]> http://hasematzel.de/blog/2009/06/15/meinungen-zum-deutschen-multimedia-award/feed/ 0 http://hasematzel.de/blog/2009/06/15/meinungen-zum-deutschen-multimedia-award/