Komplexe Deployments mit Drupal

Ein Stichwort das man immer wieder hört wenn es um Drupal geht ist «Community». Das liegt einerseits am zugrundeliegenden Kern, welcher mit Rechte- und Nutzerverwaltung, Tagging sowie Kommentarintegration von Haus aus viel mitbringt, was man für Auftritte mit Community-Fokus benötigt. Es liegt auch an den zahlreichen Modulen der Drupal-Community, welche die jeweiligen interaktiven Individualfunktionen bereitstellen. Spannend wird es nun, wenn neue Funktionen im laufenden Betrieb dazukommen.

Ausgangslage

Drupal pflegt sehr viel seiner Konfiguration in der Datenbank. Dies bedeutet prinzipiell, dass man entweder Dateien und Datenbank bei grösseren Funktionsänderungen komplett ersetzt oder die Datenbank erhält und alle Änderungen im Backend händisch auf der Live-Instanz nachträgt. Das händische Nachtragen ist bei grösseren Änderungen keine realistische Lösung, selbst wenn die Fenster für Downtime gross genug sind, allein schon aufgrund der Fehleranfälligkeit. Bei einer Seite mit viel User Generated Content scheidet das Ersetzen der Datenbank fast immer aus, wenn man nicht SQL-Tabellen per Hand zusammenführen möchte.

Features

Das Modul Features hat sich dabei in unserer Projekterfahrung als unverzichtbar erwiesen, um solche Deployments mit Drupal zu lösen. Ganz allgemein nimmt es Datenstrukturen wie Inhaltstypen, Felder, Menüs aber auch allgemeine Konfigurationen wie Berechtigungen aus der Datenbank und gibt diese in Form eines Moduls aus. Somit sind diese portabel und können durch das Aktivieren des erstellten Moduls deployed werden  (siehe auch Bundling site settings using Features). Die Versionierung hilft zudem dabei Veränderungen des Features einzustufen (z.B. direkte Übersteuerung gegenüber einer Überprüfung). Features zeigt dabei auch den jeweiligen Unterschied der Datenbank zur Codebasis in einem einfach zu bedienenden Frontend, was das Sichten von Abweichungen erleichtert.

Kurzum, es schafft Vertrauen, dass Einstellungen und Datenstrukturen so sind wie definiert, ohne dass man auf jedem System jede Administrationsseite individuell kontrollieren muss. Änderungen werden sofort sichtbar und können entweder durch erneuten Export in den Code integriert werden oder bei einem Anwenderfehler auch problemlos wieder rückgängig gemacht werden.

Es unterstützt aber auch bei der Entwicklung, da es die unabhängige Entwicklung von Funktionen ermöglicht, ohne dass auf dem gleichen Entwicklungssystem gearbeitet werden muss oder eine Datenbank geteilt werden muss. In Verknüpfung mit Gits intelligentem Fast-Forward-Merging lässt sich so ein sauberes und nachvollziehbares Commit- und Merge-Protokoll erreichen, welches funktionalen Code inklusive der benötigten Konfigurationsparameter enthält.

Content?

Wo die Drupalwelt hinter gewissen Enterprise-Systemen weiterhin zurückbleibt ist die Portabilität von Inhalten. Mit den oben beschriebenen Möglichkeiten lässt sich die Struktur von Inhalten ideal transferieren, der jeweilige Inhalt ist aber nicht ohne grössere Umstände von einer Instanz auf die andere gebracht, ohne dass die Datenbank ersetzt wird. Es verbleiben einem hierbei folgende stabile Möglichkeiten (mit denen wir gute Erfahrungen gemacht haben):

  • Export und Import von einzelnen Nodes: Besonders hilfreich bei komplexen Inhalten, wie einem Webform-Formular, das nicht mehrfach erfasst werden soll. Die Ausgabe des Exporters lässt sich wiederum auch in das VCS überführen und sichert somit die Transparenz der aktuellen Fassung.
  • Export und Import von Taxonomien: Der Transfer von Taxonomien mit Hilfe von Taxonomy CSV sollte für die meisten Szenarien ausreichen. Übersetzungen in Verbindung mit Hierarchie können etwas Handarbeit benötigen.
  • Einlesen von strukturieren Inhalten: Mit Feeds lassen sich Quellen wie CVS und XML mit moderaten Aufwand einmalig oder automatisch in Drupal als Inhalte einlesen, welche danach wie andere Inhalte weiterverwendet werden können. Wenn Inhalte in solchen Formaten zur Verfügung gestellt werden können, ist dies eine ideale Alternative zur Beschäftigung eines Content-Migration-Teams.

 

TYPO3 Updates – Versicherung oder überschätztes Sicherheitsbedürfnis?

Ein wenig provozierend der Titel dieses Blogposts – natürlich mit Absicht so gewählt. Die Antwort auf die obige Frage muss lauten: Abwägen!

Pauschal kann man nicht sagen, dass jedes erschienene Update auch zwingend die eigene TYPO3 Website betrifft und eingespielt werden sollte.  Leider ist es in der Praxis häufig so, dass die Kosten und Mühen für ein Update „gespart“ oder verdrängt werden und lieber abgewartet wird. Aber warten auf was?

Das ist dann in etwa so, wie wenn man mit seinem Internetauftritt „Russisch Roulette“ spielt. Gerade bei einer Firmenwebsite ist eine solche Entscheidung aus Sicherheitsüberlegungen nicht zu empfehlen.

Bezieht man sich auf die Sicherheit eines Systems, dann lassen sich Updates in die folgenden priorisierten Kategorien einteilen:

  • Prio 1: Security Issues -> Sicherheitslücken welche entdeckt wurden
  • Prio 2: Bugfixes -> Behebung von Fehlern in der Software
  • Prio 3: Improvements -> Funktionserweiterungen

Dabei kann natürlich ein Update auch Verbesserungen in allen 3 Bereichen beinhalten. Weiterhin gilt es zu unterscheiden, ob ein Update das TYPO3 Basissystem betrifft (den sogenannten CORE) oder sich auf Erweiterungen bezieht.  Genau hier kommt der Effekt zu tragen, dass nicht jedes Security Issue die eigene Website betreffen muss, da ja auch nicht überall dieselben Erweiterungen und Versionen eingesetzt werden.

Wie geht man also am besten als IT-Verantwortlicher mit dem Thema TYPO3-Updates um?

(more…)

Die Organisation eines Contentmigrations-Offices im Rückblick – TEIL I

Seit Anfang April bin ich nun schon bei Namics tätig, wobei ich bereits im letzten Sommer einen ersten Einsatz als Content Migrator bestreiten durfte. Gerne blicke ich deshalb mit einer dreiteiligen Blogpost-Serie auf mein „erstes“ Projekt bei Namics zurück.

Vor etwas mehr als einem Jahr fiel der Startschuss für die Content Migration des Raiffeisen.ch Redesigns. 5 Migratoren, 1 Supervisor und 1 kundenseitige Vertreterin nahmen sich der Herausforderung der ca. 2’500 zu migrierenden Seiten an. Die Organisation des Contentmigrations-Offices sollte dabei nicht unterschätzt werden, weshalb ich im Folgenden einen kurzen Einblick zu den wichtigsten Punkten gebe. Kurz zu den Personen: Verantwortlich auf Seiten Namics waren André Meier als Projektleiter für das Redesign und Lukas Honold als Teilprojektleiter für die Content Migration. Ich engagierte mich, wie bereits erwähnt, als einer der 5 Content Migratoren.

(more…)

Research Online, Purchase Offline: Der RoPo-Effekt

Was mir am Smart Business Day vor zwei Jahren aufgefallen ist, entwickelte sich zu einer „etablierten Grösse“. Illustriert an der folgenden Aussage: Fast 2/3 der Käufer informieren sich Online vor Kontakt mit dem Verkäufer (USA, Quelle: ITSMA).

Die ältere Quelle, die vor zwei Jahren, war eine im Jahr 2008 in Deutschland durchgeführte Erhebung des E-Commerce-Center Handel der Universität Köln. Sie sagte, dass 23,4% der Käufe in stationären Filialen im Online-Shop vorbereitet wurde. Da war die Internet-Durchdringung aber noch vier Jahre jünger!

Quelle: ECC Handel

Aufmerksame Leser merken zudem, dass es in 27,2% der Fälle auch ein Verhalten „Research Offline, Purchase Online“ gibt.

Die Unterstützung des Kanalwechsels innerhalb eines Kaufprozesses ist ein wichtiger Erfolgsfaktor und damit auch eine wichtiger Parameter bei der Erfolgsmessung des Online-Kanals. Je nach Situation ist die Rolle des Online-Shops zur Verkaufsvorbereitung wichtiger als die des Verkaufs selbst. Der Online-Shop dient als Pfadfinder zum gewünschten Produkt / Verkäufer und dient damit auch als Ersatz für Katalog und Werbung.

Unter dem Titel „Influencing Offline, The New Digital Frontier“ publizierte Google im Dezember 2011 eine Studie mit weiteren aktuellen Belegen aus Europa. Drin wir die Online-Recherche vor dem Online-Kauf mit 31% (Niederlanden) bis 48% (Frankreich) bemessen. Fast noch interessanter ist eine darin erwähnte Erhebung von Görtz, dass der durchschnittliche Warenkorb nach einer Online-Recherche mit EUR 701% um 33% grösser ist als ohne.

Quelle: Google

Und hier noch die wichtigsten Gründe, weshalb Käufer dennoch den Weg in das Ladengeschäft machen.

Gemäss der Google-Studie, 2011, Europa, Normalisiert auf 100%:

- Produkt vor dem Kauf anschauen / in die Hand nehmen (54%)
- sofortige Mitnahme gewünscht (16%)
- mangelndes Vertrauen in die Online-Präsentation (11%)
- mangelnde Verfügbarkeit Online (11%)
- vorab zu klärende Fragen zum Produkt (8%)

Gemäss der ECC-Studie, 2008, Deutschland, Doppelnennung möglich:

- Produkt mitnehmen (81%)
- Produkt anfassen / sehen (81%)
- vorab zu klärende Fragen (68%)
- schneller im Laden (67%)
- einfacher im Laden (58%)
- im Laden die Konditionen prüfen (56%)
- persönliche Beratung zum Produkt (54%)

… würde ich doch glatt beim Business Case beim nächsten E-Shop einrechnen ;)

PS: Nicht explizit angesprochen aber eine riesige Herausforderung ist, dass Kunden wegen der Recherchemöglichkeiten über Detailaspekte des nachgefragten Produktes häufig besser informiert als der Verkäufer selbst.

Shopping. Commerce.

augmented_reality_iphone_plantronics

In-store Augmented Reality mit neuer IBM App. Ja, es geht nicht um E-Commerce, Multi- oder Omni-Channel oder sonstwie um Schlagwörter, sondern um Shopping und Commerce, Einkaufen und Verkaufen. Und das Erlebnis dazu. Es wird Zeit ohne Grenzen von On- und … Weiterlesen

Eine Tour durch die Testpyramide

Stellen sie sich vor der Compiler ihrer Programmiersprache würde nicht nur Typfehler, sondern auch einen Großteil der Verhaltensfehler in der Applikation finden können. Welche Auswirkung würde das wohl auf die Qualität ihrer Software haben? Gerade Praktiken der agilen Softwareentwicklung wie die schnelle, häufige Veröffentlichung oder sogar die kontinuierliche Veröffentlichung (Continuous Delivery) sind ohne ein schnelles und umfassendes Feedback über die Softwarequalität nicht denkbar. Automatische Tests können genau dieses Feedback geben – und dennoch werden sie von sehr wenigen Projekten genutzt.

Leider ist die Erstellung von effektiven automatischen Tests eine Fähigkeit, die bei der Ausbildung von Softwareentwicklern oft zu kurz kommt. Viele naive Ansätze der Testautomatisierung, wie etwa mit Tools, die wenig Aufwand durch Aufnahme und Wiedergabe von UI-Interaktionen versprechen, können schnell dazu führen, dass ein Team von dem Vorhaben frustriert ist und den Wert der automatischen Tests in Frage stellt. Das kann etwa dann der Fall sein, wenn kleine Änderungen an dem User Interface dazu führen, dass eine ganze Reihe an Tests fehlschlagen und Entwickler vor der Frage stehen, ob es sich tatsächlich um eine Regression handelt oder um eine falsche Fehlermeldung.

Im Extremfall führt dieser Missstand dazu, dass Änderungen am User Interface nur widerwillig von den Entwicklern vorgenommen werden. Es ist eine paradoxe Situation, da doch gerade durch die Tests auch bei tiefgreifenden Änderungen mehr Sicherheit und damit eine deutlich erhöhte Flexibilität der Software erreicht werden sollte. Die richtige Herangehensweise an Testautomatisierung ist deshalb der Schlüssel für eine frustfreie und wirtschaftliche automatisierung von Testfällen und Grundlage für rapide und häufige Lieferung von Software.

(more…)

Storytelling. Best Practices.

Schon seit längerer Zeit sind insbesondere große Unternehmen daran, ihre digitalen Inhalte und deren strategische Strukturierung aufzuwerten und zu professionalisieren. Häufig wird als kommunikativer Rahmen der Ansatz des „Storytelling“ genutzt, jedoch oft zu kurz gedacht.

Im vierten Teil der Serie besprechen wir einige interessante Beispiele für erzählte Geschichten.

Disclaimer: Der folgende Eindruck soll nicht täuschen- ich finde nicht, dass sich Storytelling auf B2C beschränkt. Die verbesserte neuronale Aufnahme von Informationen durch Geschichten ist ebenfalls prädestiniert für Business-to-Business-Kommunikation (B2B). Es gibt auch einige spannende B2B-Cases. Oft mangelt es diesen jedoch am gesamtumfassenden Konzept, welches in den folgenden Beispielen jeweils besser zur Geltung kommt.

#1: Chipotle Mexican Grill 

Chipotle ist eine US-amerikanische Schnellrestaurantkette, welche Gerichte “live” vor dem Kunden zubereitet. Im Rahmen der “Food with Integrity”- Strategie fokussierte sich das Unternehmen darauf, das Thema Nachhaltigkeit in das Restaurantkonzept zu integrieren. Das folgende, animierte Video erzählt die Geschichte “Back to the roots”.

Elemente, die zum Konzept des Chipotle-Storytelling gehören:

  • Transparenz. Chipotle legt offen, wieviele Tiere geschlachtet werden und wie diese aufgezogen wurden.
  • Service. Die Restaurantkette lässt Kunden erweiterten Service genießen (Vorbestellung per Fax).
  • Verbindlichkeit. Das Markenversprechen gilt: Chipotle serviert aktuell “100% naturally raised beef”.
#2: Renault Electric Life
Renault verdreht die Geschichte der Welt und bebildert im Video eine Gesellschaft, die ausschließlich mit Verbrennungsmotoren funktioniert. Damit parodiert Renault in sehr charmanter Weise andere Automobilhersteller, die am klassischen Motorenkonzept festhalten.


Elemente, die zum Konzept des Renault-Storytelling gehören:

  • Ironie und Witz. Durch die Verdrehung der industriellen Geschichte nimmt sich Renault als Teil der Automobilindustrie nicht zu ernst und andere Hersteller auf die Schippe.
  • Konsistenz. Der neue Renault-Claim “Drive the Change” zeigt, wie ernst Renault das Thema nimmt.
  • Authentizität. Nur als Hersteller von Elektroautos, die real existieren (und nicht erst in 3 Jahren verfügbar sind), kann ein solches Storyboard ernst genommen werden.

#3: Hancook

Hancook zeigt seine Interpretation zum Thema “Nachhaltigkeit” im Video, welches den Produktentwicklungsprozess eines Reifens mit geringem ökologischen Fußabdruck veranschaulicht. Spannend ist, dass es sich hier um ein “low emotion”-Produkt (nämlich einen Autoreifen) handelt, welches aber durch die gute und schön umgesetzte Story ins rechte Licht gerückt wird.

HANKOOK TIRE – ECO DRIVING PROMOTION MOVIE from AlfredImageWorks on Vimeo.

Elemente, die zum Konzept des Hancook-Storytelling gehören:

  • Hochwertigkeit und Qualität. Die Umsetzung des Spots ist äußerst gelungen- hier wurden keine Kosten und Mühen gescheut.
  • Einfachheit. Hancook erklärt in einfachen Sequenzen die Herstellung eines komplexen Produkts und integriert die Markenbotschaft nahtlos.

Alle genannten Elemente tragen Ihren Teil zum Erfolg von guten Stories bei. Durch die multiple Kanalrezeption moderner Kunden sind jedoch zwei Elemente guter Markenstories besonders hervorzuheben. Es handelt sich um

  1. Konsistenz und
  2. Authentizität.

Ohne reale Fundierung von Markenbotschaften und – versprechen kann kein Storytelling-Ansatz funktionieren- Menschen rezipieren schnell negativ, was beispielsweise bei der GEMA in Deutschland gut erkennbar wird. Ein Ansatz kann jedoch auch noch so vielversprechend, glaubwürdig und authentisch erscheinen, sofern dieser jedoch nicht über alle Customer Touchpoints durchgezogen wird, wird der Ansatz nicht funktionieren.

Content Marketing konkret – Beispiel Buch und Netz

Auf diesem Blog schon viel berichtet, einer der Top 10 Trends in diesem Jahr oder wie es Seth Godin prägnant sagt: „Content Marketing is the Only Marketing Left“.

Einer der Möglichkeiten ist es, selbst tolle Inhalte anzubieten. Aus der eigenen „Feder“ oder bei Söldnern bestellt (aka Content-Agenturen oder gleich bei Namics ;).

Eine spannende weitere Möglichkeit zeigt uns Andreas Von Guntens Verlag „buch & netz“ erstmals mit ihrem Kunden Digicomp Academy AG.

(hier der Link zum Post)

buch & netz verlegt Bücher nach einem modernen, unserem Medienverhalten angepassten Modell. Ein Teil davon ist es, Unternehmen und Organisationen ein Buch- oder Kapitelsponsoring anzubieten. So geschieht es grad mit dem Buch «E-COMMERCE KONKRET» dank dem Sponsor Digicomp Academy AG. Digital gratis während zwei Tagen.

Tolles Buch, guter thematischer Zusammenhang und ein nettes Angebot für uns Leser (sofern ich meine Daten angeben will). Ich finds eine grossartige Idee. Danke!

Flexible iOS-Views

Aus Sicht eines App-Entwicklers ist die vergleichbare geringe Anzahl von Displaygrössen eine der grössten Stärken der iOS-Plattform. Es gibt nur zwei Formfaktoren (iPhone und iPad) mit jeweils einfacher und doppelter Pixeldichte. Für Entwickler ist diese reduzierte Anzahl an Displaygrössen von Vorteil, da der Design- und Testaufwand gegenüber anderen Plattformen überschaubar bleibt.

Warum flexible Views?

Trotz der geringen Anzahl an Displayausprägungen sollten iOS-Entwickler nicht in die Versuchung kommen, sämtliche Positions -und Grössenangaben in den Views hartzucodieren. Insbesondere mit der Plattform unerfahrenere Programmierer neigen gerne dazu. Spätestens dann, wenn sich die Anordnung von einzelnen View-Fragmenten bei der Rotation des Geräts ändern soll, wird es mit hartcodierter Positionierung haarig. Und wer weiß – eventuell etabliert Apple mit dem iPhone 5 eine neue Displaygrösse, die im Seitenverhältnis von den bisherigen Modellen abweicht. Eine sorgsame Umsetzung der View-Struktur ist also unerlässlich, um die App auch langfristig an neue Anforderungen oder Geräte anpassen zu können.

Wie lösen Android und BlackBerry-SDK das Problem?

Blicken wir zunächst kurz über den Tellerrand und betrachten, wie das BlackBerry- und Android-SDK das Problem lösen: Beide bieten sog. LayoutManager an, um flexible Views zu realisieren. Aber was genau macht ein LayoutManager? Grob gesagt ist er ein Container, der mehrere Views zusammenfasst und positioniert. Er kann gleichzeitig auch die Grösse seiner Subviews festlegen, sie aber vorher nach der präferierten Grösse fragen. Erst nach Abschluss dieser Layoutphase wird das Zeichnen eingeleitet.

Das BlackBerry-SDK stellt für LayoutManager die abstrakten Manager-Klasse zur Verfügung. Es gibt zwar einige konkrete Implementierungen im SDK, allerdings habe ich in meinen letzten BlackBerry-Projekten die Erfahrung gemacht, dass diese den seltesten Fällen ausreichen. Man muss also sehr häufig eigene Manager schreiben. In der Android-Welt leitet man dagegen von der ViewGroup-Klasse ab, sofern die Standardimplementierungen wie GridLayout nicht ausreichen.

Was bietet iOS?

Kommen wir nun zum iOS-SDK. Hier gibt es keine dedizierte LayoutManager-Klasse. Eine Trennung zwischen Container und View findet somit nicht auf Klassenebene statt. Stattdessen ist jede View gleichzeitig ein Container. Die für Views verantwortliche Klasse UIView bietet mit “layoutSubviews” und “sizeThatFits:” Methoden an, um einen vollwertigen LayoutManager zu realisieren. Bevor eine View gezeichnet wird, ruft das Framework layoutSubviews auf. Sobald sich die Größe der View (z.B. durch Rotation des Geräts) ändert, wird erneut layoutSubviews aufgerufen, damit die Subviews sich an die neue Grösse anpassen können. Für ganz einfache flexible Positionierungen muss man jedoch nicht immer layoutSubviews implementieren. Stattdessen kann man die aus dem InterfaceBuilder bekannten AutoSizing-Flags nutzen (auch bekannt als “struts & springs”), mit denen man die Abstände zum Rand der View fixieren kann. Aber sobald ein sog. Reflow-Verhalten gefordert ist oder die Views sich abhängig von der Orientation des Geräts neu positionieren müssen, führt kein Weg an einer layoutSubviews-Implementierung vorbei.

Beispiel

Das nachfolgende Beispiel soll das Zusammenspiel von layoutSubviews und sizeThatFits: demonstrieren: Auf einem Screen soll sowohl eine Toolbar (ToolbarView) als auch ein Inhaltsbereich (BodyView) platziert werden. Die Höhe der Toolbar soll dabei immer 20% der Bildschirmhöhe einnehmen und oberhalb der BodyView liegen. Die BodyView soll die verbleibende Bildschirmfläche nach unten ausnutzen.

View im Landscape-Modus: 20% für den Header ergeben 150 Punkte.

View im Portrait-Modus: 20% für den Header ergeben 201 Punkte.

 

Damit das funktioniert, erstellen wir eine RootView, die die ToolbarView und BodyView als Subviews enthält. Diese RootView implementiert layoutSubviews folgendermassen:

- (void) layoutSubviews {
  // Frage die Toolbar, welche Grösse sie
  // von der Gesamtfläche einnehmen möchte.
  CGSize toolbarSize = [self.toolbarView sizeThatFits:self.bounds.size];
  CGRect toolbarFrame =
    CGRectMake(0,0, toolbarSize.width, toolbarSize.height);
  [self.toolbarView setFrame:toolbarFrame];

  // Die BodyView bekommt die restliche Fläche.
  CGFloat bodyWidth = self.bounds.size.width;
  CGFloat bodyHeight = self.bounds.size.height - toolbarSize.height;
  CGRect bodyFrame =
    CGRectMake(0, toolbarFrame.size.height, bodyWidth, bodyHeight);
  [self.bodyView setFrame:bodyFrame];
}

 

Betrachten wir nun die Implementierung der sizeThatFits: Methode der ToolbarView:

- (CGSize) sizeThatFits:(CGSize) size {
  CGFloat myWidth = size.width;
  CGFloat myHeight = size.height * 0.2;
  return CGSizeMake(myWidth, myHeight);
}

 

Fazit

Alle Plattformen nutzen das LayoutManager-Prinzip für die Umsetzung von flexiblen Views. Das iOS-SDK bietet zwar keine dedizierte Klasse dafür, aber ermöglicht mit dem Zusammenspiel von layoutSubviews und sizeThatFits: dennoch die einfache Umsetzung von eigenen LayoutManagern.

Veröffentlicht unter Mobile

Wenn Storytelling versagt. Der Problemfall Saturn.

Storytelling, Teil III

Schon seit längerer Zeit sind insbesondere große Unternehmen daran, ihre digitalen Inhalte und deren strategische Strukturierung aufzuwerten und zu professionalisieren. Häufig wird als kommunikativer Rahmen der Ansatz des „Storytelling“ genutzt, jedoch oft zu kurz gedacht.

Im dritten Teil der Serie geht es darum, Schwachstellen von Stories zu erkennen- am Beispiel der Elektronik-Fachmarktkette Saturn.

Um im vorab besprochenen Beispiel zu bleiben: Saturn hat keine ausdefinierte Markenstory, versucht aber über sehr scharfe Informationsspitzen (abgefeuert durch Claims) Nuancen von leicht dechiffrierbaren Geschichten zu erzählen.

Der aktuelle Claim „Soo! muss Technik“ ist Nachfolger vom weit bekannteren und zur damaligen Zeit stark kritisierten „Geiz ist geil“. „Soo! muss Technik“ ist als Informationsspitze lanciert, um indifferenten Kunden zu suggerieren: bei Saturn bist Du immer richtig, sofern Du Dich für Technik begeistern kannst. Saturn tut alles dafür, um Technik ins rechte Licht zu rücken.

Im Wochenmagazin „DIE ZEIT“ wurde von einer „Nullaussage“ und einem „Luftloch der Kommunikation“ gesprochen, was etwas übertrieben ist, aber inhaltlich auch nicht komplett falsch.

Indirekt betont der Claim die Wertschätzung des Retailmarktes gegenüber digitalen Kanälen, da die lokalen Möglichkeiten, Technik zu präsentieren, aus Saturn-Sicht besser geeignet sind, Kunden zu überzeugen. Auch online wären Showrooms etc. möglich, werden jedoch nicht ausreichend bespielt- der beratende Effekt des Servicemitarbeiters fehlt und wird digital nicht ersetzt. Ab hier bricht der Ansatz der Markenstory („immer und überall richtig“), u.a. weswegen der digitale Abverkauf bei der Kette auch so stottert.

Am Beispiel sieht man, wie schwer es ist, eine gute Story zu lancieren und wie wenig Sinn es macht, Storytelling an Werbebotschaften auszurichten (statt umgekehrt). Saturn stand beim Wechsel des Claims  vor der schwierigen Situation, „Geiz ist geil“ abzulösen.

Aus meiner Sicht entstand jedoch die Notwendigkeit weniger aus dem offenbar zu beobachtenden Kaufverhalten („Qualität vor Quantität“), sondern aus dem Schmerz heraus, die dahinterliegende Story nicht mehr authentisch erzählen zu können. Zu häufig waren Personen mit mobilen Endgeräten im Laden, die die Preise im Lokal mit Online-Shops verglichen und dabei die geringe (preisliche) Wettbewerbsfähigkeit festgestellt haben- ein No-go, wenn man sich als Marke den besonders Geizigen verspricht.

Der folgende vierte Teil der Storytelling-Serie widmet sich erfolgreichen Beispielen von Storytelling-Ansätzen.

Page 30 of 200« First...1020...2829303132...405060...Last »