Gisteren werd het nieuwe seizoen voor en in nachttheater Sugar Factory in Amsterdam geopend. Een leuke aanleiding om weer eens een website aan een kritische blik te onderwerpen. Dit theater (ik zou het een club noemen, maar ze bieden veel meer) bestaat relatief kort en zit vlakbij het Leidseplein, tegenover de Melkweg. Een superlocatie, met een super uiterlijk van binnen en bijpassende uitstraling in de marketing. Gisteren werden een aantal highlights van het aankomende seizoen gepresenteerd; de jongen van poëzie avond The Open Stanza was erg vermakelijk (zeker eens gaan kijken of zelf bijdragen!), en de mannen van Kofi Anonymous kregen zelfs de 3/4 lege en matte zaal enizgszins in beweging met hun funky tunes. Maar laat ik me bij mijn leest houden… we bekijken de Sugar Factory website. Guess what…
De website is geheel in een stijl die je kunt verwachten van zo’n organisatie: hippe kleuren, grote platen, stoere taal. En bepaald niet gebruiksvriendelijk. Omdat ik waarde hecht aan mijn contacten daar gaan we er even gestructureerd naar kijken. Niet in de laatste plaats omdat ik hoop dat mijn gefundeerde mening ook echt navolging krijgt. Dan blijft de Sugar Factory nog lang bestaan, en kan ik er nog vaak heen 🙂
Na elke usability issue staan een paar concrete todo’s voor de webbouwer of Sugar Factory staff, voorzien van prioriteit. Laat het duidelijk zijn dat het hier een vluchtige blik betreft op een site waar veel aan kan gebeuren. De hardcore zoekmachine optimalisatie en usability muggezifterij bewaren we voor over een paar jaar, als Sugar Factory de meest succesvolle website van het Nederlandse uitgaansleven heeft.
Frames
Jaja: frames! Alle frames moeten natuurlijk worden verwijderd. Dat betekent dat elke pagina een eigen zichtbare URL (webadres) heeft, met alle voordelen van dien. Dit is een absolute voorwaarde om de site enigszins bruikbaar te maken voor bezoekers. Er zijn tig redenen om frames niet te gebruiken, de belangrijkste dat het hele idee van het WWW om zeep geholpen wordt. Het WWW bestaat uit aan elkaar hangende webpagina’s. Frames proppen meerdere pagina’s in elkaar, waardoor niet meer contextueel gelinked kan worden.
Even snel een paar van de grootste nadelen van frames, mocht iemand daar behoefte aan hebben:
- Webpagina’s kunnen niet gebookmarked worden. Alleen de homepage is te bookmarken, maar als iemand een bepaald feest in zijn bookmarks wil zetten, kan dat niet.
- Webpagina’s kunnen niet doorgestuurd worden. Er is voor een site als Sugar Factory weinig belangrijkers dan dat bezoekers de site aan hun vrienden doorsturen. “Ik ga naar dit feest, kom je mee?”. Maar dan zit er niks anders op dan te linken naar SugarFactory.nl en te hopen dat de ander ook dat precieze feest kan vinden.
- Webpagina’s kunnen niet goed geprint worden. Sommige browsers, zoals Mozilla Firefox, hebben dit probleem aardig onder de knie, maar Internet Explorer bakt er weinig van. Alleen het eerste frame wordt afgedrukt. Erg onhandig als je bijvoorbeeld de agenda van Sugar Factory aan de muur wil hangen…
- Zoekmachines kunnen de site niet goed indexeren. Omdat er veel kleine pagina’s zijn waar onvolledige informatie op staat, en deze pagina’s niet met elkaar in verbinding staan. Mocht het ooit voorkomen dat Sugarfactory.nl in een zoekmachine scoort, dan krijg je dit soort resultaten. Gebruikers weten niet waar ze terecht zijn gekomen, en kunnen niet verder. Dat ziet er bij Google trouwens ook niet netjes uit.
Er is voor een site als Sugar Factory weinig belangrijkers dan dat bezoekers de site aan hun vrienden doorsturen. “Ik ga naar dit feest, kom je mee?”.
Als elke pagina een echt eigen pagina is, moet vervolgens elke pagina ook een eigen titel krijgen. Het beste voor gebruikers en zoekmachines is om titels dit format te geven: [titel van de pagina] – Sugar Factory
Wanneer een gebruiker dan de pagina bookmarked of ziet staan in zijn taakbalk, ziet zij direct waar ze is, wat voor informatie de pagina bevat. Overigens moet Sugar Factory (SF) de titels maken, maar waarschijnlijk moet de webbouwer (WB) het CMS ook aanpassen zodat dit mogelijk is.
| Wat to do? | Wie? | Prio |
| Geen frames meer op de site gebruiken. Nooit. Nergens! | WB | 1 |
| Elke pagina zijn eigen duidelijk omschrijvende titel geven. | SF | 1 |
Typografie
Nog vaak wordt door vormgevers gedacht dat letters er ook op een beeldscherm “lekker” uitzien als ze onleesbaar klein zijn. Helaas, letters zijn bedoeld om te lezen, dus ze moeten leesbaar zijn. Voor koppen worden kapitalen gebruikt, die ook slechter leesbaar zijn dan gewone kapitalen en onderkasten. Ook zijn de letters in Internet Explorer niet te vergroten of verkleinen, waardoor mensen zelfs als ze weten hoe het moet, de site niet lekker kunnen lezen.
Verder wordt voor een aantal soorten tekst een hele lichte kleur blauw gebruikt, uit de huisstijl. Die kleur is op een beeldscherm echter niet geschikt om tegen een witte achtergrond weergegeven te worden. Ook als achtergrond van zwart, en lichtblauw als tekst op zwarte achtergrond, is het contrast behoorlijk slecht. Maar vanuit estetisch oogpunt is dat nog wel te overleven.
Tot slot worden voor veel koppen plaatjes gebruikt. Het gebruikte lettertype geeft daar echter geen aanleiding toe, er zou net zo goed gewoon CSS voor gebruikt kunnen worden. Plaatjes maken de site trager en slechter toegankelijk Ze zijn immers niet te vergroten/ verkleinen, en zoekmachines kunnen er niks mee.
Er zijn ook prima CSS trucs waarmee je de tekst in gewone HTML schrijft, maar de plaatjes in de CSS aanroept om zo toch die mooie letters te krijgen.
| Wat to do? | Wie? | Prio |
| Lettertype vergroten naar minstens 80% van standaard lettertype | WB | 1 |
| Lettertype schaalbaar maken (dus: uitdrukken in % of em) | WB | 2 |
| Geen zwart op lichtblauw gebruiken, geen lichtblauw op wit. | WB | 2 |
| Geen plaatjes maar CSS gebruiken voor tekst opmaak, of alternatief bieden in de vorm van tekst + CSS. | WB | 3 |
Firefox & Javascript
Uit de statistieken van de website blijkt dat maar een paar procent van de bezoekers Firefox gebruikt. Er is wel een behoorlijk aandeel Apples, maar die zouden wel eens op het Sugar Factory kantoor kunnen staan, want hun aandeel was hoger dan gebruikelijk.
Firefox zal echter een steeds grotere plek op de markt innemen, op de meeste websites loopt het aandeel tegen de 15%. SugarFactory.nl is voor hen nog iets onhandiger, doordat allerlei Javascript rollovers niet werken. Nu zijn die niet echt nodig, maar het is wel erg handig als je bijvoorbeeld je muis cursor ziet veranderen als je over een link heen gaat.
Het echte en groteren probleem is hier echter dat er allerlei Javascript code wordt gebruikt waar dat helemaal niet nodig is. Voor rollovers kun je gewoon het CSS attribuut “hover” gebruiken. En als een link gewoon een “a href” is, maakt elke browser er vanzelf wel een “handje” cursor van.
| Wat to do? | Wie? | Prio |
| Javascript niet meer gebruiken voor rollovers | WB | 3 |
| Alternatief: Javascript geschikt maken voor andere browsers dan Internet Explorer | WB | 3 |
| Javascript niet gebruiken voor links, vervangen door gewone a href’s. | WB | 1 |
Language gebruik
Alle communicatie van Sugar Factory is in het Engels. Dat staat stoer, het geeft Amsterdam en het theater een internationaal karakter en het argument zal zijn dat veel van het gewilde publiek Engels praat. Ik vraag me echter af of dat wel echt zo is. De paar Engels sprekenden die ik gisteren tegen kwam konden allemaal ook Nederlands omdat ze hier al jaren woonden.
92% van de bezoekers komt uit Nederland en waarschijnlijk meer dan dat want Webalizer is niet echt betrouwbaar. Een aantal andere clubs schrijven gewoon in het Nederlands: Paradiso, Melkweg, Club 11. Maar er zijn er natuurlijk ook die het bij hip Engels houden: Panama (gemixt), Hotel Arena, Jimmy Woo. Eigenlijk doet alleen Odeon het goed: je kunt kiezen. Maar zij hebben dan ook bijna geen content online staan, dus dat is makkelijk praten schrijven.
Echt consequent wordt er ook niet omgegaan met de taal, want Sugar Factory heet gek genoeg wel gewoon “nachttheater” en veel van het nieuws wordt ook Nederlands geschreven.
Sugar Factory kan en moet met de Nederlandse website bezoekers een band op bouwen, niet met toeristen. Die hebben veel minder toegang tot internet en zijn twee weken later weer weg. De ideale oplossing is een geheel Nederlandse site, met een Engels klein zusje, waar het programma en de het theater kort worden uitgelegd.
Op posters en flyers in de stad lijkt me Engels trouwens wel een goede keuze.
| Wat to do? | Wie? | Prio |
| Website in het Nederlands schrijven | SF | 3 |
| Ideaal alternatief: site in Engels en Nederlands beschikbaar maken. | WB | 3 |
Wat vind jij?
Ik moet zeggen dat ik wel geinspireerd raak door de site van Sugar Factory. Er is zoveel meer uit te halen, met wat meer focus en slimheid op en in online marketing. Misschien overdrijf ik: mag een hip nachttheater niet gewoon een hippe niet-zo-gebruiksvriendelijke site hebben? Is de coole uitstraling van de Engelse taal niet belangrijker dan dat suffe Nederlands?
Het leuke van deze branche is dat nog meer dan in het “gewone” bedrijfsleven imago en design boven duidelijkheid en usability worden geplaatst. Wat zou er gebeuren als een club het roer radicaal omgooit en afscheid neemt van alle opsmuk, Flash en overdesigned spul? Welke kansen zien jullie hierin voor Sugar Factory en haar concullega’s?
usarchy.com 
Goede punten waar ik me in kan vinden, ben benieuwd of ze er wat mee doen. Vaak schint het hip-gehalte bij dit soort tenten superieur aan usability.
Lijkt me zeker een bezoekje waar als ik het programma zie! Daarin wel een usability issue: als je doorklikt naar meer details van een dag kan je alleen nog met een zeer onduidelijke clipart-achtige back button terug naar het overzicht van het programma, de ‘Program’ knop bovenaan was inactief.
Overigens wel een leuke feature: een reminder service die kan je een x aantal dagen voordat het plaatsvindt een mailtje sturen.
Je hebt trouwens de aanbevelingen, what to do’s, een stuk duidelijker weergegeven!
LikeLike
Je gaat wel wat snel Ruben, waarbij je wat slordige conclusies trekt. Vandaar even onderstaand gezeur:
Hoewel frames inderdaad niet aan te raden zijn kunnen ze wel degelijk gebookmarkt worden (afzonderlijk dat wel, en voor de gemiddelde gebruiker wellicht niet zo bekend). Middels een JavaScriptje kun je vervolgens controleren of een pagina in de benodige frameste geopend is en zo niet dan kan dit middels een ‘replace’ bewerkstelligd worden. JavaScript? Jawel, en voor de arme sloebers die dat niet kunnen betalen zorg je natuurlijk voor een “Help, ik zie geen menu”-linkje die hetzelfde doet.
Schaalbare font-grootte kan behalve in % of em ook in ex aangegeven worden.
Mensen die (uitgaande van de aangeraden lettergrootte) de zwarte tekst op het lichtblauw niet kunnen lezen zullen waarschijnlijk sowieso eens uit moeten kijken naar client-side stylesheets waarmee de opmaak aan hun visuele beperking wordt aangepast. Opera biedt deze optie standaard voor mensen die hoog contrast nodig hebben.
Zoekmachines kunnen wel met alt-teksten overweg, dus dat argument om geen plaatjes te gebruiken voor tekst vervalt wanneer je alt-teksten gebruikt. Wat natuurlijk niet wil zeggen dat het gebruik van tekst niet de voorkeur zou hebben boven een afbeelding, zeker met betrekking tot de schaalbaarheid en het eventuele dynamische karakter van de content.
Wanneer je CSS gebruikt voor roll-over zaken dan betekent dat met betrekking tot het gebruik van afbeeldingen dat je alleen achtergrond-afbeeldingen kunt wijzigen. Het nadeel van achtergrondafbeeldingen is natuurlijk echter dat je er geen alt-tekst aan mee kunt geven (zeker bij een link toch wel noodzakelijk) en dat ze bij de meeste browsers standaard niet geprint worden.
Van afbeeldingen die in de content zijn opgenomen kunnen wel andere eigenschappen gewijzigd worden middels CSS (border, width, height, etc.) maar niet de bestandsnaam. Met JavaScript kan dit wel.
Het feit dat ondanks de engelstalige communicatie toch de term Nachttheater gebruikt wordt is natuurlijk helemaal niet vreemd. Dat klinkt voor de gemiddelde toerist namelijk gewoon erg exotisch. In Duitsland ga je ook liever naar een Biergarten dan naar een beer yard, zelfs al hebben ze het menu in het Engels.
Overigens lijkt me een Nederlandse site/variant geen slecht idee voor een Nederlands bedrijf.
waar ik me persoonlijk aan stoorde op de site waren al die dubbele slashes in de teksten en het gebruik van kapitalen voor o.a. namen in de tekst zelf. Levert een erg onrustig beeld op.
Zo, genoeg gezeurd. Verder heb ik wel een fijn weekend gehad hoor 😉
LikeLike
shit, mijn <tik op de vingers></tik op de vingers> tags zijn eruit gefilterd
LikeLike
@Sander:
“Zoekmachines kunnen wel met alt-teksten overweg, dus dat argument om geen plaatjes te gebruiken voor tekst vervalt wanneer je alt-teksten gebruikt.”
Dat is absoluut geen reden om plaatjes te gebruiken voor lappen tekst. Het alt-attribuut is namelijk bedoeld om afbeeldingen te beschrijven, in korte vorm. En dus niet geschikt om een stuk tekst in een afbeelding over te nemen. Dit is gewoon hartstikke fout. Wat tekstueel kan moet tekstueel, en zo niet dan zorg je altijd voor een tekstuele variant (bijvoorbeeld een visability:hidden voor de tekst en in plaats daarvan de afbeelding als achtergrond instellen middels CSS).
“Het nadeel van achtergrondafbeeldingen is natuurlijk echter dat je er geen alt-tekst aan mee kunt geven (zeker bij een link toch wel noodzakelijk) en dat ze bij de meeste browsers standaard niet geprint worden.”
Dat is eveneens incorrect. Het is juist beter om achtergrondafbeeldingen te gebruiken middels CSS dan een IMG-tag in de code te plaatsen zodra het gaat om navigatie. Want zodra je een achtergrondafbeelding gebruikt als overlay voor de tekstuele variant heb je altijd een goede presentatie: m?©t CSS de afbeelding, zonder CSS de tekstuele variant. Een betere oplossing dan het alt-attribuut.
LikeLike
Ai, had ik die tags nu maar gepatenteerd!
@Mark:
Zoals ik al aangaf is het inderdaad beter om geen afbeeldingen te gebruiken voor tekst. Dat staat echter los van het zoekmachine-argument van Ruben en mocht je (om wat voor rede dan ook) toch een afbeelding gebruiken voor tekst, dan lijkt het me dat je in de alt-tekst niet meer of minder zet dan de tekst uit die afbeelding, tenzij de afbeelding uit meer dan tekst alleen bestaat natuurlijk.
Overigens had ik het beter op het title-attribuut kunnen betrekken.
Natuurlijk zijn er veel betere manieren om je teksten van de gewenste opmaak te voorzien. De variant die jij beschrijft is daar een voorbeeld van (m.n. geschikt voor statische content, tenzij je afbeeldingen on-the-fly laat renderen), maar ook sIFR kun je hiervoor gebruiken.
Hetzelfde geldt inderdaad ook voor de navigatie. Ruben suggereerde naar mijn idee echter dat in de huidige site elke onmouseover simpelweg vervangen kon worden door een CSS-hover en dat is niet het geval, tenzij je dus meer gaat verbouwen zoals jij voorstelt.
Mijn kritiek had vooral betrekking op de stelligheid waarmee Ruben sommige zaken uitte. Maar blijkbaar heb ik me daar ook aan schuldig gemaakt 😉
LikeLike
Sander: de stelligheid geldt voor de voorbeeldenn die ik hier noem, niet voor elke website op elk moment. Sure, er zijn altijd mitsen en maren, maar ik vind dat je toch uit moet gaan van usability perfectie. Dat daar in de praktijk concessies aan worden gedaan; sure!
Voor de eindeloze hoeveelheid mouseovers op de sugar factory website kunnen prima CSS hovers gebruikt worden, toch?
Wat je zegt over frames is, zoals je zelf ook wel weet, absurd. Dat frames met 100 workarounds voor ervaren webdevelopers toch echt wel te bookmarken zijn, heeft geen enkele waarde voor 99,99271% van de gebruikers. En laten we ons voorlopig nog even op die mensen richten, k? 😉
LikeLike
@Ruben: Sommige van je argumenten werden wel degelijk gebracht alsof ze in het algemeen gelden, anderen waren inderdaad specifieker op deze site gericht. In mijn reactie heb ik daar volgens mij ook rekening mee gehouden.
Het aantal mouseovers doet denk ik niet echt ter zake voor wat betreft de keuze voor CSS of JavaScript. Ook hier ben ik in mijn reactie overigens juist uitgegaan van de huidige situatie. Idealer en algemener zou een oplossing zijn zoals degene die Mark noemt.
Ook voor wat betreft de frames geef ik aan dat het inderdaad zeker niet ideaal is. Een “Help, ik zie geen menu”-linkje vind ik overigens niet echt een indrukwekkende workaround. Maar nogmaals, ook ik vind dat je wel erg goede redenen moet hebben om frames te gebruiken.
Maar voor wie schrijf je dit log eigenlijk, voor sitebouwers of voor potenti?´le bezoekers? Ik dacht/denk voor de eersten en zo heb ik je stelligheid dus ook ge?Ønterpreteerd. Mijn reactie is dan ook die van een sitebouwer op de argumenten van een andere sitebouwer.
LikeLike