Sitecore Commerce Connect – Teil 1: Ein Überblick am Beispiel Hybris

Wie in meinem Vortrag zum Thema “Evaluierung einer Hybris-Anbindung an Sitecore” auf der letzten Sitecore Usergroup in Bielefeld versprochen, möchte ich mit dieser Beitragsserie unsere ersten Eindrücke von der Anbindung eines externen Shopsystems (in diesem Beispiel Hybris) an Sitecore mittels des Commerce Connect Moduls mit euch teilen.

In diesem Artikel geht es mir darum, euch einen ersten Überblick über das Marketing-Potenzial und Funktionsumfang des Moduls zu verschaffen. In den nächsten Beträgen wird es dann technischer mit konkreten Ausschnitten aus Konfigurationsdateien und Quellcode.

Warum sollten WebCMS und E-Commerce Platform verbunden werden?

Bevor wir an die technischen Details gehen, erlaube ich mir zunächst einige Gedanken aus Sicht von Produkt-Management, Marketing und Vertrieb auf Betreiberseite:

Webnutzer erwarten immer mehr eine einheitliche User-Experience, die sich über alle Kanäle und Plattformen eines Unternehmens erstrecken soll. Zudem bringen auch Online-Shop Systeme kleinere CMS-Funktionalitäten mit und damit wird auch die Darstellung von Inhalten immer besser. Warum sollten dann CMS und Shop miteinander verbunden werden?

Sitecore bietet bereits in seiner eigenen Suite ein umfangreiches Bundle an Funktionen, um verschiedenste Touchpoints (Webseite, Newsletter, Social Media, Offline-Kanäle am POS usw.) zu einem Nutzererlebnis aus einem Guss zu verschmelzen.

Mit diesem Beispiel möchte ich Möglichkeiten aufzeigen, mit denen Besuchern auch auf Unternehmenswebseiten die Kernfunktionalitäten eines Online-Shops angeboten werden können (wie bspw. Produkte in den Warenkorb legen) und wie diese kombinierten Webseiten- und E-Commerce-Daten dann von der Unternehmenswebseite automatisch an das Shopsystem übergeben werden.

Ein Beispiel für eine Customer Journey mit Optimierungspotenzial sähe beispielsweise so aus:

Der Kunde schaut auf einer Webseite nach einem Produkt, muss sich das Produkt merken und im separaten Online-Shop danach suchen um zu bestellen.

Das bedeutet:
Durch die zwei separaten Technologien Webseite und Shop entsteht für den Kunden Fehler- und Frustrations-Potenzial. Für Unternehmen und Shop-Anbieter kann das bedeuten: Erhöhte Abbruchgefahr und damit niedrigere Conversion-Rate.

Mit Lösungen wie dem Commerce Connect arbeitet die Technologie im Hintergrund für den Kunden, nimmt ihm Arbeitsschritte ab und erhöht damit die Wahrscheinlichkeit, dass es zu einem Verkauf kommt.

Der Endkunde bemerkt so den Technologiewechsel aus dem WebCMS in den Online-Shop überhaupt nicht und hat ein nahtloses Nutzererlebnis im Bestellprozess.

Kurzvorstellung Sitecore Commerce Connect

Sitecore Commerce Connect sieht sich als Framework und API zur nahtlosen Integration von 3rd-Party Commerce Systemen in Sitecore. Das Ziel ist die Überführung der Experience Marketing Features in die Commerce Welt:

Einheitliche Darstellung: Produktkataloge, “normale” Inhalte und Bilder aus einem Guss
Bearbeitung von Produktkatalogen, Seiteninhalten und Bildern in einen System
Nutzung der Sitecore Facettensuche über ALLE Inhalte.
Personalisierung auch über das Kaufverhalten der Besucher
Tracking von Conversions und Values rund um den Einkauf
Identifizierung von und Einblick in die wertvollsten Kunden
Reaktion auf Änderungen im Geschäft, in Echtzeit

Konkreter Umfang des Commerce Connect Moduls

Das Sitecore Modul bietet die Möglichkeit Produktkataloge mit dem externen Commerce System zu synchronisieren, d.h. es stellt entsprechende Templates, Klassen, Repositories, Import-Pipelines etc. zur Verfügung:

Sitecore-Commerce-Connect-Modul

Erste Engagement-Pläne zu Warenkorb-Abbrüchen, neuen Aufträgen und Wiederverfügbarkeit von Produktbeständen werden mitgeliefert und genutzt:

Sitecore-Commerce-Connect-Engagement-Plan

Selbstverständlich kommen auch Erweiterungen für die Sitecore Rule Engine mit:

Sitecore-Commerce-Connect-Rule-Engine

Das Framework des Sitecore Commerce Connect

Die Architektur wird von Sitecore wie folgt skizziert, wobei der Commerce Server Connector und der Dynamics AX Connector fertige Connectoren von Sitecore selbst sind und der Hybris Connector von uns im Rahmen der Evaluierung entwickelt wurde.

Service Layer:

Folgende Bereiche deckt das Modul ab:

Warenkorb
Preise
Kunden und Benutzer
Bestände
Produkte
Aufträge
Geschenkkarten
Wunschlisten
Bezahlung
Versand
Treueprogramme

Die einzelnen Layer sind optional und unabhängig voneinander. Ein Layer umfasst ein Datenmodell und Pipelines mit ggf. zugehörigen Service Providern. Die farblich markierten Service Layer wurden im Rahmen des PoC näher beleuchtet. Wenn ihr einen Eindruck haben möchtet was sich dahinter verbirgt, habt etwas Geduld – die zugehörigen Artikel folgen.

Prinzipien

Weil sie mir so gut gefallen haben, hier eine kurze Zusammenfassung und Übersetzung der Prinzipien welche dem Modul von Sitecore selbst auferlegt wurden:

Simplicity – kleinster gemeinsamer Nenner
Extensibility – Domain Model erweiterbar
Independently – keine Abhängigkeit zwischen Service Layern
Abstraction – keine Sitecore oder Shopsystem Abhängigkeit in Service Layern
Pipelines – jeder Service Layer benutzt Sitecore Pipelines
Fallback – fehlende Implementierungen im Shopsystem können überbrückt werden

Erstes Resumé

Mein Eindruck nach der Evaluierung des Commerce Connect anhand einer Hybris-Anbindung:

Der erste Einstieg ist herausfordernd, kurz stand ich davor wie “der Ochs vorm Berg”. Auf dem Partnertag in Frankfurt wurde von Sitecore eine Schulung zu dem Modul angekündigt. Die kann ich dann nur empfehlen.
Das bringt mich zu den zur Verfügung stehenden Materialien:
- Es gibt umfangreiche Dokumentationen über das Modul im Developer Netzwerk.
- Cookbooks gibt es leider keine, diese helfen sonst häufig die erste Hürde zu nehmen.
- Wenn die Dokumentation nicht weiter hilft, gibt es im Internet aktuell leider noch wenig Material zum Commerce Connect.
- Geholfen haben immer wieder die herunterladbaren Beispiel-Implementierungen für AX und CommerceServer und natürlich dotPeek.
Customizing gehört zum Grundkonzept. Durch eine gute Abstraktion ist fast alles flexibel anpassbar. Das gefällt, auch wenn es manchmal nicht einfach ist, im Pipeline-Dschungel den Überblick zu bewahren.
Für eine solide und benutzerfreundliche Integration ist eCommerce-KnowHow unumgänglich. Die dahinterliegenden Modelle und Prozesse müssen durchdrungen werden.
Die Komplexität einer Commerce Integration bringt auch höhere Konzeptions- und Abstimmungsaufwände mit sich als vielleicht sonst im CMS-Umfeld üblich.
Das Modul umfasst keine Layout-Komponenten und keine speziellen Applikationen.
Der “Merchandising Manager” ist NICHT Bestandteil des Commerce Connect, sondern des CommerceServer Connect.
Eine gute Einsatzmöglichkeit für das Modul ist m.E. eine PIM-Integration.
Zu guter Letzt: Die Arbeit mit dem Modul hat mir Spaß gemacht!

Die Präsentation zum Vortrag:

Evaluierung einer Hybris-Anbindung an Sitecore mittels Commerce Connect from comspace GmbH & Co. KG

In den kommenden Tagen werde ich diese Serie mit den folgenden Artikeln fortführen:

23. Oktober 2015

Ottobock HealthCare: erfolgreiches internes E-Mail-Marketing mit Inxmail

Als unser langjähriger Kunde Ottobock vor einiger Zeit ein Tool zur unternehmensinternen Mitarbeiterinformation- und Kommunikation suchte, schlug ihm unser Projektleiter das Inxmail E-Mail-Marketing System vor. Die Idee zur Verwendung eines E-Mail Marketing Instruments wurde aus der Anforderung geboren, die News aus dem Ottobock Produktmanagement zielgruppenorientiert mit weiterführenden Downloads-Links und Responsemöglichkeit im Unternehmen zu versenden.

Mit der Ausarbeitung eines Newsletter-Layouts im Corporate Design von Ottobock und der Entwicklung und Programmierung eines Templates haben wir das E-Mail-Marketing Konzept mit Inxmail erfolgreich umgesetzt. Inzwischen existieren rund 13 verschiedene Newsletter in mehreren Sprachversionen, darunter auch in Kyrillisch und auf Arabisch – mit entsprechend anderer Laufrichtung des Textes und der Bedienelemente. In einem zweiten Schritt haben wir die Redakteure umfassend in der Erstellung und Auswertung der Newsletter und der Empfängerverwaltung geschult.

Newsletter zur internen Kommunikation: Was war die Ausgangslage?

Das Produktmanagement der Mobility Solutions – dem Unternehmensbereich, der hochwertige Rollstühle und Reha-Bedarf herstellt – versandte in unregelmäßigen Intervallen umfangreiche Präsentationen an alle Vertriebsbeteiligten der über 50 Standorte weltweit per MS-Outlook®. Nicht nur, dass die inhaltlich wichtigen Infos Postfächer verstopften – es gab auch keine Übersicht für die Versender, was eigentlich von Interesse war. Ein attraktiver Newsletter, der die Neuigkeiten anteasert und bei Bedarf auf weitere Infos und viel häufiger auf wichtige Dokumente verlinkt, stellte die passende Lösung dar. Mit den Inxmail Webspaces lassen sich gerade die Download-Dokumente bestens verwalten und bereitstellen.

Besonders wichtig für die Produktmanager: der direkte Response. Zu den allermeisten News gibt es einen konkreten Ansprechpartner, der per Mail aus dem Newsletter heraus direkt angeschrieben werden kann – ohne jeden Medienbruch. Und: Newsletter eignen sich auch dazu kurzfristig definierte Zielgruppen zu erreichen.

Ausweitung der Newsletter auf den B2B-Bereich

Da sich die Kommunikationsform innerhalb des Unternehmens bewährt hat, wurde das Angebot für die B2B Kommunikation ausgebaut. Inzwischen erhält auch der ausgewählte Fachhandel, die Sanitätshäuser, in Deutschland und Österreich regelmäßig Updates aus dem Produktsegment Mobility.

Damit nicht genug: Die Lösung, per Newsletter intern zu informieren, überzeugte weitere Abteilungen der Otto Bock HealthCare, die gerne auf die guten Erfahrungen mit der Inxmail-Lösung zurückgriffen.

Die unterschiedlichen Unternehmensbereiche und mehr als 60 Redakteure können auf Basis der bestehenden Listen nun sehr gezielt Artikel verfassen, die dann in einem weiteren Schritt durch die Chefredaktion freigegeben und als Newsletter versendet werden.

Durch die einfache Texteingabe ohne HTML-Kenntnisse erweist sich die Erstellung der Mailings für die Redakteure als sehr komfortabel und einfach. So wird die Lösung auch im Produktmanagement sehr gut angenommen.

Inzwischen haben wir auf eigenen Vorschlag die Templates aller Listen in einer Vorlage konsolidiert. Da sich die Newsletter über Header und – besonders wichtig – in der Anbieterkennung des Footers unterscheiden, sind variable Teile der Templates als Bausteine hinterlegt. Einerseits können Anpassungen, z.B. an einen neuen Markenauftritt wie aktuell nach dem Website-Relaunch, einfacher umgesetzt werden, und gleichzeitig ist bei der Erstellung eines Mailings für die Redakteure sichergestellt, dass die verwendete Vorlage auch die richtige ist.

Mit Inxmail ließ sich das interne und inzwischen auf ausgewählte Partner ausgeweitete E-Mail Marketing gerade deshalb gut einführen, weil mit einzelnen Funktionen und kleinen Volumen in der Mietvariante (ASP-Service) mit sehr überschaubaren Kosten begonnen werden konnte. Die Weiterentwicklung des Tools haben wir stets in enger Abstimmung mit dem Auftraggeber durchgeführt.

Learnings und Anforderungen konnten alle Beteiligten am Projekt schnell zur Umsetzung bringen. Inzwischen gibt es auch über Inxmail erzeugte An- und Abmeldeseiten, die problemlos in das bestehende CMS integriert werden können.

Durch das Newsletter-Template im Ottobock-einheitlichen Layout können wir die korrekte Optik in allen Mailings gewährleisten, obwohl die Newsletter dezentral in verschiedenen Abteilungen erstellt werden. Die zahlreichen Auswertungsmöglichkeiten wie Öffnungs- und Klickraten liefern uns gute Hinweise für die Mailing-Optimierung. Ein weiterer Vorteil von Inxmail Professional ist die einfache Realisierung von Zielgruppen-spezifischen Mailings, indem wir die Empfänger durch die Vergabe von Attributen bestimmten Zielgruppen zuordnen können.

Janett Klaus, Head of Digital Marketing | Marketing Communications

Fazit zum internen Newsletter-Mailing

Mit einem effizienten E-Mail Marketing Tool wie dem Inxmail System können innerhalb einer großen Organisation schnell notwendige Informationen transportiert werden. Die Anfangsinvestitionen bleiben dabei moderat. Das Tool kann laufend und gezielt – entsprechend der sich entwickelnden Businessprozesse – ausgebaut und angepasst werden.

Wenn auch Sie eine Lösung für Ihr E-Mail Marketing suchen: Fragen Sie uns einfach! Wir stellen Ihnen gerne die E-Mail-Marketing Lösung von Inxmail vor. Als Inxmail Solution-Partner sind wir ein erfahrener Dienstleister und unterstützen Sie bei der Umsetzung Ihres individuellen Newsletter-Konzeptes.

25. September 2015

Schnelleinstieg in das Team Development for Sitecore (TDS)

Ihr habt noch nicht mit dem TDS gearbeitet, möchtet es aber mal ausprobieren? Dann seid ihr hier richtig. Mit diesem Blog-Beitrag möchte ich euch einen schnellen Einstieg in das TDS vermitteln. Wenn ihr wissen wollt was das TDS ist und wie es grundsätzlich funktioniert, dann könnt ihr das in diesem Beitrag nachlesen.

Installation des TDS

Auf der Webseite von Hedgehog könnt ihr das TDS herunterladen und 30 Tage lang kostenlos testen. Anschließend müsst ihr euch nur noch den zu eurem Visual Studio passenden Windows Installer heraussuchen, z.B. den HedgehogDevelopmentTDS_VS2013.msi und euch durch den Assistenten klicken.

Konfiguration von TDS Projekten

Zunächst setzt ihr wie gewohnt ein neues Projekt auf, d.h. ihr installiert Sitecore und richtet eine Visual Studio Projektmappe/ Solution ein.

Anschließend werden die TDS-Projekte eingerichtet. Eine erste TDS-Projektstruktur könnte wie folgt aussehen:

Tds.Core – enthält Client-Anpassungen
Tds.Master.Templates – enthält Templates
Tds.Master.Layouts – enthält Layouts, Sublayouts etc.
Tds.Master.Content – Beispielcontent, den jeder Entwickler braucht.

Je Projekt führt ihr folgende Schritte durch, wie hier am Beispiel des Tds.Master.Template-Projektes visualisiert:

1. TDS-Projekt anlegen

Rechtsklick auf der Projektmappe > Hinzufügen > Neues Projekt:

2. TDS-Projekt konfigurieren

Rechtsklick auf dem TDS-Projekt > Eigenschaften:

General Tab

Datenbank eintragen, hier “master”
Hinweis: Ein Projekt, z.B. das Tds.Master.Template-Projekt sollte mit dem Web-Projekt verbunden werden, dann wird das Web-Projekt auch automatisch mit deployed (Pfad siehe Build Tab).

Build Tab

Sitecore Web Url: Url unter der das Projekt zu erreichen ist
Sitecore Deploy Folder: Root-Verzeichnis der Webseite
Den Sitecore Connector installieren und die Verbindung testen.
Hinweis: Die erste generierte Guid in ALLE Projekte kopieren, diese muss innerhalb der Projektmappe identisch sein.

3. Item Synchronisation einrichten

Um die zu synchronisierenden Items einzurichten, klickt ihr mit der rechten Maustaste auf TDS-Projekt > “Get Sitecore Items” und wählt die Items aus:

Anschließend könnt ihr einfach mal ein Item in Sitecore anlegen und im Visual Studio das TDS-Projekt mit der rechten Maustaste > “Sync with Sitecore” synchronisieren:

Das war’s schon. Das erste TDS-Projekt ist fertig eingerichtet.

Einrichtung Code Generierung

Als nächsten Schritt möchte ich mit euch noch die automatische Generierung von Template-Klassen mittels Glass.Mapper einrichten.

1. Installation Glass.Mapper.Sc

Bevor wir damit starten, solltet ihr sicher stellen, dass im Web-Projekt

das NuGet-Paket “Microsoft ASP.NET MVC” installiert ist und
die Sitecore.Kernel-Bibliothek als Verweis zur Verfügung steht.

Anschließend müsst ihr einfach das NuGet-Paket “Glass.Mapper.Sc“ von nuget.org installieren:

2. Generierung einrichten

Hierzu bedarf es folgender Schritte:

In den Projekteigenschaften des TDS-Projekts, das die Templates synchronisiert (hier Tds.Master.Template), auf dem Tab “Code Generation” die Code Generierung aktivieren.
T4-Templates für den Glass.Mapper hier herunterladen.
Folgende tt-Dateien im Tds.Master.Templates Projekt im Folder “Code Generation Templates” ablegen und zum TDS-Projekt hinzufügen:
- Helpers.tt
- GlassV3Header.tt
- GlassV3Item.tt
- GeneralExtensions.tt
- Inflector.tt
- StringExtensions.ttt

Die Generierung konfigurieren
- Target Project: Web-Projekt
- Code Generation Target File: z.B. “Model/GeneratedClasses.cs”
- Base Namespace: z.B. Modle
- Header Transformation File: GlassV3Header.tt
- Base Project Transformation File: GlassV3Item.tt

3. Generierung testen

Entweder ihr klickt mit der rechten Maustaste auf das TDS-Projekt > “Re-Generate Code for all Items” oder ihr fügt im Sitecore ein neues Item hinzu und synchronisiert dieses mit dem TDS-Projekt.

Wenn ihr keine Fehlermeldung erhaltet, dann findet ihr eure Templates als Klassen in der “GeneratedClasses.cs” wieder. Andernfalls schaut mal im nächsten Absatz.

Mögliche Stolpersteine

Fehlender Namspace Glass.Mapper.Sc.Mvc

Es ist wichtig, dass ihr erst ASP.NET MVC installiert und dann das Glass.Mapper.Sc-Paket, andernfalls wird der Verweis auf “Glass.Mapper.Sc.Mvc” nicht mit installiert.

T4-Templates gesperrt

Wenn ihr die Meldung ”ErrorGeneratingOutput” wiederholt in der generierten Klasse findet, dann liegt es häufig daran, dass ihr die T4-Templates von einer externen Quelle geladen habt und diese noch entsperrt werden müssen:

Überflüssige Leerzeile

Wenn ihr in der generierten Klasse untenstehende Meldung seht, dann schaut mal im “GlassV3Item.tt”. Dort ist vermutlich in der letzten Zeile eine Leerzeile, die zu entfernen ist.

*********************************************
 An error occured while generating code for item '/sitecore/templates'.

T4 Template: F:\SitecoreDEV\Projekte\TdsDemo\TdsDemo.Tds.Master\Code Generation Templates\glassv3item.tt

Errors:

Kompilierte Transformation: Ungültiges Token 'this' in Klasse, Struktur oder Schnittstellenmemberdeklaration.

Kompilierte Transformation: Die Methode muss einen Rückgabetyp besitzen.

Kompilierte Transformation: Typ erwartet.

*********************************************

Wie geht es weiter?

Die erste Einrichtung habt ihr jetzt hinter euch und damit habt ihr auch einen ersten Eindruck vom TDS gewonnen. Wenn ihr das Thema vertiefen wollt, empfehle ich euch z.B. das Manual von Hedgehog. Zum Thema automatische Builds und Deployment-Strategien findet ihr im Build Extensions Whitepaper Ansätze.

Ich freue mich über Kommentare zu euren Erfahrungen mit dem TDS!

19. August 2015

Professionelle Sitecore Entwicklung mit dem TDS

Wofür steht eigentlich TDS?

TDS steht für Team Development for Sitecore. Es ist im Wesentlichen eine Visual Studio Erweiterung der Firma Hedgehog, einem Technologie-Partner von Sitecore mit Sitz in den USA.

Was macht das TDS?

Zusammengefasst ermöglicht bzw. reduziert es die Komplexität von:

Automatisierten Builds und Deployments in Sitecore
Autarken, schnell aufsetzbaren Entwicklungsumgebungen
Generierung von Template-Klassen

Im Detail bedeutet das Folgendes:

Item Synchronisation

Sitecore Entwicklung heißt vereinfacht, Quellcode im Visual Studio zu schreiben und Templates, Layouts, Client-Erweiterungen etc. als Items über Sitecore in der Datenbank anzulegen und zu bearbeiten. Der Quellcode wird selbstverständlich in einem Versionskontrollsystem, wie z.B. SVN oder Git, verwaltet, aber was passiert mit den Anpassungen in der Datenbank?

Da die Sitecore Items nicht im Versionskontrollsystem liegen, ist kein ganzheitlicher Stand im Nachhinein einsehbar, geschweige denn bearbeitbar.

Das TDS schließt diese Lücke in der Sitecore Entwicklung: es bietet eine komfortable Möglichkeit auch Sitecore Items mittels Versionskontrollsystem zu verwalten. Dialoggesteuert können Items aus der Versionsverwaltung in das Sitecore eingespielt werden oder aus dem Sitecore zur Ablage in selbiger serialisiert werden.

Durch die ganzheitliche Betrachtung von Quellcode und Datenbank, können wir in der Entwicklung die Vorteile eines Versionskontrollsystems voll nutzen:

Es kann in Branches entwickelt werden, die dann zu definierten Zeitpunkten zu Releases zusammengeführt werden.
Definierte Stände können jederzeit vollständig wiederhergestellt werden.
Wir können sinnvoll (ohne Sitecore Packages) mit verteilten Entwicklungsdatenbanken arbeiten: Jeder Entwickler hat seine eigene Datenbank statt der bisher globalen Datenbank.
Jeder Entwickler kann einfach mal einen Branch auschecken, etwas ausprobieren inkl. Datenbankanpassungen und hinterher einfach wieder alles verwerfen.

Automatisches Deployment

Mittels TDS können Sitecore Update-Packages gebaut werden, die dann im Rahmen eines automatischen Deployments auf einem Zielsystem ausgeliefert werden können.

Das Update-Package kann einfach mittels Sitecore Installation Wizard (zu finden unter /sitecore/admin/UpdateInstallationWizard.aspx) auf dem Zielsystem installiert werden. Für eine automatisierte Auslieferung steht z.B. das Modul Sitecore.Ship zur Verfügung, mit dem die Datei mittels HTTP-Request hochgeladen werden kann.

Achtung: Nicht einfach das Sitecore.Ship vom NuGet-Server installieren, denn dieses ist nicht Sitecore 8 kompatibel. Bitte in diesen Fällen die Version von GitHub nutzen.

Generierung von Template-Klassen

Das TDS bietet außerdem die Möglichkeit, Template-Klassen basierend auf T4-Templates zu generieren. Entsprechende Glass.Mapper-Templates findet ihr auf GitHub. Der Glass.Mapper ist ein OR-Mapper für Sitecore Items, Details findet ihr hier.

Die Template-Klassen werden vom TDS während der Item-Synchronisation im Hintergrund automatisch mit aktualisiert.

Zu guter Letzt sei hier noch gesagt, dass auch ein einfaches Klassen-Template Diagramm generiert werden kann:

Sitecore Klassen-Template-Diagramm — TDS Template-Klassen-Diagramm

Gibt es Alternativen?

Natürlich ist das TDS kein Muss. Es gibt auch kostenfreie Tools, die das TDS teilweise ersetzen. Im Folgenden findet ihr eine Liste der Module, welche zusammen beispielsweise die Funktionen alternativ übernehmen können:

Item Sychronisation: Unicorn
Erstellung von Update-Packages: Courier
Generierung von Template-Klassen: Sitecore.CodeGenerator

Alle verwendeten Module sind SharedSource und stehen auch auf GitHub zur Verfügung.

Mir hat die Alternativ-Idee grundsätzlich gut gefallen, denn TDS ist ja auch nicht gerade günstig. Aufgrund folgender Punkte haben wir uns dennoch für das TDS entschieden:

Nicht alle Module waren zum Testzeitpunkt Sitecore 8-kompatibel.
Anpassungen sind zwar möglich, aber wären dann auch dauerhaft erforderlich. Eine neue Sitecore Version heißt Test und ggf. neues Build.
Komfort und Stabilität: Für vergleichbare Funktionen sind mehr bzw. umständlichere Schritte erforderlich und das führt letztlich immer zu Reibungsverlusten.
Wir fokussieren uns auf unser Business CMS-Entwicklung und kaufen uns die erforderlichen Entwicklungswerkzeuge, samt Support und Wartung.

Erste Schritte

Neugierig geworden? Dann schaut mal auf der Webseite von Hedgehog: 30 Tage könnt ihr das TDS kostenlos evaluieren.

Und für den Schnelleinstieg steht euch hier im Blog eine Schritt für Schritt Anleitung zur Verfügung.

Fazit

Als Sitecore-Entwicklerin möchte ich ohne das TDS nicht mehr arbeiten.

In wenigen Minuten ist ein neuer Branch eines Kundenprojektes zur Entwicklung auf meinem Rechner bereit:

Branch des Kundenprojektes erstellen und ausschecken
Leere Sitecore Installation in der erforderlichen Sitecore Version mittels SIM Tool installieren
Visual Studio Solution des Projektes öffnen
1. Item Synchronisation des TDS ausführen
2. Solution veröffentlichen.
Site in Sitecore publizieren.

Und dass ich keine Deployments mehr manuell mittels Packages, sondern automatisiert mittels TDS und Buildserver durchführen möchte, versteht sich wohl von selbst 🙂

Welche Erfahrungen habt ihr mit dem TDS gemacht? Ich freue mich auf Eure Kommentare.

15. Mai 2015

Digitale Kundenerlebnisse schaffen mit der Sitecore Experience Plattform 8.0

Sitecore hat sich in den vergangenen Jahren immer stärker von einem reinen Content Management System zu einer umfassenden Plattform für digitale Kundenerlebnisse gewandelt. In dieser Plattform werden verschiedenen Unternehmens-Systeme zusammenführt und Webseiten individueller auf den Nutzerbedarf anpasst. Mit Einführung der neuen Version 8.0 rücken die Marketing-Funktionalitäten des Systems noch stärker in den Vordergrund als bisher. User Experience ist der große Übergegriff, dem sich alle Sitecore CMS-Funktionalitäten verschreiben. Für den Endverbraucher der auf der Website angebotenen Produkte sollen über alle Kanäle hinweg konsistente digitale Erlebnisse geschaffen werden, die mit der Sitecore Experience Plattform eingerichtet und weitgehend automatisiert gesteuert, optimiert und analysiert werden können.

“Experience” ist Bestandteil aller Sitecore Produkte

So ist es nur konsequent dass Sitecore auch die Namensgebung seiner gesamten Plattform und der einzelnen Produkte im Laufe des vergangenen Jahres auf das Kundenerlebnis ausgerichtet hat: Die ehemalige Customer Engagement Plattform wurde in Sitecore Experience Platform umbenannt, aus dem Digital Marketing System (DMS) wurde die heutige Experience Database und den Page Editor findet der Redakteur jetzt als Experience Editor wieder. Email Experience Manager (EXM), Experience Profile und Experience Analytics sind weitere Module, die die User Experience schon im Namen tragen.

Was sind die Highlights von Sitecore 8.0?

Zunächst einmal sorgt die an Windows 8 angelehnte Kachel-Optik für eine klare übersichtliche Gestaltung im Backend, das dem Anwender einen raschen Überblick über die verfügbaren Funktionalitäten bietet.

Die grundlegenden inhaltlichen Veränderungen gegenüber den Vorgänger-Versionen bestehen in der optimalen Visualisierung aller gewonnenen Kundendaten im Sitecore Experience Profile sowie in den vielfältigen Analyse-Möglichkeiten. Sämtliche Kundeninformationen und -interaktionen aus verschiedenen, auch Sitecore-unabhängigen Kanälen – ob Online oder Offline – werden in den Experience Profiles zusammen geführt – und dies nicht nur vergangenheitsbezogen, sondern in Echtzeit. Aus diesen lassen sich dynamisch Zielgruppen segmentieren, die ihrer Kundenhistorie entsprechend (Surf- und Klickverhalten, Geo-Daten etc.) relevante Inhalte angeboten bekommen.

Die Features von Experience Analytics helfen dem Marketer dabei, Szenarien und Website-Inhalte mit Hilfe von A/B- oder multivariaten Tests zu bewerten und zu optimieren und mit Hilfe der Engagement Values aufzuzeigen, welche Aktionen in den verschiedenen Kommunikationskanälen erfolgreich sind. Die umfangreichen Statistiken aus der xDB, der Experience Database, ergänzen die Erkenntnisse zum Kundenverhalten aus anderen Webanalyse-Tools.

MongoDB ergänzt die Datenbank-Architektur

Die Experience Database der Version 8.0 arbeitet auf der Basis von MongoDB. Diese NoSQL-Datenbank ist aufgrund ihrer flexiblen Datensatzstrukturen und ihrer Skalierbarkeit besser für Big Data Marketing geeignet als die Microsoft SQL-Datenbanken und erlaubt das Speichern umfangreicher Datenmengen als nicht-relationale Objekte. Weiterhin zeichnet die MongoDB Vorteile in der Zugriffsgeschwindigkeit aus.

Fazit:

Sitecore 8.0 stellt Unternehmen eine ausgereifte Marketing-Plattform zur Verfügung, um einerseits durch personalisierte Inhalte die Usability für die Nutzer zu steigern und andererseits durch tiefgehende Analysen die Kommunikation in allen Kanälen kontinuierlich und überwiegend automatisiert zu personalisieren und damit die Wertschöpfung des Unternehmens zu erhöhen.

Dabei sollte allerdings darauf geachtet werden, dass vor lauter automatisierten Optimierungsmöglichkeiten und einer Vielzahl an verfügbaren Kennzahlen nicht die gesetzten Kampagnenziele aus den Augen verloren werden. Kennzahlen wie Zugriffe, Verweildauer oder Click-through-rates geben zwar wichtige Signale, jedoch muss die Steigerung einzelner KPIs isoliert betrachtet nicht unbedingt auf die Online Marketing-Ziele einzahlen. Empfehlenswert ist daher ein in regelmäßigen Abständen wiederholter Abgleich der in Sitecore umgesetzten Maßnahmen mit den Zielen der Online Strategie.

Demnächst werden wir hier im Blog über einige unsere Praxiserfahrungen mit Sitecore 8.0 berichten.

4. Dezember 2014

So entstand die Bielefeld 360 Grad App der Neuen Westfälischen

Am Anfang eines jeden neuen Projektes steht die richtige Team-Zusammenstellung. Bei unseren CMS-Projekten werden die Teams vor allem nach der verwendeten CMS-Technologie wie Sitecore oder FirstSpirit zusammen gesetzt. Im Fall der 360 Grad Bielefeld App-Entwicklung setzte sich das Kernteam nach den Anforderungen der Neuen Westfälischen aus drei Personen zusammen, die besonders gut zum Bereich Web-Anwendungsentwicklung passen:

John Gibbon als Web-Entwickler, Daniel Blomeyer als Frontend-Entwickler und Markus Plauschinn war der verantwortliche Projektmanager.

Die App selber können Sie hier für 1,79 EUR herunterladen:

Wer macht was?

Kurz gesagt: WebEntwickler_innen bauen die eigentliche App auf – die Anwendung eben. Frontend-Entwickler_innen sorgen dafür, dass die App gut aussieht und vor allem gut benutzt werden kann und Projekt-Manager_innen sind die Schnittstelle zwischen Kunde und comspace. Sie sorgen für die Abstimmung der Anforderungen, geben Lösungsansätze die durch Entwickler_innen erarbeitet werden an die Kunden zurück, erstellen den Projektplan und behalten ein Auge auf die Einhaltung von Terminen.

Ausführlich können Sie sich in diesem Artikel über die Berufsportraits informieren

Das heißt im Falle der Bielefeld 360 Grad App

Stefan Gerold von der Neuen Westfälischen stellte uns einen ersten Entwurf als Ausgangslage für den Aufbau der App vor. Diese bestand aus einer Webseite, die die grundsätzlichen Funktionen und erste Panorama-Fotos enthielt. Auf dieser Basis entstand eine technische Konzeption, die das spätere Endprodukt zum 800 Jahre Jubiläum der Stadt Bielefeld beschrieb.

Die technische Konzeption ließ uns die besonderen Herausforderungen erkennen, für die wir individuelle Lösungen entwickeln mussten:

Ansicht und Navigation durch Panorama-Bilder
lange Ladezeiten durch große Panoramas vermeiden – Zielgröße der App kleiner als 50MB
Bielefeld 360 Grad soll in verschiedenen Größen in Hoch- und Querformat dargestellt werden (auf Smartphones und Tablets verschiedener Größen)

Neben den Basisanforderungen wie Menü-Steuerung, Hilfe- und Infoseiten haben wir aus der vorliegenden Lösungsskizze die genauen Anforderungen rückwärts abgeleitet (re-engineered). Dann wurde zunächst einmal eine Web-Anwendung erstellt, die auf stationären Rechnern entwickelt wurde. Begonnen wurde mit dem Rahmen und der Navigation. Dann folgten die ersten Bielefeld-Panoramen um die App benutzbar zu machen. Die mobile Anwendung wurde zunächst einmal nur simuliert. Aus dieser Entwicklung entstanden dann die einzelnen Lösungsansätze, mit denen wir die Darstellung der großen Bielefeld-Panoramas ermöglichten:

Wir zerschnitten die Panoramas in Einzelbilder, die später in der App wieder zusammen gesetzt dargestellt werden, wie man es bsw. von Google Maps kennt
Um eine flexible Darstellung auf unterschiedlichen Bildschirmgrößen zu ermöglichen wurden die Markierungen neu gesetzt, mit deren Hilfe sich Benutzer_innen auf ihrem Bielefeld-Rundgang durch die einzelnen Panoramas navigieren
Bildergalerien und Zusatzinformationen wurden den Orten im Panorama zugeordnet und über eine Menüfunktion zugänglich gemacht
Radio Bielefeld steuerte Tonspuren bei, die automatisch abgespielt werden sollen, wenn ein Panorama angeklickt wird. Hierzu benötigte die App eine eigene Abspielfunktion für Audiodateien
Das führte zu einem zusätzlichen Button um den Ton schnell an und aus zu schalten

Nachdem die erste funktionierende Web-App mit entsprechenden Funktionen stand, fütterten wir das Cordova-Framework mit dem Projektergebnis. Dieser Werkzeugkasten zur Webentwicklung, der mittlerweile zu Adobe gehört, hält den Aufwand gering, um aus einer Web-Anwendung eine lauffähige App für verschiedenste Smartphone-Systeme zu erzeugen.

Danach ging eigentlich alles ganz schnell: Der erste Stand wurde durch uns präsentiert und in mehreren Feedbackrunden nah am Kunden wurde mit der NW die App fertig entwickelt. Dabei wurden vor allem viele kleine Änderungen Schritt für Schritt durchgeführt, wie die Gestaltung des App-Icons, Testinstallationen auf verschiedenen Geräten usw.

Wie kommt die App in den Store?

Hier kommt das eigentlich aus dem voran gegangenen Absatz zum Tragen, denn von der Fertigstellung der App, der Freigabe durch den Kunden bis zur tatsächlichen Verfügbarkeit im Appstore (besonders bei Apple) vergehen gerne einmal zwei bis drei Wochen. Sollte Ihre App also zeitkritisch sein – bsw. für eine Messe oder ein Jubiläum, planen sie ausreichend Zeit für das Einstellen in die App-Stores ein. Mittlerweile ist es sowohl im Apple wie auch im Android Store möglich, eine automatische Veröffentlichung nach Freigabe zu deaktivieren. So lässt sich ein gleichzeitiger Launch verschiedener Versionen realisieren.

Weitere Einblicke in die Entstehung der Bielefeld 360 Grad App erhalten Sie in den kommenden Tagen zu folgenden Themen:

Wie entstand die Idee zur App – Interview mit Stefan Gerold von der NW
Panorama Fotografie was ist das eigentlich – Fotograf Andreas Frücht erklärt
Die Berufe hinter der App: Anwendungsentwickler, Frontent-Developer, Projektmanager
Elsa-Brändström-Straße 2-4: Eines der Panoramas über den Dächern Bielefelds entstand auf dem Dach von comspace

10. September 2014

Sitecore CMS in der Cloud mit Microsoft Azure – Ein Fallbeispiel

Ein Enterprise CMS-System wie Sitecore in der Cloud zu betreiben macht in vielen Fällen Sinn. Insbesondere bei regelmäßigen Lastspitzen oder bei weltweit verteilt betriebenen Webseiten. Azure ist Microsofts Cloud-Lösung, bringt automatisches Deployment von Webservern mit und unterstützt natürlich auch Microsoft SQL Datenbanken. Da Sitecore auf Windows-Server-Plattformen läuft, bietet sich hier eine genauere Prüfung einer kombinierten Lösung an.

Ein solches Vorhaben bringt einiges an Fragen, Anforderungen und Herausforderungen mit sich. Deswegen führten wir ein Testprojekt durch, bei dem unsere Kollegin Friederike die Kopie eines Kundenprojekts in die Azure Cloud umzog, um valide Erfahrungen mit dieser speziellen Lösungs-Kombination zu sammeln. Diese Erfahrungen haben wir in einem Test-Tagebuch festgehalten, aus dem wir Ihnen hier die wichtigsten Erkenntnisse vorstellen möchten.

Alles ist ein Service

Mittlerweile gibt es tatsächlich die Abkürzung XaaS bzw. EaaS – „Everything as a Service“ als Überbegriff für all die Leistungen wie Software, Plattformen, Infrastrukturen, Laufzeitumgebungen, Hardware und viele mehr, die sich als Services buchen und on demand beschaffen lassen.

Die generellen Hauptvorteile für Kunden beim Einsatz einer Cloud-Strategie sind:

Keine Bindung an physische Güter
Aktualität und Leistung von Hardware immer ausreichend
flexible Abrechnung nach Nutzungsintensität, -Dauer, Nutzeranzahl
keine Kapital-Bindung
geringe bis keine Wartungskosten

Die eingangs gezeigte Infographik von Microsoft (hier zum Download als PDF) illustriert sehr gut, welche Gesamtmöglichkeiten die Microsoft Azure Cloud-Services bieten. Wir konzentrieren uns hier auf einen kleinen Teilbereich.

Sitecore CMS in der Cloud – IaaS

Eine Telko mit dem Azure Vertrieb brachte zunächst Überraschendes hervor: Das Aufsetzen einer Sitecore Instanz dauert nur 7 Minuten. Weltweit! Das ist erstmal schwer zu glauben, stellte sich aber als Tatsache heraus.

Aber: Das bedeutet im einzelnen das hinzu schalten / hochfahren einer weiteren Sitecore CD Instanz dauert 7 Minuten. Das basiert allerdings auf einer vollständig konfigurierten Publizierungsinstanz / Deployment Center. Dieses vorzubereiten und aufzusetzen (Sitecore Installation) und dann zu konfigurieren dauert natürlich länger. Diese Arbeit hätte man aber auch bei einer Installation im eigenen Rechenzentrum.

In einem unserer Testläufe haben wir Azure als IaaS (Infrastructure as a Service) getestet. Zum einen kann ein virtueller Server als „Quick Create“ aufgesetzt werden. Diesen kann man sich wie einen frisch installierten Rechner vorstellen.

Interessanter sind für uns in diesem Fall die vorkonfigurierten Server-Images aus einer Gallery. Wir entscheiden uns für Option A3 mit 4 CPU-Kernen und 7 Gigabyte Arbeitsspeicher. Übrigens ist als Serverstandort in Westeuropa nur Amsterdam oder Dublin möglich. Eine Standort-Option in Deutschland gibt es (zumindest noch) nicht.

Die Installation von Sitecore lief für unsere Experten an sich problemlos. Einzig an einigen Stellen musste die Dokumentation konsultiert werden:

diverse Module für den IIS Webserver nachinstallieren
Datenbankuser korrekt anlegen
korrekte Portangabe setzen

Kosten für den Installationsvorgang auf der virtuellen Maschine: 0,21 €

Zitat aus unserer Technik: „Hier habe ich genau die gleichen Malessen mit Lizenzen, Updates, Wartung, Administrierung wie im eigenen Rechenzentrum. Nur das Blech habe ich in diesem Fall nicht.“

Mehr können Sie dazu hier in der Dokumentation bei Microsoft erfahren.

Azure SQL wird in die Cloud ausgelagert – SaaS

Hier liegt nur die Datenbanksoftware in der Cloud. Dadurch wird das zu Grunde liegende Betriebssystem irrelevant. Dabei unterliegt Azure SQL einigen Unterschieden zur Microsoft SQL, wodurch sich die Datenbanken nicht so einfach migrieren ließen wie gewohnt.
In diesem SaaS-Fallbeispiel wird also nur ein Softwarebestandteil in der Cloud genutzt.
Wenn die Windows-Server sowieso zur Verfügung stehen, haben wir für dieses Modell keine direkte Anwendungsmöglichkeit in unserem Umfeld gefunden.

Sitecore CMS in der Cloud – PaaS

Sicherlich das spannendste Szenario. Hierzu haben wir zunächst die virtuelle IaaS Maschine kopiert und als Deployment Center benutzt. Natürlich hätten wir hierfür auch einen bereits lokal und physisch vorhandenen Server hernehmen können.

Dann wurde eine Kopie der Daten des Kundenprojekts, die wir freundlicherweise für unseren Test nutzen durften, in das Projekt migriert. Nach ca. einem Tag war die Migration der Daten (Languages, Templates, CoreDB, Files Package, Database Package und Configs) erfolgreich durch.

Sitecore wurde auf die aktuellste Version upgegradet.

Das Azure Modul wird schlussendlich installiert und konfiguriert.

Danach kann innerhalb von 7 Minuten per Klick ein Server hochgefahren werden. Ob in Hongkong, Dublin oder Australien ist dabei quasi unerheblich.

In diesem Fall liegt alles was wir benötigen bereits vorinstalliert als „Plattform“ in der Cloud:

Betriebssystem
IIS Webserver
lauffähiges Sitecore
und Datenbank als SaaS oder Datenbank-Server oder im eigenen Rechenzentrum“

Wenn der DNS-Eintrag auf den Azure Traffic-Manager und die Routings entsprechend angepasst sind, werden bspw. Anfragen aus Südostasien deutlich schneller bedient, als wenn diese Besucher auf einen Webserver in Deutschland geroutet würden, da der Traffic Manager als Geo-DNS fungiert und den Traffic intelligent je nach Standort der Benutzer umleitet.

Bei besonderen Lastspitzen geht das ganze Procedere übrigens auch automatisch.
Sprich:
Server werden nach Bedarf gestartet, wenn plötzlich der Traffic irgendwo auf der Welt hoch geht. (Wenn zum Beispiel ein Fernsehbeitrag in Australien gezeigt wird.) Genauso können stärkere Maschinen per Termin im Voraus gebucht werden. An Weihnachten, bei einer geschalteten Kampagne oder zum Produkt-Launch. Zum angegebenen Zeitpunkt werden demnach die Serverkapazitäten erhöht und nach Ablauf wieder gesenkt um auf smarte Weise Kosten zu sparen.

Aus welchen Gründen kann eine CMS-Instanz in der Cloud Sinn machen?

Admins sparen Hardware, Zeit, Geld, Lizenzen, Wartung. Backups aus der Cloud auf lokale Rechner sollte man sich natürlich trotzdem noch ziehen.
Entwickler können schnell mal ein volles Testsystem hochziehen für 1-3 Tage nutzen und dann wieder abschalten. Gezahlt wird zeitgenau abgerechnet anstatt für fünfstellige Summen neue Server zu kaufen.
Global verteilte Standorte sind on demand möglich und damit auch eine schnellere Auslieferung an Endnutzer.
Plötzlich ansteigender Traffic kann automatisiert und nach fein einstellbaren Regeln abgefangen werden.

Gibt es eine Kostenersparnis?

In unserem Beispiel könnte die Azure-Lösung einige Prozentpunkte günstiger sein als die vorhandene physische Struktur.
Aber:
Ein Umzug in die Cloud wäre ein umfangreiches Projekt, das momentan noch die Einsparungen auffressen würde.
Für neue Projekte könnte eine Cloudnutzung durchaus von Beginn an günstiger sein.

Qualitätssicherungssysteme und Entwicklungssysteme, die nur bei Bedarf genutzt werden, könnten in einem „Pay-as-you-Go“-Bezahlmodell durchaus zukünftig eine Ersparnis bedeuten.

Fakt ist, dass sich Anbieter von Cloudlösungen wie Google, Microsoft und Amazon – um nur einmal die großen zu nennen – quasi ständig neu unterbieten was die Kosten angeht oder den Funktionsumfang für den Kunden erweitern. Damit werden Cloud-Ansätze zunehmend attraktiver.

Unser Fazit:

Die Komplexität eines Cloud-Umzugs ist nicht zu unterschätzen und setzt eine sehr präzise Planung für einen konkreten Use-Case voraus. Je nach Use-Case kann bereits heute eine Kostenersparnis realisiert werden. Performance-Gewinn und -Optimierung ist auf jeden Fall möglich.

Interessieren Sie Details zu unseren Erfahrungen mit Sitecore in der Cloud? Nehmen Sie gerne Kontakt mit uns auf!

Weiterführende Informationen:

In einer hervorragenden 7-teiligen Blog-Serie beschäftigt sich Microsoft Architect Evangelist Holger Sirtl hier bei MSDN mit der Auswahl der einzelnen Ausführungsmodelle von Microsoft Azure anhand von verschiedenen Szenarien:
Teil 1: Überblick über die Ausführungsoptionen
Teil 2: Virtual Machines
Teil 3: Cloud Services
Teil 4: Websites
Teil 5: Mobile Services
Teil 6: Auswahl des besten Ausführungsmodells
Teil 7: Wechsel des Ausführungsmodells

Für die Kostenkalkulation eines Cloud-Projekts hat Microsoft einen Preisrechner veröffentlicht

Monatliche, kostenlose Webcasts zum Thema Azur bietet Microsoft hier an

Fallstudien zu Microsoft Azure finden Sie hier

Eine zusätzliche Beschreibung der Besonderheiten bei der Installation des Moduls Sitecore Azure finden Sie bei den schweizer Kollegen im namics-Blog

15. Oktober 2013

comspace mit mobilem ChatBot auf MobileCon2013 in San Jose vertreten

Unser Kollege Martin Freisen wird sich morgen ins sonnige Kalifornien zur Konferenz MobileCon2013 aufmachen und dort vom 17. bis 18.10. als Experte einen Hackathon für unseren Partner Jibe Mobile begleiten. Zahlreiche Entwickler werden während des Hackathons Erweiterungen für einen von uns gebauten mobilen Chat-Roboter programmieren und Martin wird ihnen für Fragen als Ansprechpartner zur Verfügung stehen. (Ein Hackathon (Wikipedia-Definition) ist ein Programmierwettbewerb, bei dem in möglichst kurzer Zeit so viele innovative Lösungen wie möglich entstehen sollen.)

Titel des Hackathons: Sprint RCS Messaging: Enhance content delivery with an app using Jibe’s RCS API.

Was ist ein ChatBot und was kann er?

Das Bot steht als Abkürzung für Roboter. Es handelt sich demnach um einen Roboter, der chatten, also eine Unterhaltung führen kann. In unserem Fall sogar über mobile Endgeräte. Der bekannteste ChatBot dürfte wohl die gute, alte Eliza sein. Dem einen oder anderen dürfte auch der Begriff Turing-Test bekannt vorkommen, mit dem durch gezielte Fragen festgestellt wird, ob am anderen Ende eines Chats eine Maschine oder ein Mensch sitzt.

Wozu ein ChatBot gebraucht wird:

Klingt nach einer unnötigen Spielerei? Wird aber immer wichtiger. Beispielsweise in der Kundenberatung:

Stellen Sie sich vor, sie surfen auf eine Katalogseite und suchen ein ganz bestimmtes Produkt. Der ChatBot spricht Sie an, was er für Sie tun kann und Sie geben Ihre Anfrage ein: „Ich suche nach einem iPhone Radio“. Der ChatBot sucht nach besonderen Begriffen in Ihrer Eingabe – in diesem Fall iPhone und Radio und gibt die passende Antwort aus.
Diese Antworten können nach vorher festgelegten Regeln oder später sogar nach einem intelligenten Algorithmus ausgewählt werden. Vom einfachen Suchergebnis nach iPhone-Radios bis hin zu gezielten Rückfragen des ChatBots, die das Ergebnis weiter verfeinern.

Denkbar ist aber auch eine barrierefreie Navigation durch Webseiten: Sie sprechen Ihre Suchanfrage ins Smartphone, durch Speech-to-Text wird Ihr Befehl in maschinenlesbare Befehle umgewandelt, die der ChatBot ausführt. Beispiel: „Ich hätte gerne die Speisekarte“. Sie müssen sich nicht durch die Navigation klicken, sondern der ChatBot öffnet Ihnen direkt die gewünschte Webseite. Funktioniert natürlich auch mit Tastatureingaben. Statt zu klicken können Webseiten so auch mit gezielten Kommandos bedient werden.

Was kann unser ChatBot denn nun?

Bisher haben wir das Grundgerüst für die Web-Version des Bots auf Basis von node.js gebaut, die folgende Funktionen beherrscht:

Nachrichten empfangen
Nachrichten senden
Dateien senden
Location senden

Damit sollen die Entwickler während des Hackathon rumspielen, Funktionen erweitern und Anwendungen bauen. Der Event ist vom US-Mobilfunkanbieter Sprint gesponsert, der auch die Preise von 1000$ bis 5000$ für die besten Lösungen zur Verfügung stellt.

Wir sind irre gespannt, welche Lösungen während des Hackathons entstehen werden. Natürlich werden wir hier nach Martins Rückkehr aus San Jose berichten 🙂

Weiteres gibt es auch im offiziellen Blog der Konferenz und im Blog bei Jibe Mobile zu lesen.

11. Oktober 2013

Recap von den OpenCms Days in Köln

Am 30. September und 1. Oktober 2013 fanden zum 5. Mal die OpenCms Days in Köln statt, die internationale User Konferenz und Ausstellung rund um das Content Management System OpenCms. Zahlreiche Nutzer und Experten aus aller Welt nahmen die Gelegenheit wahr, sich über ihre Erfahrungen mit OpenCms auszutauschen.

Das Konferenzprogramm bot insgesamt 16 interessante Vorträge zum Thema OpenCms von erfahrenen Rednern aus aller Welt. Im Vordergrund stand die Vorstellung des neuen OpenCms Release 9. Neben den Vorträgen der Entwickler des OpenCms waren auch Partner-Unternehmen eingeladen, um ihre Erfahrungen aus den Bereichen Social Media, Cloud Dienste und Responsive Design mit der Community zu teilen.

Zum ersten Mal schnupperten auch unsere beiden Kolleginnen Hanna (Projektleiterin) und Anna Katharina (Developerin) die OpenCms Conference-Luft und sie haben viele positive Eindrücke aus Köln mitgenommen. Die Konferenz fand im MediaPark statt, einem der attraktivsten und architektonisch herausragendsten Standorte Kölns, der damit einen excellenten Rahmen für die Veranstaltung bot. Damit war auch für reichlich interessante Abwechslung in den Pausen gesorgt wie bspw. mit der Bernd und Hilla Becher-Ausstellung.

An folgenden Sessions haben unsere Kolleginnen teil genommen:

Neues in OpenCms 9

Zunächst wurde das Demo-Projekt vorgestellt, das mittlerweile ein responsives Design besitzt. Außerdem sind einige neue Module zur Demo hinzugekommen wie Slider, Image Galleries und weitere dynamische Listen. Besonders hervorgehoben wurde das Klon-Feature, mit dem man ein bereits vorhandenes Modul klonen kann, ohne die zuvor bereits verknüpften Inhalte zu verlieren. Auch im Backend gab es einige kleinere Anpassungen mit neuen Icons, einem verbesserten Publish-Dialog und einer größeren Nutzerfreundlichkeit im Formeditor. Ein weiteres neues Feature sind die „Network Shares“. Diese ermöglichen es, dass Ordner des virtuellen File Systems des OpenCms als Netzwerk-Laufwerk im eigenen Betriebssystem genutzt werden können.

Das Update von Version 8.5 auf Version 9 soll sehr einfach funktionieren. Der Praxis-Test bleibt abzuwarten – das Release wird erst Ende Oktober 2013 zum Download bereit stehen.

OpenCms Days Vortrag OpenCms 9 — Vortrag OpenCms Release 9

OpenCms-Partner stellen ihre Lösungen vor

1. OpenCms at paf.com: content distribution in a fully automated release process

Ville Komulainen arbeitet für eine finnische Online-Gaming Website. Da sowohl die Spiele, als auch die redaktionellen Inhalte der Website auf einem System liegen, aber viele Menschen daran arbeiten müssen, hat jedes Team seine ganz eigene Entwicklungsumgebung. Um jedoch in regelmäßigen Abständen Releases zu veröffentlichen, muss das System diese Releases einwandfrei deployen können. Dies ist besonders wichtig, da die Website mit dem Geld der Nutzer interagiert; sie ist quasi eine Bank. Aus diesem Grund hat die Firma ein sehr kompliziertes System entwickelt, das automatisiert die Veröffentlichung der Releases abwickelt.

2. Outsourcing OpenCms Template Design

Dieser Vortrag wurde von dem Japaner Yuta Aoki (Ubicast) gehalten und hat für reichlich Diskussionen gesorgt. Grundsätzlich ging es ihm darum, zu erzählen, welche Erfahrungen er und seine Firma beim Outsourcing des Template Designs für ihre Website gemacht haben und was sie daraus lernen konnten. Veranschaulicht hat er das mit Hilfe von Folien, die Probleme und Lösungsempfehlungen zeigten. Eine Aussage war, dass Designs zu teuer seien und der Lösungsvorschlag war, Designer über sog. “99ers”-Websites (Seiten mit Festpreisen wie $299) zu engagieren. Des Weiteren ging es darum, Kriterien für gute Designer-Arbeit zu finden und diese als Guidelines niederzuschreiben. In der Diskussion stimmten die meisten zwar zu, dass es gute Designer zu günstigen Preisen und auch schlechte Designer zu teuren Preisen gibt, aber es gibt eben auch günstige UND gute Designer. Das einhellige Fazit war jedoch, dass das Entscheidende bei der Zusammenarbeit zwischen Designer und Programmierer die Kommunikation ist, um ein gutes und preiswertes Projekt zu realisieren.

3. Social Connect for OpenCms Portal

Helmut Manck, CEO bei eonas IT-Beratung und -Entwicklung GmbH, stellte in seinem Vortrag eine von seinem Unternehmen entwickelte Erweiterung für OpenCms vor, die sich mit Social Media Funktionalitäten beschäftigt. Zunächst einmal wurden dabei die am meisten verbreiteten und beliebtesten Social Media Features beschrieben und dann analysiert, welche dieser Funktionalitäten im OpenCms Anwendung finden könnten. Da das OpenCms auch oft in Intranet-Projekten zum Einsatz kommt, wurde nach Alternativen gesucht und damit verglichen. Das Unternehmen hatte versucht, eine ähnliche Funktionalität wie die des “Business Social Networks” Yammer für das OpenCms zu entwickeln, in der jedoch alle verwendeten Tools das System mit Informationen füttern. So kann man beispielsweise nach einer Person suchen und bekommt Informationen aus allen im Unternehmen verwendeten Tools. Realisiert wurde dies mit Hilfe der RSS-Feeds aus den einzelnen Tools und SOLR-Queries. Das Open Source Projekt steht Interessierten auf Github zur Verfügung.

4. A technical approach to OpenCms responsive web design

Inhalt dieses Vortrags von Henning Treu, IT Consultant bei der codecentric AG, war es, wie mit Responsive Web Design die Nutzer besser erreichbar sind, aber damit auch der Workflow zur Entstehung einer Website gundlegend verändert wird. Um Responsive Web Design (RWD) umzusetzen, müssen alle Teilnehmer des Workflows entsprechend mitarbeiten. Ein großer Vorteil des RWD ist die Übermittlung von Bildern. Wird die Website in einem Desktop Browser mit schneller Internetverbindung angezeigt, stellt die Übertragung von Bildern in hoher Auflösung normalerweise kein Problem dar, wohingegen mobile Geräte wie Smartphones nicht über eine so hohe Bandbreite verfügen und dementsprechend länger für das Laden einer Website benötigen. Henning Treu stellte eine Technik vor, durch die das OpenCms den Ansatz des RWD auf Bilder anwenden kann, sodass die Website auch auf mobilen Geräten schnell geladen und dargestellt wird und so die User glücklich macht. In seinem Ansatz befindet sich eine Action-Klasse im OpenCms, die das Bild, sobald es hochgeladen wird, verarbeitet und aus dem Bild drei Bilder in verschiedenen Größen/Qualitäten generiert und im VFS (Virtual File System) speichert. Das Problem dieses Lösungsansatzes ist jedoch leider, dass dieser Vorgang relativ langsam abgewickelt wird, sodass es durchaus 10 Minuten in Anspruch nehmen kann, bis die Bilder verfügbar sind. Dadurch erscheint der Ansatz auch im Falle einer großen Anzahl Bilder relativ problematisch. Das Fazit dieses Vortrags war also eher enttäuschend, da sich scheinbar noch kein optimaler technischer Lösungsansatz im OpenCms für RWD gezeigt hat.

5. OpenCms all dressed up: styling your websites with themes

Dieser Vortrag sollte eigentlich von Sebastian Bolt und Robert Diawara gehalten werden, jedoch war nur Erstgenannter anwesend, weshalb leider auf technische Fragen verzichtet werden musste. Thema des Vortrags war die Vorstellung des von componio entwickelten Produkts “SkinnDriva”. SkinnDriva ist ein OpenCms Modul für die Frontend-Generierung. Es zeichnet sich durch hohe Flexibilität aus, da verschiedenste Frameworks wie Bootstrap, Grid360 oder Bootstrap genutzt werden können und Ressourcen automatisch gepackt, aber seperat bearbeitet werden können. Die Entwickler sehen in der Nutzung von SkinnDriva auch eine Stärkung der Vorteile von OpenCms am Markt, da das User-Interface-Design einfacher angepasst werden kann und flexibler ist als in vielen anderen CMS. Um SkinnDriva nutzen zu können, muss das Paket heruntergeladen und mit drei Modulen in das OpenCms installiert werden. Das “Commons”-Modul dient der Kompatibilität mit anderen Frameworks wie Bootstrap. Das “Core”-Modul stellt Formatter, Taglibs und die grundsätzliche Funktionalität bereit. Das “Base”-Modul stellt bereits eine Vorauswahl an Modulen wie einem Artikel-Modul bereit, die genutzt und nach Belieben angepasst werden können. Nachdem das Template registriert, erstellt und die Formatter angepasst sind, kann SkinnDriva genutzt werden. Zudem will Componio in Zukunft eine Art Community anbieten, in der Nutzer ihre Themes anderen zur Verfügung stellen können.

Ob comspace einen Nutzen aus SkinnDriva ziehen kann, ist abzuwarten. Leider existierte am Präsentationstag noch keine Demo und auch keine Community-Website. Die Zuhörer konnten also nur einer sehr abstrakten Theorie lauschen. Diese hörte sich vom Prinzip sehr ähnlich an wie die bereits bei comspace für die Frontend-Entwicklung genutzten Tools und Techniken. Für die Neugierigen ist SkinnDriva für OpenCms unter www.skinndriva.com verfügbar.

OpenCms Days Kaffeepause — wohlverdiente Kaffeepause

Und welche interessanten Begegnungen gab es noch?

Unsere beiden Kolleginnen tauschte sich u.a. mit der Agentur 3m5 aus Dresden über ihre Erfahrungen mit OpenCms aus. Ebenfalls sehr angenehm haben sie die Bekanntschaft mit einem Entwickler einer Schweizer Bank empfunden. Er war sehr erfahren im Umgang mit dem OpenCms, da er seit vielen Jahren damit arbeitet, und konnte viele interessante Anekdoten bezüglich der Zusammenarbeit zwischen Entwicklern, Designern und Marketing erzählen.

Besonders beeindruckend zu erfahren war, dass das Team, das das OpenCms entwickelt, aus nur 8 Personen besteht: 6 Entwickler, Sektretärin und Chef. Das Team entwickelt nicht nur, sondern setzt auch noch Projekte für Kunden um und finanziert so den Unterhalt seiner Mitarbeiter.

Das Fazit: Die Atmosphäre im MediaPark war angenehm, die Veranstaltung mit Rund-um-Verpflegung vom OpenCms-Team gut organisiert und die Vorträge äußerst lehrreich. Die OpenCms „Überraschungstüte“ mit verschiedenen nützlichen Werbemitteln und vielen Gummibärchen als Pausensnack hat ebenfalls zur guten Erinnerung an die beiden Tage beigetragen;). Wir hoffen, nicht das letzte Mal an den OpenCms Days teilgenommen zu haben!

8. August 2013

Fragmentierung mobiler Endgeräte macht Responsive Design immer wichtiger

Nein mit Fragmentierung meine ich nicht die verstreute Speicherung auf einem Datenträger, sondern die schier unendliche und damit immer problematischer werdende Vielfalt von mobilen Endgeräten und Darstellungsmöglichkeiten von Webseiten. OpenSignal hat vor einigen Tagen eine Studie veröffentlicht, die zeigt, wie heterogen insbesondere der Android-Gerätemarkt ist:

Fast 12.000 verschiedene Geräte-Modelle konnte das Unternehmen OpenSignal unter den Downloads seiner App OpenSignalMaps ausmachen bei einer Gesamtzahl von untersuchten Geräten von 682.000. Das ist im Vergleich zu 2012 fast eine Verdreifachung der Geräte-Diversität.

Ganz genau hat Staircase 11868 Geräte Modelle ermittelt. Das ist schon ein Wort. Nimmt man sich jetzt noch die 9 üblichen Android-Betriebssysteme der Versionen 2.x und 4.x, dann kommen wir auf 4,6 Sextillionen (sprich: 11868 hoch 9 – Danke, Wolfram Alpha) Kombinationen. Zugegeben, diesen Grad der Fragmentierung werden wir nicht erreichen, aber eine Zahl mit 36 Nullen verdeutlicht recht gut die immer stärker wachsende Individualität des Webs.

Fragmentierung Android Geräte (c) OpenSignal

Was bedeutet diese Fragmentierung für den Nutzer?

Grundsätzlich können Web-Einsteiger und Neu-Nutzer wie z.B. die stark wachsende Zielgruppe 55 Jahre und älter, die Benutzung des Web durch immer intuitiver zu bedienende Geräte erschließen. Auf Apple-Geräten derzeit noch deutlich einfacher: Beispielsweise lässt sich selbst auf einem iPhone der ersten Generation die Grundbedienung von iOS noch nachvollziehen und auf ein Gerät der neuesten Generation übertragen: Ein iPad verhält sich ähnlich wie ein iPhone und wie ein iPod. Auch wenn eine gewisse Fragmentierung unter iOS Geräten zu beobachten ist wie (AndroidMag hier erklärt) beziehen sich die Unterschiede zwischen Apples Geräten weniger auf übergeordnete System-Merkmale als auf bsw. die Funktionsweise der Kamera oder Einzel-Apps wie Passbook.

Schauen wir dann auf die Android Welt, sieht die Sache schon anders aus: Ein Gerät unter Android 2.x fühlt sich von der Bedienung für einen Anfänger anders an, als ein Gerät unter 4.x. Kommen dann noch die herstellerspezifischen Besonderheiten ggü. dem Standard-Android-System hinzu wie Samsungs KIES oder die Benutzeroberfläche von HTC Sense wird ein Umdenken zwischen den Geräten noch schwieriger.

Bemerkenswert in diesem Zusammenhang ist die Marktmacht im Android-Segment von Samsung. 47,5% aller Geräte kommen vom koreanischen Hersteller. An 2. Stelle kommt Sony mit 6,5% gefolgt von Motorola mit 4,2% und HTC mit 3,9%. Bei den meistverkauften Gerätemodellen fällt die Verteilung noch deutlicher aus: Die Top-10 der Android-Bestseller besteht zu 9 Geräten aus Samsung-Produkten. Einzig das Google Nexus 4 (hergestellt von LG)

Daher sollte die Bedienung einer Webseite über die unterschiedlichen Systeme und Geräte so konsistent wie möglich bleiben, um Anwender nicht unnötig zu verwirren und die Benutzung von Webseiten nicht zusätzlich zu erschweren.

Die Probleme des Nutzers lassen sich auf die Darstellung von Webseiten übertragen

Ganz ähnlich verhält es sich bei der Darstellung von Webseiten auf mobilen Endgeräten: Unterschiedliche Betriebssystemversionen, Bildschirmgrößen, Bedienkonzepte und Browserfunktionen führen zu der Eingangs erwähnten Fragmentierung der digitalen Endgeräte.

In der guten alten „Gründerzeit des Internet“ gab zwischen 1995 und 1998 es die Browserkriege zwischen Netscape Navigator und Microsoft Internet Explorer (aktuelle Informationen zu den „Browserkriegen“ hat Henning Brune zusammengetragen). Und schon damals war es eine Herausforderung, eine Webseite technisch so auszuliefern, dass die Gestaltung in beiden Browsern möglichst gleich aussah.

Interessanterweise ist die Fragmentierung unter den Display-Größen noch am geringsten. Hier konzentrieren sich die die 70% der Androids, 74% der iOS-Geräte und nahezu 100% der Windows-Devices in einem Bildschirm-Größen-Segment von 3,5 bis 4,9″:

Displaygroessen-eMarketer-slideshare-flurry-analytics — Folie zu Displaygrößen aus einem Responsive Design Webinar bei eMarketer

Responsive Design oder mobile Ausgabekanäle?

In unseren Enterprise-CMS Projekten nutzen wir derzeit entweder Ausgabekanäle, die für bestimmte Merkmale mobiler Endgeräte optimiert sind (eine solche Lösung haben wir auf der diesjährigen CeBIT vorgestellt) oder wir setzen auf responsives Design, bei dem sich die angezeigte Webseite an Displaygrößen und Darstellungsmöglichkeiten automatisch anpasst. Zum Beispiel werden Inhalte statt in 3 Spalten nur in 1 Spalte angeordnet oder Menus in einer Auswahlbox zusammengefasst, um sie auf einem mobilen Gerät besser bedienen zu können. In einigen Fällen kann eine Mischform Sinn machen, bei der Inhalte der Standard-Seite gekürzt werden um nur Informationen darzustellen, die für die mobile Zielgruppe Sinn machen.

Beruhigend ist im Zusammenhang der fragmentierten Endgeräte-Landschaft, dass die Anpassung einer mobilen Webseite deutlich einfacher zu bewerkstelligen ist, als eine native App, da bei einer Migration letzterer deutlich mehr Einflussfaktoren bsw. durch die verwendete Harddware zum Tragen kommen.

Aber in Zukunft ist doch sicher eine Standardisierung zu erwarten?

Eher nicht. Ganz im Gegenteil. Es kommen ständig neue Geräteklassen hinzu. Denken Sie einmal an Google Glass und entsprechende Datenbrillen-Kopien, an Smartwatches oder vernetzte Entertainment-Systeme in modernen Autos. Und das sind nur die aktuell auf der Schwelle stehenden Geräte. In 3-5 Jahren werden daraus wiederum neue Anwendungsfelder und Innovationen entstanden sein.

Eine langfristige Lösung wird wohl eher darin liegen, Standards zu schaffen und diese über unterschiedliche Systeme und Geräte einzuhalten um Endnutzern ein möglichst gleichbleibendes und konsistentes Nutzungserlebnis zu bieten.