Entwicklung Archives » Seite 6 von 7

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.

20. September 2012

FormBuilder – eine comspace-Erweiterung für die Open Text Web Solutions

Ab und zu wollen unsere Entwickler ihr Arbeitsleben im täglichen Umgang mit den verschiedenen CMS-Systemen erleichtern und erarbeiten immer mal wieder sinnvolle Erweiterungen, die nicht nur für uns, sondern auch für unsere Kunden interessant sind.

Eine dieser Entwicklungen ist der sog. FormBuilder für das Content Management System Open Text. Er ermöglicht es Redakteuren, auch ohne Programmierkenntnisse, schnell und einfach Formulare zu erstellen.

Welche technischen Voraussetzungen müssen dafür gegeben sein?

Ein OpenText Websolutions Delivery Server, ein SMTP Server für den Mailversand und eine Hibernate kompatible Datenbank sind die nötigen technischen Anforderungen für den FormBuilder.

Wie funktioniert der FormBuilder?

Um ein Formular auf einer Website zu integrieren, muss zunächst die FormBuilder-Rahmenseite erstellt werden. Danach können im SmartEdit Modus die verschiedenen Felder angelegt und über die Formularansicht oder die roten OpenText Bearbeitungspunkte, sofern diese vorher angelegt wurden, gepflegt werden. Außerdem können verschiedene Elemente wie bspw. E-Mail-Empfänger, E-Mail-Sender, E-Mail-Betreff etc. bearbeitet werden.

Für die Gestaltung des Formulars gibt es viele Möglichkeiten. Der Redakteur kann folgende Elementtypen verwenden und selber anordnen:

Checkboxen
Inputfelder einfach oder doppelt
Radiobuttons
Selectboxen
Textareas
Dateiupload
Eingabenvalidierung

Zusätzlich kann optional das Einbinden eines Google ReCaptcha zur Erhöhung der Sicherheit bei der Datenübertragung und eine Eingabevalidierung für bestimmte Felder, z.B. für E-Mail-Adresse oder Geburtsdatum, ausgewählt werden.

Der Redakteur kann entscheiden, ob nach Ausfüllen und Abschicken des Formulars eine Mail, ein Datenbankeintrag oder beides generiert wird. In jedem Fall ist der OpenText Delivery Server für die Generierung der Ausgabeinformation zuständig.

Der FormBuilder ist modular erweiterbar und kann so spezifischen Kundenanforderungen jederzeit angepasst werden.

13. Juli 2012

Unterschied zwischen HTTP und HTTPS

Das Hypertext Transfer Protocol (HTTP, Hypertext-Übertragungsprotokoll) wird benutzt, um Webseiten aus dem World Wide Web in einen Webbrowser zu laden.

Das Protokoll HTTPS gewährleistet die Sicherheit auf einer Internetseite. HTTPS steht für HyperText Transfer Protocol Secure (sicheres Hypertext-Übertragungsprotokoll) und dient zur Verschlüsselung und zur Authentifizierung der Kommunikation zwischen Webserver und dem Browser.

Dieses Protokoll stellt das einzige Verschlüsselungsverfahren dar, das ohne gesonderte Softwareinstallation auf allen Internet-fähigen Computern unterstützt wird.

Die Daten im Web wären ohne Verschlüsselung für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Internetseiten benutzen dieses Protokoll, um zu verhindern, dass Dritte die Informationen manipulieren können, die zwischen der Internetseite und dem Benutzer ausgetauscht werden.

Einsatz von HTTPS

HTTPS wird oft auf Internetseiten benutzt, wo mit sensiblen Daten wie zum Beispiel Bankverbindungen in Online Shops gearbeitet wird.

	Das grüne Vorhangschlosssymbol sowie das grüne HTTPS und die ausführlichen Informationen zeigen dem Benutzer schnell, ob die Seite sicher oder unsicher ist.
	Falls man sich auf einer Internetseite mit HTTPS Verschlüsselung befindet und kein grünes Vorhangschlosssymbol, sondern ein rotes durchgestrichenes HTTPS in der Browser Adresszeile erscheint, dann ist der Browser davon überzeugt, dass diese Internetseite trotzdem unsicher ist.

Fazit

Wenn eine Internetseite sensible Daten von Ihnen verlangt, zum Beispiel die Bankverbindung in Onlineshops, dann schauen Sie unbedingt in die Adresszeile, ob die Internetseite mit HTTPS läuft und das grüne Vorhangschlosssymbol vorhanden ist.

22. Juni 2012

Facebook direkt aus dem CMS mit Inhalten versorgen

Kürzlich haben wir ja bereits auf das Onlinemagazin Kuchenkult.de unseres Kunden Coppenrath & Wiese hingewiesen. Dabei erwähnten wir auch die Facebook-Community der Conditorei Coppenrath & Wiese.

Je mehr Social Media Kanäle zu befüllen sind, desto mehr Arbeitsschritte müssen gemacht werden. Schlimmstenfalls ist der Redakteur, der Inhalte in die verschiedenen Unternehmenskanäle einstellt sogar gezwungen, von einem Werkzeug ins andere zu wechseln.

Um diesen Mehraufwand zu vermeiden, haben wir ein Tool für Coppenrath & Wiese entwickelt, mit dem der Mitarbeiter Inhalte direkt aus dem Content Management System Open Text heraus auf Facebook veröffentlichen kann.

Technisch haben wir diese Aufgabe so gelöst:

Der Redakteur findet in seiner gewohnten Pflegeumgebung einen speziellen Bereich, in dem er jede der Facebookseiten auswählen kann. Dort können die gewünschten Inhalte wie in den anderen Teilen des Internetauftritts auch mit speziell optimierten Inhaltsmodulen gepflegt werden – oder auch bereits vorhandene Inhalte referenziert werden. Es werden also die selben Redaktionsworkflows und Arbeitsschritte wie für die Pflege der herkömmlichen Seiten genutzt. Diese Seiten werden in einen speziellen Bereich des Webservers publiziert, wo die Daten aufbereitet und dem Zugriff über Facebook zur Verfügung gestellt werden. Für jede der Seiten wurde eine kleine Facebook-App geschrieben, die automatisch diese aufbereiteten Inhalte auf den Facebookseiten anzeigt, nachdem sie publiziert wurden.