[fp/bug] Back button fubar bij klikbare plaatjes

[Tyrian]

Bij nieuwspostings als deze waar klikbare plaatjes worden gebruikt is de back button niet meer functioneel om terug te gaan van het full-size plaatje naar het oorspronkelijke nieuwsbericht. Dit verlaagt de gebruiksvriendelijkheid van het artikel imho.

Tags: "back button", vorige, thumbnails.

[moto-moi]

Naast de plaatjes klikken of op het knopje 'sluiten' werkt hier anders prima? Dat de backknop niet werkt is logisch, het is tenslotte geen nieuwe pagina, maar een overlay die on demand wordt opgebouwd.

[Glaanie]

En een klikje buiten het kader of op het knopje 'Sluiten (X)' is teveel moeite? De backbutton werkt niet, omdat je de pagina in feite niet verlaat. Je opent slechts een nieuw venster, die gewoon gesloten kan worden (OK, technisch gezien is het een div met een hoge z-index, maar het principe is hetzelfde).

Edit: En wederom zijn mijn wannabee mod-taken ernstig verstoord door een echte mod

[ Voor 12% gewijzigd door Glaanie op 23-08-2008 14:05 ]

[Tyrian]

Het is beter om bij de standaard browser knoppen te blijven in plaats van een eigen oplossing te maken. ("Naast de plaatjes klikken of op het knopje 'sluiten'") Het is immers voor de gebruiker onpraktisch om voor elke site een andere manier van navigatie te gebruiken.

Dat de backknop niet werkt is logisch, het is tenslotte geen nieuwe pagina, maar een overlay die on demand wordt opgebouwd.

Hoe het technisch gezien is opgebouwd daar heeft de gebruiker natuurlijk weinig boodschap aan. Het gaat hier om de bediening/usability.

[Harm]

Is dit probleem niet omwerkbaar door een '#plaatje1' aan de url in de adresbalk toe te voegen? Of is dat niet de manier waarop ajax-pagina's normaal gesproken de werking van de terugknop in stand houden?

[edit]
Ik zou het namelijk ook wel handig vinden als ik gewoon met mijn gewone browsersneltoetsen terug kan naar de vorige pagina. Nu moet ik verplicht een muis pakken.

[ Voor 29% gewijzigd door Harm op 23-08-2008 14:12 ]

[posttoast]

Als de vorige pagina gewoon hetgeen onder de overlay is kun je toch de ESC-toets op je keyboard gebruiken? Heb je die muis niet nodig.

Edit: niet dus, dat is misschien wel een mooie nieuwe feature (is vrij gebruikelijk in dit soort lightbox-oplossingen).

[ Voor 31% gewijzigd door posttoast op 23-08-2008 14:15 ]

[crisp]

Keyboard-support (o.a. voor ESC) staat nog op de ToDo

[BtM909]

Tyrian schreef op zaterdag 23 augustus 2008 @ 13:50:
Bij nieuwspostings als deze waar klikbare plaatjes worden gebruikt is de back button niet meer functioneel om terug te gaan van het full-size plaatje naar het oorspronkelijke nieuwsbericht. Dit verlaagt de gebruiksvriendelijkheid van het artikel imho.

Hoe wordt de gebruiksvriendelijkheid verlaagd als je geen pagina verlaat? De back + forward knoppen hebben pagina navigatie doeleinden. Als jij naar beneden scrollt, werkt back + forward ook niet in dezelfde lijn.

Tags: "back button", vorige, thumbnails.

offtopic:
tag je je post nou voor de search? Grappig

[Harm]

BtM909 schreef op donderdag 28 augustus 2008 @ 11:01:
[...]

Hoe wordt de gebruiksvriendelijkheid verlaagd als je geen pagina verlaat? De back + forward knoppen hebben pagina navigatie doeleinden. Als jij naar beneden scrollt, werkt back + forward ook niet in dezelfde lijn.

Omdat het lijkt alsof je dat wel doet. Je opent namelijk nieuwe content (afbeeldingen) en daarmee verlaat je voor je gevoel (technisch gezien niet) de pagina waar je vandaan komt. Dit vergelijken met scrollen is niet helemaal eerlijk, omdat je bij scrollen zelf de scrollactie uitvoert. Echter, als je naar een anchor op dezelfde pagina wordt gestuurd (url à la http://tweakers.net/nieuws/11111/#reacties) dan komt die wèl in je browsegeschiedenis te staan en werkt de back-knop wel.

[BtM909]

Harm schreef op donderdag 28 augustus 2008 @ 11:15:
[...]
Omdat het lijkt alsof je dat wel doet. Je opent namelijk nieuwe content (afbeeldingen) en daarmee verlaat je voor je gevoel (technisch gezien niet) de pagina waar je vandaan komt. Dit vergelijken met scrollen is niet helemaal eerlijk, omdat je bij scrollen zelf de scrollactie uitvoert. Echter, als je naar een anchor op dezelfde pagina wordt gestuurd (url à la http://tweakers.net/nieuws/11111/#reacties) dan komt die wèl in je browsegeschiedenis te staan en werkt de back-knop wel.

Nogmaals dan doe je een pagina (navigatie actie). Al die lightboxjes zijn eigenlijk functionaliteit wat IE, ondere andere, al had met de image bar. Op een site kan ik snel inzoomen op een thumbnail. Dat is niet hetzelfde als navigeren.

Hence m'n vergelijking met scrollen. Ik wilde het ancor voorbeeld nog toevoegen, maar dacht dat dat al duidelijk was

[Janoz]

* Janoz is het eens met Tyrian. Ik heb zelfs al een paar keer gehad dat ik op de backspace of op het back kknopje op de muis drukte om de plaatjes weg te krijgen.

[Patriot]

Ik sluit me hier wel bij aan. Vooral bij grotere afbeeldingen vergis je je nog wel eens en kom je opeens op de vorige pagina uit. Het is inderdaad een relatief kleine moeite om op sluiten te drukken, maar het zou net dat kleine beetje handiger zijn als je ook de backspace knop zou kunnen gebruiken.

[Room42]

Tip voor tweakers met Firefox en Adblock: Block "http://tweakimg.net/x/imageviewer.js" en je plaatjes openen zich voortaan weer gewoon in een nieuw venster. Ideaal, imho

[ Voor 3% gewijzigd door Room42 op 31-08-2008 01:42 ]

[Patriot]

Mja, dat vind ik weer een beetje overdreven, want in principe is het ook wel handig dat niet de hele pagina opnieuw hoeft te laden. Een oplossing met anchors is imho beter, en volgens mij helemaal niet zo moeilijk om te implementeren.

[Room42]

tja, ik middel- (of ctrl-) click ze altijd allemaal open om ze vervolgens met ctrl-tab langs te lopen. Dat werkt imho fijner dan die viewer omdat ze dan tenminste ook meteen full-size zijn. Full-size viewen in de imageviewer van T.net is sowieso niet fijn. Dan blijf je scrollen Ook dat de "volgende" knop de hele tijd verspringt is

[crisp]

esc-support zit inmiddels al een tijdje in de imageviewer. <backspace> support vind ik nog steeds twijfelachtig: je verlaat immers (zichtbaar) niet de pagina zelf; als je dat wilt ondersteunen dan zou elke navigatie binnen de imageviewer zelf ook een historyentry moeten worden. Dat laatste ben ik nog nooit tegengekomen, dus onze huidige implementatie sluit daarmee waarschijnlijk beter aan bij de verwachtingen van de gebruiker bij vergelijkbare imageviewers.