Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verbindungsstatus clientseitig #119

Open
StephanieFrancke opened this issue Jun 26, 2024 · 21 comments
Open

Verbindungsstatus clientseitig #119

StephanieFrancke opened this issue Jun 26, 2024 · 21 comments
Assignees

Comments

@StephanieFrancke
Copy link
Collaborator

StephanieFrancke commented Jun 26, 2024

Ausgangslage

Als Lokpersonal oder Beobachter möchte ich sehen, falls ich aktuell keine neuen Daten erhalte, damit ich den Stand der Informationen kenne.

Weiterführende Links

Figma link für DEVS: https://www.figma.com/design/b4EUSXE2AgrPu5Tv3HyEis/11%3A-Stories-Formulierung?node-id=8291-85123&m=dev&t=UC1cX80C3NWHNvcH-1

PDF für Fachgruppe: Story119.pdf

Out of Scope

  • Die Überwachung der Datenlieferung bei intakter clientseitiger Verbindung wird erst mit der Umsetzung des aktiven Lokpersonals möglich und mit Verbindungsstatus serverseitig #322 umgesetzt.

Akzeptanzkriterien

  • Wenn es zu einem clientseitigen Verbindungsunterbruch (kein Internet) mit mehr als 60 Sekunden kommt, wird dies entsprechend angezeigt.
  • Das Icon verschwindet, sobald das Problem behoben ist.

Testszenarien

Vorbedingung:

--

Durchführung:

  • Im DAS wird eine beliebige Fahrordnung geöffnet.
  • Das Gerät hat eine Internetverbindung.
    • Es wird kein Hinweis auf einen Verbindungsunterbruch dargestellt.
  • Das Gerät wird in den Flugmodus gesetzt.
    • Das Icon für einen Verbindungsunterbruch (clientseitig) erscheint nach 60 Sekunden.
  • Der Flugmodus wird deaktiviert
    • Das Icon für den Verbindungsunterbruch verschwindet.
@EverheardofUX

This comment has been minimized.

@StephanieFrancke StephanieFrancke moved this from Backlog to Entwicklungsteam Review in Driver Advisory System Oct 21, 2024
@StephanieFrancke

This comment has been minimized.

@mghilardelli

This comment has been minimized.

@EverheardofUX

This comment has been minimized.

@StephanieFrancke StephanieFrancke changed the title Verbindungsstatus Verbindungsstatus clientseitig Oct 24, 2024
@EverheardofUX

This comment has been minimized.

@EverheardofUX EverheardofUX moved this from Entwicklungsteam Review to Projekt Review in Driver Advisory System Oct 24, 2024
@uncl3s4m
Copy link

uncl3s4m commented Dec 9, 2024

Der Verbindungsstatus wird uns heute neben der LOPAS- eigenen Anzeige sehr prominent durch ADL angezeigt. Das LP erhält dann eine kaum übersehbare Meldung eines Verbindungsunterbruches (zum ADL- Kanal), nach wieder hergestellter Verbindung wird "ADL- Anmeldung erfolgreich" angezeigt. Wird dies in Zukunft auch auf gängige Art angezeigt, respektive unterschieden?

@StephanieFrancke
Copy link
Collaborator Author

Der Verbindungsstatus wird uns heute neben der LOPAS- eigenen Anzeige sehr prominent durch ADL angezeigt. Das LP erhält dann eine kaum übersehbare Meldung eines Verbindungsunterbruches (zum ADL- Kanal), nach wieder hergestellter Verbindung wird "ADL- Anmeldung erfolgreich" angezeigt. Wird dies in Zukunft auch auf gängige Art angezeigt, respektive unterschieden?

Hoi @uncl3s4m
Die ADL Meldungen kommen zukünftig zusammen mit fast allen anderen Fahrordnungsdaten via SFERA Schnittstelle von TMS VAD. Bei einem Verbindungsunterbruch (siehe Icon in dieser User Story) bekommt man daher kein ADL - aber auch keine anderen Updates (PüA, Umleitungen, etc.). Sprich: Der Verbindungsunterbruch gilt immer für die ganze Fahrordnung. Passt das so für dich?

@stbruni
Copy link

stbruni commented Dec 11, 2024

Zwischen Iselle und Domodossola ist die Netzabdeckung sehr schlecht. Im LOPAS wird heute einfach die Datenverbindung erweitert. Das heisst, wenn das Datensymbol verschwindet, zeigt auch das LOPAS an, dass es offline ist. Allerdings ist die Verbindung mit Edge dort so schwach, dass bereits keine Daten mehr ankommen.
Wird im DAS die Verbindung ebenfalls vom System übernommen oder wird dies mit einer anderen Kontrolle überprüft (Ping)?

@Felix-Traber
Copy link

Vor allem unter dem Aspekt, dass man immer mehr aktuelle Daten auf das Fahrbild bringen möchte, muss aus meiner Sicht ein Verbindungsunterbruch prominenter erkennbar sein. Zudem sollte in einem solchen Fall das Fahrbild beispielsweise leicht eingefärbt werden, so dass es unübersehbar wird, dass man ein Verbindungsunterbruch hat. Sind die 60 Sekunden Zeitdauer zweckmässig? Oder müsste ein Verbindungsunterbruch nicht schon früher angezeigt werden. Bei kurzen Signalabständen könnte eine Fahrwegänderung unter Umständen genau in diesen Zeitraum fallen, in welchem ein Verbindungsunterbruch erfolgt ist. Die Fahrwegänderung wäre dann evtl. nicht sichtbar für den LF.

@StephanieFrancke
Copy link
Collaborator Author

Zwischen Iselle und Domodossola ist die Netzabdeckung sehr schlecht. Im LOPAS wird heute einfach die Datenverbindung erweitert. Das heisst, wenn das Datensymbol verschwindet, zeigt auch das LOPAS an, dass es offline ist. Allerdings ist die Verbindung mit Edge dort so schwach, dass bereits keine Daten mehr ankommen. Wird im DAS die Verbindung ebenfalls vom System übernommen oder wird dies mit einer anderen Kontrolle überprüft (Ping)?

Hoi @stbruni

Ich habe mit unseren Entwicklern kurz die technischen Möglichkeiten abgeklärt und es wären beide Varianten (Anzeige gemäss Gerät oder regelmässiges Prüfen der Verbindung) möglich.
Mein Vorschlag wäre, dass wir regelmässig prüfen, ob eine Datenverbindung noch besteht. Dadurch könnten wir auch den Fall abdecken, dass man mit einem WLAN verbunden ist, worüber aber keine wirkliche Datenverbindung besteht.
Diesen Vorschlag nehme ich in die nächste Fachgruppe zur Diskussion mit.

@EverheardofUX : Für dich zur Info.

@StephanieFrancke
Copy link
Collaborator Author

Vor allem unter dem Aspekt, dass man immer mehr aktuelle Daten auf das Fahrbild bringen möchte, muss aus meiner Sicht ein Verbindungsunterbruch prominenter erkennbar sein. Zudem sollte in einem solchen Fall das Fahrbild beispielsweise leicht eingefärbt werden, so dass es unübersehbar wird, dass man ein Verbindungsunterbruch hat. Sind die 60 Sekunden Zeitdauer zweckmässig? Oder müsste ein Verbindungsunterbruch nicht schon früher angezeigt werden. Bei kurzen Signalabständen könnte eine Fahrwegänderung unter Umständen genau in diesen Zeitraum fallen, in welchem ein Verbindungsunterbruch erfolgt ist. Die Fahrwegänderung wäre dann evtl. nicht sichtbar für den LF.

Hoi @Felix-Traber

Dass ein Verbindungsunterbruch erst nach 60 Sekunden angezeigt wird, war ein Wunsch, den wir in der letzten Fachgruppe aufgenommen haben. Bei LEA wird heute der Verbindungsunterbruch auch erst nach einer gewissen Dauer angezeigt (die Dauer ist sogar höher als 60 Sekunden). Die Befürchtung war, dass es zu viel Ablenkung gibt, wenn wir den Verbindungsunterbruch sofort anzeigen.
Passt das so für dich oder sollen wir das in der nächsten Fachgruppe nochmals genauer besprechen?

@EverheardofUX : Den Input bezüglich der Darstellung überlasse ich dir.

@Felix-Traber
Copy link

Felix-Traber commented Dec 12, 2024 via email

@i002423
Copy link

i002423 commented Dec 16, 2024

Verbindungsstatus ADL vPRO DIS SOB.pdf

Ich bin mir nun nicht sicher, ob dies mit der SFERA Schnittstelle auch ein Thema sein kann. Besteht die Möglichkeit, dass kein Verbindungsunterbruch besteh, jedoch die Verbindung zur SFERA Schnittstelle fehlt? Wir haben für jede Eventualität eine Anzeige im DIS für den Lf erstellt. Siehe Anhang.

@dschmucki
Copy link
Collaborator

Für den Benutzer ist es schlussendlich egal, ob er Internet hat oder TMS-VAD keine Daten liefert / liefern kann. Schlussendlich ist die Applikation "Offline". Ich würde an der Stelle versuchen, die Komplexität (für den Benutzer) tief zu halten.

Die 60 Sekunden scheinen mir willkürlich. Müsste das für eine obere Schwelle nicht ableitbar sein, im Sinne, wie kurzfristig können Änderungen überhaupt kommuniziert werden, resp. wie relevant kann eine Änderung sein, welche "jetzt" publiziert wird? Gibt es den Case überhaupt, dass "jetzt" etwas publiziert wird was auch "jetzt" relevant ist oder gilt das sowieso immer erst in x Minuten?

Der andere relevante Faktor für die Zeit hängt von der Darstellung (dezent oder prominent) und der daraus resultierenden Ablenkung ab. Ein Flackern sollte um jeden Preis vermieden werden. Das dürfte wohl nur über Tests eruierbar sein? Für die Technik: Wert sollte konfiguriert werden können.

@stbruni
Copy link

stbruni commented Dec 19, 2024

Für den Benutzer ist es schlussendlich egal, ob er Internet hat oder TMS-VAD keine Daten liefert / liefern kann. Schlussendlich ist die Applikation "Offline". Ich würde an der Stelle versuchen, die Komplexität (für den Benutzer) tief zu halten.

Könnte es für den Benutzer nicht wichtig sein, ob sein Tablet eventuell ein Problem mit der Datenverbindung hat oder das Problem auf Seite TMS-VAD ist?
Im ersten Fall könnte eventuell ein Neustart des Tablets oder der Datenverbindung helfen, im zweiten Fall könnte ich vielleicht jemanden Informieren.

@StephanieFrancke
Copy link
Collaborator Author

Verbindungsstatus ADL vPRO DIS SOB.pdf

Ich bin mir nun nicht sicher, ob dies mit der SFERA Schnittstelle auch ein Thema sein kann. Besteht die Möglichkeit, dass kein Verbindungsunterbruch besteh, jedoch die Verbindung zur SFERA Schnittstelle fehlt? Wir haben für jede Eventualität eine Anzeige im DIS für den Lf erstellt. Siehe Anhang.

Hoi @i002423
Tatsächlich wäre es möglich, dass das Gerät selber keinen Verbindungsunterbruch hat, aber SFERA technische Probleme hat und keine Daten sendet. Diesen Fall werden wir erst mit #322 abdecken, da wir dafür die Aktivmeldung vom Lokpersonal benötigen. Für den aktiv gemeldeten Lokführer gibt es dann eine zusätzliche Anzeige, falls er trotz intakter Internetverbindung keine Daten erhält. Wir schätzen es aktuell aber so ein, dass dieser Fall sehr selten eintreten sollte. Ich hoffe, das passt so für dich.

@StephanieFrancke
Copy link
Collaborator Author

Für den Benutzer ist es schlussendlich egal, ob er Internet hat oder TMS-VAD keine Daten liefert / liefern kann. Schlussendlich ist die Applikation "Offline". Ich würde an der Stelle versuchen, die Komplexität (für den Benutzer) tief zu halten.

Könnte es für den Benutzer nicht wichtig sein, ob sein Tablet eventuell ein Problem mit der Datenverbindung hat oder das Problem auf Seite TMS-VAD ist? Im ersten Fall könnte eventuell ein Neustart des Tablets oder der Datenverbindung helfen, im zweiten Fall könnte ich vielleicht jemanden Informieren.

Hoi @stbruni
Ja genau, so ist generell die Einschätzung der Mehrheit in der Fachgruppe. Mit der Umsetzung von dieser Anforderung und #322 werden wir dann beide Anzeigen haben. Der Unterbruch der Datenlieferung von SFERA kommt nachgelagert, da wir dafür den aktiv gemeldeten Lokführer benötigen.

@StephanieFrancke
Copy link
Collaborator Author

Hoi Stephi Für mich betr. der Zeit so passend. Bei der Anzeige des Unterbruchs müssen wir wohl auch die Situation Brig - Domo denken. Eine deutliche Anzeige wäre aus meiner Sicht wichtig, aber man muss in dem Fall auch ohne visuelle Einbussen nach / von Domo fahren können. Aktuell beim LEA App ist es so, dass man die WLAN Verbindung ausschalten muss zu fahren. Es geht dabei um die Funktion der WarnApp, welche bei aktivem WLAN gestört werden kann. Wäre das beim DAS kein Problem? Detail weiss vermutlich der Fachbus LEA. LG Felix

Hallo Felix
Gemäss Fachbus ist das aktive WLAN für die WarnApp vorallem darum störend, weil die Internetverbindung da teilweise sehr eingeschränkt ist. Ich denke dieses Problem könnten wir auch in anderen Konstellationen haben (z.B. schwache Verbindung, welche nicht wirklich für Datenübertragungen reicht). Daher würde ich vorschlagen, dass wir einfach generell die tatsächliche Internetverbindung regelmässig prüfen (unabhängig davon, was das System anzeigt).
Alternativ wäre es aber auch möglich, die WLAN Verbindung zu erkennen und den Lokführer aktiv darauf hinzuweisen. Von DAS aus können wir das WLAN leider nicht automatisch unterdrücken.
Ich werde den Vorschlag so in der nächsten Fachgruppe nochmals genauer vorstellen und dann können wir gerne noch dazu diskutieren.

@EverheardofUX : Für dich zur Info. Dies betrifft die Anforderung für eine Zusatzanzeige der WLAN-Verbindung, welche wir an der letzten Fachgruppe diskutiert hatten. Gemäss meinem primären Vorschlag, wäre die Zusatzanzeige nicht notwendig, für die Alternative hingegen schon.

@stbruni
Copy link

stbruni commented Jan 10, 2025

[...] Ich denke dieses Problem könnten wir auch in anderen Konstellationen haben (z.B. schwache Verbindung, welche nicht wirklich für Datenübertragungen reicht). [...]

Bei unseren Tablet hatten wir bei WaRa im Depotbereich Spiez das Problem, dass das Tablet automatisch mit dem WLAN verbunden hat, bei der Weiterfahrt hat es anschliessend wieder auf das mobile Netz gewechselt und so kam ein Unterbruch zustande, der zu Fehlern führte.
Wenn das LEA Tablet natürlich mit dem "SBB Free" verbindet, wird dies in sehr vielen Bahnhöfen der Fall sein.
In Android kann explizit für eine einzelne App das WLAN unterbunden werden, so wird immer das mobile Netz verwendet. Bei iOS habe ich nur die Funktion WLAN Unterstützung gefunden, wo bei schlechtem WLAN automatisch mobile Daten verwendet werden.

@StephanieFrancke
Copy link
Collaborator Author

[...] Ich denke dieses Problem könnten wir auch in anderen Konstellationen haben (z.B. schwache Verbindung, welche nicht wirklich für Datenübertragungen reicht). [...]

Bei unseren Tablet hatten wir bei WaRa im Depotbereich Spiez das Problem, dass das Tablet automatisch mit dem WLAN verbunden hat, bei der Weiterfahrt hat es anschliessend wieder auf das mobile Netz gewechselt und so kam ein Unterbruch zustande, der zu Fehlern führte. Wenn das LEA Tablet natürlich mit dem "SBB Free" verbindet, wird dies in sehr vielen Bahnhöfen der Fall sein. In Android kann explizit für eine einzelne App das WLAN unterbunden werden, so wird immer das mobile Netz verwendet. Bei iOS habe ich nur die Funktion WLAN Unterstützung gefunden, wo bei schlechtem WLAN automatisch mobile Daten verwendet werden.

Hoi @stbruni
Merci vielmals für deine Recherche und Ergänzungen!
Am besten besprechen wir das weitere Vorgehen am Donnerstag nochmals gemeinsam. Das WLAN wird Stand heute durch DAS weder automatisch ein- noch ausgeschaltet. Das heisst, es würde für eine gute Verbindung ausreichen, wenn das Lokpersonal die WLAN Option einfach immer deaktiviert lässt. Aber ihr könnt mir hierzu sicher noch genauer aufzeigen, ob das gut in den Alltagsgebraucht durch das Lokpersonal passt.

@StephanieFrancke StephanieFrancke moved this from Projekt Review to Blocked in Driver Advisory System Jan 16, 2025
@StephanieFrancke
Copy link
Collaborator Author

StephanieFrancke commented Jan 23, 2025

Update vom 16.01.25 aus der Fachgruppe: Die Anforderung wurde blockiert, da noch zusätzlich Lösungen für den Umgang mit dem WLAN geklärt werden sollen. Idealerweise wird das WLAN durch DAS unterdrückt. Abklärungen dazu sind am Laufen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Blocked
Development

No branches or pull requests