-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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 |
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. |
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 @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. @EverheardofUX : Für dich zur Info. |
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. @EverheardofUX : Den Input bezüglich der Darstellung überlasse ich dir. |
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
Von: Stephanie Francke ***@***.***>
Gesendet: Donnerstag, 12. Dezember 2024 12:04
An: SchweizerischeBundesbahnen/DAS ***@***.***>
Cc: Traber Felix (PP-BP-ZFR-FFP) ***@***.***>; Mention ***@***.***>
Betreff: Re: [SchweizerischeBundesbahnen/DAS] Verbindungsstatus clientseitig (Issue #119)
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<https://github.com/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<https://github.com/EverheardofUX> : Den Input bezüglich der Darstellung überlasse ich dir.
-
Reply to this email directly, view it on GitHub<#119 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BH3LUJOP7KIJOQEDLV7UIV32FFUSVAVCNFSM6AAAAABJ5OV6F2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZYGU3DMOBVGM>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
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. |
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. |
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? |
Hoi @i002423 |
Hoi @stbruni |
Hallo Felix @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. |
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. |
Hoi @stbruni |
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. |
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
Akzeptanzkriterien
Testszenarien
Vorbedingung:
--
Durchführung:
The text was updated successfully, but these errors were encountered: