web output - english posts

node.js Einführung und Javascript Best Practices - WebTech Conference 2010

nospam@example.com (Dirk Ginader) — Thu, 14 Oct 2010 12:00:00 +0000

Zu meiner sehr grossen Freude hatte mich die Redaktion des Software & Support Verlages auch in diesem Jahr wieder eingeladen bei der Webtech Conference zu sprechen.

Nach dem positiven Eindruck vom letzten Jahr war es überhaupt keine Frage für mich. Ausserdem hatten mich meine kürzlichen Experimente mit dem neuen Spielzeug node.js auch so begeistert dass ich es kaum erwarten konnte diese Begeisterung zu teilen.

Ich freute mich auch dementsprechend riesig als ich sehen konnte dass das Publikum sich genauso begeistern konnte wie ich. Hier sind also die Slides meiner beiden Vorträge:

Javascript auf Client und Server mit node.js - webtech 2010

View more presentations from Dirk Ginader.

Javascript done right

View more presentations from Dirk Ginader.

The 5 Layers of Web Accessibility

nospam@example.com (Dirk Ginader) — Wed, 01 Jul 2009 12:00:00 +0000

A Month ago I was very happy to be able to speak at Skills Matter as Part of the monthly YDN Tuesdays. I spoke about my ideas about Web Accessibility and introduced them as "The 5 Layers of Web Accessibility".

Thanks to Skills Matter you can now watch the recording of this talk here. You can also find the according Slides underneath:

The 5 Layers of Web Accessibility

View more documents from Dirk Ginader.

You can also read the great writeup by Marc Hibbins who very nicely sums up the contents of my talk.

Accessible Javascript with and without WAI ARIA at GeekUp Leeds

nospam@example.com (Dirk Ginader) — Thu, 16 Apr 2009 12:00:00 +0000

Yesterday I had the great pleasure to have been invited to speak at a GeekUp special in Leeds.

I must say that these lovely Northeners turned out to be the best audience a speaker can dream of. I was presented with an endless stream of really good and very interesting questions. It's a shame there was no recording because the amazing audience really made this evening and my slides can in no way show the great discussions and fun we had.

Accessible Javascript with and without WAI ARIA

View more presentations from Dirk Ginader.

Zu Gast im Mindgarden

nospam@example.com (Dirk Ginader) — Thu, 16 Apr 2009 12:00:00 +0000

Vor kurzem durfte ich zu Gast im Shoreditch Studio des Mindgarden Podcasts sein. Mindgärtner Tobs interviewte mich zum vergangenen BarcampLondon6. Wir plauschten eine halbe Stunde über das Barcamp an sich und darüber wie ich, zusammen mit dem Rest des Teams, das Barcamp organisiert hatte.

Der Mindgarden Podcast ist übrigends generell eine Emfehlung wert. Die tolle Mischung von Web Dev Themen, Humor und Musik ist klasse und daher erlasse ich hiermit Subscribe-Befehl

Think Visibility - SEO and more

nospam@example.com (Dirk Ginader) — Mon, 09 Mar 2009 12:00:00 +0000

Last weekend I had the great pleasure to have been invited to a very interesting new conference.

Dom "The Hodge" Hodgson kicked off the first, of hopefully a lot more conferences called, Think Visibility.

The one day conference featured a very wide selection of talks across Usability, Eye Tracking, Social Media, Affiliate, Analytics and many more with a slight focus on SEO. The Talks I've listened to were packed with a lot of insight and informations you wouldn't expect the speakers to give away. I learned a lot and I'm now very tempted to try out some of the SEO Voodoo myself

Not only was the Think Visibility very interesting but also great fun! The Northerners and their guests are a lovely bunch and as great to talk to during the conferences as in the Pub before and afterwards.

Here are the Slides of my own Talk. A very basic introduction to Web Accessibility for a audience containing hardly any frontend guys which was quite new to me:

Avoiding common Accessibility mistakes

View more presentations from Dirk Ginader. (tags: thinkvisibility accessibility)

jQuery Accessible Tabs - Wie man Tabs WIRKLICH zugänglich macht

nospam@example.com (Dirk Ginader) — Sat, 07 Feb 2009 00:00:00 +0000

Während viele Tabs-Scripts behaupten zugänglich zu sein sind es die meisten leider weit davon entfernt. Während ich dieses jQuery Plugin zusammen mit meinem Kollegen Artur Ortega entwickelte, suchten wir nach existierenden Javascript Tabs die Artur mit seinem Screenreader tatsächlich bedienen kann. Wir gaben die Suche irgendwann auf.

Das Problem, dass selbst die besseren Scripts haben, ist die Fehlende Rückmeldung an den Nutzer, dass tatsächlich etwas Passiert. Die meisten Tabs Scripts ändern das Aussehen der Tabs und die Sichtbarkeit der zugehörigen Inhalte aber lassen den Nutzer da zurück wo er war - auf dem Tab auf den geklickt wurde - ohne Ahnung was gerade passiert ist (vergleichbar mit einem Klick auf die immer noch viel zu beliebten "Blinden Links" (a href="#")).

Das ist auch genau der große Unterschied den dieses Script macht. Während das Verhalten für Nutzer ohne Sehbehinderung exakt die gleiche ist passiert sehr viel unter der Haube. Aber erstmal zurück zum Anfang.

jQuery Accessible Tabs benutzt ein sehr einfaches und flexibles HTML Markup als Basis. Alles was es braucht ist ein Wrapper mit Headlines und Inhalts-Elementen nacheinander. Die einfachste und bestmöglichste Alternative ohne Javascript ohne Auszusehen als würde etwas fehlen oder etwas währe kaputt.

<div class="tabs">
<h2>eine Beispielüberschrift</h2>
<div class="tabbody">
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
<h3>Lorem ipsum</h3>
<p>Nullam malesuada suscipit pede. Nullam ipsum lacus, varius</p>
</div>
<h2>noch eine Beispielüberschrift</h2>
<div class="tabbody">
<p>Integer tincidunt. Cras dapibus. Vivamus elementum nisi.</p>
<p>Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel.</p>
</div>
<h2>alles andere</h2>
<div class="tabbody">
<p>Hier könnte Ihr Inhalt stehen</p>
</div>
</div>

Ein einfacher jQuery Aufruf transformiert das Markup in accessible Tabs:

$(document).ready(function(){
$('.tabs').accessibleTabs();
});

Um nicht nur so zugänglich sondern auch so flexibel wie möglich zu sein, kann das Script mit verschiedensten Einstellmöglichkeiten konfiguriert werden.

$('.tabs').accessibleTabs({
// Der Name der Klasse die dem Div zugewiesen
// welche um das Markup herumgeschrieben wird
wrapperClass: 'content',
// Der Name der Klasse die das aktuelle Tab markiert
currentClass: 'current',
// Tag oder valider Query Selector der Elemente
// aus denen die Tabs Navigation erzeugt wird
// (die Originale werden entfernt)
tabhead: 'h4',
// Tag oder valider Query Selector der Elemente die
// als Inhalte der Tabs genutzt werden sollen
tabbody: '.tabbody',
// Anzeigeeffekte: 'fadeIn', 'slideDown' oder 'show'
fx:'show',
// Geschwindigkeit (String|Number): 'slow', 'normal', oder 'fast')
// oder die Milisekunden die die Anzeigeeffekte dauern sollen
fxspeed: 'normal',
// Text um Screenreadern anzuzeigen welches der ausgewählte Tab ist
currentInfoText: 'current tab: ',
// Definition wo der Text eingefügt wird
// Entwender 'prepend' oder 'append'
currentInfoPosition: 'prepend',
// Klasse des span mit dem Infotext
currentInfoClass: 'current-info'
});

Also gut, warum ist dieses Script zugänglicher als andere?

Das, was dieses Script hauptsächlich besser macht als die anderen ist ein Feedback für Nutzer von Screenreadern nach dem Klick. Wenn der Nutzer auf einen der Tabs klickt wird tatsächlich auf der Seite navigiert.

Jeder Link in den Tabs führt tatsächlich zu einem fokusierbaren Inhalt. Um dies zu ermöglichen, erzeugen wir einen benannten Anker in dem zugehörigen Inhalt des Tabs. Dieser Anker, da er keine href-Egenschaft hat, kann von Haus aus aber keinen Fokus erhalten. Um dies zu ermöglichen wird ihm die Eigenschaft tabindex="0" zugewiesen. Warum 0? Weil ein Tabindex von 0 nicht die natürliche Tabordnung des Dokumentes verändert aber dem zugewiesenen Element trotzdem ermöglicht Tab-Fokus zu bekommen.

<h4>
<a id="accessibletabscontent" name="accessibletabscontent" class="accessibletabsanchor" tabindex="0">
Eine Beispielüberschrift
</a>
</h4>

In dem benannten Anker wird der selbe Text wie im Tab eingefügt welches gerade geklickt wurde und das ganze mit einer Headline umklammert. Dies stellt eine sehr angenehme Erfahrung für die Nutzer von Screenreadern dar, da es auf nette Art und Weise bestätigt, dass man gerade zu einem anderen Inhalt auf der Seite gesprungen ist.

Ein weiteres Zusatzfeature für Screenreader Nutzer ist ein kleiner Text der auf den aktuell ausgewählten Tab kennzeichnet. Standardmäßig lautet dieser Text "current tab: " gefolgt von dem Standardtext des Tabs. Dieser Text, ebenso wie seine Position (entweder davor oder danach) ist aber sehr leicht internationalisierbar.

Problem: Das Fokussieren von versteckten oder eben noch versteckt gewesenen Elementen

Während dem Testen der Tabs stießen wir auf ein sehr interessantes und ebenso störendes Verhalten des Screenreaders Jaws (und sehr wahrscheinlich auch von anderen). Wir wollten auf die Headline in dem Inhaltselement eines Tabs fokussieren nachdem es eingeblendet wurde. Bei jedem Test war der Screenreader nicht in der Lage das entsprechende Element zu finden und sprach statt dessen um Ende des Dokumentes oder einer anderen zufälligen Position. Dieses Phänomen wird durch den virtuellen Buffer des Screenreaders verursacht, einer internen Kopie des DOMs in dem der Screenreader navigiert. Der virtuelle Buffer gleicht seinen Inhalt regelmäßig mit dem DOM des Browsers ab aber dies ist stets erst nach einer Verzögerung.

Um um dieses Problem herum zu arbeiten nutzen wir einen anderen Lösungsansatz. Der benannte Anker auf den wir verlinken ist tatsächlich nicht in dem versteckten Inhaltselement sondern im DOM davor und "offscreen" (position:absolute;left:-999em) versteckt. Tatsächlich zeigt jeder Tab auf den exakt selben Anker. Wir schreiben den Inhalt des Headline-Elementes einfach jedes mal neu und blenden das zugehörige Inhaltselement entsprechend ein oder aus. Das empfundene Verhalten ist genau das gleiche. Der Screenreader Nutzer klickt auf den Tab, folgt dem Link und findet den verlinkten Inhalt mit der entsprechenden Headline.

Man kann sich das Script hier in einer einfachen Version und hier in einer YAML Umgebung in Aktion ansehen. Das jQuery Plugin wird ebenfalls Teil der kommenden Version 3.1.1 des CSS Framework Yaml sein.

Man kann das script zusammen mit den demos hier herunterladen.

jQuery Accessible Tabs - How to make tabs REALLY accessible

nospam@example.com (Dirk Ginader) — Sat, 07 Feb 2009 00:00:00 +0000

While a lot of Tabs-Scripts claim to be accessible it turns out, most of them are really not. While developing this jQuery Plugin with my coworker Artur Ortega, we tried to find a single existing Javascript powered Tabs-Interface that Artur, using his Screenreader, would actually be able to use properly. We eventually gave up the search.

The one Problem even the better ones have is the missing Feedback of the content change. Most of the tabs scripts change the style of the tabs and the visibility of their corresponding content but leave the user just where he was - on the tab-link - not knowing that something happened (just like clicking on a, ever so popular, inactive link (a href="#")).

This is also the big difference this Script makes. While the user experience for users without visual impairment is exactly the same, there's a lot happening under the hood. But let's start from the beginning.

jQuery Accessible Tabs uses a very simple and flexible HTML markup as it's base to build upon. All it needs it's a wrapper containing Headlines and content elements one after the other. This provides a nice non-javascript fallback that does not look like something is missing or broken.

<div class="tabs">
<h2>some dummy headline</h2>
<div class="tabbody">
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
<h3>Lorem ipsum</h3>
<p>Nullam malesuada suscipit pede. Nullam ipsum lacus, varius</p>
</div>
<h2>another dummy headline</h2>
<div class="tabbody">
<p>Integer tincidunt. Cras dapibus. Vivamus elementum nisi.</p>
<p>Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel.</p>
</div>
<h2>anything else</h2>
<div class="tabbody">
<p>Here could be your content</p>
</div>
</div>

A simple jQuery call then transforms this to the accessible Tabs:

$(document).ready(function(){
$('.tabs').accessibleTabs();
});

To not only be accessible but also to be as flexible as possible the script allows configurations to be passed to.

$('.tabs').accessibleTabs({
// Classname to apply to the div that is wrapped around
// the original Markup
wrapperClass: 'content',
// Classname to apply to the LI of the selected Tab
currentClass: 'current',
// Tag or valid Query Selector of the Elements to Transform the
// Tabs-Navigation from (originals are removed)
tabhead: 'h4',
// Tag or valid Query Selector of the Elements to be treated as
// the Tab Body
tabbody: '.tabbody',
// can be 'fadeIn', 'slideDown', 'show'
fx:'show',
// speed (String|Number): 'slow', 'normal', or 'fast') or the number of
// milliseconds to run the animation
fxspeed: 'normal',
// text to indicate for screenreaders which tab is the current one
currentInfoText: 'current tab: ',
// Definition where to insert the Info Text.
// Can be either 'prepend' or 'append'
currentInfoPosition: 'prepend',
// Class to apply to the span wrapping the CurrentInfoText
currentInfoClass: 'current-info'
});

So, why is this Tabs-Script more accessible than others?

The main thing this Script does better than the others is providing a click feedback for Screenreader Users. When the user clicks on one of the tabs there's actually a navigation going on on the page.

Every link in the tabs is pointing to an actually focusable content. To allow this, we create a named anchor inside of the tabs content. This anchor, as it has no href property, is not focusable by default though. To make it focusable we gave it a tabindex="0". Why 0? Because a tabindex of 0 does not change the natural tab flow of the page but it makes an element focusable which is not able to receive focus by default.

<h4>
<a id="accessibletabscontent" name="accessibletabscontent" class="accessibletabsanchor" tabindex="0">
some dummy headline
</a>
</h4>

Inside of the named anchor we add the same text as the tab that was just clicked and wrapped it into a headline element. This provides a very nice user experience for screenreader users, as it nicely confirms that you actually jumped into a new content of the page.

The other thing that adds benefit for screenreader users is a little text that indicates the currently selected tab. It defaults to "current tab: " followed by the default text of the tab. For internationalisation reasons this text as well as the text position (either before or after) can easily be configured.

Problem: Focussing hidden or recently hidden Elements

During the testing of the tabs we discovered a very interesting, yet very annoying, behaviour of the Screenreader Jaws (and probably others too). We wanted to focus the headline in the content of the current tab after clicking the tab which made the content visible. Everytime we tested, the Screenreader was unable to find the element to focus on and simply jumped to the end of the page or randomly somewhere else. We discovered that this is only happening when the focus target was recently hidden. This phenomenon is caused by the screenreaders virtual buffer, an internal copy of the actual DOM in which the Screenreader user navigates. The virtual buffer does regularly update itself from the Browser DOM but there's always a delay.

To work around this issue we used a different approach. The named anchor we're linking to is not actually in the hidden tab content but before it in the DOM of all of the contents and hidden offscreen. Also actually every link in the tabs is pointing to the same anchor. We're simply dynamically rewriting the headline text on the fly and show and hide the contents accordingly. The user experience is just the same. The screenreader user clicks on the tab, follows the link and finds the linked content starting with a corresponding headline.

You can see the script in action in a simple version here and in a Yaml environment here. This plugin will also be part of the The CSS Framework Yaml in its upcoming version 3.1.1.

You can download the script including the demos here.

CSS Voodoo - The dark art of CSS Hacks

nospam@example.com (Dirk Ginader) — Sun, 01 Feb 2009 00:00:00 +0000

CSS Hacks are something one doesn't talk about in the public. Developers are ashamed of using them. They are bad, they are evil and you really shouldn't use them at all...

...but sometimes there's simply no other way - and then you sell your soul to the hack-devil...

Since I joined Yahoo! I stopped using Conditional Comments for Performance Reasons (less HTTP Requests). So I needed to get familiar again with the common Hacks for Internet Explorer I had completely forgotten about.

Over time I hardly ever ran into situations when other Browsers misbehaved - but it did happen (after all they are all just software and as we all know there is no software without Bugs...).

So following you'll find the current State of my CSS Hack Collection. You can see them in action on my CSS Hacks Example page. Please use with caution and do yourself the favour and try ANYTHING else BEFORE you capitulate and use them!

In my Demo I have Paragraphs containing the names of the targeted Browsers and hide them by default.

body p { display: none; }

Then I use the Browser specific Hacks to make the Browser names visible again:

Internet Explorer

/* IE 6 only */
body #ie6 {
_display: block;
}

/*IE 6 and IE 7 */
#ie6andie7 {
*display: block;
}

/* IE 7 only */
html > body #ie7 {
*display: block;
}

Firefox

/*Firefox 2 and 3 */
#firefox2, x:-moz-any-link {
display: block;
*display: none; /*overrule for ie6 and ie7 which also read this rule*/
}

/*Firefox 3 only (for Firefox 2 only use the rule above and this to overwrite for Firefox 3*/
#firefox3, x:-moz-any-link, x:default {
display: block;
*display: none; /*overrule for ie6 and ie7 which also read this rule*/
}

Safari

/* Safari */
@media screen and (-webkit-min-device-pixel-ratio:0) {
#safari {
display: block;
}
}

Opera

/* Opera */
@media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) {
head~body #opera {
display: block;
}
}

Alright - now I feel dirty and go have a shower...

CSS Voodoo - Die dunke Kunst der CSS Hacks

nospam@example.com (Dirk Ginader) — Sun, 01 Feb 2009 00:00:00 +0000

CSS Hacks sind etwas über daß man nur hinter verschlossenen Türen redet. Entwickler schämen sich sie zu benutzten. Sie sind schlecht, sie sind böse und man sollte sie wirklich überhaupt nicht benutzen...

... aber manchmal gibt es einfach keinen anderen weg - und dann verkauft man seine Seele and den Hack-Teufel...

Seit ich angefangen habe bei Yahoo! zu arbeiten habe ich aus Performance Gründen (weniger HTTP Abfragen) aufgehört Conditional Comments zu benutzen. Ich musste mich also plötzlich wieder mit den üblichen Hacks für Internet Explorer vertraut machen die ich schon völlig vergessen hatte.

Seither bin ich fast nie in Situationen geraten in denen sich auch andere Browser schlecht benommen hätten - aber es kam vor (immerhin sind sie alle nur Software und, wie wir alle wissen, gibt es keine Software ohne Bugs...).

Es folgt der aktuelle Stand meiner CSS Hack Sammlung. Man kann sich eine funktionierende Demo auf meiner CSS Hacks Beispielseite anschauen. Bitte nur mit besondere Vorsicht benutzen und tu dir selb st den Gefallen und probier ALLES ERDENKLICHE BEVOR du aufgiebst und sie selber benutzt.

In meiner Demo habe ich Absätze, die den Namen der Browser enthalten, die mit den Hacks angesprochen werden können, standardmäßig ausgeblendet.

body p { display: none; }

Dann benuze ich die Browser spezifischen Hacks um die jeweiligen Browsernamen wieder sichtbar zu machen:

Internet Explorer

/* IE 6 only */
body #ie6 {
_display: block;
}

/*IE 6 and IE 7 */
#ie6andie7 {
*display: block;
}

/* IE 7 only */
html > body #ie7 {
*display: block;
}

Firefox

#firefox2, x:-moz-any-link {
display: block;
*display: none; /*overrule for ie6 and ie7 which also read this rule*/
}

/*Firefox 3 only (for Firefox 2 only use the rule above and this to overwrite for Firefox 3*/
#firefox3, x:-moz-any-link, x:default {
display: block;
*display: none; /*overrule for ie6 and ie7 which also read this rule*/
}

Safari

/* Safari */
@media screen and (-webkit-min-device-pixel-ratio:0) {
#safari {
display: block;
}
}

Opera

/* Opera */
@media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) {
head~body #opera {
display: block;
}
}

So - jetzt fühle ich mich schmutzig und gehe duschen...

Barcamp London 6 - I'm one of the Organizers

nospam@example.com (Dirk Ginader) — Sat, 31 Jan 2009 00:00:00 +0000

After, believe it or not, 7 Barcamps as a participant it's now time to give back some of my experiences and "wisdom".

Teamed up with some of the other usual Barcamp suspects I organized the upcoming Barcamp London 6.

After we finally got the venue confirmation of the Guardian yesterday here's the official annoucement:

28 - 29 March 2009 the 6th London Barcamp will happen in the gorgeous new building of the Guardian.

In 2 weeks time the first ticket wave will be released (exact day and time will be announced). To avoid missing this important date you better follow us on twitter, subscribe to the reminder on the website and check into Upcoming.

Barcamp London 6 - ich bin im Orga-Team

nospam@example.com (Dirk Ginader) — Sat, 31 Jan 2009 00:00:00 +0000

Nach, sage und schreibe, 7 Barcamps als Teilnehmer ist es an der Zeit meine gesammelte "Erfahrung" und "Weisheit" einzusetzen.

Zusammen mit einigen anderen der üblichen Barcamp-Verdächtigen habe ich das kommende Barcamp London 6 organisiert.

Nachdem wir gestern endlich die finale Zusage von the Guardian als location bekommen haben gibt es jetzt endlich die offizielle Ankündigung:

Vom 28. - 29. März 2009 findet in den schicken neuen Räumen der Zeitung the Guardian das sechste Londonder Barcamp statt.

In 2 Wochen werden schon die ersten Tickets vergeben (genauer Tag und Uhrzeit werden noch bekannt gegeben). Damit Ihr diesen wichtigen Termin nicht verpasst, folgt uns auf twitter, tragt euch in den Reminder auf der Website ein, macht euer Häkchen bei Upcoming und und und...

Yahoo! Currency Converter - mein Lieblingsprojekt ist live

nospam@example.com (Dirk Ginader) — Wed, 17 Dec 2008 00:00:00 +0000

Vor ca. einem 3/4 Jahr entwickelten mein Kollege, der User Experience Designer Graham Beale, und ich Ideen für einen Prototype eines neuen Währungsumrechners für den weltweiten Relaunch von Yahoo! Finance. Wir wollten Features die wir so noch nirgends im Internet gesehen hatten. Wir wollten Konvertierung ohne Reload, eine Suche nach Währungsnamen wie in der Firefox 3 "awesome bar", totale Barrierefreiheit, noch viel mehr und das alles natürlich in Echtzeit.

Knapp ein Jahr, viele Usertests, viele neue Ideen, viel Screenreader testing mit meinem Kollegen Artur Ortega und sehr viel Entwicklungszeit später ist gestern nacht das Ergebnis online gegangen!

Über die vielen Screenreader spezifischen Tricks die wir hierfür angewand und zum grossen Teil neu entwickelt haben muss ich unbedingt noch gesondert Bloggen. Bis dahin wünsche ich viel Spaß mit dem neuen Yahoo! Currency Converter und empfehle einfach mal die Anwendung nur mit der Tastatur zu bedienen, Javascript mal ganz auszuschalten oder natürlich einfach mit der tollen Währungs-Suchfunktion zu spielen .

Yahoo! Currency Converter - my favorite project is now live

nospam@example.com (Dirk Ginader) — Wed, 17 Dec 2008 00:00:00 +0000

About 9 months ago my fellow co-worker, the User Experience Designer Graham Beale, and I started developing ideas for a prototype of a new Currency Converter for the worldwide relaunch of Yahoo! Finance.

We wanted Features we haven't seen like this in the Internet so far. We wanted conversion without a page reload, searching for currencies like in the Firefox 3 "awesome bar", total accessibility, much more and of course everything in realtime.

About a year, many user tests, many new ideas, a lot of Screenreader testing with my fellow co-worker Artur Ortega and even more time developing, the result went online yesterday night!

I need to blog about the many Screenreader specific tricks, we used and for a large part also created for this, separately. Until then I wish you lots of fun with the brand new Yahoo! Currency Converter and suggest to use the App at one point only using the Keyboard, switch of Javascript or just play with the neat Currency Search .

Technikwürze feiert 3 Jahre Pfeffer im Ohr - ich feiere mit

nospam@example.com (Dirk Ginader) — Tue, 16 Dec 2008 00:00:00 +0000

Gestern feierten David Maciejewski Stefan Nitzsche, Sascha Postner und ich das 3-jährige Jubiläum des wichtigsten deutschen Webstandards Podcasts Technikwürze.

Die Sendung schaffte es schon in den ersten Minuten das humoristische Niveau der folgenden 82:57 Minuten gnadenlos festzulegen sodass ich, als ich heute morgen in der Tube saß, immer wieder von meinen Mitfahrern schräg angeschaut wurde, da ich konstant kichernd und grinsend meinem iPod lauschte

Meine Tonqualität war zwar leider sehr bescheiden (man hört quasi die den Ärmelkanal rauschen... ) aber Spaß hat es trotzdem gemacht.

Reinhören!

OMG! web output finally has it's own design!

nospam@example.com (Dirk Ginader) — Sun, 14 Dec 2008 00:00:00 +0000

I really didn't expect this myself.

More than a year ago I already had a design idea and did a mockup in Fireworks. A working HTML Dummy was quickly done. Then I had a look into how to build Templates in Serendipity (the Software used for this blog) and instantly lost any interest in ever finishing this.

Serendipitously the old Design was so incredibly ugly and the Code so painfully invalid that the few times I had so see it myself made me being so ashamed of it that I eventually had a Sunday full of Smarty (the Template engine used in Serendipity) and tadaaaaaaaaaaa:

The new Design actually was actually launched!