Full-screen applicaties: de gevolgen voor web usability

Geschreven op 2011-09-14 • gesprek

Het is voor de meeste web designers en front-end developers vanzelfsprekend, maar vandaag werd ik weer hard met de neus op de feiten gedrukt: een link automatisch in een nieuw browservenster laten openen vormt een usabilityprobleem.

Het meest gehoorde argument is dat bezoekers in de war geraken—zie Jakob Nielsen: Top 10 Mistakes in Web Design. Je zou kunnen redeneren dat zoiets alleen van toepassing is bij bezoekers die niet zo oplettend zijn: de Vorige knop wordt immers uitgeschakeld, waardoor je gewoonlijk wel merkt dat er een nieuw venster geopend werd. Het is éen van de vele visuele hints die ervoor zorgen dat je meestal zonder al te veel wrijving terug kan geraken waar je wou zijn.

Back to the Future

Als gevolg van het terugkeren naar fullscreen computergebruik (zie OS X Lion & Windows 8) gaat dat type argument helaas niet meer op. Tijdens een fullscreen surfsessie (op mijn 13″ scherm geen overbodige luxe) opende een link zonder enige aanwijzing een nieuw venster. Omdat fullscreen surfen betekent dat je geen browserinterface ziet, had ik geen aanwijzing dat er een nieuw venster geopend werd. Ik wilde graag terugkeren naar de pagina waar ik vandaan kwam, maar aan mijn swipe naar links werd door de browser geen gevolg gegeven—normaal gezien keer ik daarmee terug naar de vorige pagina. Omdat ik geen feedback kreeg wist ik bovendien niet wat er aan de hand was.

Het probleem met externe links oplossen

Je kan zeggen dat zoiets voor een stuk aan browsermakers ligt en dat klopt ook. Ik kan minstens vijf manieren bedenken waarop een browser duidelijk zou kunnen maken dat er een nieuw venster geopend werd—ook in full-screenmodus. Maar web designers hebben de verantwoordelijkheid om zich aan de huidige situatie aan te passen en dat betekent rekening houden met de huidige beperkingen van full-screen browsen.

Persoonlijk zou ik het probleem oplossen door de bezoeker bij bepaalde links de keuze te geven om het in een nieuw venster te openen of niet. Op die manier is a priori duidelijk welke actie volgt na een interactie. Via jQuery/JavaScript kan je achter elk ankerelement met bijvoorbeeld een rel="external"- of class="external"-attribuut tussen haakjes de link te herhalen met een target="_blank"-attribuut. Quick and dirty ziet dat er als volgt uit:

$(document).ready(function() {
	$('a[rel="external"]').each(function() {
		$(this).after(
			" (<a href=\""
			+ $(this).attr("href") +
			"\" target=\"_blank\">Open in nieuw venster</a>)"                      
			);
	});
});

Web apps moeten zich gedragen als native apps

Waarom full-screen HTML5 websites een grotere toekomst hebben dan native apps is voer voor een andere post. Maar het probleem dat ik eerder omschreven heb past wel in een groter kader waarbij het voor een web designer nog belangrijker wordt om rekening te houden met het feit dat de browserinterface straks helemaal afwezig is. Eenvoudig gezegd betekent het dat je elke website als web-app kan behandelen: met een eigen interactiemodel en voldoende visuele clues waaruit bezoekers die interacties kunnen afleiden. Wat die clues juist kunnen zijn zal ik in een volgende post proberen samen te vatten.

Conversation is closed

Conversations close automatically after six weeks. Feel free to contact me directly if you have feedback on this article.