eZürich Workshop – Tag 2

Nach dem ersten Tag des Workshops eZürich wurde es konkret und damit spannend: Die Entwicklung des Zielbilds resp. der Vision der zuvor priorisierten Themen war auf dem Programm. Auf diesem Weg wandeln sich die Themen noch, eine zweite Priorisierung steht aus und da am nächsten Freitag eine Pressekonferenz abgehalten wird, wurde ich gebeten die Themen noch nicht preizugeben. Logisch… auch wenn es mich in den Fingern kitzelt ;-)

Interessant fand ich den Ansatz/Methode die Diskussion zu führen und daher noch ein paar Worte dazu.

Die zwölf Themen die es zu detaillieren galt waren in drei parallel arbeitende Gruppen eingeteilt. Jeder Teilnehmer hatte pro Thema eine von drei Rollen: Experte, Berater oder Netzwerker. Die Struktur erklärte damit plötzlich meine Namenskarte.

Die Experten sassen am Tisch und diskutierten unter Leitung der Moderation, die gleichzeitig die Dokumentation übernahm. Die Berater verfolgten die Diskussion, durften aber nicht mitreden. Sie hatten zwei definierte Zeitfenster in denen sie den Experten am Tisch den Verlauf der Diskussion reflektieren und zusätzlichen Input zum Thema liefern konnten. Die dritte Rolle, die Netzwerker hatten die Aufgabe die nebenläufigen Diskussionen zu verbinden also zwischen den Räumen zu zirkulieren.

2948-P1020688.jpg

Die Rolle der Netzwerker wurde nicht ausgefüllt. Dies wahrscheinlich weil die Gruppe so klein war, dass die Themen genügend bekannt waren und es zahlreiche Augenblicke gab, an welchen die Gesamtdiskussion sowieso zusammengeführt wurde. Auf den ersten Blick verstand ich das Konstrukt der Berater nicht, die Dynamik war aber nützlich. Dies, da die Berater aufmerksam zuhören mussten (weil sie nicht immer reinreden „durften“) und wegen dem limitierten Zeitfenster musste ich als Berater meinen Input klar priorisieren und sehr kompakt einbringen. Ein guter Ansatz!

Als die vier Zeitfenster durch waren und die zwölf Themen damit detailliert waren, fand sich die Gruppe im Plenum und jedes der Themen wurde vorgestellt und in der folge einzelne Aspekte (nicht das Thema selbst) durch die Teilnehmer mit sieben Klebern priorisiert.

2949-P1020682.jpg

Interessant war die letzte Runde, in welcher die Berater sich weigerten zwei Themen zu diskutieren, da sie diese aufgrund des Verlaufs als unnütz erachteten. Dank eines klaren Votums eines Teilnehmers (eigentlich am Vorabend an der Bar diskutiert) wurde ad hoc sehr geschickt ein neues Thema geschaffen. Eine gesunde Dynamik.

Es bleibt spannend und sehen wir mal, was ich vor der Pressekonferenz noch kommunizieren darf.

PS: Beat Döbeli hat seine Präsentation am selben Tag schon online gestellt… das ist für mich eZürich-like

eZürich Workshop – Tag 1

Einen Prozess der drei Tage dauert kann man kaum am ersten Tag beurteilen. Logisch und auch von einer der vier anwesenden Stadträten, Dr. Claudia Nielsen, heute Abend so formuliert. Auch Annette Kielholz hat auf http://twitter.com/ezueri den Umstand in etwa so kommentiert. Was geschah?

Heute war Start der von der Computerworld heraufbeschworenen „Elefantenrunde“ von eZürich und mein Arbeitsplatz war – aus Platzgründen wie ich erfahren habe – auf einem Schiff.

2945-P1020607.jpg

Ziel ist es in drei Tagen Massnahmen zu definierten, die auf die folgende Frage einbezahlen. Und zudem sollen Industrievertreter bei der Umsetzung eingebunden werden:

„Was müssen wir in den nächsten vier Jahren gemeinsam tun, um Zürich als den europäischen Top-Standort für ICT- Dienstleistungen und ICT-Infrastruktur zu positionieren?“

Ausgangslage der Arbeit waren die 612 Ideen welche in einer öffentlichen Befragung generiert und allen Teilnehmern im Vorfeld verteilt wurde. Die Zusammenfassung der Umfrage findet sich bei eZürich auf der Website und wurde heute auch von Hans-Dieter Zimmermann auf den FHS eSociety Blog kommentiert. Die Anzahl der eingereichten Ideen war im Vergleich mit ähnlichen Umfragen in Berlin (72) oder München (100) übrigens sehr hoch.

Als Einstieg in den Tag präsentierten die Einreicher der drei bestbewerteten Ideen diese persönlich: „Zürich wird CompiSternli-Stadt“, „eZürich in Politik und Verwaltung verankern – Wir wollen mehr als nur Ideenlieferanten sein!“ und „DynabookZ: Entwicklung eines persönlichen mobilen Lerngeräts für Zürcher Schulkinder auf Open Source Basis“. Die bereits bewährte CompiSternli-Idee finde ich persönlich sehr sympathisch und stark und Beat Döbelis Präsentation der altbekannten Dynabook-Idee von Alan Kay, angepasst auf das Infrastruktur- und Ausbildungsniveau von Zürich, war perfekt kondensiert und erklärt.

2946-P1020620.jpg

Während und nach den Präsentationen gab es die „übliche“ Kärtchen-Übung und danach einen Marktplatz, auf welchen einzelne Teilnehmer von ihnen ausgewählte Ideen verkaufen mussten. Eine Runde weiter kamen solche mit mindestens sieben Unterschriften.

Nach einer Konsolidierungsrunde und einer gemeinsamen Diskussion wurden von rund 30 Stück auf 18 reduziert die im weiteren bearbeitet wurden (nicht ohne Stolz gelang es mir aus dem kollektiven Schatz die zwei zu verkaufen welche am wenigsten Negativstimmen fassten inklusive der „Nummer 1″).

Der nächste Schritt war die Dokumentation der Fragestellung und des IST-Zustandes der Ideen während zwei Runden an neun Tischen, zwischen denen die Teilnehmer frei rotierten. Jedes Thema erhielt damit im Durchschnitt den Input von rund 30 Teilnehmern.

Und schlussendlich konnten sich die Teilnehmer über vorab zugeteilte Gruppen (bei mir G und L) ihren Themen für den nächsten Tag zuordnen. Uff… ein ziemliches Stück Arbeit und bald geht es weiter.

Belohnt wurden wir übrigens mit einem feinen Mittagessen im Rathaus in Rapperswil.

2947-P1020648.jpg

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

CDI: Leichtgewichtige Injection in Java EE 6

Bei der Umsetzung von Java Enterprise Projekten steht man (besser) früher oder (schlechter) später vor der Wahl eines geeigneten Komponenten-Frameworks. In der Vergangenheit fiel die Wahl dabei häufig auf Spring, da es gegenüber EJB, dem Java Standard, lange leichtgewichtiger und moderner daherkam. Mit EJB3 hatte sich dies im Java EE 5 bereits ein wenig geändert, da nun eine Konfiguration über Annotations ermöglicht und die Anzahl der notwendigen Interfaces reduziert wurde. Trotzdem blieb EJB ein Schwergewicht, weil es nur auf den grossen, umfangreichen und komplexen Java EE Applikationsservern eingesetzt werden konnte. Dies war für viele Projekte ein schlagender Grund um auf EJB zu verzichten.

Für jeden das passende Profil

Mit Java EE 6, das seit Ende 2009 verfügbar ist, hat Sun bzw. inzwischen Oracle mächtig in Sachen Leichtigkeit aufgeholt. Die Applikationsserver müssen nun nicht mehr den kompletten Satz an Features des Standards unterstützen. Stattdessen wurden „Profiles“ eingeführt, spannend ist im Umfeld der Web Applications natürlich das „Web Profile“. Die Tabelle bei ehemals Sun gibt einen guten Überblick, welche Features dort unterstützt werden und welche entfallen. Klar, die Reduktion kostet Opfer: Gerade Integrations-Technologien wie JMS, JCA, JAX-WS oder JAX-RS fallen weg.
Dafür wird aber der gängige Stack für Web Applications vollumfänglich unterstützt, sowohl in View (Servlet, JSF2), Komponenten (EJB, CDI) als auch Persistenz (JPA, Bean Validation). Eine solche Web Application kann auch, und das ist neu in Java EE 6, als WAR Datei deployed werden. Vorbei die Zeiten der XML-überfluteten EARs. EJB3.1 ist als Lite Ausprägung im Web Profile enthalten. Lite bedeutet u.a. den Verzicht auf MessageDriven Beans und die neue asynchrone Ausführung von Methoden. Die Application Server können sich mit dem neuen Profil deutlich schlanker formen und reduzieren damit sowohl Administrationsaufwand als auch Betriebskosten.

Diese neu gewonnene Attraktivität von Java EE ist spürbar: Auf Konferenzen wie der W-JAX 2010 war das Interesse an den Standard Frameworks sehr gross. In Workshops wie dem Java EE 6 Roundtrip von Adam Bien konnte man froh sein, einen Sitzplatz zu ergattern.

Ein neues Komponentenmodell

Ein wichtiger Bestandteil von Java EE 6 Web Profile ist die „Contexts and Dependency Injection“, kurz CDI. Hierbei handelt es sich um ein weiteres Komponentenmodell, also ähnlich wie EJB. CDI verfolgt aber andere Ziele: Es enthält kein automatisches Transaktionshandling, hat keine Remote und Local Interfaces und hält hinsichtlich der mitgelieferten Features sicherlich keinen Vergleich zu EJB stand.

Dafür besitzt es aber eine nochmals erhöhte Flexibilität, die gerade bei Web Applications in vielen Schichten sinnvoll ist. Denn, soviel sei vorweg genommen, es ist durchaus ein gangbarer und oft sinnvoller Weg, CDI mit EJB zu kombinieren. Beispielsweise könnte eine JSF2 View an einen CDI View Layer gekoppelt sein. Die Business Logik im nachgelagerten Layer kann dann transaktionssicher per EJB gekapselt sein. Die danach folgende Persistenz kann wieder per CDI flexibel gehandhabt werden. Dies ist, wie gesagt, nur ein Beispiel; trotzdem zeigt es bereits einerseits wie flexibel auf die Anforderungen des Kundensystems eingegangen werden kann, andererseits aber auch dass bei der Architektur des Systems Beratung zwingend notwendig ist.

Ganz kurzer Ausritt in die Theorie: CDI wird durch den JSR-299 spezifiziert. Dieser Standard bildet einen Layer auf dem JSR-330 „Dependency Injection“. Man benutzt also eigentlich beide Standards.

Einbindung von CDI in die Web Application

Zurück zur Praxis. Um eine Library vom Container bzw. dessen CDI-Implementierung (Referenz ist JBoss Weld) für CDI zu scannen, muss eine beans.xml Datei angelegt werden. Keine Angst, die „Hell of XML“ bricht nicht aus, denn die Datei bleibt in der Regel bis auf das Root-Element leer. Sie dient nur als Notifizierung dass die Library (kann auch ein JAR sein) gescannt werden soll.

CDI besteht wie üblich aus Scopes und Beans. Die Steuerung erfolgt über Annotations. Eine Bean kann per @Named zum CDI Kontext hinzugefügt werden. Sie ist dann per Standard im Request Scope. Über gezieltes Scoping wie @SessionScoped kann eine Bean auch mehrere Requests überleben. Interessant ist dabei, dass im Gegensatz zu anderen Komponentenmodellen, z.B. JSF2 @ManagedBean, erzwungen wird dass eine passivierbare Bean, also zum Beispiel @SessionScoped, java.io.Serializable implementiert. Ist dies nicht der Fall, versagt CDI / Weld den Start. Dies beugt vielen unangenehmen Überraschungen vor, falls später einmal Sessions passiviert und wiederhergestellt werden.

@Named
public class Addition {
    // ...
}

Wenn hier kein Parameter an die Annotation hinzugefügt wird, wird sie automatisch mit dem Klassennamen benannt, hier also „addition“. Man kann aber via Parameter den Namen auch selbst festlegen.

Der umgekehrte Weg, also die Nutzung einer im CDI Kontext registrierten Bean, kann auf mehrere Wege geschehen. Innerhalb einer anderen CDI Bean kann per @Inject Annotation darauf zugegriffen werden. Die Deklaration erfolgt typsicher. Der Container wird bei Initialisierung dieser Bean entweder eine im Scope vorhandene Bean injecten oder eine neue Bean erzeugen und an diese Stelle referenzieren.

    @Inject
    private Addition addition;

Wie man sieht wurde kein textueller Name bei der Annotation genutzt. Es reicht die Typangabe, um die Bean zu lokalisieren. Dabei kann es durchaus Fälle geben, in denen mehrere Beans vom gleichen Typ im Kontext vorhanden sind. Es gibt jedoch auch hier Mittel, typsicher die richtige Variante herauszufinden. Dazu später mehr.

Die Injection funktioniert auch innerhalb von Servlets, hier ein Beispiel in Servlet API 3.0:

@WebServlet(name="CDIServlet", urlPatterns={"/cdi"})
public class CDIServlet extends HttpServlet {
    
    @Inject
    private Addition addition;
    // ...
}

Da verwundert es nicht, dass auch ein Zugriff aus der Expression Language in JSF2 möglich ist:

    <h:outputText value="#{addition.text}" />

Hier muss nun erstmals der mit @Named implizit eingeführte Name der Bean genutzt werden. EL ist leider nicht typsicher.

Und so geht es weiter

Mit den nun vorgestellten Mitteln können Beans in CDI registriert sowie wieder referenziert werden. Dies ist jedoch nur die Grundlage für erweiterte Features, welche CDI dann richtig interessant machen. Im in Kürze folgenden Teil geht es daher tiefer in den Code: Wie man Beans ohne @Named und aus Methoden heraus in CDI erstellt, wie man Mengen von Beans injected und damit einen echten Plugin Mechanismus baut, sowie wie man mehrere Beans der gleichen Klasse im Kontext trotzdem typsicher unterscheiden kann.

Bis dahin beantworte ich gerne Rückfragen rund um CDI und/oder Java EE 6.

Intelligenzblatt – Wirklich viel nachgedacht?

Die Schaffhauser Nachrichten bieten ihre Inhalte auf dem Web seit Donnerstag nur noch gegen Geld resp. für bezahlende Print-Abonnenten an. Die Branche freute es, dass endlich jemand das Experiment wagt, lobt das Vorgehen in ersten Umfragen scheu, gibt stark regionalen Inhalten (im Gegensatz zu News) eine Chance und schiebt gleich in den Satz rein, dass die es nicht so tun werden. Und ich schaue mir die Site der Schaffhauser Nachrichten endlich mal an.

Das erste was mir dabei ins Auge springt ist der Seitentitel, der in der Trefferzitaten bei Google einen prominenten Platz findet („andere“ Inhalte gibt es ja auf für Crawler nicht mehr): Intelligenzblatt.

2917-schaffhauser_intelligenzblatt.png

Komisches Selbstverständnis – nicht wirklich sympathisch. Aber darum geht es ja nicht, aber um die Frage, ob das mit der Bezahlung intelligent gemacht ist. Ich meine nein. Die Homepage ist mit „Schlössern“ zugekleistert… sieht es im Verlies des Munot möglicherweise so aus?

2922-schaffhauser_nachrichten_home-thumb-500x417-2921.png

Und tatsächlich es gibt nichts mehr zu lesen ausser Titel. Nach meiner Ansicht der falsche Ansatz, denn auch bei jedem Marktstand gibt es als Argument für einen Kauf ein „Versucherli“. Vom negativen Effekt auf die externe Verlinkung (soziales Web auch schon in SH angekommen) und die damit verbundene Erschliessung und Rangierung durch Suchmaschinen ganz zu schweigen.

Eher in der Kategorie lustig zu Hause ist der Bildschirm den ich erhalte, wenn ich auf einen Deeplink klicke. So beispielsweise auf das „Lesen Sie mehr“ bei der heutigen Top-Story oder auf einen Link bei Google (die alten Seiten sind sowohl in Index wie auch im Cache noch drin).

2919-schffhauser_nachrichten_meier_ID-thumb-500x414-2918.png

Nun fehlt mir möglicherweise der Lokalkolorit, aber bei besten Willen kann ich die „Meier-ID“ geistig nicht mit den Schaffhauser Nachrichten verbinden. Aber schliesslich ist es mir bei „Intelligenzblatt“ ja auch nicht spontan gelungen und da es ja keine Inhalte gibt um es zu be- oder widerlegen, gehe ich mal getrost in das sonnige Wochenende.

PS: ACAP ist als „Silver Bullet“ wohl auch wieder gestorben

Veröffentlicht unter Allgemein | Verschlagwortet mit

Drupal 7 Release

Endlich ist es soweit, Drupal 7 ist „fertig„. Nach dem Ausprobieren der Release Candidates wollte man schon gar nicht mehr zurück auf Drupal 6 und nun kann man die neuen Funktionen und Verbesserung auch guten Gewissens nutzen.

Es lassen sich allein schon über die technischen Verbesserungen der Kernfunktion zahlreiche Blog-Posts füllen aber das was einem Administrator in den ersten Minuten auffällt ist, dass Usability ernst genommen wurde.

2889-d7-pageadd-thumb-500x443-2888.png

Der Screenshot zeigt das Erstellen einer Seite im neuen Overlay-Backend und man merkt deutlich, dass die Prinzipien des D7UX-Projekts einem die Arbeit erleichtern und die Funktionen ansprechend aussehen lassen. Es sind besonders die kleinen Details wie ein ansprechender Abbrechen Button oder passendere Menünamen, welche die Arbeit für den Redakteur oder Administrator angenehmer machen. Kein Vergleich zu dem in die Jahre gekommenen Garland.

Wer das Open Source CMS Drupal bereits kennt der weiss, dass der Drupal Core, welcher nun in Version 7.0 vorliegt, nicht für eine Drupal-Umsetzung genügt. Es ist das Ökosystem von hunderten, ausgereiften Modulen, welches Drupal so vielseitig macht und die berechtigte Frage ist: Muss ich auf alles was nicht Core ist warten?

Die Antwort ist glücklicherweise meist nicht, denn das D7CX-Gelöbnis hat die Mehrheit der Entwickler von Top-Modulen überzeugt, stabile Versionen Ihrer Module zum Drupal-7-Release fertigzustellen. Sicherlich werden viele kleinere Module auch noch einige Zeit benötigen bis eine stabile Version verfügbar ist. In den meisten Fällen kann man aber jetzt mit Drupal 7 starten.