Terrific – a Frontend Development Framework goes Open Source

terrifically.org

Der Frontend Entwicklungsprozess wird durch die rasante Technologie- und Browserentwicklung immer komplexer. Die stetig steigende Vielzahl von Zielgeräten und Auflösungen, Animationen, CSS3, HTML5 etc. tun ihr Bestes, um die Aufwände und die Komplexität schon während der Konzeptionsphase zu erhöhen. Die unendlichen … Weiterlesen

Clarify – Ein Toolkit für den Frontend Workflow

Der Frontend Entwicklungsprozess in einem Projekt wird immer komplexer und zeitaufwendiger. Aufgrund einer Vielzahl von Zielgeräten und Auflösungen, Verhaltensweisen, Animationen, CSS3, HTML5, etc. steigen zwangsläufig auch die Aufwände und die Komplexität während Konzeptionsphase in allen Disziplinen. Dieser Wandel ist enorm spannend und bietet fast unendliche Möglichkeiten. Es ist aus meiner Sicht aber auch der Moment über die Effizienz im Workflow nachzudenken.

Wir setzen mit Terrific ein fantastisches Werkzeug ein, dass uns ermöglicht modulare und wartbare Frontendbausteine effizient umzusetzen. Es gehört aber nach wie vor zu jedem Projekt dazu, die Spezifikationen zu komplettieren, seien dies nun Vermassungen, Farbcodes, Verhaltensweisen, Geschwindigkeiten von Übergängen, etc. Aber genau diese Erarbeitung kostet Zeit und kann optimiert werden.

Aus diesem Grund ist durch Diskussionen mit Experten aus den Bereichen UX, Design, Projektleitung & Entwicklung innerhalb kurzer Zeit ein Tool entstanden, das einzelne dieser Arbeiten mit kleinen Hilfsmitteln versucht zu unterstützten. Clarify. Es handelt sich dabei um eine Webapplikation mit einer darunterliegenden Datenbank. Nachfolgend gibt es einen Vorgeschmack der Funktionen des aktuellen Prototyps.

Projekte & Screens

Clarify erlaubt das Erfassen von Projekten und das Hochladen von Screens (JPG, PNG) zu jedem Projekt. Es listet diese übersichtlich in der Projektansicht auf. Ein Klick auf einen Screen öffnet die Toolansicht. Sie besteht aus mehreren Layern, u.a. Kommentare, Vermassungen, Farben, Schriften, etc. Initial befindet man sich auf der Kommentaransicht.

Kommentare

Im Kommentarlayer ist es möglich Punkte mit Nummern auf dem Screen zu platzieren und dazu jeweils einen Beschreibungstext zu hinterlegen. Denkbar sind Implementierungshinweise, Infos zu Modulen oder einfach nur Annotationen.

Vermassung

Jeder Frontend Entwickler hat seine Tools um Abstände & Grössen zu vermassen (falls nicht schon bei der Designübergabe vorhanden). So richtig glücklich wurde ich aber noch mit keinem. Nachfolgend sieht man die Vermassungsfunktion von Clarify. Sie zeigt eine Lupe ähnlich wie bei einem Color Picker für den Start- und Endpunkt an. Nachfolgend wird die Breite & Höhe angezeigt. Nachträglich kann die Vermassung angepasst werden. Alle Vermassungen werden in der Datenbank für spätere Outputs wie einem Styleguide gespeichert.

Farben

Das Tool erlaubt Designern und Entwicklern, je nach Workflow, Farben direkt vom Screen zu picken. In Clarify werden die ausgewählten Farben in eine Projektfarbbibliothek hinzugefügt und vom jeweiligen Screen referenziert. Dies erlaubt uns in Zukunft z.B. für ein Projekt automatisiert LESS Templates mit Farben anzulegen. Desweiteren hat man immer den Überblick, welche Farben über das gesamte Projekt hinweg verwendet werden.

Es ist auch möglich eine Farbe anstatt vom Screen zu picken, über die Farbbibliothek auf einen Screen zu ziehen. Dies ist z.B. hilfreich, wenn man im Vorhinein schon weiss, dass dies genau dieses Gelb sein muss, unabhängig davon ob es einen Hauch von jener abweicht.

Embedding

Der Kommentarlayer kann bereits im jetzigen Zustand in andere Systeme per Javascript eingebettet werden. Dies ist hilfreich z.B. in einem Wiki oder im Jira Bugtracking. Man hat dann immer eine aktuelle Version des automatisch skalierten Screens mit den Kommentarpunkten, ohne das man von Hand in Photoshop beginnen muss Punkte zu zeichnen.

Styleguide

Ein möglicher Output von Clarify (dank der strukturiert erfassten Daten) könnte ein Styleguide sein. Hier ein ganz einfaches Beispiel:

Roadmap

Dies ist der heutige Stand des Prototyps, in der nächsten Phase entstehen die Werkzeuge für Verhalten (Dropdown, Slider, etc.) und für Schriften (Zeilenhöhen, Schriftgrössen, px/em). Ich bin gespannt was ihr so darüber denkt, welche Ideen ihr zu dem Thema habt. Last was von euch hören, via Kommentare oder Mail (roger.dudler@namics.com). Mein Ziel ist es Clarify so schnell als möglich zu veröffentlichen und allen zugänglich zu machen. Stay tuned.

Ein ganz besonderer Dank für die spannenden Diskussionen geht an Thommy, Olaf, Daniel, Alex, Remo & Ernst & das gesamte Team Roman!

Makerbot – Wir bauen einen 3D-Drucker. Teil 1

Ein Traum geht in Erfüllung.
Schon während meines Interaktion Design Studiums war unsere kleine Studenten Gruppe fasziniert von neuen Opensource Technologien wie Processing oder der Hardware Platform Arduino, die Designern neue, einfache und günstige Möglichkeiten eröffneten, Prototypen mit einem hohen Grad an Funktionalität zu entwickeln.

Zu dieser Zeit, ca. 2007, wurde die RepRap Research Foundation ins Leben gerufen, welche es sich zu Aufgabe gemacht hatte einen sich selbst kopierenden 3D-Drucker zu bauen. Einer der Gründungsmitglieder der RRRF, Zach Smith, gründete 2009 zusammen mit Bre Pettis und Adam Mayer in New York die Firma MakerBot Industries, um einen preiswerten Opensource 3D Drucker zu entwickeln. Einer dieser Drucker – Seriennummer 4626 – steht nun in Zürich bei Namics.

Vor ca. 3 Woche erschien in unserem Intranet ein Beitrag zum Thema Makerbot. Darauf hin tat sich eine Gruppe Mitarbeiter zusammen und gründete eine „3D-Genossenschaft“. Die Finanzierung war innerhalb von 2 Tagen gesichert, der Drucker-Bausatz kam eine Woche später per Post, gestern wurde mit dem Zusammenbau begonnen.

Innerhalb von 4 Stunden hatten wir ca. 2/3 des Druckers montiert, als ein wichtiges Bauteil defekt ging :-(
Zeit eine Pause einzulegen, die ersten 3D Modelle (z.B. eine Wurst in der Tasse) zu konstruieren, und sich das Timelapse Video anzuschauen:

Viel Spass und bis zum 2. Teil.

P.S.: Nachdem Film noch ein kleiner Lesetipp für jeden der sich für Home-Fabrication und das Internet of Things interessiert: „Bruce Sterling – Shaping Things“

Terrific im Projektprozess

In den letzten Terrific Posts ging es vor allem um die Prinzipien und einige technische Details des Frontend Development Frameworks.

Dabei wurde die Frontend Entwicklung isoliert betrachtet. Terrific hat jedoch mehr zu bieten! Das 5-Komponenten-Prinzip hilft dabei, den ganzen Projektprozess einheitlicher zu strukturieren. Somit rückt Terrific mehr ins Zentrum und dient nicht mehr bloss als Frontend-Instrument.
Vielmehr resultieren daraus direkte oder indirekte Vorteile für alle Disziplinen – Kreation, Technik und Projektleitung – und Strukturierungskonventionen, die sich durchs gesamte Projekt durchziehen. Davon profitieren schlussendlich natürlich vor allem unsere Kunden – aber zuerst mal ganz von vorn ;-)

Im folgenden habe ich versucht, die Auswirkungen von Terrific für die einzelnen Disziplinen anhand eines Projektprozesses zu illustrieren.

Design, Interaction und User Experience

Was muss von den Kreativen beachtet werden?

Die Antwort ist schlicht und ergreifend: Nichts!
Terrific soll die Kreativität der Designer nicht einschränken oder ihnen schon zu früh im Projektverlauf den modularen Gedanken aufdoktrinieren.

Wie kann Terrific also den Kreativen helfen?

Komplexe Animationen und Interaktionen sind mittlerweile in jedem Projekt anzutreffen. Leider lassen sich solche Verhalten mit Programmen wie Photoshop / InDesign nur unzureichend simulieren. Hinzu kommt, dass bei innovativen Vorschlägen die Machbarkeit z.T schwer abgeschätzt werden kann und sich die Diskussion mit dem Kunden ohne reales Beispiel extrem schwierig gestaltet.

Mit Terrific lassen sich Prototypen relativ schnell erstellen. Da es sich um reale „Web-Prototypen“ handelt, wird mit dem Prototyp implizit auch deren Machbarkeit sichergestellt. Zudem ist das Feedback direkter, genauer und basiert auf realem Verhalten und nicht auf „webfremden“ Simulationen. Dies hat natürlich auch den Vorteil, dass die Prototypen kein Wegwerfprodukt sind, sondern später wiederverwendet werden können.

2925-repowerConfigurator-thumb-500x464-2924.png

Prototype: Repower Widget Configurator

Tönt fast zu gut um wahr zu sein? Einziger Haken an den Terrific-Prototypen ist, dass deren Umsetzung in der Regel mehr Aufwand verursachen als vergleichbare Axure Prototypen. Wenn der Prototyp jedoch in der definitiven Lösung zum Einsatz kommt, so wird der ansonsten anfallende, doppelte Aufwand mehr als wieder wettgemacht. Zusätzlich wird das Machbarkeitsrisiko bereits in einer sehr frühen Phase eliminiert.

Zwischenstand

Betrachten wir unseren fiktiven Projektprozess, so hätten wir die Kreationsphase nun abgeschlossen. Die Designs stehen und alle komplexen, risikobehafteten Interaktionen und Animationen wurden mit Terrific Prototypen umgesetzt.

Wie weiter?

Aufteilung in Terrific Komponenten

Overlay, Lightbox, das Ding mit dem abgedunkelten Hintergrund – oftmals unterscheidet sich das verwendete Vokabular zwischen dem Kunden und den involvierten Projektmitgliedern ziemlich stark. Ein einheitliches Vokabular erleichtert die Kommunikation jedoch erheblich und hilft Missverständnissen vorzubeugen.

Um ein einheitliches Vokabular schon von Beginn an zu forcieren und um möglichst alle Faktoren zu berücksichtigen, wird die Aufteilung in Terrific Komponentenidealerweise interdisziplinär erarbeitet.

Als anzustrebendes Ziel gilt:
1 Funktionale Einheit = 1 Designkomponente = 1 Terrific Module = 1 Backend Module

2928-repowerWeatherWidget-thumb-500x248-2927.png

Gemeinsames Vokabular: Weather Widget

Frontend

Sind die Terrific Komponenten definiert, fällt der Startschuss für die Frontend Entwicklung. Hier entfesselt sich die wahre Stärke von Terrific. Durch die vollständige Modularisierung mittels OOCSS und TerrificJS können die Frontend Tasks maximal parallelisiert werden. Zudem unsterstützt der modulare Aufbau auch die Versionierung optimal.

2937-terrificStructure-thumb-200x199-2930.png

Beispiel: Einheitlicher Komponenten Aufbau – Terrific Module „MyAgora“

Der einheitliche Komponenten Aufbau hilft nicht nur bei der Entwicklung, sondern ermöglicht auch Reviews und Testing auf Komponenten-Basis durchzuführen. So werden Probleme frühzeitig erkannt und die Qualität des Codes steigt. Terrific leistet so auch einen wichtigen Beitrag zur Qualitätssicherung.

2934-terrificTesting-thumb-500x242-2933.png

Module Testing – Jedes Module lässt sich einzeln (inkl. Funktionalität) testen

Backendintegration

Bei der Entwicklung von Terrific spielte die einfache Integration in unterschiedlichste Backendsysteme (CMS, Applikationen etc.) eine zentrale Rolle.

Dennoch: Nichts geht von allein
Aber: Terrific hilft, den Integrationsprozess pro Backendsystem zu optimieren und zu standardisieren!

In der Praxis bedeutet dies, dass pro Backendsystem eine optimales Integrationsszenario entwickelt wird, das anschliessend für alle folgenden Projekte wiederverwendet werden kann.

Die Liste von erfolgreichen Integrationsszenarios, die bereits von Namics erarbeitet wurden, ist schon ziemlich beachtlich und wird immer länger:

Projektleitung und Controlling

Auch für die Projektleitung und fürs Controlling ergeben sich durch den modularen Aufbau von Terrific zahlreiche Vorteile.

Gerade bei zeitkritischen Projekten eröffnet die parallele Komponentenentwicklung neue Skalierungsmöglichkeiten. Zudem können die einzelnen Terrific-Komponenten 1:1 in Systemen wie Jira abgebildet werden, was sowohl das Tracking des Projektfortschritts als auch die Planung von Sprints erheblich vereinfacht.

Was hat eigentlich unser Kunde davon?

Alle oben genannten Punkte betreffen vor allem unsere interne Projektarbeit. Aber was sind denn die konkreten Vorteile für unsere Kunden?

Die Tatsache, dass durch den Einsatz von Terrific die Frontend-Entwicklung auf ein Maximum strukturiert und standardisiert wird, zieht zahlreiche Vorteile nach sich.

  • gesicherter Know-How Erhalt
  • der Ressourcen-Einsatz ist parallisierbar – vor allem bei Engpässen zeitlicher Natur kann dies ein enorm wichtiger Faktor sein
  • Standardisierung verhindert historisch gewachsene Altlasten
  • erhöhte Flexibilität beim Staffing senkt das Projektrisiko
  • sehr schnelles Projektsetup
  • kürzere Einarbeitungszeiten für neue Projektmitglieder
  • massiv vereinfachte Weiterentwicklung
  • hohe Wiederverwendbarkeit
  • Unabhängigkeit vom Backendsystem – ein Systemwechsel bedeutet kein Frontend Neubau
  • granulareres Testing – dadurch werden Probleme früher erkannt

Die Liste liesse sich noch beliebig erweitern. Aber um es auf den Punkt zu bringen: Terrific!

Weitere Terrific Informationen

Open Source Projekt: Terrific und TerrificJS

Terrific – Modulare Frontendentwicklung
Terrific und OOCSS
The Terrific Way Of JavaScript
Terrific im Projekprozess

Intranet Summit 2010 – Intranet als Kulturtreiber

Repower „nur ein Stromanbieter aus der Ostschweiz“ legte 2009 eine unglaubliche Performance hin. Das Umsatzwachstum und die Erweiterung um weitere Firmen zwang Repower von einem House of Brands strategisch neu Richtung Branded House zu steuern. Ein erklärtes Ziel war das Rebranding des Intranets und dieses neu zu beleben. Im April 2010 wurden der Internet-Auftritt wie auch das Intranet neu lanciert. Namics als Partner konnte gemeinsam mit Repower dieses Intranet als neues Arbeitswerkzeug zur täglichen Unterstützung entwickeln. So entstand ein Atlassian Confluence Wiki, das den kulturellen Wandel über alle Länder hinweg unterstützt.
Letzte Woche gewährten Paolo Raselli und Roman Zollet einen öffentlichen Einblick in das Intranet.

Am Swiss Intranet Summit zeigten sie den Aufbau der Seite und deren Funktionalität mit Schwerpunkt auf News, Dashboard und Favoritenlogik. Als Projektleiter des neuen Intranet-Auftrittes war es schön diese Präsentation vorbereiten zu können und hier ist das PDF dazu.

2546-repower_001-thumb-500x225-2545.jpg

2549-repower_003-thumb-500x225-2548.jpg

Die Plattform bietet Raum für Standorte in drei Sprachen und einer Newslogik welche sich über alle Bereiche hinweg steuern lässt. Zudem gibt es ein Dashboard (umgesetzt mit Terrific), auf welchem der einzelne Mitarbeiter Raum gibt sich nützliche Tools individuell zusammenzustellen. So können News nach Land, Sprache, Zeitraum, usw. persönlich konfiguriert werden. Weitere Widgets wie: Wetter, Währungsrechner, Favoriten und SBB-Verbindungen dürfen da nicht fehlen.

Zusammenfassend ist zu sagen, dass eine Technologie für die Zukunft gewählt wurde um Kultur und verantwortungsvollen Umgang mit der eigenen Marke GROSS zu schreiben.

Simon Daiker

The Terrific Way Of JavaScript

Wie im „letzten Post“:http://blog.namics.com/2010/07/terrific-oocss-part2.html veranschaulicht, setzt Terrific im HTML/CSS Part voll auf „OOCSS“:http://wiki.github.com/stubbornella/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“:http://www.jquery.com – 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“:http://blog.namics.com/2010/06/terrific-part1.html 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“:http://blog.namics.com/2010/06/terrific-part1.html erwähnt, nutzt Terrific die „OOCSS-Namenskonventionen“:http://blog.namics.com/2010/07/terrific-oocss-part2.html 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.$);

That’s it! Abgesehen von dem „Drumherum“ – ein klassischer 3-Zeiler ;-)

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

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

Diese Zeile instanziert eine neue Terrific-Application. Was auffällt ist, dass Terrific den „Namespace“:http://docs.jquery.com/Using_jQuery_with_Other_Libraries Nx (für Namics) verwendet. So kann Terrific auch parallel zu bestehenden oder durch das Backendsystem vorgegebenen JavaScript-Funktionalitäten verwendet werden.
Der Parameter $(‚.page‘) gibt den Context der Applikation an – .page ist nach OOCSS-Konvention der Seitencontainer.

application.registerModules();

registerModules übernimmt den Hauptteil des Bootstraps. Die Methode durchsucht den DOM-Tree nach Modulen – nach OOCSS-Konvention besitzen sämtliche Module die Klasse .mod – und instanziert per Namenskonvention die entsprechenden Module. Zum Beispiel wird für die Klasse .modNews das JavaScript Modul Nx.Module.News instanziert.

Als Pendant zu den OOCSS-Skins bietet Terrific JavaScript-Skins an – welche im Grunde nichts anderes als Module „Decorators“:http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript 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“:http://en.wikipedia.org/wiki/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();

Mit startAll wird die Initialisierung der Module gestartet. Jedes Modul durchläuft dabei potentiell vier Phasen, welche nach Bedarf durch die entsprechende „Hook-Methode“:http://de.wikipedia.org/wiki/Schablonenmethode implementiert werden können.

  • 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.

2131-Terrific-Module.png

Das Currency Converter Module hat folgende Funktionalitäten:

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

dependencies

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“:http://benalman.com/code/projects/jquery-throttle-debounce/docs/files/jquery-ba-throttle-debounce-js.html von „Ben Alman“:http://benalman.com/.

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

Der dritte Parameter – in unserem Beispiel „onBinding“ – gibt an, in welcher Phase die dependency benötigt wird. Terrific kümmert sich um das Timing und die entsprechenden Callbacks. Zudem stellt Terrific sicher, dass von mehreren Modulen benötigte dependencies nicht doppelt nachgeladen werden.

beforeBinding

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();
}

Durch die Verwendung von this.$ctx (this.$ctx enthält den Module-DOM-Node) als zweiten Parameter im jQuery-Selector, werden die Events nur auf die aktuelle Modulinstanz gebunden. So können Module also auch problemlos mehrmals auf einer Seite verwendet werden.

onBinding

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.

Im keyup-Eventhandler kommt das in der dependencies-Phase nachgeladene debounce-Plugin zum Einsatz. Dadurch kann die Anzahl Ajax-Requests stark reduziert werden, da die Berechnung erst nach 250ms Idle-Time ausgelöst wird.

afterBinding

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“:http://www.namics.com/taten/neues-intranet-repower/ wurde komplett mit Terrific umgesetzt. Integriert wurde das Ganze in das Enterprise Wiki „Atlassian Confluence“:http://www.atlassian.com/software/confluence/. Wiki? Anspruchvolles Frontend? Wie man dies unter einen Hut bringen kann, zeigen wir im nächsten Terrific-Post!

h4. Weitere Terrific Informationen

Open Source Projekt: Terrific und TerrificJS

Terrific – Modulare Frontendentwicklung
Terrific und OOCSS
The Terrific Way Of JavaScript
Terrific im Projekprozess

Terrific und OOCSS

Wie im letzten Terrific-Post angetönt, geht es in dieser Episode ein bisschen ans Eingemachtere… also dann, auf gehts…

Wieso OOCSS?

Terrific basiert auf OOCSS. Um die Vorteile von OOCSS zu begreifen, muss man zuerst die Schwachstellen und Probleme von CSS verstehen.

Code ist sehr „fragil“
Eine falsche Änderung kann durch die Kaskadierung unvorhersehbare Effekte hervorrufen – zum Beispiel Layoutfehler auf Seite xx.

Parallele Entwicklung im Team ist extrem schwierig
Die CSS-Regeln beeinflussen sich gegenseitig. Ohne genaue Kenntnisse über die Arbeit der Teamkollegen, ist die parallele Entwicklung praktisch unmöglich.

Code-Reuse ist sehr selten
Wir „vertrauen“ nicht auf den Code von anderen. Dies nicht aufgrund egomanischen Zügen, sondern weil uns die Erfahrung gelehrt hat, dass wir oftmals eleganter und schneller zum Ziel kommen, wenn wir CSS-Code von Grund auf selber schreiben. Nicht selten bedient man sich dabei stark gekapselten CSS-Selektoren à la „#id .class“, die einen Reuse wegen ihrer hohen Spezifität und Individualität praktisch ausschliessen.

Konsequenzen

  • Code wird unübersichtlich und unstrukturiert
  • Der Code wächst linear zur Projektgrösse = Performanceprobleme

Beides hat zur Folge, dass die Fehleranfälligkeit stark ansteigt und der Code unwartbar wird.

Wie macht man es besser?

OOCSS wurde von Nicole Sullivan (Yahoo) entwickelt und stellt einen wiederverwendbaren Baukasten an CSS-Klassen zur Verfügung. Oberstes Ziel von OOCSS ist es, vorhersagbares Verhalten ohne Seiteneffekte sicherzustellen. Dies wird erreicht, indem das Markup und die dazugehörigen CSS-Klassen stark standardisiert werden.

Alle Terrific Komponenten werden entsprechend den OOCCS-Regeln umgesetzt:

Elements

Grundlegende Definition der HTML Elemente

/* Link */
a.base, a.base:link, a.base:visited {
    color: #434343;
    text-decoration: underline;
}

Als Namenskonvention wird.base verwendet. Dadurch kann man von Module zu Module selbst entscheiden, ob man den Basisstyle eines Elements verwenden will oder nicht.

Layout

Aufteilung in einzelne, voneinander getrennte Bereiche (z.B. Header, Footer, 3 Spalten)

2126-Terrific-Layout-thumb-500x241-2125.png

Das zugehörige Markup ist beinahe selbsterklärend:

<div class="page">
<div class="head">
<h2>Head</h2>
</div>
<div class="body">
<div class="leftCol">
<h2>Left Column</h2>
</div>
// more leftCols
<div class="rightCol">
<h2>Right Column</h2>
</div>
// more rightCols
<div class="main">
<h2>Main Content</h2>
</div>
</div>
<div class="foot">
<h2>Foot</h2>
</div>
</div>

Mit den OOCSS-Klassen page, head, foot, leftCol, rightCol und main lassen sich in kürzester Zeit Layouts erstellen, die bis und mit IE 5.5 abwärtskompatibel sind.

Grid

Seitenspezifische Unterteilung in Lines und Units

2129-Terrific-Grid-thumb-500x189-2128.png

Und das Markup? Et Voilà!

<div class="line">
<div class="unit size1of5">
<h3>1/5</h3>
</div>
// repeat 3 times
<div class="unit size1of5 lastUnit">
<h3>1/5</h3>
</div>
</div>
<div class="line">
<div class="unit size2of5">
<h3>1/5</h3>
</div>
<div class="unit size3of5 lastUnit">
<h3>1/5</h3>
</div>
</div>

Lines und Units können beliebig verschachtelt werden. So können auch komplexeste Grids mühelos erstellt werden. Lediglich bei den Units muss darauf geachtet werden, dass die Summe aller Breitenangaben nicht die umgebendende Line sprengt. Mit den von OOCSS mitgelieferten size-Klassen (size1of5, size3of5 etc.) wird dieses Problem durch prozentuale Breitenangaben umgangen. Bei eigenen Grids muss dieser Umstand jedoch berücksichtigt werden.

Modules

Module sind in Terrific das zentrale Thema. Praktisch sämtliche Inhalte und Funktionalitäten stammen aus den Inhaltsmodulen.

Beispiel: Currency Converter

2131-Terrific-Module.png

Um den Entwickler nicht einzuschränken, gibt OOCSS nur die Wrapper-Divs vor. Terrific erweitert das ganze noch durch eine modulspezifische Klasse (modCurrencyConverter), welche für die Kapselung des CSS und das Terrific JavaScript System benötigt wird.

<div class="mod modCurrencyConverter">
<div class="inner">
<div class="bd"><!-- 1-n times --> ...</div>
</div>
</div>

Sämtliche CSS-Regeln werden mit der spezifischen Modulklasse prefixed. Die Kaskade von CSS übernimmt also quasi die „Objektorientierungs“-Rolle.

.modCurrencyConverter .bd {
    background: #fff;
    padding: 10px 10px 18px 10px;
}
...

Skins

Skins bieten die Möglichkeit, das Aussehen von Modulen gezielt zu überschreiben. So können zum Beispiel mandantenfähige Systeme problemlos umgesetzt werden – ein Modulegrundstyle und ein Skin pro Mandant – ohne sämtlichen Code duplizieren zu müssen.

2137-Terrific-Skin-thumb-400x194-2134.png
<div class="mod modCurrencyConverter
       skinCurrencyConverterHighlighted">

<div class="inner">
<div class="bd"><!-- 1-n times --> ...</div>
</div>
</div>

Der Skin erbt sämtliche Regeln des Moduls. Um den Hintergrund zu verändern, muss im Skin-CSS also lediglich die entsprechende Regel überschrieben werden:

.skinCurrencyConverterHighlighted .bd {
    background: #aebbcb;
}

Skins sind auch nützlich, um „ähnliche“ Inhalte in einem einzigen Modul zusammenzufassen. Die voneinander abweichenden Definitionen werden dabei in die Skins ausgelagert.

Wie weiter?

Die HTML/CSS Problematik wird von OOCSS sauber gelöst. Das beschriebene 5-Komponenten-Prinzip von Terrific unterstützt dabei die modularisierte Frontendentwicklung optimal.

Aber wie sieht es mit dem JavaScript Part aus? Mehr dazu im nächsten Terrific-Post!

Weitere Terrific Informationen

Open Source Projekt: Terrific und TerrificJS

Terrific – Modulare Frontendentwicklung
Terrific und OOCSS
The Terrific Way Of JavaScript
Terrific im Projekprozess

Terrific – Modulare Frontendentwicklung

Hintergrund

Die Komplexität von Frontends wird immer grösser – und somit natürlich auch der Spass bei der Umsetzung. Dachte man bis vor Kurzem in „Seiten“, so spricht man jetzt vermehrt von Modulen und Single Page Applikationen. Dieser Schritt weg vom Seitendenken hin zu wiederverwendbaren Modulen, die beliebig miteinander kombiniert werden können, zieht auch ein Umdenken in der Frontendentwicklung nach sich.

Wiederverwendbarkeit, Skalierbarkeit, parallele Entwicklung und Reduzierung von Abhängigkeiten sind die zentralen Anliegen der modularen Frontendentwicklung.

Das Thema wird zurzeit heftigst an allen Frontendkonferenzen und in der Community diskutiert. Dabei werden die einzelnen Technologien meist isoliert betrachtet.

Ein spannender Ansatz für den HTML/CSS Part bietet OOCSS von Nicole Sullivan. OOCSS wird bereits auf zahlreichen Websites eingesetzt und hat sich auch schon in grossen Projekten (z.B Yahoo) erfolgreich bewährt.

Interessante Ideen zum JavaScript Part liefert Nicholas Zakas in seinem Vortrag Scalable JavaScript Application Architecture

Beide Ansätze gehen vom Modulgedanken aus, basieren jedoch aufgrund der isolierten Betrachtung auf unterschiedlichen Konventionen.

Genau hier setzt Terrific an!

Terrific

Terrific ist ein von Namics entwickeltes Frontend Development Framework, das auf Basis von OOCSS, jQuery und unzähligen anderen Ideen, Diskussionen und Best-Practices entstanden ist.

Im Gegensatz zu den technologiegebundenen Ansätzen nutzt Terrific die OOCSS-Namenskonventionen technologieübergreifend sowohl für den HTML/CSS Part als auch für den JavaScript Part. Dadurch entsteht eine lose gekoppelte, modulare, clientseitige Architektur, die den ganzen Frontendprozess standardisiert – wenn nicht sogar revolutioniert!

5-Komponenten-Prinzip

Jede Terrific-Applikation besteht aus fünf Basiskomponenten:

  • Elements -> grundlegende Elemente (h1, h2 etc.)
  • Layout -> einzelne, voneinander getrennte Bereiche, die den meisten Seiten innerhalb Applikation gemeinsam sind (z.B. Header, Footer, 3 Spalten)
  • Grid -> weitere, seitenspezifische Unterteilung in Lines und Units
  • Modules -> Inhaltsmodule
  • Skins -> Skins für Module

Beispiel Repower Intranet:

2027-Repower_Dashboard_Layout-thumb-500x325-2019-thumb-500x325-2020.jpg

* Grün: Layout

2025-Repower_Dashboard_Grid_Modules-thumb-500x325-2022-thumb-500x325-2023.jpg
  • Magenta: Grid
  • Blau: Modules

In den nächsten Terrific-Posts gehe ich detailliert auf die einzelnen Komponenten und deren Umsetzung ein. Es wird also technisch und sehr spannend!

Weitere Terrific Informationen

Open Source Projekt: Terrific und TerrificJS

Terrific – Modulare Frontendentwicklung
Terrific und OOCSS
The Terrific Way Of JavaScript
Terrific im Projekprozess