Formular Templates

Formulare sind auch so ein Gebiet, wo der Auftraggeber gewöhnlicherweise am wenigsten Vorstellungen hat, wie sie auszusehen haben, jedoch genau weiss, wie sie nicht aussehen sollen. Auf Zugänglichkeit und Nützlichkeit wird dabei in der Regel wenig Wert gelegt, und auch wenig daran gedacht, dass Formulare im Netz nicht so funktionieren, wie bspw. die Eingabefelder in einer Excel-Tabelle. Ich habe dahingehend eigentlich alles Ansätze durchgespielt: auf die Wünsche des Kunden komplett eingehen, und alles was möglich ist mittels Javscript und Ajax herausholen oder auch zu versuchen, Accessibility und Usability zu diktieren: funktioniert leider beides nicht so richtig (hinsichtlich User- und Kundenzufriedenheit).

Ausserdem habe ich festgestellt, dass verschiedene Entwickler sehr unterschiedliche Ansätze bei der Umsetzung von Formularen haben, was vor allem bei großen Websites oft dazu führt, dass Formulare keineswegs einheitlich gleich funktionieren. Oft werden Formulare auch schon von Anwendungen schlecht vorgegeben und sínd schwierig anzupassen: bspw. in Drupal.

Vielleicht hilft allen dabei Uni-Form:

Uni-Form is an attempt to standardize form markup (xhtml) and css, „modularize“ it, so even people with only basic knowledge of these technologies can get nice looking, well structured, highly customizable, semantic, accessible and usable forms.

Die Formulare von Uni-Form sehen nicht nur gut aus (das auch), sondern verfolgen sehr geschickt einen standardisierten Ansatz der Bedienbarkeit. Das scheint mir alles sehr gelungen und durchaus ein zwei Überlegungen Wert, ein solches oder auch genau dieses Modell in die Site zu übernehmen.

Asynchron Uploaden

In einem früheren Projekt haben ich schon ein paar schlechte Erfahrungen mit asynchronen File-Uploads sammeln dürfen, es hat einige Zeit gedauert, das cross-browser-kompatibel zum Laufen zu bringen. Bei El Micox gibt’s nun eine ziemlich sauber ausformulierte Version eines asynchronen Uploads via iFrame, dass sich sicherlich auch gut in jQuery o.ä. Libraries umsetzen lässt. Empfehlenswert.

Debugging again

Better Explained ist ja irgendwie auch ein sehr vielversprechender Name für eine Website. Dort finden wir aktuell: How To Debug Web Applications With Firefox, eine saubere Auflistung der drei essentiellen Debugging-Hilfen für Webanwendungen: die Web Developer Toolbar, Firebug und Live HTTP Headers, sowie jeweils eine kurze Anleitung, wie man die genannten Extensions benutzen kann. Level: Starter. [via roScripts: Top developer tools of the month.]

Spass mit Firebug

Firebug gehört wirklich, wirklich zu den nützlichen Tools, die man beim Entwickeln verwenden kann. Ein kleines Beispiel, mal so aus dem praktischen Geschäft heraus…

Beim Schreiben angepasster Stylesheets für den IE benutze ich ausgiebig Firebug. Und zwar lade ich mir im Firefox die Seite und identifiziere parallel die Anzeigefehler im IE. Mit dem Firebug lasse ich mir dann die Styles des in Frage kommenden Elements anzeigen (siehe oben).

Irgendwann bin ich dann dazu übergangen, den ganze Styleblock aus der Firebug-Ansicht heraus zu kopieren und in das IE-spezifische Stylesheet zu pasten. Dort editiert man den Block wie gewünscht. Und um die mitkopierte Datei- und Zeilenangabe kommen flugs Kommentarzeichen drumrum. Fertig: eine sauber referenziertes Stylesheet für den Deppenbrowser…

So. Feierabend für diese Woche. Zu Hause wartet schon unser Balkon.

Spammer aussperren, bevor Traffic entsteht

Das Project Honeypot macht auf sich aufmerksam, indem es eine Woche lang Projekte vorstellt, die es initiiert. Das Projekt von gestern »http:BL« hört sich ziemlich interessant an: eine Spammer-Blacklist, die mithilfe eines Apache-Moduls abgefragt werden kann und dann Verdächtigen bspw. gleich den Zutritt zur Webpräsenz verwehrt (oder Emailadressen aus dem HTML ausfiltert o.ä.). So könnte man sowohl Kommentarspammer aussperren und Emailharvester ins Leere laufen lassen (sic!). Und dabei jede Menge Bandbreite sparen… Alles noch Beta, aber wie gesagt, klingt wirklich gut.

Switch nicht durchfallen lassen

Douglas Crockford gibt im Yahoo! Interace Blog eine kleine Lehrstunde in Sachen switch-Statement. switch, geerbt aus einer langen Ahnenreihe von Programmiersprachen (Java, C++, C), kann ein mächtiges Instrument sein. Aber – mächtige Instrumente habe das oft an sich – es ist auch gefährlich: man kann es viel zu sehr zu einem goto umwandeln, was man nicht will. Auch wenn die Erinnerung an alte Brotkastentage lebt:

10	print "Dummes Zeug"
20	goto 10

LOL. Nein, nein, das wollen wir nicht.

Und switch hat noch ein anderes Problem: die sogenannten Fallthroughs. Allzuoft (das sieht man auch gerne mal in PHP-Programmen) wird es benutzt, um für eine Bedingung mehrere Tasks auszuführen, ganz einfach indem man das break am Ende eines case-Blocks weglässt. Denn dann wir bekanntermaßen fröhlich weitergeswitched. Was als prima Trick daherkommt, ist gar nicht so schlau, weil das Vergessen eines breaks eben auch ein unfreiwilliger Bug sein kann. Und wer geht nun hin und findet in ein paar tausend Zeilen Code die Blöcke, die absichtlich kein break haben und welche nicht? Eben.

Zitat von Jeffrey Zeldman

Nicht ganz, aber dicht dran:

On paper, a daily news magazine employs just one “web” employee. His title is webmaster, although he is really a developer, and he is slowly being squeezed out. The actual web development work—and there is a ton of it, every day—is performed by two IT staffers. A half dozen other folks work on page templates and site image production; on paper, they are graphic designers. The site is directed by a committee representing the editorial, advertising, and marketing departments. But regardless of their placement on the org chart, they are really web people, making web content and web layout decisions that are then executed by the “graphic designers” and “IT guys.” In all, nearly fifteen workers toil over the magazine’s website each day, yet the magazine’s web “staff” consists of one guy who’s about to take an early retirement.

Webdesign, the hidden profression. Yepp.

Sieben gute Javascript-Tipps

Dunstan Diaz, User Interface Engineer bei Google und Erfinder des CSS Naked Day, hat sieben nützliche Javascript-Techniken gesammelt, die man sicherlich ohne weiteres als best practice für die Entwicklung grosser JS-Projekte hernehmen kann. Nichts für Anfänger, wie so oft bei Javascript.

Neben den sechs praktischen Fällen, bei denen man gleich noch ein wenig mehr über die berühmt, berüchtigten Closures lernen kann, gefällt mir Tipp Nr. 7 eigentlich am besten. Hier wird uns ganz abseits von Codebeispielen empfohlen, das Rad neu zu erfinden! Hehe, ein Tipp den man selten in Sachen Programmierung hört, der aber widerspiegelt, auf welche Abwege man sich bei JS begeben kann, wenn man beispiele aus dem Netz blind abtippt oder lediglich anpasst. Zum einen ist das Netz verseucht mit schlechten, veralteten oder hanebüchenen Tipps und Code, zum anderen kommt man mit abschreiben niemals über den zweiten Anstieg der Lernkurve (»Jetzt kannst Du Javascript – nun lerne richtig Javascript!«) hinweg.

»Take the survey!«

Das allseits beliebte A List Apart Magazin veranstaltet eine Umfrage unter den programmierenden, entwickelnden und schreibenden Netizens: rund 37 Fragen, die man schnell hinter sich bringen kann, zu gewinnen gibt’s auch etwas und von den Ergebnissen partizipieren wir dann alle im Magazin. Los, mitmachen!

35 mal fünf Fragen

Auf die Idee muss man auch erst mal kommen: das Smashing Magazine hat 35 prominenten Webdesignern jeweils 5 Fragen über Webdesign gestellt. Herausgekommen sind 175 Antworten mit Tipps und Hinweisen darauf, wie die bekanntesten Webdesigner arbeiten. Und, wenig überraschend, alle Kochen mit Wasser. Denn: viel Neues findet sich in diesen Antworten nicht, wer regelmäßig Webrecherche betreibt, kann und wird alle genannten Techniken, Schriften, Ansätze kennen. Aber das ist ja nicht schlimm, denn zum einen ist das ein sehr guter Überblick, zum anderen beweist es, wie stark die weltweite Onlinecommunity der Webdesigner ist.