Sauberes Design für zentralisierte Navigation?

Question

Kontext

Einzelseite/Ajax-Web-App

Grundcodestruktur

Locationmanager (verantwortlich für den Browser-Hash-Aktualisierung und die Anwendung Standort zu einem anderen Kachel schaltend)

Seite/Tile Flow

Basisinformationen> Haushalts Info> Fahrzeug Infos> Bezahlungsoptionen> Bestellung prüfen> Zahlung eingeben und

Problem

Senden Wenn der Benutzer von Bezahlungsoptionen navigiert zu überprüfen, um eine lange (5- 8 Sekunden) Service-Aufruf wird vorgenommen, um Bestelldetails zu berechnen. Nach der Auflösung des Anrufs soll der Rückruf den Benutzer zur Seite "Bestellung prüfen" führen. Das Problem ist, wenn der Benutzer während dieser Zeit zurückklickt und zu Haushaltsinformationen zurückkehrt, sobald der Anruf verrechnet wird, werden diese "automatisch" zum Überprüfungsauftrag gebracht. Sehr peinliche Benutzererfahrung.

Einschränkungen

den Anruf abbrechen, ist keine Option. Brauchen Sie eine Lösung für die Navigation.

derzeitige Implementierung

Speicher "Currentlocation" vor dem calculateOrder Aufruf zu machen. Übergeben Sie den "currentLocation" im Callback an die setLocation-Methode als intentedStartingPoint. Innen setLocation Methode if(intendedStartingPoint === Locationmanager.currentLocation) {//Navigate}

Um es zusammenzufassen, wenn der Benutzer die Lage ändert, während der Anruf im Gange ist, auf die Auflösung des Gesprächs werden wir nicht navigieren, da der Benutzer erwartet nicht Kommentieren navigiert werden an diesem Punkt.

Das funktioniert, oder?

The Catch

Wir haben viele Orte in der App, wo setLocation in einem Rückruf für einen langen Lauf Aufruf aufgerufen wird. Das bedeutet, dass ich alle setLocation Aufrufe mit einem neuen Parameter - intendedStartingPoint - aktualisieren muss. Während es für mich Sinn macht, scheint es, dass es Potenzial hat, ein bisschen überladen zu werden.

Irgendwelche Ideen, wie man es aufräumt und zentralisiert?

Answer 1

So kann jetzt ein Benutzer auf der Seite Kaufoptionen auf die Schaltfläche Berechnen klicken. Sie zeigen dann eine Art Ladeanzeige an (hoffentlich) und senden eine asynchrone Anfrage an einen Server mit setLocation('ReviewOrder') in einer Fortsetzung. Es gibt eine ganze Reihe von Stellen in der Anwendung, wo Sie dieses Muster verwenden.

Das Problem von unerwarteten (aus Benutzersicht) Redirects ist da, weil mit diesem Ansatz Server Datenabruf und UI-Navigation gekoppelt sind. Eine Lösung, die Ihnen in den Sinn kommt, ist sie zu entkoppeln und setLocation Aufrufe von allen lang laufenden Anfrage Fortsetzungen zu entfernen. Es kann folgendermaßen funktionieren.

Wenn der Benutzer auf die Schaltfläche Berechnen klickt, starten Sie eine asynchrone Anforderung und zugleich sofort zum Bewertungsbestellseite navigieren (das ist wichtig, aus einer UX Perspektive, da die Benutzer nun klar zu verstehen, dass die Schaltfläche Berechnen navigiert zu Überprüfungsauftrag). Zeigen Sie auf der Seite "Bestellbestellung" eine Ladeanzeige an, die etwas wie "Bitte warten, ca. 10 Sekunden verbleibend ..." anzeigt. Wenn eine Anfrage abgeschlossen ist, verstecken Sie den Ladeindikator und zeigen Sie die Daten an.

So haben Ihre Benutzer ein konsistentes UX, das weiß, dass immer dann, wenn sie auf eine Schaltfläche in Ihrer Anwendung klicken (sie navigieren zu einer Ansicht) und es keine überraschenden automatischen Weiterleitungen gibt.

Answer 2

Wenn der Benutzer in der Lage ist, zurückzugehen und alle eingegebenen Informationen auf den vorherigen Seiten zu ändern, ist es ein Muss, alle ausstehenden Serviceanrufe für ungültig zu erklären. Wenn ein Serviceaufruf, der auf veralteten Informationen basiert, zurückkehrt, muss er verworfen werden.

Dies bedeutet, if(intendedStartingPoint === Locationmanager.currentLocation) {//Navigate} ist nicht ausreichend. Sie müssen etwas wie if(intendedStartingPoint === Locationmanager.currentLocation && /* no information altered in the meantime*/) {//Navigate} tun.

Jetzt für Ihr Design Frage: Es ist ein wenig schwer, dies ohne konkreten Code zu bauen, aber man konnte folgendes tun:

• Mittel bereitstellen registrieren und lang laufenden Anrufe in LocationManager
• zu verwalten lang laufende Anrufe sollen dann immer mit den LocationManagerLocationManager
• registriert werden sollen, dass man höchstens versichern lang laufende Gespräch aktiv zu einem Zeitpunkt
• Wenn ein Standortwechsel auftritt , alle (oder der eine aktive) lang andauernde Anruf muss ungültig gemacht werden
• Rückruf eines lang laufenden Anrufs sollte prüfen, ob es nicht ungültig ist, und nur navigieren, wenn dies der Fall ist. LocationManager könnte dies für alle Rückrufe einheitlich tun.
• Neue lange laufende Anrufe könnten einen bereits laufenden Anruf ersetzen/ungültig machen oder abgelehnt werden, wie Sie möchten.

Ich hoffe, dass dies in Ihrer konkreten Situation sinnvoll ist.

Answer 3

Als Erstes berechnen Sie die Bestelldetails über einen asynchronen Aufruf und zeigen/simulieren Sie eine Fortschrittsanzeige für den Endbenutzer über Javascript.

Die zweite Sache: Erzwingen Sie nicht ReviewOrder Kachelöffnung in Ihrer Service-Callback-Funktion. Wenn der Dienst die Berechnung abgeschlossen hat, überprüft die Callback-Funktion die aktuelle Kachel. Ist sie nicht ReviewOrder, werden die berechneten Informationen in der Sitzung oder im lokalen Speicher gespeichert.

Wenn Benutzer ReviewOrder Kachel navigiert, vergleichen Sie Bestelldetails, die vom Benutzer mit den gespeicherten Bestelldetails kamen (z. B. über die Hashing-Funktion).

Wenn die Hashcodes der Benutzerauftragsdetails und der gespeicherten Bestelldetails identisch sind, dann zeigen Sie die gespeicherten Bestellinformationen an, andernfalls rufen Sie den Dienst erneut auf.

Wichtiger Hinweis: Um Schmieden zu verhindern, sollten Sie die folgende Art und Weise:

Auf Bestellung Details auf dem Server berechnet wird, erzeugt einzigartige Auftrags-ID, die für den Benutzer zurückgegeben werden. Speichern Sie dann die berechneten Bestelldetails zusammen mit dieser ID in der Serverdatenbank. Wenn der Benutzer die Bestelldetails nicht geändert hat, sendet Ihr Skript nur diese Bestell-ID als Zeichen an den Server, diese Bestellung wurde akzeptiert. Dann lesen Sie Ihre Datenbank und bearbeiten Sie die Bestellung mit dieser ID.

Wenn die Bestellung nicht abgeschlossen wurde, dann verwenden Sie eine geplante Aufgabe, die Ihre Datenbank von nicht abgeschlossenen Bestellungen bereinigt (zum Beispiel - Bestellungen, vor 24 Stunden berechnet, aber immer noch nicht abgeschlossen).

Answer 4

Da Sie den Benutzer nicht daran hindern können, zwischen den Kacheln zu navigieren, wird die Benachrichtigung über die Berechnungsverzögerung nicht das ganze Problem lösen. Sie können dem Benutzer die geschätzte Zeit bis zum Abschluss mitteilen, Sie können einen Fortschrittsbalken anzeigen und Sie können ihn sofort zum Kachelberichtauftrag bringen, um auf die Ergebnisse zu warten. Wenn er jedoch von der Kachel weg navigiert, bleibt Ihre ursprüngliches Problem.

Wenn der Benutzer nach all diesen Informationen wegfahren wollte, muss er sich bewusst dafür entschieden haben, das Verfahren zu unterbrechen. Es wäre eine schlechte UX, sie zurück in den Review Order zu bringen. Was jetzt?

Sie schlagen ziemlich vernünftig vor, dass die mit calculateOrder gesendete Rückruffunktion einen intendedStartingPoint Parameter an setLocation übergeben sollte. Sie machen sich Sorgen, dass Sie dazu jeden Aufruf an setLocation ändern müssen, um den neuen Parameter zu berücksichtigen. Keine Angst, JavaScript bietet eine gute Möglichkeit, dieses Dilemma zu lösen.

Sie können einen neuen Parameter zu setLocation hinzufügen, ohne die bestehenden Aufrufe zu ändern. Dies erfordert lediglich, dass intendedStartingPoint das letzte Argument in der Argumentliste von setLocation sein muss. Dann kann Ihre neue Version von setLocation den Wert von intendedStartingPoint überprüfen, um zu sehen, ob es undefined ist.

Wenn intendedStartingPointundefined ist, wissen Sie, dass setLocation empfängt einer der alten Anrufe, diejenigen, die nicht intendedStartingPoint passieren kann. In diesen Fällen ignorieren Sie intendedStartingPoint und fahren fort wie zuvor. Andernfalls vergleichen Sie intendedStartingPoint mit der aktuellen Position und fahren entsprechend dem Ergebnis des Vergleichs fort. Ein noch besserer Ansatz wäre, den neuen Parameter nicht intendedStartingPoint zu machen, sondern ein Objekt namens options, das intendedStartingPoint als eines seiner Attribute enthält. Dadurch können Sie weitere optionale Werte an setLocation übergeben, wenn dies in Zukunft erforderlich ist.

Das neue Verhalten von setLocation ist ziemlich einfach. Bevor Sie einen neuen Standort festlegen, prüfen Sie, ob intendedStartingPoint dem aktuellen Standort entspricht. Wenn dies der Fall ist, müssen Sie nichts tun, da der Benutzer bereits dort ist, wo er sein soll.Aber wenn die intendedStartingPoint unterscheidet sich von der aktuellen Position ist, hat der Benutzer navigiert weg, so dass Sie etwas tun:

if (LocationManager.currentLocation !== options.intendedStartingPoint) { 
    // Tell the user that the calculation has finished. 
    // Ask her if she wants to return to Review Order now. 
}