Im Detail: Vertretungsanfragen

‍

Die ilert Mobile App wird hauptsächlich von Responder:innen genutzt, um Benachrichtigungen über kritische Alarme zu empfangen, unterwegs darauf zu reagieren und den aktuellen On-Call-Status einzusehen. Sie bietet verschiedene Funktionen, darunter kritische Push-Benachrichtigungen, Schnellaktionen für Alerts und individuelle Einstellungen für kritische Benachrichtigungen. Mit der App können Responder:innen ihre aktuellen On-Call-Schichten und Eskalationsregeln einsehen, Schichten von Kolleg:innen übernehmen oder Vertretungsanfragen erstellen, um Kolleg:innen um eine Übernahme der On-Call-Schicht zu bitten. Letzteres ist eine neue Funktion von ilert, die sich als besonders hilfreich für die Kommunikation zwischen Nutzer:innen erwiesen hat. In diesem Beitrag werfen wir einen genaueren Blick auf die Entwicklung dieser Funktion und die Herausforderungen, die dabei zu bewältigen waren.

Warum wurden Vertretungsanfragen eingeführt?

Seit der Einführung der On-Call-Schedules können Nutzer:innen sogenannte Overrides erstellen – also spezielle Schichten, die Vorrang vor regulären Schichten haben. Ein Override erlaubt es, eine andere Person für eine ganze oder teilweise Schicht als On-Call-Verantwortliche:n einzutragen. Overrides müssen nicht an bestehende Schichten gebunden sein – sie können für beliebige Zeiträume erstellt werden, auch außerhalb definierter Schichten.

‍

Später wurde die Funktion „Take On-Call“ eingeführt, also die Möglichkeit, eine fremde Schicht zu übernehmen. Beide Methoden erzeugen technisch gesehen einen Override, doch keine stellt sicher, dass die jeweils andere Person über diese Änderung informiert wird. Das führte in der Praxis dazu, dass Personen plötzlich für Schichten verantwortlich waren, ohne davon zu wissen – was im Ernstfall kritisch sein kann.

‍

Die Lösung war ein neuer Flow: Nutzer:innen sollten die Möglichkeit bekommen, gezielt eine andere Person um die Übernahme einzelner On-Call-Zeiträume zu bitten – mit klarer Kommunikation und Rückmeldung. Daraus entstand das Konzept der Vertretungsanfragen.

Design der REST API für Vertretungsanfragen

Der typische Ablauf einer Vertretungsanfrage ist:

1. Nutzer:in A erstellt eine Vertretungsanfrage und bittet Nutzer:in B, eine oder mehrere Schichten ganz oder teilweise zu übernehmen.
2. Nutzer:in B erhält eine Benachrichtigung und kann die Anfrage annehmen oder ablehnen.
3. Nutzer:in A wird über die Entscheidung informiert.

‍

‍

Die Vertretungsanfragen-API basiert auf einem eigenen Entity-Typ mit mindestens folgenden Feldern:

• sender
• receiver
• shifts
  

‍

Zusätzlich haben wir ein Nachrichtenfeld (message) eingeführt, damit Nutzer:innen zusätzliche Informationen zur Anfrage übermitteln können. Für die UI haben wir außerdem den aktuellen Status (state) und das Erstellungsdatum (createdAt) als Read-only-Attribute bereitgestellt. Bei einer Ablehnung kann optional ein Kommentar mit der Begründung (declineComment) übermittelt werden. Zur Anzeige mehrerer Anfragen in der Listenansicht und für sinnvolle Filter wurde das Feld state in Kombination mit einem im Frontend berechneten Status expired genutzt. Eine Vertretungsanfrage gilt als abgelaufen, wenn die letzte enthaltene Schicht beendet ist.

‍

Neben klassischen Create- und Read-Operationen wurden eigene Endpunkte fürs Akzeptieren, Ablehnen und Zurückziehen eingeführt. Update- und Delete-Operationen gehören aktuell nicht zum Flow und sind nicht geplant.

Vom Mockup zur finalen UI

‍

Zwischen Mockup und finaler Version der Ansicht zur Erstellung einer Vertretungsanfrage gibt es keine großen Unterschiede. Lediglich das Styling wurde angepasst, und es wurde ein zusätzliches Infofeld zur Zeitzone eingeführt. Die finalen Versionen der Listen- und Detailansicht sehen folgendermaßen aus:

‍

Kommunikation ist der Schlüssel

Ein zentrales Ziel dieser Funktion ist es, Nutzer:innen dazu zu motivieren, frühzeitig auf Vertretungsanfragen zu reagieren – da On-Call-Schichten zeitgebunden und oft kurzfristig sind. Außerdem sollen alle relevanten Kommunikationsprozesse in der ilert Mobile App stattfinden, sodass ein Toolwechsel überflüssig wird. Dafür wurden mehrere Kommunikationswege implementiert:

Push-Benachrichtigungen

Sobald eine Aktion bei einer Vertretungsanfrage erfolgt, wird eine Push-Benachrichtigung an die jeweils betroffene Person gesendet:

• Vertretungsanfrage erstellt → Empfänger:in wird benachrichtigt
• Anfrage angenommen/abgelehnt → Absender:in wird benachrichtigt
• Anfrage storniert → Empfänger:in wird benachrichtigt
  

Aber was passiert, wenn die empfangende Person die Mobile-App nicht nutzt?

‍

E-Mail

ilert prüft, ob die relevanten Nutzer:innen über mindestens ein registriertes Push-Token (ein eindeutiger Geräte-Identifikator) verfügen. Falls nicht, wird automatisch eine E-Mail an die primäre Adresse mit den Details zur Vertretungsanfrage gesendet.

In-App Badge‍

‍Da Push-Benachrichtigungen versehentlich übersehen oder weggeswiped werden können – auch bei zeitkritischen Anfragen – wurde in der Listenansicht ein roter Kreis (Badge) oben links am Menü-Icon eingeführt. Dieser zeigt an, ob ungelesene Vertretungsanfragen vorhanden sind. Zusätzlich zeigt der Menüpunkt eine Zählung aller offenen Anfragen an.

Filter bereitstellen, aber UI schlank halten

Eine Filtermöglichkeit für Vertretungsanfragen in der Listenansicht ist notwendig – beispielsweise für empfangene und gesendete Anfragen. Ein weiterer, komplexerer Filter betrifft nur relevante Anfragen, also solche, die noch nicht abgelaufen oder beantwortet sind.

‍

Da bereits ein Toggle für „Erhalten / Gesendet“ existiert, hätte ein zusätzlicher „Aktuell / Alle“-Toggle die Oberfläche überladen.

‍

Ein Vorschlag war eine Filterleiste wie bei der Alert-Liste – diese Idee wurde jedoch verworfen, da sie zum Releasezeitpunkt nur einen Filter enthalten hätte, was nicht stimmig gewirkt hätte. Die finale Lösung: standardmäßig werden nur offene Anfragen (Status Pending) angezeigt, alle weiteren sind über einen Button zugänglich. Diese Lösung bietet die beste Balance zwischen Übersichtlichkeit und Funktionalität.

‍

Alltag bringt Details ans Licht

Nach dem Release begann das ilert-Team selbst mit der Nutzung der Funktion – und stieß schnell auf eine Schwäche: Nach dem Ausführen einer Aktion (Accept, Decline, Cancel) verschwand die betreffende Anfrage sofort aus der Liste, ohne dass der veränderte Status ersichtlich war.

‍

Zwei Verbesserungen wurden daraufhin umgesetzt:

‍

• Nach einer Aktion bleibt man in der Detailansicht, um den aktualisierten Status direkt zu sehen.
• Relevante Anfragen bleiben 24 Stunden nach einer Aktion weiterhin in der Liste sichtbar.

‍

Zuvor verschwand eine Anfrage sofort nach der Statusänderung aus der Liste, da diese auf dem state-Feld basierte. Um auch kürzlich bearbeitete Anfragen anzuzeigen, wurde ein zusätzlicher Query-Parameter in der API eingeführt. Damit kann das Frontend eine createdAt-Zeitgrenze definieren. Die Antwort enthält dann alle Vertretungsanfragen – unabhängig vom Status – ab diesem Zeitpunkt bis jetzt. So können Nutzer:innen alle offenen sowie kürzlich bearbeiteten (innerhalb der letzten 24 Stunden) Anfragen einsehen.

‍

‍Haben Sie die ilert App noch nicht installiert? Probieren Sie sie gerne aus – jetzt für Android oder iOS herunterladen.