[UX] Browser history: gegevens vernieuwen na aanpassing?

[egonolieux]

Ik heb een website waarbij dezelfde informatie op meerdere pagina's weergegeven wordt. Stel nu dat de gebruiker van pagina X naar pagina Y gaat en op pagina Y een item aanpast (met AJAX). Vervolgens drukt de gebruiker op de browser back knop. Is het dan gewenst dat pagina X de laatste versie van het aangepaste item toont, of dat de pagina exact wordt weergegeven zoals de gebruiker hem verlaten heeft?

Langs de ene kant denk ik dat de gebruiker de aangepaste informatie wil zien, maar langs de andere kant lijkt mij dat te vloeken met het concept "history".

[TERW_DAN]

Het is lastig hier iets over te zeggen, zonder te zien hoe het daadwerkelijk in elkaar steekt. Wat je je denk ik moet afvragen, is wat de gebruiker als pagina ervaart, en wat het gewenste resultaat is.

Dezelfde informatie op meerdere pagina's klinkt sowieso als een raar concept, wat voor een gebruiker erg onduidelijk is.

[egonolieux]

TERW_DAN schreef op dinsdag 17 oktober 2017 @ 22:27:
Het is lastig hier iets over te zeggen, zonder te zien hoe het daadwerkelijk in elkaar steekt. Wat je je denk ik moet afvragen, is wat de gebruiker als pagina ervaart, en wat het gewenste resultaat is.

Dezelfde informatie op meerdere pagina's klinkt sowieso als een raar concept, wat voor een gebruiker erg onduidelijk is.

Ik heb het hier in abstracte termen verwoord, maar mijn concrete implementatie is niet zo vreemd hoor . Het gaat over een lijst met items waarbij de gebruiker het aantal per item kan aanpassen (pagina X). Pagina Y is dan de detailpagina van de item in kwestie, waarop het aantal ook kan aangepast worden.

Op de detailpagina wil ik een knop voorzien die de gebruiker terug naar het overzicht (lijst) brengt. De vraag is dan of ik de knop laat functioneren als de browser history back knop (al dan niet met Cache-control: no-store voor de overzichtpagina), of dat ik gewoonweg de gebruiker met een link er naar stuur.

[TERW_DAN]

Ik zou zeggen dat als je op de terugknop klikt als je op die detailweergave bent (al dan niet met aanpassingen), en je klikt op terug, dat je dan op de pagina terecht komt met de lijst.

Wijzigingen/fitlers die je dan doet zou je op kunnen slaan en toe kunnen passen, als dat een zinnige usecase is.

[egonolieux]

Ik heb eens wat zitten rondkijken op andere sites en het grootste deel geeft de meest recente data weer bij het teruggaan met de browser back button (soms met AJAX, soms met Cache-control: no-cache).

Los van het bovenstaande feit, stel nu dat je een pagina hebt waarop je op producten kan filteren. Telkens als je een filter aanklikt, wordt het resultaat herladen met AJAX en wordt er met history.pushState een nieuwe entry aan de browser geschiedenis toegevoegd met de data van de huidige filters. Als je terug gaat in de geschiedenis wordt de popstate event geactiveerd en haal je adhv de filterdata uit de popstate event de resultaten opnieuw op met AJAX. Dit heeft dus eigenlijk als implicatie dat je met dynamische pagina's vrijwel altijd de meest recente data ophaalt, ook al ga je terug in de geschiedenis.

Kwestie van consistentie (en gebruiksgemak) denk ik dus dat telkens de meest recente resultaten weergeven de beste optie is.

[Cubix]

Probeer je in te leven in de gebruiker en vraag je af wat de redenen kunnen zijn om op “back” te klikken. Wat is de verwachting? En pas daar het gedrag op aan.

Als je de mogelijkheden hebt zou je het in een usabilitytest kunnen toetsen. Of goedkoper: vraag de gebruiker bij wijze van test om feedback na het gebruik van de back knop.

[Harrie_]

egonolieux schreef op vrijdag 20 oktober 2017 @ 06:03:
Ik heb eens wat zitten rondkijken op andere sites en het grootste deel geeft de meest recente data weer bij het teruggaan met de browser back button (soms met AJAX, soms met Cache-control: no-cache).
[...]
Kwestie van consistentie (en gebruiksgemak) denk ik dus dat telkens de meest recente resultaten weergeven de beste optie is.

In aanvulling op de opmerking van @Cubix: dat is ook wat de user verwacht en denk ik ook wat je zelf als eindgebruiker zou verwachten. De data niet refreshen bij een history.back is gewoon verwarrend.

Stel je hebt een profiel-pagina waar staat ingevuld dat je in Amsterdam woont. Je drukt op -edit- en past dit aan naar Rotterdam. Je krijgt als user een response waarbij wordt gemeld dat 'de wijzigingen succesvol zijn opgeslagen', vervolgens druk je op de back-knop om terug te gaan naar je profiel-pagina waar je weer vrolijk 'woonplaats: Amsterdam' ziet staan. Ik denk dat er maar heel weinig usecases zijn waar het wenselijk is dat je bij een history.back de oude data laat zien...

[Cubix]

Bij veel mensen is het pagina gebaseerde internet de standaard. En daar hoort de back-knop ook bij. Ajax-achtige interacties en content-updates maken dat model ingewikkeld.

Daarom maak ik vaak duidelijk de keuze om het het voor bepaalde doelgroepen gemakkelijk te maken door aan het pagina-model te kiezen zodat bookmarks, backknop etc nog lekker blijven werken zoals ze verwachten. Pas als ik een webapplicatie aan het ontwerpen ben laat ik dat los.

[Harrie_]

Cubix schreef op vrijdag 20 oktober 2017 @ 13:26:
Bij veel mensen is het pagina gebaseerde internet de standaard. En daar hoort de back-knop ook bij. Ajax-achtige interacties en content-updates maken dat model ingewikkeld.

Daarom maak ik vaak duidelijk de keuze om het het voor bepaalde doelgroepen gemakkelijk te maken door aan het pagina-model te kiezen zodat bookmarks, backknop etc nog lekker blijven werken zoals ze verwachten. Pas als ik een webapplicatie aan het ontwerpen ben laat ik dat los.

Ook bij webapplicaties hou ik dat in stand, de eindgebruiker zit in een browser en ik mag mijn prachtige product dan wel een webapplicatie vinden maar mijn ervaring leert dat de eindgebruiker het toch beschouwt als een website.

Voor webapplicaties duw ik consistente vars ook altijd naar de clean url, zodat webapp.local/verkooporders/klant/1403/sortdesc/leverdatum/ zonder problemen gebookmarkt kan worden...