Update: When Mozilla released Firefox 6 short after this post was published and I don’t want to touch the plugin on each firefox update I set the maximum version in the plugin to *.*.*

FlashTracer is a amazing plugin for Firefox, which displays the contents of the flashlog.txt in the sidebar. Unfortunately the author didn’t mark the plugin as compatible with Firefox 4 and 5 yet, so that it’s impossible to install it the usual way. However there are some alternatives:

• Flashbug shows flashlog.txt in Firebug – but in my oppinion it’s unusable: After page refresh and even after something was traced, you have to scroll down manually to see the message and there’s also no way to clear the log
  
• Flash Tracer for Firebug also pretends to display flashlog.txt in Firebug but doesn’t with current Firefox and Firebug versions
• Vizzy Flash Tracer is a nice Log Viewer for flashlogs. Though usage is unpractical, because it is a standalone application and so you always have to switch between Flash Builder, Firefox and Vizzy windows or arrange them artfully.
• Eclipse Log Viewer also is a nice Log Viewer, which integrates as View in Eclipse. Usage is also complicated with this, because you have to switch between Firefox- und Flash Builder.

So there are some ways – for Air applications Vizzy and Eclipse Log Viewer surely are good solutions and the latter is also great to display other log files (eg. PHP error log, MySQL slow query log…). Though with none of them it’s possible to view the application/movie and it’s trace output at the same time in the same window which however is essential for most use cases. So longing for the good old FlashTracer-Plugin got bigger – so big that i finally grabbed the original plugin and modified/replaced the install.rdf and so made it installable again. The “new” plugin has another ID and isn’t bound to the original update site, so that it is quasi independent.

Finally here’s the link: FlashTracer for Firefox 4 und 5
(Installation and setup as described here)

Wie immer steht und fällt alles mit einem fundierten Konzept. Stichwort Usability: die Spezies Mensch kann am besten mit einer strukturierten Umgebung umgehen. Also die Ärmel hochgekrempelt und ein Plan entwickelt.
Nach der anfänglichen Ideensammlung und -bewertung sieht man sich jedoch zunehmend mit der Entscheidung konfrontiert, zwischen Alternativen der Umsetzung wählen zu müssen. Ein solches Dilemma kann sich bei der Arbeit an Fanpages dadurch ergeben, dass man sich von vornherein in einem fremden Kontext bewegt und präsentiert. Die zu treffende Entscheidung ist also, ob man seine Inhalte stilistisch an Facebook angleicht, oder das Layout betont davon abhebt. Variante eins birgt Homogenität und das Gefühl den gewohnten Nutzungskontext nicht zu verlassen. Variante zwei die Möglichkeit gezielt und differenziert Emotionen anzusprechen. Als sehr gelungene Umsetzung eines facebook-nahen Layoutes kann wohl ohne Zweifel die Shopapplikation gelten, die smatch.com seinen Partnern wie frontlineshop.com anbietet.

• http://apps.facebook.com/frontlineshop/

Dem gegenüber präsentiert sich Mercedes Benz betont differenziert vom Layout der umgebenden Plattform.

• http://www.facebook.com/MercedesBenz

Im direkten Vergleich wird die Motivation der unterschiedlichen Umsetzungen offenbar. Mercedes Benz lebt vom Image „mehr“ als nur ein Automobilhersteller zu sein. Es geht bei der Fanpage demnach primär darum, dieses Bild gezielt mit den Mitteln des eigenen Coporate Designs in den Köpfen der Betrachter zu verankern. Frontlineshop.com hingegen hat weniger Interesse daran, sich dem potenziellen Kunden gegenüber als Unternehmen zu materialisieren. Der Fokus liegt eben nicht auf der Präsentation der Firma, sondern auf eher den Produkten.

Weiterhin muss überlegt werden, wieviel Informationen man auf einer Fanpage überhaupt unterbringen möchte. Fest steht, je mehr Informationen man unterbringen will, desto höher ist die Gefahr der Unübersichtlichkeit. Gleichzeit steigt die Notwendigkeit einer Struktur, die das Navigieren vereinfacht.

Im Bezug auf Fanpages ist hier die Anzahl an Tabs das zu betrachtende Nadelöhr. Jede Seite einer Fanpage wird über einen Reiter mit maximaler Breite von 106 Pixel angesprochen. Angesichts der verfügbaren Gesamtbreite von 520 Pixel schieben sich „überschüssige“ Reiter in eine Erweiterungsliste, die über das Pfeilsymbol rechts in der Navigation aufgerufen werden kann. Das bedeutet, dass nicht mehr als sechs Reiter zur gleichen Zeit in der Navigation erscheinen. Es besteht also die Eventualität, dass Informationen auf Seiten in der Erweiterungsliste leicht übersehen werden können, da sie nicht im visuellen Fokus stehen. Die Begründung hierfür liegt im Layout der Navigationsleiste. Das Pfeilsymbol hat diesbezüglich mit zwei Nachteilen zu kämpfen. Unglücklicherweise nimmt es den letzten Platz in der Navigationsleiste ein. Zusätzlich präsentieren sich die übrigen Tabs, abgesehen vom aktiven Reiter, in zartem Pastellblau mit dunkelblauer Schrift. Betrachtet man nun Heatmaps, die im Zuge von Usability-Tests via Eyetracking entstanden sind, wird das Problem schnell offenbar. Für gewöhnlich wird der Content einer Webapplikation in Form eines „F“ erfasst.

F Reading Pattern Eyetracking

Anschaulich wird hierbei, dass grundlegend die Position der Navigationsleiste nicht die Schlechteste ist. Problematisch allerdings ist der Umstand, dass die Aufmerksamkeit nach rechts hin abnimmt, soweit kein Item den Blick des Betrachters auf sich zieht.

Im Bezug auf Customtabs erweisen sich deren vorgeschriebene Abmaße als Flaschenhals. 520 Pixel – das ist wahrlich nicht viel, um große Mengen Content nebeneinander unterzubringen. Da liegt ein Argument natürlich auf der Hand, denn die verfügbare Höhe ist nicht beschränkt. Scrollen bedeutet zwar Arbeit, grundsätzlich aber kein Nachdenken. Fest steht allerdings, dass je länger ein Customtab ist, desto mehr Inhalt liefert er. Sofort wird wieder die Erinnerung an Proportionalität zwischen der Informationsmenge und dem Anspruch auf Strukturierung wach.

Ist weniger also mehr oder bringt viel auch viel? Fest steht: dem Erfolgsfaktor Usability muss bereits in der Konzeption mehr Beachtung geschenkt werden. Das darf aber nicht das einzige Mal sein, dass man sich über die Gebrauchstauglichkeit von Applikationen auf Facebook Gedanken macht. Denn die stetige Dynamik bedingt auch eine stetige Anpassung. Dieser Faktor ist speziell im Kontext eines sozialen Netzwerkes erfolgsentscheidend. Immerhin sind Menschen hier noch viel weniger als sonst im Netz explizit auf der Suche nach Informationen, was den Anspruch steigert, sie erst gar nicht suchen lassen zu müssen.

Kurz gefasst, ist das einer der eingeschleiften Arbeitsabläufe beim Erstellen von HTML- Templates. Erst recht, wenn nach dem groben Behau einer Website-Skulptur deren Makeup via CSS folgt, wird der ständige Wechsel zwischen Editor und Browser zum Mantra.

Befasst man sich mit der Thematik Customtabs auf Fanpages zu erstellen wird schnell offenbar, dass dieses Prinzip so nicht funktioniert bzw. um einiges umständlicher ist. Der von Facebook gelieferte Zugang, um eigenen Content mittels Quelltext zu hinterlegen, ist ein Formular im Browser mit einer Breite von 300 Pixeln. Das bedeutet, dass mit viel gutem Willen knapp 50 Zeichen nebeneinander passen. Dieser Wert kann schwanken, da innerhalb der Eingabemaske kein Monospace-Font verwendet wird. Wer also ansonsten Wert auf sauberen Codestyle legt kommt hier schnell an die Grenzen der Übersichtlichkeit, da Einrückungen und lange Attributsbezeichnungen die Zeile zum Umbrechen veranlassen.Allein diese Gesichtspunkte sind wohl Motivation genug, um sich einen Workflow anzueignen, der eine probate Alternative zum Coding innerhalb des FBML- Formulars darstellt.

So kommt an erster Stelle wieder der gute alte Editor ins Spiel. Mit vertrauten Eigenschaften wie Monospace- Font, Codehighlighting und einer Zeilenlänge über fast die komplette Bildschirmbreite lässt er für Programmierer ein familiäres Verbundenheitsgefühl aufkommen und ist Garant für systematischen (und somit übersichtlichen) Codestyle. An zweiter Stelle gilt es umzudenken. Um ein HTML- Template im Browser darstellen zu lassen, bedarf es einiger Tags, die beim Erstellen von Customtabs nicht zulässig sind. Die Lösung: ein Dummytemplate. Dieses besteht grundsätzlich aus einem Blockelement innerhalb der Bodytags, welches die essenziellen Styles enthält:

• eine Breite von 520 Pixeln
• overflow: hidden

Innerhalb dieses Elementes kann dann munter Quellcode hinterlegt werden, welcher die Inhalte beherbergt, die im Customtab der Fanpage erscheinen sollen. Ist alles auf einem Stand, der zufriedenstellend ist, gilt es lediglich diesen Quellcode zu kopieren und im FBML- Formular einzufügen. Nebenbei bemerkt ist es sinnvoll vor dem Einfügen ein paar Zeilenumbrüche im Formular zu setzen. Die Begründung: Die Darstellung des Formulars inklusive seines Inhaltes funktioniert nicht immer fehlerfrei. So kann es schon mal vorkommen, dass einem die letzte Zeile des Quelltextes nicht angezeigt wird und man annimmt einen Fehler gemacht zu haben, indem man ein Tag nicht geschlossen hat.

Aber HTML ohne CSS ist wie Currywurst ohne Pommes. Der saubere Weg ist demnach, Stylesheets in einer externen Datei zu definieren, auf welche innerhalb des HTML- Templates verwiesen wird. Grundsätzlich kein Problem bei der lokalen Entwicklung über den oben beschriebenen Weg. Im Handumdrehen ist eine Datei angelegt und mit Styledeklararionen befüllt. Einmal eingebunden, werden Änderungen an der Datei anstandslos übernommen und geben direkte Auskunft über das Können ihres Bearbeiters.

Arbeitet man an einer Fanpage, verhält sich die Sache etwas anders. Hat man das Template eines Customtabs inklusive zugehöriger Stylesheets entwickelt, kopiert man nun den Quelltext in das FBML- Formular und verweist auf die CSS- Datei. Nach unten scrollen, speichern, Customtab anklicken und das Ergebnis begutachten. Der beste Fall ist nun, dass alles so ist, wie man es sich wünscht. Hand auf´s Herz… das passiert eher selten. Eigentlich gibt es immer Dinge, die einem erst auffallen, nachdem man seinen Quellcode auf Facebook hinterlegt hat. Das ist der Punkt, an dem man sich selber zur Disziplin ermahnen muss.

Zu frühe Migration des Quellcodes bedeutet häufig, dass man nicht den als umständlich erscheinenden Weg geht, Änderungen am Dummytemplate im Editor vorzunehmen. Man neigt dazu, den Code gleich im Formular ändern zu wollen, immerhin repräsentiert es den kürzesten Weg zwischen Code und Darstellung und führt zu einem schnellen Ergebnis. Beim Anblick des Quelltextes im Formular wird allerdings das eingangs angesprochene Problem wieder offenbar: Der Code ist wüst über Zeilenumbrüche verteilt und die Codestelle zu finden, die es zu ändern gilt, avanciert zur höheren Aufgabe. Eine versehentlich falsche Änderung ist nicht mehr wie im Editor über die vertraute Tastenkombination Strg + z zu revidieren. Hinzu kommt, dass man nun nicht mehr nur eine änderungswürdige Stelle im Code hat, die es zu finden gilt.

In diesem Zusammenhang bedarf es auch eines Umdenkens, was die Deklaration von Stylesheets angeht. Auch bei größter Anstrengung bezüglich der Selbstdisziplin macht es Facebook einem hier nicht so einfach. Spätestens ab dem Moment, in dem man feststellt, dass jede Änderung an der CSS- Datei bezüglich ihrer Wirkung auf die Fanpage effektfrei bleibt, sollte man der Ursache auf den Grund gehen.

Die Erklärung des Phänomens ist einfach. Um den Quelltext in die Plattform einzubinden, durchläuft dieser ein Preparsing. Damit wird gewährleistet, dass Quellcode, der nicht den Vorgaben entspricht (beispielsweise unzulässige Tags enthält), stillschweigend gelöscht wird bevor der Browser beginnt, den Code zu parsen. Genau das geschieht auch mit extern definierten Stylesheets. Diese werden allerdings nicht bei jedem Aufruf des Customtabs neu geparst. Einmal auf eine CSS- Datei verwiesen, wird diese verarbeitet und serverseitig gespeichert. Der Effekt: Ändert man die Datei im Nachhinein, können die Änderungen nicht übernommen werden da lediglich am Dateinamen im Einbindungspfad detektiert werden kann, ob diese Datei schon einmal eingelesen wurde. Ändert man also eine CSS- Datei ohne ihren Namen zu ändern und diesen korrekt im Quelltext einzubinden, besteht kein Anlass die Datei erneut zu parsen.

Ändert man mit jeder Änderung der CSS- Datei also ihren Namen, funktioniert alles zufriedenstellend. Das kostet freilich ein bisschen mehr Zeit und Mühe. Im Gegensatz zum Zeit- und Nervenaufwand, der einen ansonsten erwartet ist das aber sicher zu verschmerzen.

Damit wird jedem der Content-DIVs eine zusätzliche Klasse csc- mit fortlaufender Nummer hinzugefügt.

Nachdem sich alle Beteiligten wieder angezogen haben und die Gürtel auch wieder das Festhalten der Hosen übernahmen, bekamen wir Zugang zu Deutschlands größter Sortieranlage. 60.000 Pakete und 36.000 Dokumente pro Stunde werden über den 6.500 Meter langen Hauptsorter verteilt. Und dank Six Sigma verfehlt nur jede 30.000ste Sendung ihren Empfänger. Der ganze Bereich der Sortieranlage hatte den Charme eines gut strukturierten Ameisenhaufens. Abseits des markierten Gehweges für Besucher wuselten Packer, Zollbeamte, Sortierer und Dispositeure auf den unterschiedlichsten Gefährten (Fahrrädern, Rollern oder Gabelstablern)  durch die Halle.

Der Abschluss der Besichtigung galt den vier Umschlagplätzen (Alpha, Bravo, Charly, Delta) des Luftfrachtdrehkreuz. Aus sicherer und trockener Entfernung konnten Boing 757, Airbus A 300, McDonnell Douglas 11, Tupolew Tu-204 und verschiedene Turboprop-Maschinen beim Landen und Be- und Entladen bewundert werden. 1.500 Tonnen pro Werktag werden in 46 verschieden Flugziele gesandt. Beachtliche Leistung.

Nach drei Stunden interessanter Fakten, Eindrücke und Geräusche war es Zeit mit dem herkömmlichen Auto die Heimfahrt anzutreten. Auf diesem Weg nochmals vielen Dank an die piké Lifestyle GmbH für die Einladung und an die DHL für so viel spannende Transparenz.

Daraufhin war die Überlegung, die “Thumbnails” nicht über die BE- sondern die FE-Funktion (also IMAGE) zu erzeugen. Zum einen ist es damit möglich, zu erfassen, ob das Bild erfolgreich verkleinert wurde und zum anderen kann man sich so den File-Cache vom Frontend zu Nutze machen Das erste und auch einzig brauchbare Ergebnis, auf das ich bei der Suche nach “cObject im Backend” stiess, war dieser Post. Es hat zwar nicht funktioniert aber immerhin konnte ich mir hier die nötigen Includes zusammenklauben.

Ich hatte ursprünglich vor, die Lösung dort als Kommentar zu hinterlegen. Da ich aber zu Recht als Spam abgewiesen wurde, poste ich sie jetzt hier. Vorweg: Der Titel ist irreführend – ich habe es nicht geschafft bzw. nicht die Geduld gehabt, das IMAGE-Objekt im Backend zu nutzen. ABER: Um ein Bildchen mit den FE-Methoden zu verkleinern und auszugeben, braucht es nicht unbedingt das IMAGE-Objekt. Die Methode tslib_cObj->getImgResource() genügt.

Hier also kurz und knackig die Lösung (sorry für die wüste Form):

Das grundlegende Problem war, dass das in TYPO3 verwaltete Template bei jeder Änderung in WordPress manuell adaptiert werden musste. Die Lösung dafür war denkbar einfach: Zunächst wurde ein Skript entwickelt, das das Template von TYPO3 bezieht. Dies funktioniert über eine Kombination aus cURL und dem PageType in TYPO3. Dafür wurde das Standard-PAGE-Objekt im TS-Setup dupliziert und für den Seitentyp 300 etwas angepasst:

Das Ergebnis wird im WP-Frontend durch das Skript mittels cURL abgerufen und sieht folgendermaßen aus: Mit TYPO3 generiertes Template. Dies geschieht für jede im Skript konfigurierte Sprache aus Performance-Gründen nur bei Übermittlung eines geheimen Parameters. Anschließend werden die empfangenen Inhalte in temporären Dateien abgelegt.

Nachdem das Skript die richtige Sprache zur Ausgabe im WordPress-Theme gewählt und das passende Template eingelesen hat, passt es mittels preg_replace noch die Links zu CSS- und JS-Dateien und TYPO3-Links an, teilt das Template mittels explode() in Header, Body und Footer auf und schreibt dies in ein $GLOBALS-Array. Die Bestandteile werden schließlich an passender Stelle im Theme ausgegeben.

Damit ist auch schon die optische Kopplung von Website und Blog erledigt. Der zweite und wesentlich anstrengendere Schritt bestand darin, die Suchfunktionen beider Systeme miteinander zu verbinden. Zwei günstige Umstände machten die Vorüberlegungen dazu jedoch relativ einfach: Zum einen erlaubt TYPO3 eine wunderbare Erweiterungsmöglichkeit mittels XCLASS und zum anderen kann in WordPress-Feeds ein Suchbegriff mittels GET ausgewertet werden. Der weitere Weg bestand also darin, die tx_indexedsearch-Klasse mit XCLASS zu erweitern und dabei die Ergebnisse aus WordPress mit Hilfe der wunderbaren Erweiterung TW RSS Feeds einzubinden. Das Ergebnis lässt sich über die Suche oben rechts bestaunen.

Letztendlich hat die Aktion zwei Tage in Anspruch genommen und läuft weitestgehend stabil. Leider fehlt z.Zt. die Zeit, den Vorgang in einer T3X und einem WordPress-Plugin zu manifestieren. Auf Anfrage veröffentliche ich jedoch gern unbedenkliche Teile des Quellcodes.

Netzelf developed this nice mootools-based modal-script with the following features:

• Unobtrusive, lightweight Javascript (1 Class, 6,1kB compressed)
• Easy to install and use
• Modal window based on Slimbox
• Loading content via Ajax or Iframe
• Support for Tabs
• Support for caching loaded content
• Lots of options
• Fully customizable language
• Fully customizable design (via CSS)
• At least three events: load, failure and success

You can find the documentation and downloads on the Yamoodow project page:

http://netzelf.de/releases/yamoodow/

Have fun

Hörspiel Leipzig und Netzelf tun es bereits: Mit dem von Ralf Kirmse produzierten und Jörg-Uwe Schröder gesprochenen Hörbuch “Die Rückkehr der Wölfin” von Stefan Haffner wurde eine Novum in der Hörbuch-Welt umgesetzt.

Der zweite Band der Trilogie um Kommissar Martin Held auf MP3-CD wurde von Netzelf nicht nur optisch durch die Gestaltung des Covers und Booklets sondern auch um ein animiertes Menü – kompatibel für Mac und PC – bereichert. Neben einem integrierten Player und Zusatzinformationen zum Autor, dem Sprecher und zum Inhalt des Romans, enthält das Menü auch persönliche Interviews mit den Beteiligten. Außerdem ist es natürlich problemlos möglich, das Hörbuch auf den eigenen MP3-Player oder iPod zu übertragen und so schnell in den mobilen Hörgenuss zu gelangen.

Das von Hörspiel Leipzig geschaffene Hörvergnügen wurde so mit einem Plus an Hintergrundinformationen ansprechend und nutzerfreundlich von Netzelf aufgewertet.

Fakten:

• Von Stefan Haffner
• Produziert von Hörspiel Leipzig
• Gesprochen von Jörg-Uwe Schröder
• Erschienen im Mitteldeutschen Verlag
• Präsentation des Hörbuchs unter dem Titel “Ein historischer Leipzig-Krimi wird zum Hörbuch. Eine Leipziger Erfolgsgeschichte.” am 14.3.2009 bei Leipzig Liest in der Alte Handelsbörse
• Vorstellung am 15.3.2009 auf dem ARD-HörbuchForum auf Leipziger Buchmesse
• “Lerchen und Löwen” bei Amazon

Download-Link: com_gigcal-102_fixed_by_netzelf.de.zip