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.

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.

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

Apart from that the native XTC category image function has a further problem: The images have to be uploaded for each category. What next if you used a product image for a category and the product later possibly does’nt exist in this category anymore?

That’s why i prefer the automatic output of category images. Where do this images come from? They are product images from a product within the category.

While it’s quiet complicated to extend XTC with functions like these there is another relatively comfortable way: Through Smarty plugins.

The well documented and flexible parsing engine allows to use different plugins and to extend XTC without hacking any core files.

How does it work?

Step 1/2 – install the plugin

Download the Smarty plugin here and extract the file to the directory [XTC-Wurzelverzeichnis]/includes/classes/Smarty_2.6.14/plugins/ on your server.

Schritt 2/2 – Customise your template

Open the file

[XTC-root directory]/templates/[Your Template]/module/categorie_listing/categorie_listing.html

find this line

and comment it out. (Simply insert {* before and *} after)

After this line insert:

and save the file.

Ready

The attribute ready stands for the automatic output. It’s your choice to set it to true to output the image at random or to false to output first found image.

Attention: This script searches the database recursively for product images. So if you have a large amount of nested sub categorys without product images within you should not use this script for perfomance reasons.