Jörg Neumann: Eine gute Usability zeichnet sich vor allem dadurch aus, dass die App einen wirklichen Mehrwert bietet und dabei intuitiv zu bedienen ist. Das hört sich jedoch leichter an, als es ist. Denn nur, wenn man die Anwender mit ihren unterschiedlichen Eigenarten, Bedürfnissen und Wünschen versteht, kann man sie aktiv unterstützen. Design-Thinking-Techniken sind bei dieser Analyse sehr hilfreich.

JAXenter: Um die Anwender einer App proaktiv zu unterstützen, rätst Du zu Storyboards. Wie sieht ein gutes Storyboard aus und was sind seine Vorteile?

Jörg Neumann: Anders als Sketches oder Wireframes bieten Storyboards ein konkretes Design. Das hilft insbesondere bei der Kommunikation mit dem Kunden, da diese eine sehr genaue Vorstellung davon bekommen, wie die App später aussehen wird. Zudem demonstriert ein Storyboard das Verhalten der App. So können Navigation und Animation direkt erlebt und bewertet werden, bevor die Implementierung beginnt. Dies spart eine Menge unnötige Arbeit und hilft auch dem Entwickler, denn ein Storyboard sagt mehr als tausend Seiten Konzept und Styleguide.

JAXenter: Kannst Du Tools empfehlen, die sich für das Erstellen von Storyboards besonders eignen?

Jörg Neumann: Ich arbeite gern mit Indigo Studio. Das ist sehr leicht zu erlernen, läuft auf PC sowie Mac und bietet insbesondere im Bereich State-Management einige nützliche Funktionen. Ansonsten finde ich Adobe XD super. Vor allem das Aufnehmen von Bedienvideos und das Übertragen der Entwürfe auf ein Mobilgerät sind hier besondere Stärken.

JAXenter: Wie lässt sich sicherstellen, dass ein Storyboard wirklich effektiv genutzt wird bzw. den gewünschten Erfolg umsetzt?

Jörg Neumann: Ein Storyboard muss man als gemeinsames Zielbild verstehen. Erst wenn alle daran glauben, kann daraus eine wirklich gute App entstehen. Daher ist es wichtig, bei jeder Diskussion und bei allem was der Einzelne im Team tut, das Storyboard als Grundlage zu verwenden. Jede Abweichung sollte vor der Umsetzung mit dem Team besprochen und im Anschluss zunächst im Storyboard geändert werden. Denn es bildet die Grundlage der Entwicklung über den gesamten Lifecycle der App.

JAXenter: Was ist, Deiner Meinung nach, die beste Programmiersprache für mobile Entwicklung?

Jörg Neumann: Typische Beraterantwort: Kommt darauf an! Wenn ich nur für iOS entwickle, finde ich Swift super. Heute sollte man sich jedoch mehr auf Cross-Plattform-Lösungen fokussieren. Hier bietet sich aus meiner Sicht Xamarin an, da ich damit native Apps erzeugen kann, obwohl ich in C# entwickle. Neuerdings finde ich auch Google Flutter sehr interessant. Damit können ebenfalls native Apps für iOS und Android entwickelt werden, jedoch mit Dart – was insbesondere für Web-Entwickler interessant sein dürfte.

JAXenter: Welches Thema wird dieses Jahr in der Mobile-Entwicklung besonders wichtig sein bzw. in welche Richtung geht es wohl in den nächsten Jahren?

Jörg Neumann: Nach dem Hype der letzten Jahre wird sich das Thema, aus meiner Sicht, vom Consumer-Bereich noch mehr in Richtung Business bewegen. Viele Unternehmen fangen aktuell erst an, ihre Prozesse zu mobilisieren. Zudem werden die Themen Machine Learning und Augmented Reality die Entwicklung mobiler Lösungen befördern.

JAXenter: Vielen Dank für das Interview!

Geschrieben von: Katharina Degenmann

The post Mobile-App-Entwicklung: „Eine gute Usability ist das A und O für eine App“ appeared first on MobileTechCon.

Pierre Liebsch: Aus technischer Sicht ist es eher eine Glaubensfrage, was eine gute App ausmacht. Wichtig ist, dass die Software gut wartbar ist. Bei mobilen Geräten sollte man außerdem einen genaueren Blick auf Performance und Energieverbrauch legen. Außerdem sollte man sich nach Möglichkeit im Vorfeld überlegen, ob man einzelne Features als Module bereitstellt.

JAXenter: Welche Tools sind für die Entwicklung einer Android-App unverzichtbar?

Pierre Liebsch: Zum Entwickeln setze ich auf die offizielle Entwicklungsumgebung Android Studio. Darüber hinaus kann es von Vorteil sein, Bildbearbeitungsprogramme wie Adobe Photoshop zu haben, um Icons erstellen oder anpassen zu können.

JAXenter: Wer muss sich alles an einen Tisch setzen, damit eine App nachhaltig Erfolg hat?

Pierre Liebsch: Wichtig für eine App sind vor allem der Nutzen sowie die Usability. Daher ist es unerlässlich, dass man den App User versteht. Sowohl zur Planung der Funktionalitäten als auch zum Gestalten des UI’s muss die Zielgruppe verstanden werden.

JAXenter: Welche Fehler machen Unternehmen oder Entwickler bei der App-Entwicklung am häufigsten? Hast Du eine “Flop 3”?

Pierre Liebsch:

1. Es werden Rechte angefragt, ohne dass der User weiß warum. Der User muss verstehen können, warum eine App auf beispielsweise die Kontakte zugreifen können möchte. Ansonsten wird dieser der App nicht trauen.
2. Leider wird gerade im mobilen Umfeld noch immer häufig das Schreiben von Tests ignoriert.
3. Overengineering: Es werden oft Features eingebaut, bei denen man glaubt, der Nutzer könnte sie brauchen, doch letztendlich finden sie nie Verwendung.

JAXenter: Welche Tipps würdest Du für den Bau einer erfolgreichen App geben? Kannst Du uns 3 Best Practices nennen?

Pierre Liebsch:

1. Kenne deine Zielgruppe.
2. Pflege deine App und beachte das Feedback der User.
3. Setze auf Standards, d.h. nutze dem User bekannte Icons und Bedienkonzepte, anstatt alles neu zu erfinden.

JAXenter: Wie sieht, Deiner Meinung nach, die Zukunft der App-Entwicklung aus?

Pierre Liebsch: Eine genaue Aussage über die Zukunft lässt sich z.Z. nur schwerlich treffen. Mit Fuchsia hat Google ein neues Betriebssystem geschaffen, welches u.a. für den mobilen Markt geeignet ist. Die Zukunft wird sich wohl stark danach richten, wie Google Fuchsia einsetzen wird.

JAXenter: Vielen Dank für das Interview!

Geschrieben von: Katharina Degenmann

The post Erfolgreiche App-Entwicklung: “Nutze bekannte Icons und Bedienkonzepte, anstatt alles neu zu erfinden” appeared first on MobileTechCon.

Manuel Rauber und Thomas Hilzendegen: Eine offlinefähige App bedeutet, dass sowohl der Anwendungsrahmen (der Code der App) als auch die Daten selbst offline zur Verfügung gestellt werden müssen und die App nicht einfach nur mit einem Fehler abstürzt. Gerade bei den Daten beginnen hier schon die ersten Use-Case-abhängigen Herausforderungen. Sollen die Daten nur gelesen werden? Oder sollen die Daten auch im Offlinemodus verändert/gelöscht werden können?

Sobald man über schreibende Zugriffe nachdenkt, kommt automatisch die Überlegung von Konfliktmanagement hinzu. Gewinnt der letzte schreibende Zugriff? Soll der Benutzer entscheiden können, was im Falle eines Konflikts passiert? Alle schreibenden Änderungen müssen im Offlinemodus auf dem Gerät gespeichert werden, sodass sie beim Onlinegehen an das API geschickt werden können. Hierbei ist auch zu beachten, wie IDs der neuen Datensätze generiert werden. Zusätzlich haben Browser unterschiedliche Limits in Bezug auf die zu speichernde Datenmenge.

Weitere Herausforderungen entstehen im Backend. Zum einen muss in jedem Datensatz ein Tracking von Änderungen möglich sein. Bspw. bietet der Microsoft SQL Server den Spaltentyp rowversion hierfür an. Er kann genutzt werden, um Schnittstellen (JSON-basierte Web-APIs) zu entwickeln, die auf Basis der rowversion Delta-Updates generieren. Hierbei handelt es sich um alle geänderten Daten auf Basis der zuletzt gespeicherten rowversion auf dem Client. Bei gelöschten Datensätzen müssen die IDs separat gespeichert werden, sodass diese auch Bestandteil des Delta-Updates sind.

Spannend wird das Vorhaben, wenn Daten auf Basis von Security (Benutzerrollen und -rechten) dem Benutzer nicht mehr zur Verfügung stehen, denn hierbei ändert sich mit hoher Wahrscheinlichkeit der eigentliche Datensatz nicht. Das bedeutet, dass sich die rowversion nicht ändert, dennoch muss dieser Datensatz als „vermeintlich gelöscht“ an den Client übertragen werden.

JAXenter: Progressive Web Apps versprechen hier Abhilfe. Wie funktionieren sie?

Rauber und Hilzendegen: Obwohl Progressive Web Apps die Eigenschaft „Offline“ in sich tragen, lösen PWAs nicht gleich alle Probleme. Eine PWA hilft, den Anwendungsrahmen (Code) offline zur Verfügung zu stellen, aber nur bedingt bei den Daten. Möchte man die Daten, die man bereits angeschaut hat, nur rein lesend „offline“ anzeigen, kann eine PWA mit dem Service Worker hier auch unterstützen. Bei einem echten Synchronisierungsvorgang hilft eine PWA aber leider nicht.

JAXenter: Wie hoch schätzt Ihr den Mehraufwand beim Erstellen einer Progressive Web App im Vergleich zu anderen Single-Page Applications ein?

Rauber und Hilzendegen: Eine PWA würden wir nicht als Mehraufwand bezeichnen. Die eigentliche Single-Page Application muss sowieso erstellt werden, da diese die normale Anwendung darstellt. PWA ist nur ein weiteres Feature dieser Anwendung. Da eine PWA aus verschiedenen Charakteristika besteht, die aus einer Anwendung eine PWA machen, ist es abhängig von den Anforderungen, die man unterstützen möchte und die das dazu passende Feature implementiert.

JAXenter: Wo liegen die Nachteile einer PWA?

Rauber und Hilzendegen: Aktuell ist zu beachten, dass noch nicht alle neuen APIs, die eine PWA ausmachen, unter allen Browsern zur Verfügung stehen. Zum Beispiel ist hier das Push API zu nennen, das bereits in Chrome (auch unter Android) funktioniert, aber es unter iOS noch nicht mal klar ist, ob es überhaupt seitens Apple implementiert werden wird.

Auch sollte man sich bewusst sein, dass eine offlinefähige App nicht unbedingt auch offlinefähige Daten bedeutet, da hierfür mehr nachgedacht und implementiert werden muss. Dazu kommt, dass gewisse APIs im PWA-Umfeld verwirrend benannt sind. Allen voran das Background Sync API, dessen Name vermeintlich bedeutet, dass man Synchronisationsvorgänge starten kann. Doch es handelt sich dabei vielmehr um einen intelligenten Scheduler, der es erlaubt, zu gewissen Zeitpunkten Code auszuführen. Die Entscheidung, ob dieser Code einen echten Synchronisierungsvorgang startet, obliegt dem Entwickler.

Generell gilt natürlich auch, dass gewisse Browserlimitationen auch bei PWAs gelten, sei es die Bereitstellung von Speicherplatz oder die allgemeine Browserperformance. Und, wie im Web üblich, gilt, dass nicht alle nativen Funktionen genutzt werden können, wenn der Browser hierfür generell kein API bereitstellt.

JAXenter: Ihr demonstriert in eurem Workshop beim MobileTech Conference & Summit die Entwicklung einer PWA mit Angular und .NET Core. Welche Besonderheiten gilt es bei der Entwicklung von PWAs mit Angular zu beachten?

Rauber und Hilzendegen: Bei PWAs mit Angular ist zu beachten, dass die Anwendung zwangsläufig als Production Build erzeugt werden muss, damit der Service Worker von Angular funktioniert. Dieser Build ist deutlich zeitintensiver als ein Development Build, weswegen die Entwicklungsgeschwindigkeit darunter leiden könnte.

Ansonsten sind generell die Besonderheiten von PWAs und dem Web als Applikationsplattform zu beachten, unabhängig davon, ob Angular oder ein anderes Framework eingesetzt wird.

JAXenter: Zum Schluss nochmal eine Einschätzung aus eurer Praxis: Wann lohnt sich der Mehraufwand einer PWA – und wann nicht?

Rauber und Hilzendegen: Nutzt man die vom Angular Service Worker gegebenen PWA-Funktionalitäten, ist der Mehraufwand im Vergleich zur eigentlichen Anwendung nicht sehr hoch. Im Vergleich zu einer echten App, die im jeweiligen Store veröffentlicht wird, hat man aber folgende Vorteile:

• Die App unterliegt nicht den Regulationen und Prüfungen des Store-Anbieters.
• Auch Updates können somit jederzeit bereitgestellt werden und müssen nicht erneut durch den jeweiligen Store-Anbieter überprüft und freigegeben werden.

Der Mehraufwand für eine PWA lohnt sich aktuell nicht, wenn das Hauptziel der App iOS-Benutzer sind, da die Unterstützung auf iOS für PWAs bisher sehr rudimentär ist und o. g. Vorteile nicht als notwendig erachtet werden oder generell eine native im Store erhältliche App gewünscht ist.

JAXenter: Vielen Dank für dieses Interview!

Geschrieben von: Hartmut Schlosser

Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser

The post Progressive Web Apps: So lässt sich die Lieblingsapp auch offline nutzen appeared first on MobileTechCon.

Till Krempel: Die größten Erfolge am Markt konnte Augmented Reality sicher im Gaming-Bereich verzeichnen, allerdings nutzen auch heute schon soziale Medien in ihren Kameras AR-Filter zum Aufwerten des Nutzer-Contents. Es gibt aber auch durchaus Szenarien mit echtem Mehrwert für den Nutzer, wie bei der Produktvorschau in den eigenen vier Wänden oder eben bei der Indoor-Navigation in öffentlichen Gebäuden. Es gibt außerdem viele weitere denkbare professionelle Anwendungsfälle, z.B. in Industrie, Bauwesen, Luftfahrt, Retail, Logistik oder Medizin. Diese werden aber oft nicht auf dem Smartphone stattfinden, sondern auf dedizierter Hardware.

Wenn die echte Welt zentimetergenau vermessbar wird, hat das Konsequenzen. Es werden ganz neue ortsgebundene Services möglich werden.

Die für Mobilgeräte meiner Einschätzung nach spannendsten Anwendungen sind jene, die nicht nur ad-hoc eine augmentierte Realität aufbauen und diese sofort wieder vergessen, sobald das „Spiel“ vorbei ist, sondern die eine parallele digitale Welt aufbauen, die auch mit der echten Realität in Zusammenhang steht. Durch die Fortschritte in den kamerabasierten Trackingverfahren wird es möglich, die Realität auf einem sehr viel feineren Detailgrad als bisher digital zu erschließen. Wenn die echte Welt zentimetergenau vermessbar wird, und das nur anhand der schon existierenden Milliarden Smartphones die die Menschen auf diesem Planeten benutzen, hat das Konsequenzen. Es werden so ganz neue ortsgebundene Services möglich werden, die wir bisher noch nicht kennen.

JAXenter: Hardwaregestützte Ansätze sind auf dem Markt gescheitert, Lösungen wie ARCore und arKit sind praktikabler, da hierfür keine spezielle zusätzliche Hardware nötig ist. Hat die Technologie rund um die Augmented Reality einen wichtigen Schritt gemacht, oder bedeutet das letztlich nur, dass die Endprodukte zwar funktionieren, aber besser funktionieren könnten, hätte man entsprechend dedizierte Hardware?

Till Krempel: Hardware ist kein Selbstzweck, sondern wird in der Regel immer erst dann angeschafft, wenn damit neue Dinge möglich werden, die der Nutzer braucht. Solange es nicht die „Killer-Anwendung“ gibt, die der Nutzer wirklich benötigt, wird sich niemand ein neues Hardware Device anschaffen.

Wir haben die Qualität des Motion Tracking auf ARCore und Tango verglichen und die Ergebnisse sind überraschend gut. Das zeigt, dass die Hardware eben nicht für alle Aspekte des Themas zwingend erforderlich ist. Der Schritt, die in Tango Devices verfügbaren Features mit kleinen Abstrichen für jeden verfügbar zu machen, der ein halbwegs aktuelles Device hat, ist daher eine erfreuliche Entwicklung. Dies wird der Verbreitung von AR-Anwendungen helfen.

JAXenter: Es wird gemunkelt, dass GPS möglicherweise bald von einem neuen Google-Service beerbt werden könnte. Glaubst du GPS ist eine Auslauftechnologie? Welche Vorteile hätte der „Visual Positioning Service“?

Till Krempel: VPS wird GPS meiner Einschätzung nach in naher Zukunft definitiv nicht ablösen, höchstens ergänzen. Allein schon für die Fahrzeugnavigation ist GPS unabdingbar. Der Vorteil einer rein visuell-basierten Lösung ist die Erschließung der Innenräume und die höhere Genauigkeit. Für den Service wird aber eine teils massive Datengrundlage in Form von visuellen Informationen benötigt, die, wenn man sich nicht aus vorhandenen Quellen erheben kann, auch erstmal erstellt werden muss. Theoretisch kann dann aber jedes Device, welches eine Kamera und eine Internetverbindung hat, die Technologie verwenden, solange die Verarbeitung in der Cloud stattfindet. In Kombination mit der Größenordnung des Android-Ökosystems, hängt die Etablierung hier eigentlich nur von der Leistungsfähigkeit des Systems und der Verfügbarkeit der Daten ab, wenn und falls es der Service in den Produktivbetrieb schafft.

JAXenter: Was wird kurzfristig und langfristig in Sachen Augmented Reality passieren?

Till Krempel: Ich denke man muss hier unterscheiden, welche Endgeräte wir betrachten. Bisher sind arKit und ARCore nur für Nutzer eines aktuellen Smartphones verfügbar. Dementsprechend sind die Märkte für die Anwendungen hier zwar im Vergleich zu Google Tango gewachsen, allerdings immer noch klein. Da die Leute voraussichtlich nicht so schnell aufhören werden, Smartphones zu kaufen, wird die Verfügbarkeit für diese Anwendungen steigen. So werden sich auch mehr Firmen für diese Technologien interessieren und sie für ihren Anwendungsfall bewerten.

Apple & Google werden die komplexen technologischen Grundlagen für Augmented Reality in iOS und Android implementieren – so wird aus dem Nischen-Feature ein Standard-Feature.

Virtual Reality wird schneller einen zufriedenstellenden Reifegrad erreichen, z.B. als Erweiterung des „klassischen“ Videobilds bei Live-Übertragungen von Events, wie bei den olympischen Winterspielen. Der Markt ist mittlerweile voll von VR Headsets der verschiedensten Hersteller und auch über Cardboard, GearVR oder Daydream kann man schon ohne größere Investitionen daran teilhaben. In diesem Bereich ist der Wettstreit, welche Plattform sich durchsetzt, schon in vollem Gange.

Die Hardware für AR ist hier noch in einem früheren Stadium, und obwohl die Qualität der Lösungen immer besser wird, ist die finanzielle Einstiegshürde für den Endverbrauchen noch zu hoch. Es wird daher noch etwas dauern, bis der Endverbraucher sich für kleines Geld eine AR-Brille kaufen kann, für die es auch genügend Anwendungen gibt. Bis dahin ist das Smartphone für diesen Bereich noch das Mittel der Wahl.

JAXenter: Welche Erkenntnis sollte jeder Besucher deiner Session mit nach Hause nehmen?

Till Krempel: Die Session wird sich vornehmlich mit den Fortschritten in Sachen ARCore und arKit beschäftigen. Wir werden das Feature-Set erläutern, aktuelle Beispiele sehen, die wir selbst entwickelt haben, und Anforderungen an die Entwicklung von AR Apps diskutieren. Auch ein Ausblick darauf, wie solche Technologien unseren Alltag und auch das Berufsleben verändern können soll diskutiert werden.

Perspektivisch werden Apple und Google die komplexen technologischen Grundlagen für Augmented Reality in die Plattformen iOS und Android implementieren. Damit wird AR von einem Nischen-Feature zu einem einfach nutzbaren Standard-Feature. Als Entwickler programmiere ich ja auch keinen eigenen Bluetooth Stack oder GPS-Empfänger, sondern nutze die Features des Betriebssystems, um meine Anforderungen zu realisieren. Gerade für Entwickler aus dem mobilen Umfeld ist die Umsetzung von AR Features so nie einfacher gewesen als heute.

Interviewt von: Dominik Mohilo

Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.

The post Augmented Reality – wo wir stehen und was auf uns zukommt appeared first on MobileTechCon.

Christian Schwendtner: Hallo Dominik, sehr gerne! GraphQL ist vorrangig eine flexible Abfragesprache. Das sieht man auch auf der offiziellen Seite von GraphQL, wo getitelt wird „A query language for your API“. Das trifft den Kern von GraphQL ganz gut, denn es stehen die Client-seitigen Datenbedürfnisse im Vordergrund, also die Möglichkeit, auf einfache und flexible Weise die benötigten Daten für Clients abfragen zu können.

Ein spannender Punkt ist hier sicher die Flexibilität, die der Client gewinnt. Dieser kann einfach und genau definieren, welche Daten (inklusive Relationen) er vom Server benötigt. GraphQL ermöglicht also eine sehr Client- bzw. Use-Case-orientierte Sicht. Der Client kann mit einem Request genau die Daten laden, die er für einen Use Case bzw. eine Bildschirmmaske benötigt (kein Under- oder Overfetching).

Wie unterscheidet sich GraphQL von RESTful Web Services?

Christian Schwendtner: Diese Frage bekomme ich sehr oft gestellt, wenn Personen das erste Mal mit GraphQL in Berührung kommen. Bevor man diese Frage beantworten kann, ist es meiner Meinung nach wichtig, den Begriff RESTful Web Services etwas genauer unter die Lupe zu nehmen. Der Begriff ist an sich gut definiert, wird in der Praxis aber oft sehr inflationär verwendet. Wir sagen sehr gern zu jedem Service, das Ressourcen, HTTP-Verben und HTTP-Statuscodes verwendet und Daten in JSON zur Verfügung stellt, REST. Genau genommen ist es das aber nicht. Von REST oder einem RESTful Web Service dürfte man eigentlich erst dann sprechen, wenn alle Kriterien, die Roy Fielding (der Erfinder von REST) definiert hat, erfüllt sind. Ein wichtiges Kriterium dabei ist HATEOAS, also Hypermedia As The Engine Of Application State. Gerade HATEOAS wird aber bei vielen Services, die angeblich RESTful sind, nicht oder nicht ausreichend umgesetzt.

Eine gute Möglichkeit, um eine Idee davon zu bekommen, „wie RESTful“ ein Service ist, bietet das Richardson Maturity Model. In ihm sind verschiedene Level definiert, je nachdem welche Aspekte von REST umgesetzt sind. Ein Service, der nur manche Kriterien von REST erfüllt (z.B. „nur“ Ressourcen, HTTP-Verben, Statuscodes aber nicht HATEOAS) wird gerne REST-ish, REST-like oder REST-wannabe genannt. Das klingt jetzt vielleicht etwas nach Haarspalterei, aber ich denke es ist wichtig, dass man sich darüber im Klaren ist was genau man mit GraphQL vergleicht – speziell, wenn es um den Vergleich mit RESTful Web Services geht.

Meiner Erfahrung nach kann man sagen, dass GraphQL eine gute Alternative zu Level 2 des Richardson Maturity Models darstellt (Verwendung von Ressourcen, HTTP-Verben, Statuscodes), aber nicht gut geeignet ist, um als Alternative zu „echten“ REST-Services zu gelten (Stichwort HATEOAS).

Ein wesentlicher Unterschied bei GraphQL ist die verpflichtende Verwendung eines Schemas. In einem GraphQL-Schema sind alle Typen, die abgefragt werden können (Queries), und Operationen, die durchgeführt werden können (Mutations), definiert. Dadurch ergibt sich die Möglichkeit, eine Abfrage schon zur Übersetzungszeit der Anwendung auf Korrektheit überprüfen zu können oder Features wie Code-Completion zur Verfügung zu stellen.

GraphQL bietet aber einige interessante Konzepte – z.B. Fragmente: Am Client kann man GraphQL-Fragmente verwenden, um ein großes Query in kleinere Teile aufzuteilen. Das kann verwendet werden, um das Query des jeweiligen Use Cases (bzw. der jeweiligen Maske) nicht an einer Stelle definieren zu müssen, sondern die Datenbedürfnisse pro UI-Komponente definieren zu können. Das hat den Vorteil, dass die Datenbedürfnisse dort definiert werden, wo sie am besten bekannt sind. Aus den Fragmenten kann dann ein (großes) Query zusammengesetzt werden, das alle Datenbedürfnisse aller Komponenten der jeweiligen Maske enthält und die benötigten Daten können dann mithilfe eines Querys – per Request – geladen werden.

Eine weitere interessante Sache bei GraphQL sind Subscriptions. Mit einer Subscription kann sich ein Client auf ein Event des Servers registrieren, um so über Änderungen informiert zu werden (z.B. unter Verwendung von WebSockets). So kann man sehr einfach Push-Funktionalität in Anwendungen realisieren. Man könnte sagen, dass GraphQL ein opinionated Ansatz ist – das bedeutet, dass für bestimmte Probleme bestimmte Lösungen vorgesehen sind, man bekommt also einen kompletten Lösungsansatz mit allen Vor- und Nachteilen.

Wo liegen die Schwächen von GraphQL?

Christian Schwendtner: Viele sind von der Einfachheit, wie man die Client-seitigen Datenbedürfnisse in GraphQL definiert, beeindruckt. Man darf aber auch nicht die Serverseite vergessen. Durch die Freiheit, die man am Client gewinnt, muss man am Server oft mehr Denkarbeit investieren, um nicht in Performance-Probleme zu laufen. Da der Client flexibel seine Datenbedürfnisse definieren kann – frei nach dem Motto „wünsch dir was“ – ist auf der Serverseite besonderes Augenmerk auf Performance zu legen. Das sollte nicht zu spät im Projekt geschehen.

Eine indirekte Schwäche von GraphQL ist, dass es manchmal als „REST 2.0“ oder als „das bessere REST“ angepriesen wird. Ich denke nicht, dass das stimmt. Hier werden oft unterschiedliche Dinge verglichen. Die Abfragesprache ist meiner Meinung nach keine Alternative für einen „echten“ REST-Service, aber durchaus für viele REST-ish Services, wie man sie sehr oft sieht. Bei denen geht es eher darum, auf einfache und flexible Art Daten für den Client zur Verfügung zu stellen.

Nehmen wir an, ich habe eine App entwickelt, die noch auf RESTful Web Services setzt, wie schwer wäre eine Umrüstung auf GraphQL und ist das überhaupt praktikabel?

Ich denke, dass sich RESTful Web Services und GraphQL gut ergänzen können. Man kann GraphQL als Gateway einsetzen, um dem Client eine einheitliche Sicht auf die Daten zu ermöglichen. Der GraphQL-Gateway würde dann nicht selbst die Daten (z.B. aus einer Datenbank) laden, sondern die vorhandenen REST-Endpunkte aufrufen und als Aggregationspunkt fungieren.

Man würde damit einem Client die Flexibilität von GraphQL zur Verfügung stellen und trotzdem die eigentlichen Services als RESTful Services belassen. Gerade bei Microservice-Architekturen kann diese Vorgehensweise durchaus sinnvoll sein.

Bei einem neuen Projekt kann man natürlich über den alleinigen Einsatz von GraphQL nachdenken. In diesem Fall würde ich die Entscheidung von der konkreten Problemstellung abhängig machen. Blind jedes Problem mit GraphQL zu lösen, halte ich nicht für den richtigen Ansatz.

Welche Erkenntnis sollte jeder Besucher deiner Session mit nach Hause nehmen?

Dass GraphQL ein interessanter Ansatz ist, aber auch nicht die Lösung für alle Probleme. Sehr oft suchen wir nach der Lösung für all unsere Probleme. Oft vergessen wir dabei vielleicht, auf das konkrete Problem einzugehen und manchmal landen wir dann an dem Punkt „Wir hatten zwar eine Lösung, aber sie passte nicht zum Problem“. Ich denke, dass die Verwendung von GraphQL sehr sinnvoll sein kann, aber dass es nicht alle unsere Probleme auf magische Weise löst.

Ich hoffe, dass bei meiner Session für REST-Liebhaber und -Gegner etwas dabei ist. Erstere können dann vielleicht die Session mit der Überzeugung verlassen, dass GraphQL nichts für sie ist und Letztere finden eventuell endlich das Tool ihrer Wahl.

In der täglichen Arbeit als Entwickler und Architekt muss man oft Entscheidungen für eine Technologie treffen. Wichtig ist nicht selten aber auch die fundierte Entscheidung gegen eine Technologie. Ich hoffe, dass meine Session etwas zur Entscheidungsfindung beitragen kann – für oder gegen GraphQL – beides ist ein legitimer und wichtiger Output.

Interviewt von: Dominik Mohilo

Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.

The post „GraphQL ist gut, aber keine Alternative zu echten REST-Services“ appeared first on MobileTechCon.

Durch Spracherkennungstechnologien werden Diktate automatisiert, Videos und Audiofiles textdurchsuchbar, Navigationsgeräte, Smartphones und die Websuche leicht steuerbar. In der Session „Smartphones getting smarter: Automatische Spracherkennung auf dem Weg in die Praxis“ stellte Prof. Dr.-Ing. Dorothea Kolossa (Ruhr-Universität Bochum) auf der MobileTech Conference 2016 stellt die Grundlagen von Spracherkennungssystemen vor.

Dabei blickt sie auf die aktuellen Methoden der Deep Neural Networks, diskutiert die Anbindung von Spracherkennungs-Apps, Software Development Kits und Hardwarelösungen, beleuchtet die Grenzen der Technologie in Bezug auf Privacy-Fragen und zeigt den aktuellen Stand der Forschung zur robusten Sprachsteuerung auch unter schwierigsten akustischen Bedingungen.

Auch auf der MobileTech Conference / Internet of Things Conference 2017 in München erwarten die Teilnehmer Sessions zu den Themenbereichen Spracherkennung, Bots und Deep Neural Networks. So demonstriert Dominik Helleberg (inovex GmbH) in seiner Session „Sprachsteuerung mit dem Google Assistant – Add a new User Interface to your product“ anhand von Google Home/Assistant die prinzipielle Funktionsweise einer Sprachsteuerung und ihre Vergleichbarkeit mit Chatbots.

Dean Bryen, Technology Evangelist für Amazon Alexa, stellt in der Session „Enabling Voice-driven Smart Home Experiences with Amazon Alexa“ Amazons Sprachassistentin und ihre neuesten Features vor und wirft einen Blick auf das Smart Home Skills API.

Und in der Session „Tiefes Lernen und die breiten Möglichkeiten intelligenter mobiler Anwendungen“ nimmt Sie Prof. Dr. Björn Schuller (Universität Passau) mit auf einen Kurztrip durch das Universum tiefer neuronaler Verfahren, bei dem er mit den Teilnehmern entsprechende Methoden und Möglichkeiten erkundet. Wie tief werden mobile Endgeräte bald denken?

The post Smart Home, Smartphones und Spracherkennung – So funktionieren Alexa, Cortana, Siri & Co. appeared first on MobileTechCon.

Insbesondere bei denjenigen, die AMP in ihre Seiten integrieren wollen, gibt es viele Fragezeichen. Doch man muss kein Hellseher sein: Allein aufgrund der Tatsache, dass Google in Zukunft den Mobile Index als Hauptindex für seine Suchergebnisrankings heranziehen wird, gibt einen Vorgeschmack auf die große Rolle, die AMP zukünftig spielen wird.

Auch im Bereich der Progressive Web Apps kann AMP zu einem entscheidenden Technologiefaktor werden, sodass diese Technologie auch bei Apps immer bedeutender werden wird.

Allerdings sind die technischen Einschränkungen von AMP gegenüber HTML immer noch groß. Eine Umsetzung von AMP-Seiten ist aufwendig.

Thomas Kaiser (cyberpromote GmbH) hat sich sehr genau mit AMP und der dahinter steckenden Technologie beschäftigt.

Auf der MobileTech Conference gibt er in der Session “Mobile First mit Accelerated Mobile Pages: Fluch und Segen für Entwickler und SEO” im März in München sein Wissen an die Teilnehmer weiter und beantwortet Fragen nach der optimalen Umsetzung, nach potenziellen Problemen und der besten Herangehensweise.

Wir haben mit Thomas Kaiser im Vorfeld über AMP gesprochen und ihn unter anderem gefragt, was man als Entwickler beachten sollte, was besonders neuralgische Punkte der Technologie sind und welche Auswirkungen AMP auf SEO hat und haben wird.

Anwendung und Integration von AMP

Herr Kaiser, über Performance im Netz wird viel geredet – gerade, wenn es um die Performance des Webs auf Mobile Devices geht. AMP wird von Google entsprechend gepusht. Was sollte man als Webentwickler unbedingt beachten, bevor man versucht, AMP auf der eigenen Seite zu integrieren?

Thomas Kaiser: Man sollte wissen, dass sich AMP noch in der Entwicklung befindet und die Umsetzung sehr komplex ist. Das Umwandeln eines HTML-Templates in ein AMP-Template ist sehr frustrierend. Man kann auf ein einfaches Standard-AMP-Template zurückgreifen, aber das ist keine gute Lösung. Denn man möchte die Besucher dann auch auf der Website halten. Daher sind vollständige Navigation, eine Suche und vieles mehr sinnvoll. Abgesehen von einem Corporate Design, das man auch haben möchte. Das Umwandeln kann aber durchaus ein paar Tage Zeit beanspruchen! Fertige Lösungen gibt es nur wenige, und die sind bisher nur begrenzt brauchbar.

AMP berührt potenziell zahlreiche Abteilungen in einem Unternehmen, von den Entwicklern über Marketing bis hin zu Analytics/Monitoring. Wo sehen Sie besonders neuralgische Punkte?

Thomas Kaiser: Die Entwicklung ist enorm aufwändig, was der Rest im Unternehmen meistens nicht versteht. Aber AMP ist ein eigenes, neues, anderes HTML. Analytics lässt sich schon für einige Systeme integrieren (für Google Analytics gibt es eine Lösung), man sollte bei seinem Anbieter Druck machen, dass er eine Standardlösung bereitstellt. Es kann mit der Extension amp-analytics integriert werden. Es wäre aber gut, wenn der Anbieter da schon ein Vorgehen vorgibt, welches funktioniert. Denn das Tracking ist wichtig, um den Erfolg messen zu können. Das Marketing muss begreifen, dass wir nun tatsächlich vor einer Revolution stehen. Der Wandel hin zu einer mobilen Welt hat dramatische Auswirkungen und das Marketing muss sich dem stellen. Zu oft bewegt man sich noch in der Desktop Welt und DIN A4 Welt, aber die Nutzer leben bereits schon heute in der Mehrheit in einer mobilen Welt. Und mit mobil sind Smartphones gemeint, keine Tablets.

Welche Probleme können bei der AMP-Umsetzung auftreten, und wie sollten Websites und Shops das Problem angehen?

Thomas Kaiser: Das Problem sind die Einschränkungen. Viele Funktionen sind nicht möglich oder müssen komplett neu umgesetzt werden. Schon eine Suchfunktion ist kompliziert zu integrieren. Möchte man aber AMP als Landingpage verstehen, die Nutzer auf die Website bringt, müssen die AMP-Seiten auch mehr bieten als ein Logo und einen Text mit Links. Die schlechten Erfahrungen mit AMP basieren darauf, dass man die AMP-Seiten mit minimalem Funktionsumfang umgesetzt hat und Besucher in einer Sackgasse landen. Zudem muss man begreifen, dass die AMP-Seiten nur eine Landingpage in die Website hinein sind. Wenn diese dann mit deutlich schlechterer Ladezeit den Nutzer vergraulen, verspielt man einen großen Vorteil durch AMP. Die Ladezeit sollte man für mobile Geräte mit schlechtem Empfang optimieren. Hier sind ganz neue Ansätze erforderlich, die eine Anpassung von Seiten, Bildern und anderen Ressourcen für mobile Geräte erfordern. Daher sollte man aus AMP auch in der Hinsicht lernen und das Framework für die Funktionalität auf den mobilen Seiten und den Desktopseiten nutzen.

Es gibt auch einige fertige Plugins, um AMP für die eigene Seite verfügbar zu machen. Was halten Sie von solchen Lösungen?

Thomas Kaiser: Diese bieten keine Umsetzung eines Corporate Designs und sind oftmals auf bestimmte Dokumente beschränkt. Wer vergisst, das Impressum im Footer zu verlinken, läuft Gefahr, eine Abmahnung zu kassieren. Daher sind diese Lösung nur als Krücke für Experimente geeignet. Aber nicht, um AMP als strategische Maßnahme zu integrieren. Ein Automatismus, HTML-Templates in AMP-Templates umzuwandeln, ist technisch extrem schwer, wenn nicht sogar unmöglich. Daher sollte man nicht darauf hoffen, dass es 2017 fertige Lösungen geben wird. Es gibt bis heute beispielsweise keine Liste an Tag-Attributen, die bei AMP nicht erlaubt sind bzw. durch andere Attribute ersetzt werde müssen.

AMP und SEO

In puncto SEO zeichnet sich ab, dass eine frühe Integration von AMP von Vorteil sein könnte. Google selbst hat auf der Pubcon in Las Vegas angekündigt, dass der Mobile Index den Desktop Index als Hauptindex ablösen wird. Ist AMP damit zu einem klaren Muss geworden?

Thomas Kaiser: Ich würde sagen, Mobile Friendly ist ein Muss, denn das haben immer noch einige Unternehmen nicht umgesetzt. AMP ist aber ebenfalls ein Muss, denn es wird sich 2017 deutlich verbreiten und ein Standard werden. Ich gehe sogar so weit zu sagen, AMP wird ein Standard-Framework für mobile Seiten. Und wer sagt, dass AMP nicht auch für den Desktop funktioniert? Denn technisch wäre das möglich. Auch wenn Google nicht nur das ganze Internet indexiert, sondern nun auch cachen will, und man darüber besorgt sein kann: Wer da nicht mitmacht, wird bald den Kürzeren ziehen. Mittlerweile sind auch die Bilder von AMP-Seiten in der Bildersuche zu finden, sprich AMP wird in den nächsten Monaten immer sichtbarer werden. Progressive Web Apps sind hier nur ein weiterer Aspekt. Daher ist der Begriff „Revolution“ sicher nicht falsch. Ich bin nun seit 20 Jahren im SEO-Business, und es wurde schon vieles geschrieben. Wie oft ist SEO schon für tot erklärt worden. Nun ist SEO zu einem wesentlichen Antrieb für Technologie geworden, und zum ersten Mal in diesen 20 Jahren würde ich wirklich von einer großen Änderung sprechen, die massive Auswirkungen haben wird. Es gibt viel zu tun, und das in verdammt kurzer Zeit. Dumm nur, dass es noch keinen Plan gibt. Denn der ist für jedes Unternehmen, jedes CMS und Shopsystem anders. Es ist also nicht ein rein technisches Problem, sondern auch ein strategisches. Das muss von oben ausgelebt und gesteuert werden, sonst könnte es schief gehen. Leider bleibt es hier wohl an den Technikern hängen, dass die eine scheinbar „technisch Herausforderung“ als strategische Aufgabe nach oben delegieren.

The post Accelerated Mobile Pages: Fluch und Segen für Entwickler und SEO appeared first on MobileTechCon.