Fronteers — vakvereniging voor front-end developers

Webrichtlijn 63 t/m 66: Links naar downloadbare bestanden

Bij het aanbieden van downloadbare bestanden, informeer de bezoeker over hoe deze te downloaden en vervolgens te gebruiken. (R-pd.8.20) Serveer bestanden met het correcte MIME type. (R-pd.8.21) Open links naar downloadbare bestanden niet in een automatisch nieuw venster. (R-pd.8.22) Serveer downloadbare bestanden niet met opzet een onbekend of incorrect MIME type om de browser tot een bepaald gedrag te dwingen. (R-pd.8.23)

Hoe informeer jij bezoekers over bijvoorbeeld het type en de grootte van het bestand? Doe je dit middels het title attribuut, of tussen haakjes? En wat is in dat laatste geval handiger? De uitleg in de link, of na de link? Gebruik je voor het type van het bestand ook het type attribuut, of gaat dat te ver?

Bij wie ligt volgens jou de verantwoordelijkheid voor correcte MIME-types? Hoort dit thuis in een CMS, bij de back-end ontwikkelaars of moet dit vastliggen in de serverconfiguratie? Dit zou een makkelijk te wijzigen lijstje met variabelen moeten zijn, maar waarom is dit zo vaak een probleem? Ligt dit aan (verouderde) software op de server, of aan onwetendheid bij een bepaalde partij? Hoe ga je hier mee om?

Links naar downloads niet laten openen in een nieuw venster is een duidelijke richtlijn, maar waarom moeten we voorkomen dat plugins in een browser het bestand ook in de browser openen? We mogen toch aannemen dat gebruikers hiervoor bewust gekozen hebben bij het installeren van een plugin? Of dat browser bouwers hier wat onderzoek naar gedaan hebben, voordat ze tijd en energie staken in het ontwikkelen van een plugin-architectuur? De Content-disposition: attachment opmerking leidt nog net niet tot een richtlijn, maar hoe kan het dat zoveel mensen het niet prettig vinden als een bestand in de browser geopend wordt, terwijl dit wel de standaard instelling is?

En bij welk type bestand trekken we de grens? Waarom zou je JPG'jes wel in je browser laten openen, maar PDF'jes niet? Als browsers straks zelf video's af kunnen spelen, worden ze dan gezien als downloads, of niet?

Reacties

1 Wim van Iersel op 18-11-2008 om 23:53 uur:
Is het niet zo dat Jacob Nielsen over het openen van PDF documenten zegt dat je deze juist wel in een nieuw venster moet openen? Dit ben ik namelijk tegen gekomen tijdens de ontwikkeling van de website bij de gemeente Tilburg.

Helaas eiste ze bij ons dat externe sites altijd in een nieuw venster moesten openen... ik heb uiteindelijk de handdoek in de ring moeten gooien op dat punt.
2 Boye Oomens op 19-11-2008 om 11:54 uur:
Leuke kwestie dit…het type attribuut gebruik ik eerlijk gezegd nooit. Mocht het CMS en of de serverconfiguratie niet toereikend zijn m.b.t. MIMETYPES, dan vang ik dit af door een AddType handler toe te voegen in de htaccess.
3 Willem Bogaerts op 26-11-2008 om 11:09 uur:
Bij wie ligt de verantwoordelijkheid? Geen idee, maar dat is ook een organisatorische aangelegenheid. Waar ligt de verantwoordelijkheid? Dat moge toch duidelijk zijn. Als de web server direct een bestand serveert, is de webserver verantwoordelijk voor het meesturen van een correcte mime-type header. Als je een downloader script gebruikt is dat script verantwoordelijk.
4 BARTdG op 27-11-2008 om 00:10 uur:
Ik weet niet meer precies hoe dit zit, maar is het niet zo, dat als je in Windows in IE bv. een .doc opent in het browser-venster, en je drukt op Save, dat het dan wordt opgeslagen in je Temporary internet files?

Klopt dit? Zo ja, dan moet je daar m.i. rekening mee houden en altijd gaan voor Content-disposition:attachment. Anders is het bestand voor veel mensen onvindbaar.

Laat maar weten als dit niet klopt, maar ik herinner me dat ik ooit op die manier een gedownload bestand heb moeten opzoeken.

Iets anders: ik heb wel eens gewoon 2 links opgenomen: 1 voor het weergeven van een dynamisch gegenereerde .png en 1 voor het downloaden van het ding.
5 Raph de Rooij op 27-11-2008 om 15:12 uur:
@Wim: misschien kun je op basis van onderstaande argumentatie alsnog je gelijk halen; er wordt immers altijd een nieuw venster geopend ;-)

PDF-bestanden en andere downloadbare bestanden moet je gewoon helemaal niet in een browservenster WILLEN openen. Het stamt nog uit de tijd dat Microsoft dacht dat de browser een nieuw soort desktop-omgeving zou gaan worden. Dat wordt het op den duur waarschijnlijk wel, maar dan niet op de manier waarop Micorosft (destijds?) dacht dat er invulling aan diende te worden gegeven: desktopapplicaties in een webomgeving.

downloadbare bestanden dienen gewoon via Content-disposition:attachment te worden geserveerd, waarna het erbij horende programma wordt geopend. Dat is precies wat Jacob Nielsen ermee bedoelt: een nieuw venster, maar dan vooral geen nieuw BROWSERvenster.
Overigens kan hulpprogrammatuur en -apparatuur daarmee prima overweg, terwijl dat bij het onaangekondigd openen van een nieuw browservenster juist weer niet het geval is.

Over dit onderwerp is al een boom opgezet op de Stijlgids-website[1].
Uit het weblogartikel:

"Oorzaak van het 'probleem' is de manier waarop doorgaans in browsers wordt omgegaan met populaire bestandsformaten als .pdf, .doc, .rtf, .xls en .ppt. De programma's waarmee deze bestanden kunnen worden geopend worden als een plug-in geladen in de browser, waardoor de bestanden in het browservenster worden getoond. Usability goeroe Jacob Nielsen deed in zijn artikel 'Open New Windows for PDF and other Non-Web Documents'[2] een aantal aanbevelingen hoe het beste kan worden omgegaan met downloadbare bestanden. De eerste twee aanbevelingen - open ze in een nieuw venster en waarschuw de gebruiker van tevoren dat het gaat gebeuren - zijn opgenomen in de Stijlgids. De aanbeveling die Nielsen zelf als de beste bestempelt komt er echter niet in voor: voorkom dat het bestand door de browser geladen wordt. In de Webrichtlijnen is de aanbeveling wel overgenomen, zie pagina 'Links naar downloadbare bestanden'[3]."

[1]: http://stijlgids.overheid.nl/actueel/weblog/downloadbare_bestanden_openen_in_een_nieuw_venster/
[2]: http://www.useit.com/alertbox/open_new_windows.html
[3]: http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/downloadbare-bestanden/#voorkomen-in-browservenster
6 Krijn op 27-11-2008 om 15:25 uur:
Een 'downloadbaar bestand' is dus een bestand dat de browser niet native ondersteunt?
7 Rick op 28-11-2008 om 10:51 uur:
@Raph de Rooij
Ik vind het openen van PDF files in de browser juist wel fijn, idem voor MP3 files die in de browser worden geopend (QuickTime plugin). Veel mensen hebben er namelijk een hekel aan wanneer een externe applicatie moet worden geopend (buiten de browser), nog even los van de vraag of dit wel de bedoeling is. Kijk bijvoorbeeld naar het grote succes van de Flash players tegenwoordig. En ik vind in dit geval de usability belangrijker dan het volgen van de spec.
8 Mathijs Kadijk op 01-12-2008 om 17:57 uur:
De definitie van "downloadbare bestanden" is een beetje vaag. Zelf zou ik onderscheid willen maken tussen het linken naar een bestand als referentie of als download.

Als je een link plaatst naar een pdf, mp3 of iets dergelijks als referentie. Zodat de gebruiker het geluid van het vogeltje kan horen, of de specificaties van een product even door kan nemen zou ik de browser (daarmee dus de gebruiker) willen laten bepalen hoe het document geopend gaat worden. In deze situatie wil je het bestand namelijk niet opslaan, maar alleen even raadplegen om bepaalde informatie te vinden. De gebruiker kan er dan zelf altijd nog voor kiezen het bestand op te slaan.

Op het moment dat je echter iemand iets ter download aan wil bieden. Bijvoorbeeld bij een gratis mp3 of een PDF versie van de informatie op de pagina. Dan zou ik met een Content-disposition:attachment een download afdwingen en ook netjes het woord "Download" vermelden bij de link.

Uiteraard zijn er nog enorm veel verschillende situaties waar je hiermee niet uit de voeten kan en het onduidelijk is of je een download "af wilt dwingen". Dan zou ik toch de webrichtlijn aanhouden, omdat de gebruiker dan altijd alsnog op de eigen schijf op kan slaan.

Overigens is het inderdaad wel een ramp als een browser een tekstdocument vanuit een tijdelijke map opent en daar ook weer op laat slaan. Zo is menig kennis van mij al eens een document kwijt geraakt, ik denk alleen dat je dit als ontwikkelaar niet echt op moet willen lossen. Het is meer een probleem van de browserfabrikant en de gebruiker die zijn browser niet goed kent.
Plaats een reactie