WEBVTT

00:00.000 --> 00:09.180
Hallo zusammen, wir sind Immi, Pascal, Malte, Marco, Lasse und ich bin die Kathleen.

00:10.000 --> 00:14.460
Wir sind Studenten aus dem sechsten Semester mobile Medien und Medieninformatik.

00:15.000 --> 00:20.320
Bei unserem Projekt ging es um die Erstellung eines App-Prototypen für die Restaurantkette Mauritius.

00:20.860 --> 00:25.120
Auf der Folie könnt ihr auch das Logo sehen von Mauritius, vielleicht kennt es ja der ein oder andere von euch auch.

00:25.120 --> 00:32.940
Nun ein paar Worte zum Projekt allgemein.

00:33.500 --> 00:34.580
Wie entstand das Projekt?

00:35.140 --> 00:39.180
Also schon am Anfang des Semesters haben wir uns dazu entschieden, zusammenzuarbeiten,

00:40.140 --> 00:42.200
da wir ein ganz gutes Team bilden.

00:42.300 --> 00:47.740
Wir haben Frontend-Entwickler, Backend-Entwickler und jemanden aus der Konzeption und aus dem Management.

00:48.740 --> 00:51.020
Dann hat uns eigentlich nur noch ein passendes Projekt gefehlt

00:51.020 --> 00:56.680
und dann haben wir Mauritius entdeckt und haben uns sofort dafür entschieden,

00:57.220 --> 01:01.560
weil es uns gereizt hat, eben zusammen mal mit einem echten Kunden zusammenzuarbeiten

01:01.560 --> 01:04.940
und weil wir natürlich schon Erfahrungen haben in der App-Entwicklung.

01:06.120 --> 01:07.520
Dann zum Projektablauf.

01:07.800 --> 01:12.120
Wir haben uns einmal in der Woche mit dem Projektvermittler mal kurz getroffen,

01:12.260 --> 01:14.460
der stellvertretend für Mauritius agiert hat.

01:14.460 --> 01:18.960
Mit ihm haben wir dann alles weitere besprochen, wie der Projektablauf ist,

01:18.960 --> 01:24.580
was gefordert wird und er hat uns auch die Ressourcen zur Verfügung gestellt, Bilder, Informationen.

01:25.460 --> 01:29.900
Später ist dann auch noch der Geschäftsführer von der Mauritius Marketing GmbH dazugekommen,

01:30.020 --> 01:32.080
Daniel Mewis, und hat uns auch noch unterstützt.

01:33.300 --> 01:40.500
Die Projektorganisation und Kommunikation ging über Jira, Slack, Google Drive und die Dropbox.

01:41.240 --> 01:46.260
Was für Probleme traten auch während des Projekts, natürlich gab es klassische Kommunikationsprobleme,

01:46.260 --> 01:49.120
wie bei jedem anderen Projekt auch, aber es war nichts weiter Schlimmes.

01:49.560 --> 01:53.720
Es kam zu Verzögerungen, weil wir natürlich abhängig waren von den Ressourcen,

01:54.340 --> 01:56.000
die uns der Kunde zukommen lassen sollte,

01:56.460 --> 01:59.920
aber im Großen und Ganzen haben wir alles nach dem Projektplan noch geschafft.

02:01.500 --> 02:05.100
Jetzt kommen wir zu den Anforderungen.

02:05.280 --> 02:08.720
Hier könnt ihr die Pflichtfeatures sehen, die wir umsetzen sollten.

02:08.720 --> 02:12.100
Da wäre einmal das Feature nächstes Mauritius.

02:12.100 --> 02:17.100
Das ist einfach eine Anzeige von allen Standorten der verschiedenen Mauritius-Restaurants.

02:17.780 --> 02:24.020
Dann kann der Kunde sich auch noch hinnavigieren lassen, da wir Google Maps und Apple Maps eingebunden haben.

02:24.640 --> 02:28.120
Dann gibt es noch die Cocktail-, die Getränkekarte und die Speisekarte.

02:29.580 --> 02:35.360
Da kann der Nutzer dann praktisch schon vorher entscheiden, was er essen und trinken will im Mauritius.

02:36.020 --> 02:39.920
Bei den Getränken kann man sogar auswählen, welche Größe man haben möchte.

02:39.920 --> 02:41.400
Dann ändert sich der Preis in der App.

02:42.100 --> 02:44.640
Dann das wichtigste Feature war die Stempelkarte.

02:45.680 --> 02:52.920
Durch einen integrierten QR-Code-Scanner kann der Nutzer praktisch einen QR-Code-Scanner und dadurch einen virtuellen Stempel sammeln.

02:53.020 --> 02:54.660
Bei uns war das eine Palme.

02:55.240 --> 02:58.640
Und wenn er dann fünf Palmen gesammelt hat, erhält er eine Überraschung.

02:58.640 --> 03:02.660
Aber er kann halt nur einen QR-Code-Scanner, wenn er sich in Mauritius befindet.

03:02.840 --> 03:05.540
Da haben wir dann das Ganze mit Geofences realisiert.

03:06.200 --> 03:08.480
Und dann gibt es noch das Feature Aktionen.

03:08.480 --> 03:18.780
Wenn es etwas Neues gibt bei Mauritius, zum Beispiel ein gratis Kaffee zum Mittagessen, dann bekommt der Nutzer gleich eine Push-Notification und ist somit immer top informiert.

03:19.840 --> 03:26.760
Das waren die Pflichtfeatures, die wir umsetzen mussten und jetzt erhaltet ihr einen kleinen Einblick in die App und in unser Video.

03:38.480 --> 04:08.460
Vielen Dank.

04:08.480 --> 04:10.480
Amen.

04:38.480 --> 04:43.660
aber

04:43.660 --> 04:49.900
nein

05:13.660 --> 05:15.620
gerag perceieren

05:15.620 --> 05:22.180
an

06:15.620 --> 06:17.540
auf

06:45.620 --> 07:13.620
Applaus

07:13.620 --> 07:18.360
So, nachdem ihr die App jetzt schon ein bisschen kennt, werde ich euch jetzt vorstellen, wie wir darauf gekommen sind überhaupt,

07:18.480 --> 07:20.800
wie wir alle Screens irgendwie gefunden haben in der Konzeption.

07:21.100 --> 07:24.260
Da hatten wir drei große Phasen. Einmal haben wir mit Papierscribbles angefangen.

07:24.840 --> 07:27.200
Dann haben wir erste interaktive Wireframes gebaut in Exure.

07:27.720 --> 07:32.260
Und später haben wir dann Designs mit den Wireframes vereint und dann Mockups generiert, die dann umgesetzt wurden.

07:33.860 --> 07:37.040
So, die erstmal noch die allgemeinen Anforderungen an das Konzept.

07:37.900 --> 07:40.900
Es mussten natürlich erstmal alle Features und alle Screens irgendwie definiert werden.

07:41.480 --> 07:43.660
Die ganzen Funktionsverhalten mussten definiert werden.

07:43.880 --> 07:46.100
Welche Funktion ist wo zu finden und wie sieht sie später aus?

07:47.000 --> 07:49.860
Und das Ganze sollte praktisch später dann die Bauvorlage für die Entwickler sein.

07:51.620 --> 07:55.780
Die Anforderungen an das Konzept selbst waren, dass dann auf jeden Fall native Elemente zu finden sind.

07:55.900 --> 07:59.960
Also dass iOS und Android sich irgendwie nativ anfühlt für die beiden Plattformen.

08:00.580 --> 08:02.040
Die Usability muss gegeben sein.

08:02.720 --> 08:05.000
Und das Ganze muss später natürlich auch ein bisschen nach Mauritius aussehen.

08:05.000 --> 08:08.060
Soll da keine total nackte App irgendwie später sein.

08:08.060 --> 08:11.960
Deshalb noch mit den Corporate-Farben versehen und Fonts anpassen und so weiter.

08:12.800 --> 08:16.840
Und natürlich muss das Ganze noch umsetzbar sein im Rahmen von einem studentischen Projekt.

08:18.900 --> 08:20.500
So, zum ersten Schritt die Papierskribbles.

08:20.780 --> 08:23.660
Das sieht man jetzt hier mal exemplarisch im kleinen Skribble.

08:24.980 --> 08:28.000
Da wurde jetzt noch keine Differenzierung zwischen Android und iOS gemacht.

08:28.320 --> 08:31.140
Da wurde jetzt einfach nur mal ganz grob definiert, wo ist welche Funktion.

08:32.260 --> 08:34.100
Wie sieht die Kundennavigation aus der App?

08:34.180 --> 08:35.840
Wie sind die Screens hintereinander aufgelistet?

08:35.840 --> 08:38.760
und wie gesagt, wie man jetzt auch hier ganz gut sehen kann,

08:39.120 --> 08:40.580
noch keinen Wert auf die Ästhetik gelegt.

08:43.300 --> 08:45.360
Im nächsten Schritt, den interaktiven Wireframes,

08:45.480 --> 08:48.000
wurde das dann wie bereits erwähnt mit Exure umgesetzt,

08:48.460 --> 08:51.440
was den großen Vorteil hat, dass die dann auch gehostet werden können.

08:52.100 --> 08:54.420
Das heißt, man kann das erste Mal dann praktisch auch auf dem Gerät,

08:54.480 --> 08:56.940
auf dem nativen Smartphone das Ganze mal bedienen,

08:57.620 --> 08:59.520
weil das ist immer was ganz anderes, wenn man es auf dem Handy hat,

08:59.520 --> 09:02.280
dann findet man immer noch mal Fehler, die man auf dem PC noch nicht gefunden hatte

09:02.280 --> 09:06.540
und man kann dann eben das Ganze auch ganz gut dem Kunden dann vorstellen,

09:07.020 --> 09:11.160
dass der Kunde mal später sein Produkt anfassen kann wirklich und testen kann,

09:11.840 --> 09:12.980
ist das denn gut so für ihn.

09:14.160 --> 09:17.780
Gleichzeitig haben wir dann auch mit der Implementierung begonnen.

09:19.920 --> 09:23.120
Im nächsten Schritt haben wir dann die Wireframes noch mit Designs versehen.

09:23.800 --> 09:26.780
Dabei haben wir dann auch wieder getrennte Designs verwendet für iOS und für Android.

09:28.500 --> 09:30.980
Dafür haben wir das Tool Sketch benutzt, also ein Vektorprogramm.

09:32.280 --> 09:33.860
Und dann haben wir eben, wie man jetzt hier schon sieht,

09:33.940 --> 09:35.620
dann praktisch die Corporate-Farben eingebracht,

09:35.840 --> 09:39.540
die Fonts und alle Grafiken und Icons angepasst.

09:40.320 --> 09:43.900
Dabei war eine große Herausforderung das Ausspielen der Grafiken für die beiden Entwickler.

09:45.020 --> 09:46.780
Hatten wir nämlich bisher noch keine Erfahrung damit.

09:47.260 --> 09:50.880
Und zwar haben Android und iOS, wie ihr bestimmt alle wisst, verschiedene Resolutions.

09:51.160 --> 09:54.640
Bei Android sind es fünf Stück an der Zahl, wegen der ganzen Gerätevielfalt.

09:55.240 --> 09:56.500
Und bei iOS drei Stück.

09:56.820 --> 09:59.320
Da mussten wir recht lang rumkniffeln, haben mit Plugins rumgespielt,

09:59.440 --> 10:00.940
aber haben es dann am Ende noch gemeistert.

10:02.280 --> 10:05.740
Genau, das war es von mir. Ich übergebe jetzt an die Entwicklung.

10:07.680 --> 10:12.260
Danke. Ja, zum Frontend wollen wir jetzt gar nicht so viel sagen, deswegen nur mal kurz die Eckdaten.

10:12.260 --> 10:23.420
Bei der Android-App haben wir zur Datenspeicherung die Shared Preferences für die Versionierung und die JSON-Files in den internen Speicher reingelegt.

10:24.040 --> 10:26.940
Zur Serverkommunikation haben wir das Path-Framework verwendet.

10:27.580 --> 10:30.740
Für das User-Interface haben wir standardmäßig XMLs verwendet.

10:31.740 --> 10:38.020
Die App ist optimiert für Android-Smartphones, läuft aber auch auf Tablets und funktioniert ab Android 4.0.

10:38.620 --> 10:44.580
Bei der iOS-App, selbes Spielchen, damit zur Datenspeicherung NS-User-Defaults und den NS-File-Manager benutzt.

10:44.580 --> 10:50.900
Zur Serverkommunikation nutzen wir auch das Path-Framework, das User-Interface.

10:52.360 --> 10:57.120
Da haben wir uns entgegen dem Storyboard für einzelne XIB-Files, für jeden View-Controller entschieden,

10:57.120 --> 11:02.900
weil das Storyboard einfach mit sehr vielen Views einfach sehr langsam wird und es einfach nicht mehr Spaß macht.

11:04.240 --> 11:09.220
Die App ist auch optimiert für iPhones, läuft aber ebenso auf iPads und funktioniert ab iOS 7.0.

11:10.180 --> 11:12.140
Und jetzt gebe ich weiter ans Backend.

11:14.560 --> 11:19.600
Dankeschön. Also beim Backend, wir hätten das Backend auch komplett selber entwickeln können.

11:19.840 --> 11:23.700
Wir haben uns allerdings dafür entschieden, dass wir ein Backend-as-a-Service nutzen.

11:23.700 --> 11:29.000
Da haben wir uns für PaaS entschieden. Es gibt mehrere verschiedene Backend-as-a-Service-Dienste.

11:29.900 --> 11:35.140
Man kann sich Backend-as-a-Service so vorstellen, dass es im Endeffekt eine Datenbank ist,

11:35.280 --> 11:40.280
die man über eine Web-Oberfläche zugreifbar hat, die einem schon ein REST-Interface anbietet.

11:40.480 --> 11:47.440
Also man muss das Rad quasi nicht neu erfinden und man kann einfach viel schneller die Daten dann in einem Backend verfügbar machen.

11:47.440 --> 11:58.780
Genau, jetzt sieht man hier mal die Übersicht von PaaS. Links sieht man die Klassen, in denen die Daten abgelegt werden.

12:01.160 --> 12:05.940
Genau, und rechts sieht man dann auch so eine Möglichkeit, dass man auswerten kann. Also so Analysen kann man fahren.

12:06.020 --> 12:12.640
Man kann sehen, welche Geräte drauf zugegriffen haben aufs Backend, wie häufig drauf zugegriffen wurde, etc.

12:12.640 --> 12:23.740
Da wir mit einem Kunden arbeiten, also mit dem Mauritius, war uns wichtig, dass wir im Backend eine sichere Technologie nutzen.

12:24.360 --> 12:31.080
Weil was eigenentwickelt ist, da sicherzustellen, dass es erstens mal sicher ist und robust läuft, ist eben nicht so einfach.

12:31.640 --> 12:39.040
Deswegen haben wir uns für PaaS entschieden, weil es ist von einem externen Dienstleister, der die Sicherheit überwacht.

12:39.440 --> 12:42.220
Die Servers sind robust, also sie sind hoch verfügbar.

12:42.640 --> 12:48.220
Eben wie ich schon erwähnte, das Rad muss nicht neu erfunden werden, dadurch haben wir eine schnellere Entwicklung.

12:49.040 --> 12:51.660
Und es gibt schon fertige Features, die wir auch benötigt haben.

12:51.880 --> 12:56.240
Unter anderem das Push, aber auch die Trigger-Funktion, die Malte nachher noch erklären wird.

12:57.120 --> 13:01.780
Und was eben auch ganz schön ist für die Web-Oberfläche oder für den Kunde,

13:02.080 --> 13:05.420
wir haben eine fertige Web-Oberfläche, in der er eben die Daten pflegen kann.

13:06.040 --> 13:08.360
Und somit braucht er niemand von uns Backend-Entwicklern,

13:08.360 --> 13:10.360
sollte er mal zum Beispiel die Öffnungszeiten

13:10.360 --> 13:12.180
von dem Mauritius ändern möchten oder

13:12.180 --> 13:13.840
also er kann das quasi selber

13:13.840 --> 13:16.320
bedienen und das ist schon ein großer

13:16.320 --> 13:18.420
Vorteil, denke ich. So, dann

13:18.420 --> 13:19.420
übergebe ich jetzt an Malte.

13:21.220 --> 13:22.420
Ich werde ein bisschen was zur

13:22.420 --> 13:24.520
Datenhaltung und zur Versionierung in PaaS sagen.

13:25.020 --> 13:26.120
Wie der Emi schon gesagt hat,

13:26.400 --> 13:28.000
die Daten, äh die Klassen,

13:28.860 --> 13:30.400
es sind in Klassen organisierte

13:30.400 --> 13:32.440
Daten, so eine Klasse ist eigentlich

13:32.440 --> 13:34.380
nichts anderes als eine Tabelle, es heißt halt nur

13:34.380 --> 13:36.540
in PaaS so. Die Daten

13:36.540 --> 13:38.500
selber kommen aus einer JSON-Datei und werden

13:38.500 --> 13:40.080
über die Web-Oberfläche in Parse

13:40.080 --> 13:42.380
einfach importiert. Das geht ganz einfach

13:42.380 --> 13:44.560
per Drag & Drop. Muss natürlich dann

13:44.560 --> 13:46.060
dementsprechend auch vorbereitet sein,

13:46.720 --> 13:48.500
dass es dann am Ende so eine schöne Tabelle gibt

13:48.500 --> 13:50.440
wie die hier. Ich werde jetzt nicht auf

13:50.440 --> 13:52.580
alles eingehen, aber zwei Sachen will ich sagen.

13:52.700 --> 13:54.700
Die Spalte Articles, da sind die eigentlichen

13:54.700 --> 13:55.460
Nutzdaten drin.

13:56.340 --> 13:58.500
Die sind in Form von einem String,

13:58.500 --> 13:59.880
der aufgebaut ist wie ein JSON.

14:00.340 --> 14:02.460
Und die Jungs vom Frontend können sich den dann ziehen,

14:02.680 --> 14:04.520
bekommen ein Parse-Objekt zurück und können damit

14:04.520 --> 14:05.320
weiterarbeiten.

14:06.200 --> 14:09.900
Außerdem, die Spalte ganz rechts ist die Version Ink.

14:11.760 --> 14:19.200
Die ist dafür da, dass die Kategorien, die Versionen der Kategorien inkrementiert werden

14:19.200 --> 14:23.360
in einer Funktion, die im Cloud-Code ausgeführt wird.

14:25.640 --> 14:28.280
Die Version selber steht jetzt hier in der Klasse nicht drin.

14:28.600 --> 14:32.920
Das liegt daran, dass wir eine eigene Klasse für Versionen haben, die Klasse Versions.

14:33.180 --> 14:34.680
Da sind die zentral gespeichert.

14:35.320 --> 14:41.440
Wir machen das deshalb, weil wir wollen, dass die Daten auf den Endgeräten immer aktuell bleiben,

14:42.100 --> 14:46.700
aber deshalb nicht wollen, dass man, wenn man sich die Speisekarte anguckt oder die Getränkekarte,

14:47.520 --> 14:50.540
dass man jedes Mal sich die per Request holen muss.

14:50.640 --> 14:55.400
Das würde einfach nur Traffic verursachen und würde den ganzen Prozess auch ein bisschen verlangsamen, also Wartezeiten.

14:56.380 --> 14:58.540
Deshalb die Geschichte mit den Versionen.

14:59.020 --> 15:03.040
Das ist nämlich so gedacht, dass die eigentlichen Nutzdaten lokal in der App gespeichert sind.

15:03.720 --> 15:07.060
Wir müssen aber trotzdem dafür sorgen, dass sie immer aktuell bleiben.

15:07.700 --> 15:11.300
Das heißt, bei App-Start wird geguckt, sind die Versionen der Klassen aktuell.

15:11.300 --> 15:17.460
Wenn ja, passt alles und wenn nicht, dann ziehe ich mir gegebenenfalls die aktuellen Klassen runter.

15:18.260 --> 15:22.120
Wenn man jetzt diese Version-Ink-Variable false, also ein Boolean von false auf true setzt,

15:22.220 --> 15:24.480
dann wird folgende Cloud-Code-Funktion getriggert.

15:25.500 --> 15:30.180
Cloud-Code erstmal läuft serverseitig, spart also auch Ressourcen auf dem Endgerät.

15:30.180 --> 15:32.700
gut zugegeben, die ist jetzt nicht besonders

15:32.700 --> 15:34.780
komplex, aber wir wollten es einfach auch mal ausprobieren.

15:35.120 --> 15:36.720
Also es hat jetzt nicht unbedingt

15:36.720 --> 15:38.740
dient jetzt nicht unbedingt

15:38.740 --> 15:40.860
dazu, dass das Gerät

15:40.860 --> 15:42.340
vom Nutzer nicht verlangsamt wird,

15:42.700 --> 15:44.600
sondern einfach, weil wir ein bisschen damit rumspielen wollten,

15:44.720 --> 15:46.680
sage ich mal. Wenn jetzt jemand

15:46.680 --> 15:48.260
was in einer Klasse ändert,

15:48.880 --> 15:50.780
dann will er ja auch, dass der Nutzer

15:50.780 --> 15:52.660
das angezeigt bekommt. Und dafür muss

15:52.660 --> 15:54.920
er dann eben diese Version Ink

15:54.920 --> 15:56.580
den Version Ink Bool auf

15:56.580 --> 15:58.780
True setzen. Damit wird jetzt ganz kurz

15:58.780 --> 16:01.200
hier in Schritt 1 geguckt, ist sie auf true,

16:01.260 --> 16:03.300
wenn ja, gut, dann geht die Funktion weiter,

16:03.400 --> 16:05.460
wenn nicht, dann ist sie halt an der Stelle schon auch wieder beendet.

16:06.020 --> 16:06.720
In Schritt 2

16:06.720 --> 16:09.480
wird sich die jeweilige Version der Klasse geholt,

16:09.700 --> 16:11.480
wird in eine Variable gespeichert und um 1

16:11.480 --> 16:12.980
erhöht und in Schritt 3

16:12.980 --> 16:15.280
über den alten Wert gespeichert und damit hat sich

16:15.280 --> 16:16.500
die Version um 1 inkrementiert.

16:17.100 --> 16:17.980
Also es ist ganz einfach,

16:19.080 --> 16:21.140
aber damit ist eben erreicht, dass beim nächsten

16:21.140 --> 16:22.600
App-Start geguckt wird

16:22.600 --> 16:25.240
und in dem Fall wäre jetzt halt die Klasse food,

16:25.440 --> 16:26.860
also das spricht ja die Klasse food an,

16:27.300 --> 16:31.320
wäre um 1 erhöht und das würde die App merken und sehen,

16:31.480 --> 16:33.840
online gibt es eine neuere Version als das, was ich lokal habe,

16:33.920 --> 16:36.640
also ziehe ich mir die Klasse Food neu runter und ich habe die neuen Daten.

16:37.660 --> 16:39.300
Genau, das war es auch schon wieder.

16:39.960 --> 16:41.300
Und noch ein paar abschließende Worte.

16:42.280 --> 16:44.320
Genau, also zusammenfassend können wir sagen,

16:44.500 --> 16:46.840
dass wir sehr viel aus den Projekten lernen konnten.

16:47.420 --> 16:49.820
Gerade eben die Einarbeitung und die Vertiefung durch PaaS

16:49.820 --> 16:53.740
und eben für uns nochmal von den Entwicklern eine deutliche Vertiefung in die beiden Apps.

16:53.740 --> 16:56.820
dann natürlich die Arbeit mit einem Kunden, was wir

16:56.820 --> 16:58.940
davor noch nie hatten und wir dabei auch merken

16:58.940 --> 17:01.080
konnten, wie schwierig es einfach ist, dass ich ein Team

17:01.080 --> 17:02.820
mit einem Kunden irgendwie zeitlich

17:02.820 --> 17:04.940
so absprechen kann, dass

17:04.940 --> 17:07.040
einfach alles reibungslos läuft, weil das haben wir eigentlich fast nie

17:07.040 --> 17:08.340
hinbekommen, aber trotzdem

17:08.340 --> 17:10.480
alles irgendwie durchbekommen

17:10.480 --> 17:13.200
und zum heutigen Stand

17:13.200 --> 17:15.100
sieht es so aus,

17:15.160 --> 17:16.960
dass wir eben zwei lauffähige Apps haben, in denen

17:16.960 --> 17:18.920
wir großes Potenzial sehen und

17:18.920 --> 17:20.920
wir uns persönlich auch sehr freuen werden,

17:21.020 --> 17:22.840
wenn wir die Apps mal in den App-Stores

17:22.840 --> 17:23.680
wiederfinden könnten.

17:25.140 --> 17:26.840
Genau, das war es von uns.

17:27.260 --> 17:28.800
Danke für eure Aufmerksamkeit und

17:28.800 --> 17:29.780
habt ihr noch welche Fragen?

17:41.360 --> 17:43.120
Ich habe mir angeguckt,

17:43.200 --> 17:44.640
was die Anforderungen waren,

17:44.760 --> 17:46.140
die Hauptfunktionen.

17:46.620 --> 17:49.020
Da ist ja eigentlich bis auf das Design

17:49.020 --> 17:50.920
und den Datenkanal, über den die

17:50.920 --> 17:52.500
Speise- und Getränkekarten rüberkommen,

17:52.840 --> 18:00.520
Überhaupt nichts Spezifisches von Mauritius. Das könnte ja praktisch jeder Laden auf der Königstraße, jeder Laden im Dorf eigentlich genau das gleiche Ding brauchen.

18:00.980 --> 18:01.420
Das ist richtig.

18:01.460 --> 18:06.120
Da stellen sich doch eigentlich zwei Fragen. Erstens, warum machen Sie nicht sofort daraus ein Geschäft und bieten das an?

18:06.720 --> 18:14.580
Und zweitens, müsste man da nicht einfach eigentlich da noch irgendwie so eine Content-Management-Schicht dazwischen ziehen, wo man an der App gar nicht mehr viel macht?

18:14.580 --> 18:18.560
vielleicht nicht nur Backend-as-a-Service, sondern auch App-as-a-Service anbietet

18:18.560 --> 18:22.820
und dann einfach nur immer reinspielt, was der jeweilige Ladengrad braucht,

18:22.880 --> 18:24.120
aus einem kleinen Baukasten raus.

18:24.820 --> 18:30.900
Also ist es tatsächlich so, dass eine Kette wie Mauritius jetzt wirklich davon profitiert,

18:30.980 --> 18:32.680
dass sie sich da eine eigene App machen lässt?

18:35.820 --> 18:40.320
Ich denke halt, dass es durch die Möglichkeit, dass wir das Projekt gemacht haben,

18:40.760 --> 18:42.800
für sie sich schon lohnt im Endeffekt.

18:42.800 --> 18:46.140
Ja, weil, also kann man verstehen, denke ich mal.

18:47.180 --> 18:50.920
Aber der erste Punkt, den Sie angesprochen haben, darüber haben wir uns natürlich auch Gedanken gemacht.

18:51.020 --> 18:57.380
Im Endeffekt ist das wirklich dann ein Baukasten, den mehr oder weniger jede Kette oder vielleicht sogar jedes Rohr benutzen könnte.

18:58.000 --> 19:06.420
Und wir machen uns da schon Gedanken drüber und haben uns da schon überlegt, ob wir nicht doch das weiterführen und gucken, dass wir selber ein bisschen akquirieren, wie auch immer.

19:06.960 --> 19:11.020
Und mal an den Kundenrand treten, an andere Kundenrand treten und das Ganze eben weiterführen.

19:11.020 --> 19:14.300
Das ist schon so ein Plan, ist jetzt halt noch in den Kinderschuhen.

19:14.480 --> 19:16.200
Also wir denken auf jeden Fall darüber nach.

19:27.580 --> 19:28.360
Weitere Fragen?

19:30.220 --> 19:30.800
Na, eine.

19:32.800 --> 19:37.640
Ganz schnell die Frage, welche Tools haben Sie denn für das Ausspielen der Grafik jetzt verwendet im Endeffekt?

19:37.640 --> 20:06.140
Also im Endeffekt haben wir dann auch Sketch benutzt, haben dann verschiedene Plugins benutzt. Pascal, weißt du noch wie das eine heißt? Das waren praktisch Third-Party Plugins. Aus Sketch heraus dann. Aus Sketch heraus, genau. Wobei, also die iOS-Version haben wir sogar direkt mit Sketch definiert, weil man dann praktisch die verschiedenen Outputs direkt als Export angeben kann. Also iOS ist mit Sketch ganz gut, Android geht bloß über Umwege mit Third-Party Plugins.

20:06.140 --> 20:07.460
Super, danke.