mobile melting

iOS + Android App Entwicklung in Berlin | MaibornWolff GmbH

By

Jüdisches Leben in Berlin? Eine Spurensuche per App!

Jüdisches Leben in Berlin per App entdecken: Das ermöglicht die neuste Stadt-Tour von Storytude.

104

Anne Frank ist nicht nur ein jüdisches Mädchen, das vor den Nazis versteckt wurde und ein bewegendes Tagebuch darüber geschrieben hat, bis sie schließlich von den Nazis entdeckt und ermordet wurde. Anne Frank ist ein Symbol, ein Symbol für den Holocaust, so behauptet ihr Cousin Buddy Elias, der auf der neuen Storytude-Tour durch die Spandauer Vorstadt in Berlin Mitte zu Wort kommt.

Es gibt viele Spuren jüdischen Lebens in Berlin:

Die neue Audiotour, die zusammen mit dem Anne-Frank-Zentrum entstanden ist, hilft Ihnen dabei, sie zu entdecken. Da ist zum Beispiel die Blindenwerkstatt von Otto Weidt, der viele Juden vor dem Vernichtungslager retten konnte, der jüdische Friedhof, das Denkmal „Der verlassene Raum“, das an die Reichspogromnacht erinnert und die jüdische Mädchenschule. Natürlich führt die Route auch zur Synagoge und in die Rosenstraße, der ein ganzer Spielfilm gewidmet ist. Über 20 Stationen erzählen von jüdischen Schicksalen, es wird aber auch gezeigt, wo jüdische Kultur heute noch lebendig ist. Zeitzeugenberichte und Originalaufnahmen machen den Rundgang, der durch den Hackeschen Markt und die umliegenden Straßen in Berlin Mitte führt, zu einem anschaulichen Erlebnis. Unbedingt anhören!

So gehts: App laden, öffnen und unter „Berlin“ die Tour aufrufen. Bald auch für Android-Smartphones! Besucher des Anne-Frank-Zentrums am Hackeschen Markt erhalten die Tour sogar kostenfrei.

By

Android Apps auf dem Vormarsch

Android Robot*

Android Robot*

Dieser Herbst ist anders – zum ersten Mal in der Geschichte der Agentur arbeiten wir ausschließlich an Android-Projekten. Bisher dominierten Anfragen nach iPhone-Apps unsere Kundenprojekte, doch dies hat sich über den Sommer drastisch geändert.

Unsere Auftragslage folgt somit dem globalen Trend: Handys mit dem Betriebssystem Android sind längst Marktführer unter den Smartphones.

Die Frage unserer Kunden, ob es sinnvoller ist, zuerst eine iPhone- oder eine Android-App zu entwickeln, war bisher immer leicht zu beantworten. Prototypen wurden auf iOS gebaut, das war einfacher, Prestige-trächtiger und überhaupt waren iPhone-Nutzer die interessantere Zielgruppe. Mengenmäßig, aber auch finanziell. So einfach ist das nun nicht mehr – es kommt jetzt tatsächlich „ganz drauf an“.

Wann sich iOS lohnt

Unserer Erfahrung nach lohnt es sich nach wie vor oft, mit dem iPhone bzw. iPad zu starten. Und zwar wenn:

  • Es keinen Grund für Android gibt. Android-Entwicklung ist noch immer einen Tick aufwendiger und teurer, z.B. wegen der Fragmentierung der Gerätelandschaft.
  • Wenn Sie sich an eine hochwertige Nutzerschaft richten, die über dem Mainstream liegt.
  • Es ein besonders individuelles Interface sein soll – auch hier gibt es mehr Aufwände bei der Android-Entwicklung.
  • Wenn es um Endkunden-Apps geht, in denen etwas verkauft werden soll, z.B. ein Shop-Ableger.
  • Wenn es vertriebsrelevante Apps sind. Die Mehrheit der Vertriebsteams scheint auf iOS unterwegs zu sein.

 

Wann Android Sinn macht

Auch für Android gibt es gute Gründe:

  • Wenn Ihre Zielgruppe jung und mainstreamig ist.
  • Wenn Marktforschung ergeben hat, dass Ihre Kunden mehrheitlich Android nutzen.
  • Wenn Ihre App viele Nutzer erreichen soll und dabei kostenfrei ist.
  • Wenn es Sie damit leben können, dass das App-Interface nicht auf jedem der 1.000 Gerätetypen perfekt aussieht.
  • Wenn Sie noch die Chance haben, in Ihrer Firma auf die Hardware-Auswahl Einfluss zu nehmen. Hier können Sie mit der Entscheidung für Android viel Geld sparen. Vergleichen Sie z.B. die Preise eines iPads und eines Samsung Galaxy Tabs.

Auch ein relevanter Aspekt: Der Rollout und auch das Tester-Management sind auf Android deutlich einfacher und schneller. Fraglich nur, ob man diese Zeitvorteile nicht beim Debugging und Testing wieder verliert, da deutlich mehr Gerätetypen zu beachten sind.

 

Fazit: iOS ist einfacher, Android braucht einen Grund.

Hat Ihr Projekt keine der oben genannten speziellen Faktoren, dann gilt als Entscheidungshilfe: Gibt es keinen Grund FÜR Android, starte mit einer iOS-App!

Meinungen, Kommentare, Fragen zum Thema Android Apps? Gerne an lydia at mobile-melting.de oder als Kommentar.

 

* The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

By

App-Update für Storytude

Schickes neues Design, schlankere Navigation und eine neue Tour: Das Update unserer eigenen App „Storytude“ auf iOS hat uns wirklich vorangebracht. Wir haben das Produkt von Altlasten entschlackt, was ja nicht immer einfach ist:

Von der alten „Tab-Bar-Navi“ haben wir auf einen Homescreen umgestellt, der nur situativ die Code-Eingabe und den Punkt „Meine Touren“ anzeigt. Auch die Auswahl einer Tour haben wir neu konzipiert: Statt zunehmend langer Liste gibt’s nun erst die Stadtauswahl und danach gleich die Tour-Cover mit allen Grundinformationen zu sehen. Es kam aber auch etwas Neues hinzu: Zu jeder Tour gibt es nun Highlights in Text und Bild, um euch richtig Lust auf eine Tour zu machen! Auch das Backend wurde umkonzipiert und auf Amazon Webservices umgestellt und die Webseite überarbeitet.

Im gleichen Rutsch habe ich mir noch einmal genau angesehen, wie die Suchfunktion im AppStore aktuell agiert. Ich kann jedem nur empfehlen, dort testweise verschiedene Suchen auszuführen. Nur so lässt sich wirklich verstehen, was da passiert. In aller Kürze: Die Suche ist mit den bekannten Websuchmaschinen und ihren Algorithmen nicht zu vergleichen. Es werden nur Titel und Keywords der AppStore-Texte durchsucht, sodass beide maximal und klug auszunutzen sind. Die Keywordsuche ist exakt, d.h. „Berlin Tour“ deckt nicht „Berlin Touren“ ab, auch nicht „Berlin“. Da nur 100 Zeichen zur Verfügung stehen, ist eine Optimierung für mehrere Städte, wie Storytude es ja braucht, ziemlich schwierig.

Ich bin gespannt, wie wir uns nun im Ranking und in den Downloads schlagen. Bericht folgt!

https://itunes.apple.com/de/app/storytude-horen-erleben/id418306327?mt=8

bg_storytude_klein

By

Mobile Cross Plattform Entwicklung – Plattformen im Test

In den letzten Jahren drängten zunehmend neue und verbesserte Mobilplattformen auf den Markt und machen Apple seine Anteile streitig. Derzeit sieht es in etwa so aus: Android (73.6%), iOS (16.9%), Windows Phone (6.1%) und Blackberry (0.5%). Für die App Entwicklung heißt das, dass Apps für unterschiedliche Plattformen erstellt werden müssen. Somit steigen Aufwand und Kosten für eine App, denn der Quellcode muss jeweils komplett neu geschrieben werden.

Um die Kosten zu senken und die Entwicklungszeit zu verkürzen, gibt es viele Lösungsansätze im Bereich Mobile Cross Plattformen mit dem Ziel, eine App plattformübergreifend nur einmal (!) zu entwickeln. Die Ansätze können grob in Web basierte und native Cross Plattformen unterteilt werden.

Web basierte Cross Plattformen

Web basierte Cross Plattformen machen sich die Eigenschaft zunutze, das alle Smartphones Webtechnologien nutzen. Mittels HTML5, CSS und Javascript kann eine sogenannte Web App schnell und einfach für alle Mobilplattformen umgesetzt werden.

Auf dem ersten Blick scheint dieser Lösungsansatz sehr zufriedenstellend zu sein. Er birgt aber auch große Nachteile. Web Apps bedeuten immer Kompromisse im UI Bereich, die Offlinefähigkeit ist eingeschränkt wie auch der Zugriff auf Gerätefunktionen. Die Performance ist gering bis mittel, eben nicht zu vergleichen mit „echten“, d.h. nativen Apps.

Web basierte Cross Plattform Tools sind beispielsweise Appcelerator Titanium, AppFurnace, IUI, AMPchroma und PhoneGap.

Native Cross Plattformen

Native Cross Plattformen kapseln den Zugriff auf die Mobilplattformen für den Entwickler. Es gibt einen abstrakten Layer, welcher die plattformspezifischen Aufrufe übernimmt. Dadurch kann ein Feature oberhalb des Layers einmal entwickelt werden und trotzdem auf mehreren Mobilplattformen laufen. Unterhalb des Layers wird plattformspezifischer Code verwendet.

Dieser Lösungsansatz versucht die Nachteile des Web basierten Ansatzes zu verhindern, indem er „echten“, d.h. nativen Zugriff auf die Mobilplattformen gewährleistet. Die Apps können durchaus komplexer sein, da man hardwarenäher und auch performanter entwickeln kann.

In letzter Zeit haben wir vier native Cross Plattformen untersucht, die wir hier vorstellen werden:

Codename One

Xamarin

Corona

Marmalade

Cross Plattform: Codename One

Codename One ist eine Java basierte Plattform, welche erst 2012 auf den Markt kam. Codename One unterstützt iOS, Android, Windows Phone 8 und Blackberry. Als Entwicklungsumgebung eignen sich Eclipse und Netbeans mit speziellen Plugins, die einen UI Designer und einen Simulator enthalten.

Codename One bietet gute UI Toolkits basierend auf Java Swing, welche aber plattformspezifisch sind. Zum Beispiel die iOS Tabbar und Android Tabbar sind den Mobilplattform Styles nachgebildet.

Um die App auf Geräten laufen lassen zu können, wird der Sourcecode zum Codename One Buildserver geschickt und dort für die entsprechende Mobilplattform kompiliert. Am Ende kann man die erstellten, binären Installationspakete bequem per QR-Code scannen und herunterladen bzw. installieren. Debuggen auf einem Gerät ist aber nicht möglich.

Für die Nutzung des Buildservers und technische Unterstützung benötigt man eine Lizenz. Eine Codename One PRO Lizenz kostet $79 monatlich.

Cross Plattform: Xamarin

Xamarin ist eine C# basierte Plattform. Man benötigt das Xamarin Studio unter MAC OS oder Visual Studio unter Windows. Zusätzlich müssen Android SDK und iOS SDK installiert werden, um den Sourcecode kompilieren und die Emulatoren nutzen zu können. Xamarin unterstützt Android und iOS auf Windows und MAC.

Im Bereich UI verwendet Xamarin jeweils die nativen SDKs. Das bedeutet, dass die UI je Plattform geschrieben werden muss und damit echt nativ ist. Der UI unabhängige Sourcecode (Datenhaltung und Logik) wird aber gemeinsam von allen Mobilplattformen genutzt.

Da Xamarin native SDKs und Emulatoren verwendet, gibt es nur wenige Überraschungen bei Tests mit Emulatoren gegenüber Tests auf Geräten. Als Ergänzung bietet Xamarin eine TestCloud, um die Apps remote auf unterschiedlichen Geräten testen zu können.

Eine Xamarin Business Lizenz kostet $999 pro Jahr.

Cross Plattform: Corona

Corona ist eine LUA Skript basierte Plattform. Es gibt keine umfangreiche IDE, aber einen Editor und Emulator. Corona unterstützt iOS und Android.

Corona bietet einige UI Komponenten, wie Tabbar und Tabellen. Diese UI Komponenten sind plattformunabhängig. Es ist möglich, direkt im Skript native Funktionen aufzurufen.

Um die App auf Geräten laufen lassen zu können, wird der Sourcecode zum Corona Buildserver geschickt und dort für die entsprechende Mobilplattform kompiliert. Debuggen ist generell nicht möglich, weder auf dem Emulator noch auf den Geräten.

Eine Corona PRO Lizenz kostet $50 pro Monat und eine Enterprise Lizenz kostet $85 pro Monat.

Cross Plattform: Marmalade

Marmalade ist eine C/C++ basierte Plattform. Sie nutzt zudem auch HTML5 und Lua Skript. Marmalade unterstützt iOS, Android, Blackberry undWindows Phone 8. Die IDE ist unter MAC OS in Xcode integriert, dadurch kann der native Emulator verwendet werden.

Marmalade bietet nur einfache UI Komponenten, wie Label und Button, aber komplexeren Komponenten wie Tabellen, Navigationsbars oder Tabbars.

Eine Marmalade Indie Lizenz kostet $499 pro Jahr und eine Plus Lizenz kostet $1499 pro Jahr.

Vergleich der vier Cross Plattformen

  1. Codename One
  2. Xamarin
  3. Corona
  4. Marmalade

Pros:

  • one code, run everywhere
  • good debug/test
  • Java
  • very good IDE
  • iPhone/iPad
  • native UI
  • 3rd Party library possible (C#)
  • use native simulators
  • TestCloud
  • one code, run everywhere
  • Corona Enterprise: call any Objective-C or Java library from within Corona
  • Offline build
  • html5hybridApp
  • very good performance
  • gaming
  • iOS on Windows possible

Cons:

  • not the real native UI feeling
  •  build on server only
  • no 3rd party library
  • different UI view between simulator and device
  • View&Controller is platform dependent (separated coding required)
  • Lua script not yet popular
  • UI not really good
  • Revenue limit
  • license cost high – not good as native UI

Projektbeispiel „Trashbusters“

Wir haben anhand des Beispielprojekts „Trashbusters“ eine native Cross Plattform getestet. „Trashbusters“ ist eine ortsbasierte App für iOS und Android, in der man Müll-Hotspots in einer Stadt melden kann. Die Hauptanforderungen waren:

Kamerazugriff, um ein Bild des Müllhaufens aufzunehmen. Das Bild kann eventuell auch aus der Gallery ausgewählt werden.

GPS Nutzung, um den Standort des Müllhotspots festzuhalten.

Netzwerkzugriff, um alle Informationen zu einem Server übertragen und sammeln zu können.

Die eingetragenen Müllhotspots mit Bild und Ort auf einer Karte darstellen.

Da die App eine Tabellenansicht, eine Tabbar und eine Navigationsbar haben sollte, erschienen Corona und Marmalade nicht passend für das Projekt. Unter Xamarin muss der Bereich UI je Plattform entwickelt werden, so dass der Aufwand steigt. Wir haben uns also für Codename One entschieden.

Fazit

Das große Ziel der mobilen Cross Plattform Entwicklung ist es eine App gleichzeitig für verschiedene Mobilplattformen erstellen und so Apps schnell und kostengünstig auf den Markt bringen zu können. Der Entwickler muss nicht alle nativen Sprachen bzw. Mobilplattformen kennen und beherrschen, um diese Aufgabe zu erfüllen. Das Konzept lautet „one code, run everywhere“. Es wird einmal entwickelt und läuft auf allen Geräten. Das Konzept ist sinnvoll und zukunftsweisend, aber die Cross Plattformen können zur Zeit noch nicht die nativen SDKs ersetzen.

Die nativen Cross Plattformen (Ausnahme Xamarin) haben eigene, nachgebildete UI Komponenten, die zwar ähnlich den nativen Komponenten aussehen, sich aber trotzdem unterschiedlich verhalten können. Die Zeit des Testens auf verschiedenen Geräten wird nicht gespart, sondern im Gegenteil eher erschwert. In unserem Beispielprojekt kam es zu großen Unterschieden zwischen Tests mit dem Emulator und Tests auf Geräten.

Manche native Cross Plattformen bieten keine Debug Möglichkeit. Dadurch dauert die Fehlersuche beim Testen und Bugfixing länger gegenüber nativer Entwicklung. Wenn eine Cross Plattform ein natives SDK Feature nicht unterstützt, muss die fehlende Funktion selbst geschrieben oder das Projekt sogar eingeschränkt bis verworfen werden. Bestenfalls kennt man vor dem Einsatz einer Cross Plattform alle unterstützten und auch nicht unterstützten Features.

Ein weiterer großer Zeitfresser ist das Kompilieren des Sourcecodes auf einem Buildserver. Es dauert zwischen einigen Sekunden bis mehreren Minuten. Ein Buildserver birgt zudem die Gefahr, dass der eigene Sourcecode nicht geheim und im eigenen Haus bleibt. Man verliert die Hoheit über den Sourcecode und den Kompilierprozess. Man kann nicht sicherstellen, dass das erstellte App Paket keinen fremden, unsicheren Code enthält. Für viele App Projekte ist so eine Cross Plattform also völlig ungeeignet.

Ob eine native Cross Plattform eingesetzt werden kann oder nicht, hängt von vielen Faktoren ab. Unsere Erfahrung aus dem Beispielprojekt zeigt, dass die native Cross Plattform Entwicklung keinen Zeitgewinn gegenüber der nativen Entwicklung für zwei Plattformen darstellt. Im Bereich UI sehen wir die größten Schwierigkeiten zufriedenstellende Ergebnisse zu erhalten.

 

Wollt ihr mehr wissen, wendet euch an Jeanette oder Pai aus unserem Entwickler-Team unter development@mobile-melting.de.

By

Endlich: Berliner Geschichtswerkstatt mit neuer App über Zwangsarbeit

Foto

In Zusammenarbeit mit der Berliner Geschichtswerkstatt hat mobile melting kürzlich eine App entwickelt, die an das Leben von Zwangsarbeitern im nationalsozialistischen Berlin erinnert. Rund eine halbe Million Zwangsarbeiter mußten zwischen 1939 und 1945 in Berliner Fabriken, Dienststellen und Haushalten schuften. Untergebracht waren sie in etwa 3000 Lagern. Zeitzeugen leiten in fünf Touren multimedial durch die Stadt und berichten von Lagern und Fabriken, Hunger und Gewalt, Opfern und Tätern. Zu Fuß, mit dem Fahrrad oder mit der S-Bahn werden die Nutzer anhand von Karten, Bildern und Dokumenten an die Orte geführt, wo junge Menschen unter unwürdigen Bedingungen schwerste Arbeit verrichten mussten. Besucht werden die Fabriken des AEG-Konzerns, Bahnhöfe der Reichsbahn und viele Betriebe der Zwangsarbeit zwischen Flughafen und Bahnhof Zoo. Aber nicht nur die Opfer kommen zu Wort, auch die Täter, die in den Ministerien die Arbeitseinsätze organisierten, werden beleuchtet. Welche Arbeit sie verrichteten und wie sie dabei behandelt wurden – darüber berichten Sinaida, François, František und viele andere. Ab sofort steht die App auf Deutsch und Englisch für iPhones zur Verfügung. Unbedingt anhören!

By

Was kosten Apps?

Was kosten Apps? Auf diese Frage gibt es eine ganz einfache Antwort:
Soviel wie ein Auto! 

Alles klar, oder?! Ernsthaft: Je nachdem, was für ein Auto es sein soll, kommen da zwischen 5.000 und 50.000 Euro zusammen, und nach oben gibt es kaum eine Grenze. Große Player auf dem App-Markt investieren mittlere sechsstellige Summen in ihre App-Angebote, und das fortlaufend.

Interessante Werte dazu liefert diese Erhebung:
http://www.ibusiness.de/aktuell/db/709614jg.html

Unerfahrene Kunden sind oft überrascht von den Aufwänden, die bei der App-Entwicklung entstehen können. Da App-Projekte oft Marketing getrieben initiiert und gemanagt werden, wird mit anderen Marketingmaßnahmen verglichen. Die Kosten einer Broschüre oder einer einfachen Webseite sind deutlich geringer. Woran liegt das, und was sind Kostentreiber?

Gründe für die Kosten der App-Entwicklung:

  • App-Entwicklung ist noch ein relativ junges Feld, dass sich schnell und ständig weiterentwickelt – es gibt kaum Kostenvorteile durch Erfahrungswerte und Standardisierung, vieles muss ausprobiert und durch Tests verbessert werden
  • App-Entwicklung ist eine Ingenieursleistung, die Fachkräfte sind rar und entsprechend umkämpft
  • Apps sind keine Webseiten, die „nur“ etwas anzeigen, sondern sie erfüllen teils komplexe Aufgaben
  • Speicher- und Leistungsfähigkeit von Smartphones sind beschränkt, sodass sehr gut konzipiert werden muss – diese Denkleistung kostet Zeit und braucht Erfahrung
  • die verschiedenen Betriebssysteme, -versionen, Gerätetypen und Bildschirmgrößen machen das ganze nicht eben einfacher

Dass Apps einfach „zusammengeklickt“ werden können, stimmt nicht. Es wird z.B. ein Datenmodell erstellt, die Datenhaltung konzipiert, ggf. Schnittstellen zu anderen Systemen aufgebaut und jeder „View“ eigens (Screenansicht) angelegt, mit Daten gefüllt, formatiert. Wer’s nicht glaubt, ist gern eingeladen, sich mal eine Stunde bei uns in der Agentur neben einen Entwickler zu setzen!

Kostentreiber:

  • spezielle und ungewöhnliche grafische Gestaltung des Interfaces
  • viele Schnittstellen und große Datenmengen, komplexe Aktualisierungsprozesse
  • Anforderungen, mit denen der Entwickler noch keine Erfahrung hat
  • nach Projektstart ungeplant hinzukommende Anforderungen   😉

„Komisch, dass die Apps in den AppStores dann noch so billig sind!“ sprach neulich einer unserer Kunden. Stimmt. Dies ist aber eher durch Markt-Gegebenheiten und Marketingentscheidungen begründet, als dass davon auf die Kosten der App-Entwicklung rückgeschlossen werden könnte.

Und, was darf es nun sein? Ein kleiner fescher Fiat? Die neue S-Klasse? Meinungen, Feedback, Anfragen und weiteres gerne an lh@mobile-melting.de

By

Website Launch der Pink Box Österreich

Diese Woche Dienstag, also am 16. Juli, wurde gemäß Zeitplan die Pink Box Österreich gelauncht. Unser Part war wieder das Templating und darauf zu achten, dass das Front-End sich den NutzerInnen konsistent präsentiert. Das umfasst die Inhalte, das Layout und die ganzen Details, die beim Templating zu beachten sind: Bilder, Farben, Icons, Striche, Hintergrund-Grafiken, richtige Links und so weiter und so fort. Immer wieder fällt mir auf, wie viel Arbeit und Aufwand nötig sind, um eine Seite in die Welt zu bringen. Für alle, die einen Über- und Einblick möchten, trage ich hier den Prozess bzw. die Punkte zusammen, die zu einer gelaunchten Webseite führen.

Launch einer Webseite – was braucht’s?

  • Schritt 1: Die Idee, das Produkt, der Markt, die Zielgruppe. Wie bei jeder Sache, die wir Menschen kreieren und in die Welt setzen möchten, braucht es über die Idee hinaus ein Konzept. Zu Beginn stellen sich viele Fragen. Was macht diese Sache? Für wen ist sie? Was ist das Ziel? Im Falle der Pink Box könnte man sagen: es ist ein monatliches Abo mit neuen Kosmetikprodukten zum Ausprobieren für eine weibliche Zielgruppe zwischen 16 und 33 Jahren. Ziel: auf neue Kosmetikprodukte aufmerksam machen, Freude bereiten, x Stück der Boxen monatlich verkaufen und y € Umsatz machen.
  • Schritt 2: Das Internet als Vertriebsweg. Wir setzen mit der Website erst an, wenn unserem Kunden klar ist, dass ein Vertriebsweg (und in unserem Beispiel der Pink Box der einzige) das Internet ist. Dazu müssen das Geschäftsmodell und Produkt längst stehen – es sei denn, diese werden zunächst getestet. Ist die Nachfrage noch unklar, kann man mit einer relativ schlanken Website, einem schmalen Anfangsbudget und der Buchung von Anzeigen (z.B. über Google AdWords) prüfen, ob es einen Bedarf gibt. Wenn sich eine Anzahl von x Menschen für das Produkt interessieren, und dieses x in einen Bereich fällt, in dem Aufwand und Mühe lohnenwert erscheinen, dann kann man das Aufsetzen eines Online Shops in Erwägung ziehen. Ob sich dieser im klassischen Web, als Web-App oder App präsentiert, ist abzuwägen und hängt von der Zielgruppe und Nutzungssituation ab. Das kann für jedes Produkt individuell sein und bestimmt die Markteintrittsstrategie.
  • Schritt 3: Produkt und Produktwelt. Meist gibt es bereits ein fertiges Produkt, bevor wir als Web- und App-Agentur die Produktwelt im Internet kreieren. Dann bekommen wir das Logo und Fotos vom Produkt geliefert und entwerfen dazu passend die Webseite. In ihr – und jetzt wird es wirklich interessant – spiegelt sich all das, was das Produkt ausdrücken, wen es ansprechen will. Die Webseite hat bei einem normalen Nutzer wenige zehntel Sekunden Zeit, um sein Interesse, sein Gefühl zu wecken. Da kommt es auf eine ästehtische Gestaltung, schöne Bilder, schnelle Ladezeiten und den klar dargestellten Produktnutzen an. Wenn der Nutzer sich zu Beginn angezogen fühlt, dann erst beginnt für ihn die so genannte User- oder auch Customer-Journey. Vereinfacht könnten wir auch sagen, es ist die Reise, die er noch durch Ihre Webseite unternimmt, um schließlich die Bestellung abzuschicken. Diese Reise – wie jede andere auch – gestaltet sich desto einfacher, je besser die Wege sind.
  • Schitt 4: Die große Ausnahme – der Weg allein ist nicht das Ziel. Sondern der Weg sollte unbedingt zum Ziel führen. Und das möglichst einfach, ästhetisch und verständlich. Angenommen, Ihre Webseite hat dem Kunden das Produkt schmackhaft gemacht und nun möchte der Kunde Ihr Produkt bestellen. Jetzt hat er den Weg eingeschlagen und jetzt sollten alle Wegweiser an der richtigen Stelle stehen, nicht mehr ablenken, sondern zum Ziel zeigen. Und der Weg ist steinig: es gibt ein Formular mit Adressdaten auszufüllen, es gibt die Auswahl der Zahlungsmethoden, es gibt die AGB und die Erklärung zum Widerrufsrecht, schließlich die Bestätigungsmail. Wenn hier was hackt, nicht auf Anhieb geht, sehr umständlich wirkt und schlicht „nervt“, dann schubsen Sie Ihren Kunden praktisch eigenhändig vom Weg. Das soll nicht sein. Die Usability, die Bedienbarkeit der Seite, ist hier besonders gefordert. Und der einzige Weg, zu prüfen, ob beispielsweise der Bestellvorgang gut gemacht ist, ist ihn zu testen.
  • Schritt 5: Testen – das wird Ihnen jeder ernsthafte Entwickler sowieso raten. Ja, unsere Zeit ist schnelllebig. Dinge kommen schnell und gehen auch wieder schnell. Trotzdem: der solide Ansatz ist immer noch genauso gut wie eh und je. Jede Software sollte gestestet werden. Auf Funktionalität und Bedienbarkeit – das sind die beiden Hauptaspekte. Testen geht mit echten Menschen. Und hier kommen wir zur nächsten Schwierigkeit: meist werden von Kundenseite dafür keine Zeit und kein Budget eingeplant, weil der Launch schnell gehen soll. Ein grober Fehler, denn alles, was später ausgebessert werden muss, kostet doppelt oder dreimal so viel. Solide Produkte wurden getestet: Autos, Flugzeuge, iPads, iPhones, Crèmes. Würden Sie gern ungetestete Produkte benutzen? Bei einer Webseite ist der Schaden sicher nicht so groß wie bei einem Auto, das nicht bremst. Aber es birngt ebenfalls einen Verlust mit – und dieser liegt dann auf der Seite des Auftraggebers. Wenn seien Kunden nicht bestellen, war das ganze Erschaffen des Produktes hinfällig.
  • Schritt 6: Kontinuierliche Verbesserungen von Details. Das ist nunmal so: damit eine Sache langfristig funktioniert, muss sie verfeinert und immer wieder verbessert werden. So auch Ihr Webshop. Er wächst und reift mit Ihnen und dem Produkt. Da gibt’s ein neus Produkt, das ein eingestellt werden soll, hier soll ein Teaser passend zur Jahreszeit aussehen oder es gibt eine neue Zahlungsart. Das Sinnvolle soll natürlich auch Ihrem Kunden zu Gute kommen und so sollten Sie immer wieder Budget zur Pflege Ihres Webshops / Ihrer Webseite einplanen. Einen Teil können Sie einsparen, wenn Sie Produkte selbst pflegen und sich bemühen, sie auf dem aktuellen Stand zu halten. Für Kosmetik am Front-End sind Grafiker und Templater zuständig. Kleine, immer wieder neue, ansprechende Ideen für das Aussehen kommen bei der Zielgruppe gut an und können von Ihnen als Betreiber gut über verschiedene Kanäle mitgeteilt werden. Und da sind wir auch schon beim Punkt Kommunikation.
  • Schritt 7: Beschenken Sie Ihre Nutzer. Ihr Webshop ist fertig, Ihr Produkt sieht super aus, ein paar Bestellungen kommen von selbst rein, hier und da haben Sie ein paar Anzeigen geschaltet. Wenn das bereits ausreicht, prima. Falls nicht, dann sollten Sie noch zu anderen Mitteln greifen, um mehr Platz in der Welt zu bekommen: verschenken Sie etwas. Ziehen Sie neue Nutzer über ein interessantes Thema, das mit Ihrem Produkt zu tun hat, an. Wir kommen hier wieder zum Thema Mehrwert. Sobald es einen echten Mehrwert gibt, werden Ihre Kunden begeistert Neukunden anschleppen. Wenn diese dann bestellen, läuft es rund. Zum Thema Mehrwert gibt es bereits einen ganzen Artikel von uns – Sie finden ihn hier. Ob App, Web oder Welt – es gelten dieselben Prinzipien.

 

By

Wofür ist (m)eine App gut?

Es kommt häufig vor, dass wir Anfragen zu Apps bekommen, die keinen klaren Kernnutzen haben, sondern alles Mögliche können sollen. Es sollen Features programmiert werden wie Kalender, Mail aus der App schicken, Foto machen, etwas bewerten, etwas herunterladen, Website oder Video anzeigen und so weiter und so fort. Man kann wirklich alles in eine App packen, keine Frage von Können.
Sie haben sicher schon von der Eierlegenden Wollmilchsau gehört? Die Schwierigkeit besteht darin, unserem Kunden verständlich zu machen, dass sein Kunde (im Folgenden „Nutzer“ genannt) gar keine App haben möchte, die alles kann. Das liegt daran, weil es zum Einen schon jede Menge Apps gibt, die eine spezielle Aufgabe sehr gut erfüllen und zum Anderen: der Nutzer wird heutzutage so überhäuft mit Infos, mit Angeboten, mit Rabatten, mit Werbung, dass er sehr gern eine App benutzt, die ihm dient und die nicht schon wieder die Reste seiner Aufmerksamkeit verschlingen möchte.

Mehrwert. Ja, ein schönes Wort. Und doch, oft wird’s einfach vergessen, was das bedeutet. Zuerst ging es im populären Web darum sich zu präsentieren. Unsere Firma, unsere Webseite, jetzt: unsere App. Infos über uns als Firma, Öffnungszeiten etc. Schön und gut. Das sind Informationen, aber noch kein Mehrwert. Ein Mehrwert hat wirklich nur den Nutzer im Fokus. Mehrwert ist ein Geschenk, idealerweise ohne eine ersichtliche Erwartung. Mehrwert ist etwas, das dem Nutzer Spaß macht oder ihn bei etwas signifikant unterstützt. Stellen Sie sich den Mehrwert wie eine gute Flasche Wein oder eine Pralinenschachtel vor. Natürlich geben Sie sie mit einer Intention und hoffen, dass Ihr Geschenk Sie in ein gutes Licht stellt und der andere sich an Sie erinnert. Und gleichzeitig übergeben Sie diese Schachtel Pralinen wirklich. Sie übergeben nicht nur die Idee der Schachtel, sondern die Süßigkeit selbst. Und sie lassen los. Es ist ein Invest.

Bei einer App, die Sie Ihren Nutzern bieten, sollte das genauso sein. Sie investieren mit der Hoffnung, dass Sie im guten Licht stehen und Ihr Nutzer sich an Sie erinnert und gleichzeitig lassen Sie los und geben ihm das Geschenk. Das funktioniert in der materiellen und der virtuellen Welt. Sie kaufen die Schachtel Pralinen im Handel, Sie kaufen die App beim Dienstleister. Sie zahlen mehr für die App, weil Sie sie viel öfter verschenken können und sie sich nicht abnutzt.

Verschenken Sie nicht die Katze im Sack, die den Nutzer anspringt und dabei verrät, dass Sie eigentlich nur was von ihm erwarten. Verschenken Sie Freude in Form eines witzigen Spiels oder in Form von Unterhaltung, verschenken Sie ein sinnvolles Tool, das der Nutzer in seinem Alltag aufrufen und nutzen kann. Egal was – worauf es ankommt, ist Ihre Ehrlichkeit dabei. Ein ehrlicher Mehrwert zahlt sich aus, ein falscher Mehrwert bleibt als App-Leiche im App Store liegen. Das können Sie sich sofort sparen.

Es reicht völlig aus, wenn Ihre App eine oben genannte Sache richtig gut kann. Ideen, die Sie sonst noch haben oder vermitteln wollen, dürfen Sie um diesen Nutzen herumsetzen, aber stehlen Sie der Hauptidee, also dem Kernnutzen, nicht die Show. Damit hätten Sie die Schachtel Pralinen vorher geöffnet und welche gegessen. Das ist dann keine Freude. Die Idee reicht nicht, es muss konsequent sein. In beiden Fällen, Praline oder App. Sie können ja noch mal schauen unter Customer-Experience-Management, klingt riesig, meint aber immer wieder und wieder dasselbe: geben Sie etwas Freundliches, pflegen Sie auf ehrliche Weise Kontakte, um dafür in Erinnerung zu bleiben. Das geht Hand in Hand mit der User-Experience in einer App, also dem Erlebnis der Nutzung („oh toll“, „macht Spaß“, „ehm..dröge“). Bringen Sie Freude in die Welt, dröge ist sie genug!

Die Hauptfrage ist also: Was hat der Nutzer von meiner App? Macht Sie ihm gute Laune? Ist sie wirklich ein Geschenk?

Ich habe ein paar Beispiele für Apps herausgesucht, die wirklich ein Geschenk sind:

  • Zum Beispiel die Zeitreise Nürtingen App. Echt nett gemacht. Eine virtuelle Zeitreise durch die Stadt mit Archiv-Fotos und Audios. Hübsch, rund, geschenkt.
  • Oder die Mr Mood App, eine Spielerei, aber irgendwie witzig. Man kann täglich seine Laune auf interaktive Art festhalten und sieht am Ende eine Statistik. Wenn man längere Zeit schlechte Laune hatte, sollte man drüber nachdenken, etwas in seinem Leben zu ändern.
  • Nützlich könnte man diese App nennen, wenn man vor hat, nach Südtirol zu fahren. Culturonda stellt die Region vor, gibt Infos und sieht schick aus.
  • Nicht zu vergessen, die ganzen Apps, die beispielsweise Google rausgebracht hat: Mail App, Drive App, Kalender App – ich nutze sie fast täglich. Sinnvolle Tools. Google ist toll im Schenken, sie schenken die ganze Zeit. Dass sie auch nehmen, lässt sich nicht verbergen, klar. Aber sie sind verdammt erfolgreich.

Und ja, als Agentur für App Programmierung bieten wir natürlich die App Konzeption an, in der es um den Kernnutzen und Mehrwert geht.

By

Präsentation der iPhone App „Zwangsarbeit“ im Rahmen des Berliner Themenjahres „Zerstörte Vielfalt“

Berlin beschäftigt sich dieses Jahr – 80 Jahre nach der Machtergreifung durch die Nationalsozialisten – flächendeckend mit dem Thema „Zerstörte Vielfalt“. Um an die Unmengen ausgemerzter lebendiger Vielfalt zu erinnern, leisten Museen, Vereine, Gemeinden, Archive, Verbände und kulturelle Einrichtungen mit spezifischen Beiträgen zu einer ganz Berlin umfassenden Ausstellung bei. Vom Deutschen Historischen Museum mit seiner Ausstellung bis hin zur Programmierung von App werden unterschiedlichste Beiträge zu diesem Thema veröffentlicht – eine Übersicht findet sich hier.

So hat auch die Berliner Geschichtswerkstatt ein Projekt zum Thema „Zwangsarbeit“ vorbereitet, das gestern als iPhone App vorgestellt wurde. 5 Touren führen durch Berlin – zu Fuß, per Rad oder S-Bahn – und machen an merk-würdigen Orten halt. Dort berichten Zeitzeugen in Medienbeiträgen, die vorher in der App heruntergalden werden konnten, über ihre Erlebnisse, Erfahrungen, über ihre Trauer, aber auch über Alltägliches, das ihnen zur Zeit der Nationalsozialisten in Berlin begegnet ist. Polen, Russen, Ukrainer, Rumänen,  Italiener, Holländer und Menschen europäischer und nicht-europäischer Länder mit oder ohne jüdischer Herkunft wurden nach Berlin deportiert, um hier die leeren Stellen der Arbeiter zu besetzen, die in den Krieg gezogen oder dort gefallen sind. Zwangsarbeit gab es in Berlin nahezu überall, fast flächendeckend – von der AEG, über die BVG, Siemens bis hin zu kirchlichen Einrichtungen! Gerade in Berlin entstand eine absurd hohe Zahl an Lagern, die wie Pocken die Fläche der Stadt bedeckten. 1000 Lager in Schulen, Kinos, innerhalb und außerhalb der Stadt wurden für die Unterkunft der Zwangsarbeiter gebaut. Berlin war zentraler Rüstungsstandort und benötigte Arbeitskräfte. Zwar widersprach der Einsatz dem nationalsozialistischen Gedanken, Arbeiter nicht-deutscher Herkunft in Deutschland unterzubringen, aber die Kriegswirtschaft benötigte Arbeitskräfte. Es war ein Wahnsinn, ein purer Wahnsinn.

Abbildung iPhone App zur Zwangsarbeit

Berliner Geschichtswerkstatt hat die iPhone App zur Zwangsarbeit im Rahmen des Berliner Themenjahres 2013 „Zerstörte Vielfalt“ herausgegeben.

Wie nähert man sich überhaupt diesem Thema? Wie kann diese, unsere deutsche Geschichte überhaupt aufgearbeitet werden? Das frage ich mich jedesmal. Und dann sind da solche Menschen, die sich ehrenamtlich engagieren, mit Zeitzeugen sprechen, Interviews führen, an Orte des Geschehens fahren. Die Berliner Geschichtserkstatt beschäftigt sich seit 50 Jahren mit der Aufarbeitung der deutschen Geschichte. Und nun haben sie zum Berliner Themenjahr „Zerstörte Vielfalt“ ihren Beitrag geleistet, der sich eines modernen Mediums bedient: eine iPhone App, die Orte und Medien in Touren und Karten zusammenbringt. Man kann die Tour herunterladen, den Ort besuchen und dort die Vergangenheit erwecken, um zu verstehen, was Menschen auf unserem Grund und Boden, den wir täglich betreten oder an ihm zur Arbeit vorbeifahren, erlebt haben.

Die Geschichte holt uns immer wieder ein, denn die App hat im Apple App Store eine überdurchschnittlich lange Review-Zeit in Anspruch genommen, weil Archivbilder verwendet wurden, die nationalsozialistische Symbole abbilden. Apple hat eine Liste von Verboten für jedes Land und hält sich strikt daran, diese Symbole oder Parolen nicht zu veröffentlichen bzw. nicht dazu beizutragen, dass diese Verbeitung finden. Klar, wir können uns darüber ärgern. Oder es eben als Konsequenz sehen.

Ich hoffe, das Review-Team versteht, dass diese wundervolle und wichtige App sich im Kontext geschichtlicher Aufarbeitung befindet und publiziert sie so schnell es geht. Sie können sich unsere neueste Referenz hier ansehen.

Wir bedanken uns herzliche bei der Geschichtswerkstatt für dieses spannende und berührende Projekt.

By

Exkurs in die Welt der Apps Teil 1 – Was ist überhaupt so eine App?

Mir ist aufgefallen, dass der Begriff „App“, der eine Abkürzung des englischen Wortes „Application“ ist und soviel wie „Anwendung“ heißt, von Menschen, die nicht in der Branche tätig sind, für Verwirrung sorgt. Viele Menschen benutzen zwar die moderne Technik, verlieren dabei aber zunehmend den Zusammenhang zu ihrem Ursprung: dem guten alten Personal Computer mit seinem bekanntesten Betriebssystem Windows. Seitdem ist zwar alles kleiner, schneller und online, aber die Prinzipien sind gleich geblieben. Und das soll unser Rettungsanker für diesen Artikel sein.

Auf einem Personal Computer (ob es ein Laptop ist oder ein Desktop oder ein Tower) laufen Programme. Das Chef-Programm ist das Betriebssystem, das auch „OS“ von „Operating System“ abgekürzt wird. Die Programme, die vom OS gehandhabt und überwacht werden, sind Anwendungsprogramme. Ein Virenscanner ist ein Anwendungsprogramm, Microsoft Word ist eins und die Browser Safari, Firefox oder Chrome sind ebenfalls Programme. Okay, und wenn wir jetzt das ganze verkleinern, dann stellen wir fest, dass ein iPhone ein kleiner, tragbarer PC ist, der auch über ein Operating System, nämlich das iOS, verfügt. Und das iOS kümmert sich um die korrekte Ausführung der, na, Sie ahnen es, APPS! Wenn Sie die Safari-App auf dem iPhone starten, ist es nichts anderes als ein Programm auf einem PC. Nur, dass Sie es in der Hand halten können.

Eine App ist ein Programm

Eine App ist ein Programm auf dem Smartphone

 

Mit dem Betriebssystem „Android“, bei dem Google die Nase vorn hat, aber nicht alleiniger Entwickler ist, verhält es sich genauso. Ob Sie nun ein HTC, Samsung, Sony oder Google Nexus in der Hand halten: all diese Smartphones sind kleine PCs mit einem Betriebssystem, das Programme ausführen kann. Und wieder hier die Apps. Programme auf dem Smartphone sind Apps.

Als wir mit der App-Programmierung anfingen, unterschätzten wir vollkommen den Aufwand, der mit der Entwicklung einhergeht. Nach dem Motto: „kleines Gerät, kleines Programm – wird schon“, war uns nicht bewusst, welche Tücken und Schwierigkeiten auf uns warteten.
Beispielsweise, dass ein kleines Gerät weit weniger Leistung hat als ein Laptop und daher ein Programm schlank und rank programmiert werden sollte. Oder dass der Monitor so klein ist, es wenig Platz gibt und man kein riesiges Menü mit 100 Unterpunkten darstellen kann.

App-Programmierung ist anspruchsvoll, denn man muss Vieles beachten, was zur guten alten Zeit der PCs nebensächlich war. Gleichzeitig ist es eine spannende Herausforderung, mit so vielen Begrenzungen etwas Tolles zu entwickeln. Und wenn dann noch das Internet und die geografische Position hinzukommen, sind die Möglichkeiten echt verrückt.