Mobile-App-Lösungen

Eine mobile App ist keine verkleinerte Desktop-Oberfläche. Sie muss funktionieren, wenn die Verbindung abbricht, der Akku leer wird oder die Hände voll sind.

Mobile-App-Lösungen

Ob eine mobile App im Feld nutzbar ist, entscheidet meist nicht das Bildschirmdesign. Was bei Verbindungsabbruch passiert, wann Daten synchronisiert werden und welcher Datensatz gilt, wenn zwei Geräte denselben Eintrag ändern — das ist entscheidender.

Auf welcher Plattform und mit welcher Technologie entwickelt wird, richtet sich nach dem Anwendungsfall. Eine Feldanwendung mit tiefem Hardwarezugriff und eine überwiegend datenanzeigende App haben nicht dieselbe richtige Antwort.

Apps, die eine Verbindung als Voraussetzung ansehen, werden im Feld über kurz oder lang unbrauchbar.

Sind wir der richtige Ansprechpartner?

Eine mobile App ist nicht die Antwort auf jeden Bedarf. Sitzt der Nutzer am Schreibtisch und läuft die Arbeit im Browser, bringt eine separate App nur Wartungs- und Releaseaufwand, ohne einen Gegenwert zu liefern.

Ja, lassen Sie uns sprechen

  • Die Arbeit findet im Feld statt, im Stehen und oft mit einer Hand
  • Zugriff auf Gerätehardware wie Kamera, Standort, Barcode oder NFC ist erforderlich
  • Auch dort, wo keine Verbindung besteht, müssen Einträge möglich sein

Nein, das macht jemand anderes besser

  • Die App würde nur eine bestehende Weboberfläche verkleinern
  • Nutzerzahl und -häufigkeit rechtfertigen den App-Store- und Releaseaufwand nicht
  • Der eigentliche Bedarf ist Berichtswesen — das lässt sich meist günstiger über das Web lösen

Was wir tun

  • Plattform- und Technologiewahl je nach Anwendungsfall
  • Offline-Betrieb und lokale Datenspeicherung
  • Datensynchronisation und Konfliktlösung
  • Serverseitiger API-Entwurf
  • Zugriff auf Gerätehardware — Kamera, Standort, Barcode, NFC, Bluetooth
  • Push-Benachrichtigungsinfrastruktur
  • Usability-Design für Feldbedingungen
  • App-Store-Veröffentlichung und Versionsverwaltung

Wie wir vorgehen

01

Anwendungsfälle

Wir klären, wo, unter welchen Bedingungen und wie häufig die App genutzt wird. Die Feldbedingungen bestimmen die meisten Oberflächenentscheidungen von Anfang an.

02

Entwurf des Datenflusses

Hier entscheiden wir, welche Daten auf dem Gerät bleiben, wann sie synchronisiert werden und wie Konflikte gelöst werden.

03

API-Vertrag

Wir schreiben die serverseitige Schnittstelle, bevor die App-Entwicklung beginnt. So können beide Seiten parallel arbeiten.

04

Entwicklung und Feldtest

Wir testen die App auf echten Geräten unter echten Einsatzbedingungen. Emulatortests allein reichen uns nicht.

05

Release und Versionierung

Die App-Store-Prozesse übernehmen wir, die Versionspolitik legen wir gemeinsam fest. Die Kompatibilität älterer Versionen mit dem Server erhalten wir für einen Übergangszeitraum.

Unsere technischen Entscheidungen

  • Die App wird so entworfen, dass sie auch ohne Netzverbindung sinnvoll funktioniert. Feldpersonal kann Einträge auch ohne Verbindung vornehmen; sobald eine Verbindung besteht, werden die Daten synchronisiert. Apps, die eine Verbindung als Voraussetzung ansehen, werden im Feld über kurz oder lang unbrauchbar.
  • Was passiert, wenn zwei Geräte denselben Datensatz ändern, wird bereits in der Entwurfsphase festgelegt. Wird diese Regel erst später ergänzt, ist ein Teil der bis dahin gesammelten Daten bereits inkonsistent.
  • Nicht alle Nutzer aktualisieren die App gleichzeitig. Die Serverschnittstelle wird so entwickelt, dass ältere Versionen funktionsfähig bleiben; sonst fallen Nutzer ohne Update aus dem System.
  • Standortverfolgung, Hintergrundsynchronisation und Benachrichtigungshäufigkeit werden mit Blick auf die Akkulaufzeit abgestimmt. Eine App, die den Akku schnell entlädt, wird vom Nutzer abgeschaltet, selbst wenn sie technisch einwandfrei läuft.
Individuelle Softwarelösungen
Elektronikschaltungslösungen