Eine Box kann 30 Millionen Dokumente indexieren, mal 34 gibt etwas mehr als eine Milliarde. Das ist in etwa sowiel, wie google.com im Jahr 2000 im Index hatte. Das ist zwar schon 10 Jahre her, aber wenn man bedenkt, dass man dafür heute keine Schar Informatiker mehr braucht und das relativ einfach im Keller installieren kann, finde ich das schon noch ziemlich beeindruckend.

Die Zahlen, die ich von Sabine Dufaux hab, spiegeln, dass Social Media in unserem Alltag einfach stattfindet offline und online / intern und extern / privat und geschäftlich. Dazu hab ich mir ein paar Thesen überlegt (Danke an meinen Sparringpartner Jürg für die Idee) So konnte ich der eher klassischen Agenda 'soziales Leben' einhauchen.

1. Menschen kommunizieren, generieren Inhalte
2. Realität ist auch online
3. Privat und Geschäft verschmelzen
4. Intern wird extern und umgekehrt
5. Mauern und Hierarchien fallen

Bildquelle: dpa und taz

Aus der Praxis gibts Jans Geburtstagskuchen (der Teil der Kultur ist und zum Kommunikationsinhalt wird) und eine interne Frage von Samuel Peyer, die auf Twitter (extern) beantwortet wird. Wie aus einem Mitarbeiterprojekt wiederum externe Kommunikation wird, erzähl ich am I like Beispiel. Danke Mihi Risch für die 100 Aufkleber, die ich verschenken darf.

Mein Fazit ist: Kommunikationsleute werden künftig noch weniger trennen zwischen interner und externer Kommunikation und die Unternehmenskultur wird mehr vom Dialog geprägt. Persönliche Meinungen bereichern die bisherigen Botschaften oder ersetzen sie gar. Ich denke, die Herausforderungen für Firmen liegen beim Verstehen und Respektieren der neuen Kommunikation, der Sozialkompetenz (die zur Medienkompetenz gehört), Vertrauen und Transparenz. Aber all meine Gedanken dazu kann ich hier nicht wiedergeben. Wer spontan noch dabei sein möchte, ist herzlich eingeladen (heute, 18.30 Uhr), ein Kommentar hier und ein Zugticket nach Luzern reichen. Sonst ist die Präsi hier.

Wenn Ihr noch Ideen habt, nehme ich die gerne bis 17.30 Uhr in die Präsi auf.

Der Kult-Taschen-Hersteller Freitag bringt eine neue Kollektion mit dem schönen Namen "Reference Line" heraus. (persoenlich.com berichtet). Die neue Linie besticht durch Eleganz, wobei sich die Marke ihrer Grundsubstanz treu bleibt und weiterhin auf LKW-Planen setzt.

Eine schöne Micosite macht Lust auf die neuen Taschen (man muss nur ein wenig Geduld mitbringen, dann "entblättert" sich der Text). Umgesetzt wurde die Microsite übrigens von Namics ;-)

Nicht nur, weil ich gerade so die Präsi von Thomas Lang sehen durfte, gespickt mit fetzigen Beispielen, wie zugara. Dort kann ich dank Augmented Reality tatsächlich Kleidungsstücke virtuell probieren und dann gings noch um Online Wine Handel. Da war ich vom Flickrn und Twittern abgelenkt.

Die Blogwerker Olivia Menzi, Moritz Adler treffen und Andreas von Gunten herzlich die Hand schütteln und natürlich auch den emexblogger Karsten Fuellhaas bei der Arbeit sehen und mit Bernadette Bisculm Kaffee trinken - sind wert, gelegentlich doch eine Messe zu besuchen (ich konnte übrigens die Highheels nicht sein lassen - und jetzt tun mir die Füsse weh).

Dann kamen Marcel Albertin und Felix Kaiser mit ihrer Prezi. Hab ich die eigentlich das erstemal live gesehen? Präsi und Prezi haben mich beeindruckt und Wandersocken für 39.90 CHF (!) auch. Im Dialog zeigten die Jungs Visionäres und den Praxis-Check für E-Commerce. Jetzt versteh ich, warum ich Multichannel und PIM (Product Information Management) bei uns oft in einem Atemzug mit E-Commerce höre.

Die beiden Referenten (die ich spontan Namics Pirates taufte) waren zu bescheiden, einen Vortrag ein zweites Mal zu posten. Drum mach ich das jetzt.

Prezi: Potenzial und Stolpersteine. E-Commerce zwischen Vision und Realität

jQuery ist ein mächtiges Framework welches das Arbeiten mit JavaScript stark erleichtert. Mittlerweile ist jQuery mit Abstand das verbreitetste JavaScript Framework der Welt. Ganze UI-Elemente wie Tabs, oder Funktionsblöcke wie etwa eine Bildergalerie sucht man jedoch - bei jQuery selber - vergeblich. jQuery stellt lediglich zahlreiche mehr oder minder kleine Helfer zur Verfügung, welche es ermöglichen, solche Dinge mit geringem Aufwand zu erstellen.

Nun ist es natürlich nicht praktisch komplexe Funktionen wieder und wieder - und für jedes Projekt neu - zu schreiben. Hier kommen die "jQuery Plugins" ins Spiel. Ein jQuery Plugin ist in der Regel eine Erweiterung von jQuery und kann beliebig komplexe Funktionen - von History Handling über UI-Elemente bis zu Lightboxen - bereitstellen.

Aufbau eines Plugins

Die jQuery Plugin API dient dazu, jQuery um neue Funktionen zu erweitern:

// jQuery um Tab Funktion erweitern:
$.fn.tabsPlugin = function(userOptions) {
   // Plugin Code...
}

Plugins sind meist sehr ähnlich aufgebaut. Sie werden in der Regel auf ein Set von HTML Elementen angewendet und man kann das Verhalten des Plugins mit Optionen etwas beeinflussen. In etwa so:

var options = {
     activeTab: 2
};
$('div.tabs').tabsPlugin(options);

Damit würde man etwas HTML Code...

...in ein Modul verwandeln das etwa wie folgt aussieht:

Das Plugin hat dabei meist eigene Optionen, sogenannte Defaults. Diese werden durch die Optionen, welche der Benutzer dem Plugin beim Aufruf mitgegeben hat ergänzt:

var options = $.extend({}, $.fn.tabsPlugin.defaults, userOptions);

Innerhalb des Plugins, wird danach die entsprechende Plugin-Funktion auf jedem einzelnen der übergebenen Elemente ausgeführt. Dabei muss darauf geachtet werden, dass die Funktion nur auf das jeweilige Element Einfluss hat, damit mehrere Elemente auf der Seite die gleiche Funktionalität haben können.

var $tabSets = $(this);
$tabSets.each(function(){
     // Auf jedem Element die gewünschte Funktion ausführen
     var $tabSet = $(this); // Aktuelles Tab-Set
     ...
});

Nun soll's ein bisschen anders sein...

Ein Problem vieler Plugins ist, dass sie zwar meist ihre Aufgabe gut erledigen, nicht selten auch viele Optionen mitbringen, aber nicht flexibel oder erweiterbar sind. Nehmen wir ein Plugin, das aus einem Set an HTML Elementen ein Tab-UI generieren soll. Dieses Plugin übernimmt das Sammeln der Tabs und zugehörigen Panels, sowie das Ein- und Ausblenden der Panels beim Klick auf ein Tab. Ausserdem bringt es noch einige Optionen mit, womit der Benutzer festlegen kann, welche Klassen die ausgewählten Tabs haben sollen und welches Tab zu Beginn aktiviert werden soll. Ist doch Perfekt, nicht?

Was nun, wenn der Inhalt des Panels beim Aufruf der Seite noch nicht vorhanden ist sondern erst nachgeladen werden soll, wenn man das entsprechende Tab aktiviert? Herkömmliche Plugins versagen hier oft und gewünschte Funktionalität muss direkt im Plugin eingefügt werden. Dabei geht die Update-Fähigkeit verloren und es leidet die Wiederverwendbarkeit und Sicherheit des Projekts. Im Wissen, dass der Benutzer vielleicht mit dem Plugin noch weiter Anwendungsfälle hat neigt der Autor des Plugins dazu, möglichst viele Funktionen in sein Plugin zu stecken, da er es ja flexibel halten möchte. Damit wird es gross, schwerfällig und unübersichtlich und verfügt über eine Menge Funktionen, welche viele unter Umständen gar nicht brauchen. Der Autor des besagten Tab-Plugins muss dabei an Tastatur-Bedienbarkeit, Ajax- und History-Fähigkeit sowie vieles mehr denken.

Evented jQuery Plugins = flexibel & erweiterbar

Eine Lösung für dieses Problem lautet Custom Events oder kürzer - Evented. Dabei muss sich der Plugin Autor überlegen, welche grundlegende Funktionen das Plugin benötigt und stellt diese in einer möglichst schlichten Form zur Verfügung.

Ein Tab-UI-Element hat im Grossen und Ganzen eine Funktion: Beim Klick auf ein Tab, soll das zugehörige Panel aktiviert und alle anderen deaktiviert werden. Wir brauchen also eine "activate" Funktion. Ausserdem müssen zu Beginn alle Tabs gesucht, und die zugehörigen Panels gespeichert werden. Dazu benötigen wir eine "setupTabs" Funktion. Des weiteren sollten die Panels wissen, zu welchem Tab sie gehören: "setupPanels". Beim Aufruf der Seite sollen diese beiden Funktionen ausgeführt werden und das erste Tab aktiviert werden, dazu brauchen wir noch eine letzte Funktion, die "initialize" Funktion.

Diese Funktionen sind "Events". Jedes übergebene Set an HTML Elementen wird mit diesen Events versehen. Da der Event damit immer zu einem Tab-Element gehört, kann damit auch das Problem von allfälligen Konflikten mit anderen Tab-Elementen einfach gelöst werden. Wenn auf einer Seite zwei Tab-Elemente vorhanden sind, beeinfluss Tab-Verbund eins den zweiten Tab-Verbund nicht, wenn darauf der activate Event ausgeführt wird:

...
$tabSets.bind("activate",
        function(e, selected) {
            // selektiertes Tab aktivieren
        }
);
...

Events nach Aussen verfügbar machen

Der Trick besteht nun darin, dass diese Funktionen nicht einfach fest in das Plugin integriert sind, sondern das jede einzelne Funktion in ein Array gepackt wird, welches über ein Objekt customEvents von aussen Zugänglich ist. Die Funktions-Array können dadurch ergänzt, oder gar ganz überschrieben werden, bevor das Plugin auf ein Set von HTML Elementen angewendet wird.

var customEvents = {
    initialize: [function(options) {
        this.bind("initialize." + options.namespace,
        function(e) {
            // Tabs und Panels vorbereiten
            //und erstes Tab Aktivieren
        });
    }],

    setupPanels: [function(options) {
        this.bind("setupPanels." + options.namespace,
        function(e) {
            // Panels mit zugehörigem Tab verbinden
        });
    }],

    setupTabs: [function(options) {
        this.bind("setupTabs." + options.namespace,
        function(e) {
            // Tabs suchen und activate Funktion bei klick ausführen
        });
    }],

    activate: [function(options) {
        this.bind("activate." + options.namespace,
        function(e, selected) {
            // Alle Tabs deaktivieren und selektiertes
            // Tab und Panel aktivieren
        });
    }]
};

Events ergänzen

Im unserem Beispiel wollten wir, dass der Inhalt des Panels erst vom Server geladen wird, wenn das Tab aktiviert wird. Die Vorgehensweise ist nun denkbar einfach, man fügt einfach vor der Plugin-Standard-Funktion eine neue Funktion hinzu, welche den Inhalt des Panels via Ajax vom Server lädt. Dabei muss man zu keiner Zeit das Plugin selber verändern. Wenn der Plugin Autor ein Bug-Fix veröffentlich, kann das Plugin einfach aktualisiert werden - die Grundfunktionen werden die gleichen bleiben und die Erweiterung wird nicht tangiert da sie sich ausserhalb des Plugins befindet.

// Neue Funktion vor die bestehende
// activate Funktion schieben:
customEvents.activate.unshift( function(options) {
    // Die Erweiterung auf das Grund-Element
    // (nicht die einzelnen Tabs) binden:
    this.bind("activate." + options.namespace,
        function(e, selectedTab) {
            // Den Inhalt des Tabs hier
            // per Ajax in das Panel laden:
            var url= selectedTab.href;
            $(selected).data('$panel').load(url);
   });
});

Der Kern des Plugins ist dabei lediglich dafür verantwortlich, dass die Default Einstellungen mit den Benutzer-Optionen ergänzt werden und dass danach alle Tab-Elemente die Custom Events erhalten.

Hello World!

Nachdem man dieses erweiterbare und flexible Tabs-Plugin geschrieben hat, ist es natürlich schön, wenn sich der Rest der Welt auch daran erfreuen kann. In meinem nächsten Post werde ich zeigen, wo und wie man ein eigenes Plugin veröffentlichen kann und was dabei zu beachten ist.

Was vor 100 Jahren mit dem ersten Gothard-Tunnel begann, geht heute mit dem neuesten Gotthard-Projekt (dem längsten Tunnel der Welt!) in eine erfolgreiche Zukunft.

Mehr zu Jörg Schlumpf und seinem Gotthard-Projekt kann man übrigens in seinem blog erfahren.

Leider lässt die Reportage ein wenig die weiteren Wirkungsfelder vermissen. Ein paar interessante Insights aus der Sicht von Studenten, Berufsanfängern und Sika-Mitarbeitern gibt es im Experience-blog.

Dort gibt es auch mehr Infos zur Geschichte der Sika.

Wer sich für das ganze Sika 100 Jahre Projekt interessiert. Hier gehts zum Projekt, das wir mit viel Spass und Freude mit der Sika umsetzen durften.

„It is the cycle of capitalism. The story of industrial revolutions, after all, is a story of battles over control. A technology is invented, it spreads, a thousand flowers bloom, and then someone finds a way to own it, locking out others. It happens every time
[ ... und wir sind froh, dass es uns die Monopolisten so einfach machen, denn wir sehnen uns so oft nach Standards und so selten nach Komplexität ...]
As much as we intellectually appreciate openness, at the end of the day we favor the easiest path." (Chris Anderson)
„So it's not shocking that Jobs' iPad-enabled vision of media's future looks more like media's past. In this scenario, Jobs is a mogul straight out of the studio system." (Michael Wolff)

So gesehen erscheint die Frage nach dem Verursacher der Lean-Back-Renaissance wie die Frage nach Henne oder Ei. Auch im monopolistischen Kapitalismus gehören immer mindestens zwei Faktoren dazu eine Situation zu schaffen: Angebot und Nachfrage.

Hinter den Spiegeln

Die Frage hinter dieser Diskussion ist dieselbe, wie die des medienkritischen Diskurses am Ende des letzten Jahrtausends: Welchen Wert hat individuelle Selbstbestimmung, Schaffenskraft und Kreativität gegenüber großen monopolartiger (Medien-)Unternehmungen, die zu einer fragwürdigen Nivellierung von Informationen und Möglichkeiten führen und gleichzeitig Abhängigkeiten schaffen, die auch den aufgeklärtesten Menschen in Unmündigkeit halten können.
Apokalyptiker warnen vor dieser Nivellierung und Unmündigkeit und bauen dabei beständig Widerstände gegen den kapitalistischen Fortschritt in seinem Lauf auf. Gleichzeitig gleiten die Integrierten mit systemkonformer Performance durch die schöne neue Welt und schaffen befreit von Reflexion einen Fortschritt nach dem Anderen.
Michael Wolffs Vergleich von Steve Jobs als einem Mogul aus dem Studio-System aus der Medien-Vergangenheit ist in dieser Hinsicht treffen, aber auch der Vergleich selbst entstammt einer Position aus der Zeit von One-Way-Massenmedien: in diesem Moment ist Wolff ein Apokalyptiker.
Dass nicht hinter jeder individualistischen Position ein so kluger Kopf steckt zeigt die aktuelle Diskussion über google Street View in Deutschland. Hier werden Biedermänner zum Sand im Getriebe und nehmen in der Tiefe des Sommerlochs eine apokalyptische Position ein.
Auch wenn fundamentalistische Kulturkritik aus der Mode gekommen ist, macht es in Anbetracht der oben beschriebenen Diskussionen durchaus Sinn, die Positionen von Apokalyptikern und Integrierten beizubehalten.

Das Modell erweitern

Die Entwicklung im Bereich der sozialen Medien führen neben den Polen von Apokalyptikern und Integrierten zu einer weiteren Unterscheidung, die von David White als Präzisierung des Begriffs „Digital Natives" eingeführt wurde, und von Peter Kruse in dem sehenswerten (!!!) Vortrag auf der re:publica 2010 eindrucksvoll veranschaulicht und empirisch gestützt wurde: die Unterscheidung in „Digital Visitors" und „Digital Residents". Kruse sieht hier einen Diskurs unterschiedlicher Werte, der sich in der Frage unterscheiden, ob Menschen das Internet als gleichwertigen Kommunikationsraum in jeder Beziehung verstehen und nutzen.

Kruse sieht die „Residents" als Befürworter und Nutzer des sozialen Netzes und offener Standards, die Kontrolle und Hierarchien ablehnend. „Visitors" beschreibt er als Menschen, die in der Entwicklung und Offenheit des sozialen Netzes eine Gefahr sehen. Residents sind so gesehen eher Integrierte, Visitors eher die Apokalyptiker.
(Lesenswert unter diesem Aspekt das Gespräch zwischen Ilse Aigner und Sascha Lobo „Sie werden wieder überheblich" (http://www.spiegel.de/spiegel/0,1518,708305,00.html))
Fruchtbarer ist es jedoch Apokalyptiker und Integrierte als eigenständige Dimension zu betrachten- „Visitors" und „Residents" als eine weitere. Es ergibt sich eine Matrix mit vier Idealtypen, die sich auf Grund der oben beschriebenen vier Pole zuordnen lassen.

Es entstehen neben den oben beschriebenen vier Polen vier Typen, die im Folgen als Prototypen beschrieben werden:

Digitale Skeptiker:
Können sich dem Medium nicht ganz verweigern, beurteilen die Entwicklung jedoch generell kulturpessimistisch und nutzen das Internet nur so wie es gerade notwendig ist. (E-Mail, Nachrichten, Recherche) Street View ist ein guter Aufhänger neuen Medien die Grenzen aufzuzeigen.

Digitale Konsumisten:
Nutzen soziale Medien bestenfalls als „Flagge zeigen" aber nicht als Alternative zur alltäglichen Kommunikation. Orientieren sich an Standards, kaufen online ein, schauen Filme etc. Street View wird eine tolle neue Möglichkeit Informationen zu gewinnen.

Digitale Anarchisten:
Sind ausgesprochen aktiv in sozialen Medien und dem Mainstream gefühlt immer eine Plattform voraus. Bewerten geschlossene Systeme und Monopolbestrebungen negativ. Haben in der Regel kein iPhone und ihr Facebook Profil in den letzten zwei Monaten zunehmend vernachlässigt. Stehen Themen wie Street View nicht wegen der Privatsphäre sondern der Allgegenwärtigkeit von google skeptisch gegenüber.

Digitale Konformisten:
Neben alles was kommt und sind spätestens dann auf einer Plattform vertreten, wenn die im heute Journal einen Beitrag mit „früher war es mySpace und SecondLife - heute ist es ..." einleitet. Konformisten streben nach Standards, Sicherheit und Kontinuität. Sie haben verstanden, dass ihre Privatsphäre online genauso sicher ist wie offline. Schnelle Konformisten haben Bilder aus ihrer Strasse schon längst an google und ihren Facebook Account gesendet.

Definitiv ins Blaue gedacht. Mir macht es grade Spaß meine Freunde, Mitarbeiter und Prominenz in die Schubladen zu stecken ...

Der Informatiker Dick Stenmark meint, dass wenn ein Intranet zur Unterstützung des Wissensmanagements in Gebrauch genommen werden möchte, drei Perspektiven Berücksichtigung finden sollten: Zum Ersten die „information perspective", zum Zweiten die „awareness perspective" und zum Dritten die „communication perspective". Das heisst, ein Intranet sollte nicht nur aktuelle Informationen und wichtige Dokumente bereitstellen, sondern die Mitarbeitenden auch unterstützen mit der täglichen Informationsflut umgehen zu können. Sprich: Funktionalitäten bereitstellen, die die Mitarbeitenden auf neu hinzugefügte Informationen aufmerksam macht, ihnen ermöglicht Favoriten zu setzen oder Seiten zu abonnieren. Mit der „awareness perspective" ist zudem gemeint, dass Fähigkeiten und Expertisen der Mitarbeitenden eingesehen werden können bzw. auch entsprechend nach Kompetenzen gesucht werden kann. Die Suche ist dann auch ein weiteres Element, das unter diese Perspektive fällt und die in den Intranets der Spitäler entweder gar nicht vorhanden ist oder aber nur unzureichende Suchresultate liefert.

Da ein Intranet nebst dem Wissensmanagement auch noch andere Aufgaben zu erfüllen hat, habe ich nebst den Perspektiven von Stenmark die „support perspective" eingeführt. Genau dieser Perspektive kommt insbesondere im Spitalumfeld grosse Bedeutung zu. So geben die Spitalmitarbeitenden mehrheitlich an, dass ein ihre Tätigkeit optimal unterstützendes Intranet ein digitales Instrument zur Unterstützung der Arbeitsprozesse sei. Auch konnte gezeigt werden, dass jene Spitalmitarbeitenden, die das Intranet regelmässig nutzen, auch stärker bei der Arbeit unterstützt werden als andere (siehe Teil 3). Grösstenteils werden die Spitalmitarbeitenden allerdings noch immer nur „teilweise" durch das Intranet bei der Arbeit unterstützt. Intranets bieten demnach im Spitalumfeld viel Potential die Mitarbeitenden bei der Arbeit zu unterstützen - allerdings wird es noch nicht ausgeschöpft. Rasche Verbesserung dürften hier Online-Formulare, -Aufträge, -Bestellprozesse oder dergleichen bringen.

Insgesamt kann der Schluss gezogen werden, dass bei den Intranets im Spitalumfeld derzeit vor allem die „information perspective" im Vordergrund steht. Die Intranets sind für die Spitalmitarbeitenden grundsätzlich ein Instrument, um auf Informationen und Dokumente zuzugreifen. Sie nehmen es also vorwiegend als Speichermedium in Gebrauch. Die drei anderen Perspektiven finden nur wenig bis gar keine Berücksichtigung, das heisst das Intranet wird weder dazu verwendet die Mitarbeitende auf Inhalte aufmerksam zu machen, sie bei der Arbeit zu unterstützen noch um in synchroner oder asynchroner Weise mit Kollegen zu kommunizieren oder mit ihnen zusammenzuarbeiten. Oft unzureichend ist zudem die Benutzerfreundlichkeit der Intranets. So bemängeln viele Mitarbeitenden die Struktur und Übersichtlichkeit der Intranets. Dennoch: Die Intranets der Ostschweizer Spitäler bilden grösstenteils eine gute Basis, um die Mitarbeitenden an die Möglichkeiten und Funktionalitäten eines Intranets heranzuführen. Eine weitere Erkenntnis meiner Masterarbeit ist nämlich, dass sich eher diejenigen Mitarbeitenden mehr Möglichkeiten im Intranet wünschen, die bereits mit einem etwas ausgereifteren Intranet arbeiten. Getreu dem Motto: Der Appetit kommt beim Essen.

Norbert Neininger (der seinen Weblog auch noch Tagebuch nennt), seines Zeichen Unternehmer, Verleger und Präsidiumsmitglied des Verbandes Schweizer Presse, fordert in der NZZ ein Leistungsschutzrecht (exklusives Recht an ihren Inhalten auch im Internet) für Medienunternehmen.

Über diese irreale Forderung, welche Grundprinzipien der freien Marktwirtschaft widerspricht, will ich gar nicht gross reden. Viel tragischer finde ich, dass die NZZ einen so tendenziösen Artikel abdruckt.

So soll das Internet nach Neiniger ein rechtsfreier Raum sei. Nein, nicht rechtsfrei aber sehr kompliziert, so wie die globale Wirtschaft (und das richtige Leben) selbst. Unterschiedliche Rechtsprechungen in verschiedenen Ländern. Es wird nie eine Schweizer Grenze im Web geben -- oder es ist nicht das Web. Und ausserdem sei Wikipedias Ziel nicht die Vermehrung des Wissens, sondern das Erheischen von Marktanteilen, Umsatz und Ertrag. Wo kommt den so was her?

Spannend finde ich auch, dass Verlage über das "Verschenken von Inhalten", "in Unkenntnis der Mechanismen des neuen elektronischen Aufmerksamkeitsmarkts" und wegen dem nicht-funktionieren des Geschäftsmodells der Werbung ganz arg in Bedrägnis geraten sind. Doch am Ende desselben Artikel steht dann, dass "böse" Firmen wie Twitter oder Facebook Milliarden über Werbung einnehmen. Hmm. Welche Unkenntnis und weshalb sind die, die wenig Geld mit Werbung machen die Guten und die, welche viel Geld damit verdienen die Bösen?

Eine schöne Wortkreation finde ich auch das "parasitären Geschäftsmodell" so wie bei Google oder Yahoo. Ist es nicht so, dass diese einen Mehrwert bieten, welcher die User schätzen und anderswo (z.B. beim "Google-Killer" News1.ch [inkl. Herrn Neininger]) nicht finden. Eine Analyse dazu bietet beispielsweise Prof. Stefan Michel vom IMD.

Und nun der zentrale neinigerische "Lösungsvorschlag": Wir ziehen eine Wand hoch und verbieten alles und machen einen auf "Paid Content". Sehr innovative und ein netter Ansatz in einer Welt die von Netzwerkeffekten lebt.

Kritische Leser errinnern sich möglicherweise noch an die Aussage im Artikel, dass Verlage in "Unkenntnis der Mechanismen des neuen elektronischen Aufmerksamkeitsmarkts" agierten. Bingo und zurück zu Feld eins.

Ein Artikel der weder dem Niveau der NZZ gerecht wird noch den Schweizer Verlagen (und deren Verband) einen Dienst tut: «Verlage haben Anrecht auf besseren Schutz»

Und hier noch ein aktuelles Stück Zeitgeschichte des Schweizer Print-Presse:

Gefunden bei Beat Döbeli und noch ein Kommentar bei Peter Haber.

Wie im letzten Post veranschaulicht, setzt Terrific im HTML/CSS Part voll auf OOCSS. In Sachen JavaScript beschreitet Terrific jedoch völlig eigene Wege.

Was bringt's?

Die Hauptvorteile des JavaScript Systems von Terrific sind:

Leichtgewichtige Architektur
Terrific strukturiert die JavaScript-Entwicklung ohne dabei die Entwickler einzuschränken. So können Entwickler weiterhin ihr gesamtes jQuery - Knowhow voll einsetzen und profitieren gleichzeitig von den zahlreichen Features und Möglichkeiten von Terrific.

Modulare Entwicklung
Die gesamte JavaScript-Entwicklung wird durch Terrific modularisiert. So können sämtliche Module einzeln entwickelt und getestet werden und - was noch viel wichtiger ist - ohne Seiteneffekte miteinander kombiniert werden.

Skalierbarkeit
Die Seite wird mit wachsender JavaScript-Grösse nicht durch unzählige DOM-Operationen und Events verlangsamt. Es wird wirklich nur der Code ausgeführt, welcher wirklich von den Terrific-Komponenten benötigt wird.

Einfache Integration
Mit Terrific entwickelte Frontends lassen sich mühelos in die verschiedensten Backendsysteme und CMS integrieren. So kann die Frontendentwicklung komplett vom entsprechenden Zielsystem entkoppelt werden.

Wie haben wir es gemacht?

Wie schon im ersten Post dieser Serie erwähnt, nutzt Terrific die OOCSS-Namenskonventionen technologieübergreifend sowohl für den HTML/CSS Part als auch für den JavaScript Part.

Dies erlaubt es Terrific, einen einheitlichen Bootstrapping-Mechanismus zu verwenden - egal ob es sich dabei um einfache Seiten mit wenig JavaScript-Funktionalität oder komplexe Applikationen handelt.

(function($) {
    var application = new Nx.Application($('.page'));
    application.registerModules();
    application.startAll();
})(Nx.$);

Die einzelnen Zeilen haben es jedoch ganz schön in sich.

var application = new Nx.Application($('.page'));

application.registerModules();

Als Pendant zu den OOCSS-Skins bietet Terrific JavaScript-Skins an - welche im Grunde nichts anderes als Module Decorators sind.
Auch die Dekoration der Module geschieht - wie könnte es auch anders sein - per OOCSS-Namenskonvention. Besitzt ein DOM-Node die Skin-Klasse .skinNewsHighlighted so wird das Nx.Module.News Modul mit dem Nx.Module.News.Highlighted Skin dekoriert.

Um eine Kommunikation zwischen den Modulen zu ermöglichen - ohne mit dem Loose Coupling Gedanken zu brechen - werden in der registerModules-Methode auch noch per Namenskonvention definierte Kommunikationskanäle zwischen den Modulen aufgebaut.

Nachdem also alle Module inkl. Skins und Connectors in der Application registriert sind, kommt der Bootstrap in die letzte Phase.

application.startAll();

• dependencies - Nachladen von Libraries, Plugins etc. via Ajax
• beforeBinding - Daten per Ajax holen, DOM Manipulationen etc.
• onBinding - Events binden
• afterBinding - Default State herstellen, Events triggern etc.

In den häufigsten Fällen werden jedoch nicht alle Phasen, sondern nur die onBinding-Phase benötigt. Terrific kümmert sich dabei um das Timing und die sequentielle Abarbeitung der vier Module-Phasen.

Beispiel gefällig?

Greifen wir das Modul-Beispiel aus dem "letzten Post":"http://blog.namics.com/2010/07/terrific-oocss-part2.html wieder auf.

• Ajax Live-Convertion
• Non-JavaScript Variante mit Convert Button
• Automatische Erstberechnung des aktuellen Werts

Da nicht nach jedem Tastendruck eine Ajax-Berechnung ausgelöst werden soll, sondern nur sobald der Benutzer aufhört zu tippen, benötigen wir das jQuery throttle / debounce Plugin von Ben Alman.

/**
 * Hook function to load the module specific dependencies.
 *
 * @method dependencies
 * @return void
*/
dependencies: function() {
    this.require('jquery.throttle-debounce.min.js', 'plugin', 'onBinding');
}

Alternativ zur Live-Convertion bietet die Non-JavaScript Variante einen zusätzlichen Convert Button. Dieser kann in der JavaScript Variante versteckt werden. DOM Manipulationen werden - um unnötiges Flackern zu vermeiden - in der beforeBinding-Phase durchgeführt.

/**
 * Hook function to do module specific stuff before binding the events (i.e. fetching some data).
 *
 * @method beforeBinding
 * @param {Function} callback the callback function which must be called at the end
 * @return void
 */
beforeBinding: function(callback) {
    $(':submit', this.$ctx).hide();
    callback();
}

In der onBinding-Phase werden die Events gebunden.

/**
 * Hook function to bind the module specific events.
 *
 * @method onBinding
 * @return void
*/
onBinding: function() {
    var that = this;
    
    // disable the standard action on submit
    $('.converter', this.$ctx).bind('submit', function() {
       return false;
    });
    
    // bind the keyup event to start the convertion. To reduce the number
    // of ajax calls, the debounce plugin is used.
    $('.amount', this.$ctx).keyup($.debounce(250, function() {
        var $this = $(this).closest('form');
        var url = $this.attr('action') + '?' + $this.serialize();
        // ajax stuff etc.
        ...
        return false;
    }));
}

In unserem Beispiel wird durch return false - da die Live-Convertion nicht per Enter, sondern automatisch nach Beendigung der Eingabe ausgelöst werden soll - die Standard-Submitaktion unterbunden.

Damit dem Benutzer gleich zu Beginn eine aktuelle Berechnung präsentiert werden kann - zum Beispiel der aktuelle Eurokurs - wird in der afterBinding-Phase die Initialberechnung ausgelöst.

/**
 * Hook function to do module specific stuff after binding the events (i.e. triggering some events).
 *
 * @method afterBinding
 * @return void
 */
afterBinding: function() {
    $('.amount', this.$ctx).trigger('keyup');
}

Was kann Terrific sonst noch?

Obwohl die Modul-Funktionalität den Hauptpart des Terrific JavaScript Systems darstellt, hat Terrific noch zahlreiche weitere JavaScript Features zu bieten, die das Programmiererleben erheblich erleichtern. Einige der Funktionen, die Terrific mit sich bringt:

• Skins - Module Decorators
• Layouts - seitenweite Funktionalitäten, z.B. Drag'n Drop von Modulen etc.
• Connectors - ermöglichen die Kommunikation zwischen Modulen über konfigurierbare Kanäle
• Sandbox - Bezug von Ressourcen, Zugriff auf andere Modulinstanzen etc.
• Logging-Architektur
• Zentrales Errorhandling
• ...

Die Terrific-Funktionalitäten sind also ziemlich umfassend ;-). Bis jetzt konnten wir alle Kundenwünsche mit den Bordmitteln von Terrific umsetzen. Neue, anspruchsvolle und herausfordernde Frontends sind also herzlich willkommen!

Real World Beispiele?

Das Intranet von Repower wurde komplett mit Terrific umgesetzt. Integriert wurde das Ganze in das Enterprise Wiki Atlassian Confluence. Wiki? Anspruchvolles Frontend? Wie man dies unter einen Hut bringen kann, zeigen wir im nächsten Terrific-Post!

Das "Bundesgesetz betreffend die Überwachung des Post- und Fernmeldeverkehrs (BÜPF)" wird überarbeitet und die First für Kommentare dauert noch bis am 18. August. Ich persönlich meine, dass es Kommentare braucht.

Im Kern geht es um die (legitime) Überwachung durch den Staat. Doch die Formulierungen bezüglich der Reichweite sind sehr weit und insb. gehören E-Mail-Verkehr, Internet-Telefonie und auch Hosting dazu (da "Internet Service Provider" als Datenlieferanten genannt werden). Viele der Leser dieses Blog sind vom Gesetz also direkt betroffen.

Unter anderem wird gefordert, dass der Staat die Überwachungsdaten in Echtzeit erhalten kann. So bräuchte beispielsweise jeder Betreiber einer Voice over IP-Anlage eine stehende Abhörverbindung zum Bund bereitzustellen. Und diese (wie alle Massnahmen) auf eigene Kosten des Betreibers.

Nun soll sich jeder seine eigene Meinung dazu machen und dazu der Link zur offiziellen Information: "Überwachung des Fernmeldeverkehrs an die technische Entwicklung anpassen". Und wie gesagt müssten alle die etwas dazu sagen möchten, dies bis spätestens am 18. August getan haben.

Da gleichlautende Interventionen die Chance erhöhen angehört zu werden und es aus meiner Sicht auch einfacher ist qualifizierte Änderungsvorschläge zu lesen als das Gesetz selbständig anpassen zu wollen, stelle ich hier ein Schreiben zur Verfügung, welche mir open.ch als mögliche Intervention zur Verfügung gestellt wurde und dem Bundesamt für Justiz eingeschrieben resp. patrick.rohner@bj.admin.ch zugestellt werden kann.

> Download: Vernehmlassungsantwort zur Totalrevision des Bundesgesetzes vom 6. Oktober 2000 betreffend die Überwachung von Post- und Fernmeldeverkehr [doc, 90KB]

> Hier noch die Adresse:
Bundesamt für Justiz
Direktionsbereich Strafrecht
Bundesrain 20
3003 Bern

Die von der IREUS Recommendation Engine generierten Empfehlungen werden in den Teasers aur der rechten Seite aufgelistet.

• Ein Konto auf der Webseite von IREUS erstellen.
• Im Konto eine Recommendation Engine anlegen.
• Den Produktekatalog inklusive Kategorien hochladen.
• Eventuell historische Warenkörbe, für das initiale Lernen des Systems, hochladen.
• Design in der Recommendation Engine dem Shop anpassen.
• Auf der Shop Webseite einige Javascript Snippets einfügen.
• Die Recommendation Engine starten.

• Auf der Produktdetailseite werden max. 3 Produktempfehlungen zu einem einzelnen Produkt ausgegeben.
• Auf der Produktkategorieseite werden max. 3 Produktempfehlungen zur Kategorie ausgegeben.
• Im Warenkorb werden max. 3 generelle Produktempfehlungen ausgegeben und zusätzlich wird der Warenkorb bei IREUS registriert.
• Auch die Bestellbestätigung, das heisst der bestellte Warenkorb, wird an IREUS gesandt.

Welche Optionen bieten sich heute, was bringt die Zukunft? Scrollen oder nicht? - Die folgende Präsentation bringt eine Übersicht auf den Schirm.

1) Man kaufe ein "Kit 3G+ iPad"

Im "iPad-Rausch" hat SFR (France Télécom) ein Angebot für EUR 9.90 lanciert. Ich habe das das Pack (3 Tage unlimitierter Zugang inkl. ein Micro SIM) in der Fnac gekauft. Da eine Verlängerung des Zugangs pro Tag EUR 6.- (!!) kosten würde, könnte man durchaus versucht sein, ein paar Pakete zu kaufen ;-)

Da es sich um ein Prepaid handelt (kein Voice und kein SMS, nur Data) muss man seine Personalien per Post oder in einem SFR-Shop belegen, sonst wird das Abo nach 15 Tagen deaktiviert. Da ich es aber nur drei Tage nutzen werde...

2. Die Konfiguration fürs iPad

Als erstes habe ich die Micro SIM in mein iPad gesteckt und über einen "Subscriber Update" (leider nur mit iTunes und einem alternativen Internet-Zugang) erhalten. Dieser ist aber nicht notwenig resp. das einzige was ich wissen und einstellen muss ist, der APN von SFS mit dem Namen websfr

3. Und nun die Skalierung ;-)

Für die meisten Leute genügen die ersten Schritte, da wir aber rund 10 Geräte dabei haben die über WLan gerne Internet-Zugang hätten, nun der spannendste Schritt ;-) Ich habe aus der Verpackung des Kits eine Adapter Micro SIM <> SIM geschnitzt. Das Ding sieht wie folgt aus und ist praktisch für einen "erweiterte Nutzung" ;-)

Die nun so gewachsene SIM setzte ich (zusammen mit dem Wissen, dass der APN websfr heisst) in einen WLan <> GMS Router in. In meinem Fall ist es die Software JoikuSpot auf meinem Nokia Telefon, jedes Android 2.2 kann es von Haus aus, beim (genackten) iPhone wäre es PdaNet oder halt ganz normale Hardware (z.B. bei Swisscom).

PS: Nach 2 Tagen (und über 2 GBit Traffic) kann ich die Lösung nur empfehlen...

Im Rahmen einer kleinen Reihe im Blog werde ich ein paar interessante Neuerungen des Frameworks vorstellen. Bestandteil jedes Artikels ist immer auch ein lauffähiges Beispiel-Projekt, welches die besprochenen Features sowohl zur Laufzeit als auch im enthaltenen Quellcode illustriert.

Setup

Applikationen mit JSF2 sind immer noch normale Java-Web-Applikationen ohne spezielle Abhängigkeiten bezüglich Java EE 6. Damit sind sie auch in jedem halbwegs aktuellen Servlet-Container lauffähig und erfordern keinen speziellen Applikationsserver. Falls im Web-Container vorhanden, kann man jedoch die Vorzüge von Servlet 3.0, einer weiteren Java EE 6 Neuerung, nutzen. Durch dessen annotation-based Konfiguration von Servlets und Filtern erfordert JSF2 keine Konfiguration mehr. Es reicht, die Libraries in die Applikation aufzunehmen, den Rest erledigt der Container automatisch. Das FacesServlet, welches den JSF-Kontext bei Zugriffen initialisiert, wird dann auf "*.jsf" gemappt. Gerade zum Aufsetzen des Projekts ist das sehr praktisch und erlaubt es dem Entwickler, sofort loszulegen.

Durch Servlet 3.0 kann man sogar auf den Deskriptor der Applikation, die web.xml Datei, komplett verzichten. Dasselbe gilt für die JSF-eigene Konfigurationsdatei "faces-config.xml". Sie ist optional und dank der neuen annotation-based Konfiguration von JSF selbst wird sie auch nur noch in speziellen Fällen benötigt. Hierzu später mehr.

Um die Vorteile demonstrieren zu können, nutzt die angehängte Beispielapplikation Servlet 3.0, z.B. im neuen Apache Tomcat 7.0 .

View

Mach's gut, JSP - Hallo Facelets!

Die fundamentale Änderung in JSF2 im Vergleich zur Vergangenheit ist sicherlich der Wechsel der View-Technologie. Früher waren JavaServer Pages (JSP) hierfür der Standard. Nach anfänglich starker Kritik wurde dessen Integration zwar verbessert, erreichte aber nie ein Niveau mit dem alle Beteiligten zufrieden sein konnten.

Bereits vor Release von JSF2 hatte sich Facelets als quasi-Standard etabliert. Facelets ersetzt JSP durch ein XML-Format. Es bietet deutlich flexiblere Templating-Features, eine eigene Taglibrary sowie die Möglichkeit, das Gros der Standard Tag Library (JSTL) weiterhin zu nutzen. Ein weiterer Vorteil ist dass, wenn entsprechend eingesetzt (jsfc Attribut), der Code auch zur Entwicklungszeit gültiges XHTML darstellt. Dadurch kann die Seite sowohl vom Java- als auch vom Frontend-Entwickler direkt bearbeitet werden.

Mit JSF2 ist nun Facelets die Standard View Description Language (VDL). Bis auf ein paar Namensanpassungen wurden die Facelets 1.x dafür weitgehend übernommen, die Unterstützung von JSP wurde dagegen abgekündigt. Die VDL von JSF2 ist also genau gesehen nicht neu, sondern nur übernommen worden. Daher beschäftige ich mich in diesem Artikel auch nicht näher mit den Standard-Features von Facelets.

Warum GET das bessere POST ist

Denn es gibt auch abseits des VDL-Wechsels spannende Neuerungen. Eine davon ist der stark verbesserte Support von HTTP GET Requests. Früher lief eine Anfrage des Benutzers in JSF oft nach dem POST - Redirect - GET Pattern ab: Zuerst eine Action/Navigation per POST auslösen, dann den Redirect zur Ziel-View an den Benutzer senden, der dann schliesslich mit einem neuerlichen GET die neue View lädt. Anders waren Features wie Bookmarks oder Refresh-Support für den Browser des Benutzers kaum lösbar. Dies wird nun durch einige neue Features rum um die Parameter-Verarbeitung bei GET Requests in vielen Fällen möglich.

f:viewParam

Ein GET Parameter kann vor Rendering einer View in eine Bean übernommen werden. Dies funktioniert im neuen f:metadata Block einer View.

<f:metadata>
	<f:viewParam name="base" value="#{calculator.base}" />
</f:metadata>

Ein eventuell vorhandener Parameter "base" wird somit in die Bean "calculator" übernommen. Es handelt sich hierbei um eine normale Component, was den Vorteil hat dass alle Konverter und Validatoren ebenfalls auf View-Parameter angewandt werden können. Gerade bei GET Requests ist dies essentiell, denn durch simple Änderung der URL kann der Benutzer hier jegliche Werte eingeben. Zusätzlich unterstützt die Component auch das übliche required Flag, um eine Angabe zu erfordern. Kombiniert kann dies dann wie folgt aussehen.

<f:metadata>
	<f:viewParam name="base" value="#{calculator.base}" 
	required="true">
		<f:validateDoubleRange minimum="1" />	 
	</f:viewParam>
</f:metadata>

Schlägt eine Validierung fehl, wird der Wert nicht in die Bean übernommen und es tritt ein normaler JSF-Validierungsfehler auf, d.h. es wird eine FacesMessage zur möglichen Ausgabe erzeugt.

PreRenderViewEvent

Per View-Parameter kann also ein Wert vor Rendering der View in die Beans übernommen werden. Meistens will man dies, um die View entsprechend dem Parameter unterschiedlich zu gestalten. Zum Beispiel um einen Datensatz zu laden. Dafür wird eine zusätzliche Methode benötigt, die nach dem Abfüllen der Beans aufgerufen wird, aber noch vor dem Rendering der Seite. Genau zu diesem Zeitpunkt wird der PreRenderViewEvent geworfen. Im f:metadata Block kann man zu diesem Zweck einen Event-Listener registrieren. Der Listener besteht aus der Methode einer Bean; sie muss public sein, sollte keinen Rückgabewert liefern und entweder keinen Parameter, oder ein ComponentSystemEvent akzeptieren. Der Listener wird dann nach der Übernahme der Parameter aufgerufen, und zwar unabhängig von den Validierungen. Es bietet sich daher an, auf fehlgeschlagene Validierungen zu prüfen, bevor man die Parameter nutzt. Mit der neuen Methode isValidationFailed() kann seit JSF2 im FacesContext einfach geprüft werden, ob eine der Validierungen fehlgeschlagen ist.

<f:metadata>
	...
	<f:event type="preRenderView" 
	listener="#{calculator.calculate}" />
</f:metadata>

public void calculate() {
	FacesContext ctx = FacesContext.getCurrentInstance();
	if (!ctx.isValidationFailed()) {			
		...
	}
}

Neben der Initialisierung der Daten für eine View hat die Listener Methode noch weitere Möglichkeiten. So kann sie über den NavigationHandler sogar das Rendering auf eine andere View umleiten, beispielsweise bei fehlender Authorisierung des Benutzers.

h:link

Da man nun sehr einfach GET Parameter abfüllen und verwenden kann, besteht natürlich auch erhöhter Bedarf danach, GET Links zu erstellen. Zur Navigation wurde in JSF bisher hauptsächlich auf h:commandLink und h:commandButton gesetzt. Diese erzeugten POST Requests. Zwar konnte mit h:outputLink auch ein GET Link generiert werden; diese Component wendet jedoch kaum Logik an, sodass man die Link Generierung sowie das Anfügen eventueller Parameter manuell vornehmen musste.

Hier setzt die neue h:link Component an. Sie erfordert eine logische View-ID, die dann über die Navigation Rules zur URI aufgelöst wird. Im einfachsten Fall entspricht die View-ID dem Pfadnamen der Seite in der Web-Applikation ohne Dateiendung. Übrigens ist auch dies neu: Bisher musste man selbst für dieses simple Mapping Datei->View-ID eine Navigation Rule im XML erstellen. Eine erneute Vereinfachung, um sehr schnell mit der Entwicklung loszulegen.
Ausserdem kann man der h:link Component noch Parameter über den Standard-Tag f:param mitgeben, diese Parameter werden automatisch als Query-Parameter an die URL angehängt.

<h:link outcome="calculate" value="Next page">
	<f:param name="base" value="8"/>
</h:link>

Der daraus generierte Link kann dann z.B. so aussehen: /calculate.jsf?base=8 . Es sind beliebig viele Parameter kombinierbar. Bei komplexen Seiten kann es hilfreich sein, alle View-Parameter mitzunehmen, also an den generierten Link weiterzugeben. Das geht per includeViewParams Attribut. Zusätzlich angegebene f:param Tags können die Liste erweitern oder einzelne Parameter aus den includeViewParams überschreiben.

<h:link outcome="calculate" includeViewParams="true"
	value="Next page"
	<f:param name="base" value="8"/>
</h:link>

Der resultierende Link wird alle View-Parameter der aktuellen Seite umfassen, sowie zusätzlich den Parameter "base" mit dem Wert 8, egal ob bereits ein View-Parameter mit dem Namen "base" existierte oder nicht.

Damit bringt JSF2 nun endlich die Möglichkeit, umfassend mit GET-Requests zu arbeiten und somit dem Benutzer ein einfacheres, mehr RESTful Verhalten in der Applikation zu bieten. Es gibt Zusätze zu JSF, die dies noch ausbauen und ein echtes REST-Verhalten erzeugen können (z.B. PrettyFaces), aber jetzt sind auch die mitgelieferten Werkzeuge dafür tauglich und in der Komplexität akzeptabel.

Download

Ausblick

Dieser kurze Einstieg in JSF2 war nur der Anfang. An den Managed Beans wurden Änderungen vorgenommen sowie neue Scopes eingeführt. Es gibt nun mehrere Möglichkeiten, eigene Components zu erstellen. Die Validierung wurde entscheidend erweitert. Im kommenden Teil 2 der Reihe rund um JSF2 wird es um eine ganz zentrale Neuerung von JSF2 gehen: Die Einführung von out-of-the-box Unterstützung für Ajax.

Fragen und Diskussionen rund um JSF2 und Java EE 6? Gerne als Kommentar im Blog oder per E-Mail.