 |
 |
||
 |
 |
 |
|
toegankelijkheid
achtergronden project
vooronderzoeken
onderdelen Drempelsweg.nl
procesbeschrijving
evaluatie project
evaluatie stage
conclusies & aanbevelingen
projectmanagement
richtlijnen
facilitaire website
voorbeeldsites
Voorbeeldsites
De bouw van de standaardinterfaces & demosites ging zo mogelijk nog minder gestructureerd dan de facilitaire website. Voor beide demosites hebben we elk een week gekregen om uit te denken en te bouwen.
Dit was allemaal te overzien geweest als de definitieve ontwerpen niet steeds vlak voor het bouwmoment radicaal gewijzigd waren.
Voor de demosites geldt een soortgelijk bouwtraject als die van de facilitaire website. Voor elke site geldt dat er eerst een aantal testsites zijn gebouwd, gebaseerd op veronderstellingen. Deze zijn aan gehandicapten voorgelegd. Elke volgende versie had het resultaat van de vorige testronde en de ervaringen die op werden gedaan tijdens het bouwen in zich verwerkt.
volgende pagina:
Evaluatie project
Voor een overzicht:
ga naar de Sitemap
Verklarende Woordenlijst
Sneevert
De globale functionele ontwerpen van de demosites waren al in een vroeg stadium in het project klaar.
Vanaf het begin is het idee geweest om de gemeentelijke demosite op te delen in een bewonersgedeelte en een bedrijvengedeelte. De benadering was: wat zoekt een bezoeker op de website? Dit in tegenstelling tot wat de meeste gemeentes doen op hun website: welke diensten kunnen we allemaal vertalen naar de website? Met de gemeente Den Haag hebben we contact gehad om mee te denken aan het project, maar ze waren alleen in het prille begin aanwezig en toen opeens niet meer. Toen hebben we het functioneel ontwerp verder zelf aangevuld.
Met dit functioneel ontwerp is Lust aan de slag gegaan om schetsen te maken voor de demosite.
Schetsen
Het schetsen van Sneevert gebeurde veel meer op de achtergrond dan dit het geval was bij de facilitaire website. Lust is veel meer bezig geweest met het stoeien met vorm en kleur en heeft weinig laten zien van de tussenliggende stappen. In die tijd hadden we ook geen tijd meer om elke schets te bouwen om te kijken of het wel toegankelijk te maken was. Ik geloofde het allemaal wel. We waren druk bezig met het vullen van de richtlijnendatabase en in diezelfde tijd startte de bouw van de facilitaire site. Ik had inmiddels al zoveel testsites gebouwd dat ik een behoorlijke inschatting kon maken van de toegankelijkheid van een bepaald ontwerp.
Van schetsen naar bouwen
We hebben erg lang moeten wachten op de definitieve schetsen van Lust. Steeds weer waren ze nog een laatste hand aan het leggen aan een bepaald onderdeel. Toen de schetsen eenmaal kwamen was het een teleurstelling: slechts een homepage, één onderliggende pagina en een PSD (Photoshop Document) met een aantal iconen. Zoek het zelf maar uit.
Er was geen tijd meer om de schetsen terug te sturen of om meer uitgewerkte ideeën te vragen. Met deze twee schermen zouden we het moeten doen. Het functioneel ontwerp bleek ook niet zoveel houvast te bieden als ik verwacht had: alleen een algemene indeling en weinig over de functionaliteit. Net als de facilitaire site hebben we in een snelle bijeenkomst van programmeurs en webbouwers besloten welke applicaties nodig en leuk waren om de boodschap van de demosite over te brengen. Het oorspronkelijke functioneel ontwerp sprak van het online bestellen van een paspoort. We waren er al achter dat dit juridisch niet mogelijk zou zijn. Daarom introduceerden wij de Sneevert Gemeentepas, met alle invulformulieren om hem te bemachtigen van dien.Met een in de haast uitgetekend flowchartje zijn we aan het bouwen en programmeren geslagen. Op pagina's die geen informatie bevatten kwam een melding dat dit slechts een demo was. Het resultaat is toch een redelijk functionerende demosite, maar met meer achtergrondinformatie hadden we er vast meer van kunnen maken. Ik vind dit de mooiste van alle voorbeeldsites op Drempelsweg.nl.
Het goede voorbeeld?
Hoewel het best zonder had gekund, heb ik ervoor gekozen de demosite van Sneevert als enige binnen Drempels Weg in frames te bouwen. De site is erg luchtig geworden, mede dankzij de 'glasbakken applicatie', een grapje van onze programmeur.
Toen de site voltooid was zijn de pagina's voorzien van commentaar (over de technische en grafische keuzes bij het maken van de website) en per pagina gekoppeld aan de meest relevante richtlijnen.
Fig.1-4: screenshots van de evolutie van Sneevert, de gemeentelijke website
Profimarkt
De eerste schetsen van de Profimarkt behoorden tot de eerste tastbare produkten binnen het project Drempelsweg. Een aantal ideeën die in de eerste schetsen zaten zijn tot aan de definitieve versie bewaard gebleven.
Zo is de indeling van de keuzes bewaard gebleven (met de toevoeging van het receptengedeelte). Ook het idee dat het winkelwagentje altijd in beeld moet blijven (anders wordt het te abstract) is bewaard gebleven.
Schetsen
Van alle schetsen van de voorbeeldsites zijn die van de Profimarkt het best voorbereid door NMG. Toch heeft Lust nog veel bijgedragen aan ideeën bij dit ontwerp. Veel goede ideeën, maar ook een aantal on-n)duidelijke koerswijzigingen.
De eerste schetsen die we kregen aangeleverd toen het bouwmoment daar was, weken daarom weer dermate af van het (toch wel halfslachtige) functioneel ontwerp, dat alle voorbereidingen voor niets leken te zijn. Daarnaast leken enkele ideeën 'geleend' van de Albert Heijn website. Bovendien waren de schetsen incompleet, waardoor niet meteen opviel dat sommige dingen in het echt onmogelijk waren. Een voorbeeld: de navigatie 'klapte' naar rechts open op opeenvolgende schermen, maar er was niet nagedacht aan dingen die al helemaal rechts stonden. Hier zou de uitgeklapte navigatie dus buiten beeld vallen.
Bovendien introduceerde Lust opeens hele andere vormen (Fig.7) dan inmiddels was goedgekeurd door de opdrachtgever. Zo kun je alles wel onder voortschrijdend inzicht scharen.
Wat mij betreft had Lust hier een absolute wanprestatie geleverd. En dat niet alleen: wij waren degenen die het weer tot een goed einde moesten brengen.
De schetsen gingen terug naar Lust. De volgende dag (!) kregen we schetsen die een heel andere indeling hadden, andere grafische elementen bevatte en in ieder geval te bouwen leken. Maar de functionaliteit was nog steeds niet duidelijk. Was moet precies bewezen worden met deze demo?
In het zoveelste spoedoverleg tussen webbouwers, programmeurs en projectmanagers werd tot de huidige vorm besloten: er kwam een winkelgedeelte en een receptengedeelte. In het winkelgedeelte werd de sappenafdeling uitgewerkt en bij de recepten drie vleesgerechten.
Materiaaltekort
Voor de recepten en sappen hadden we nog geen enkel beeldmateriaal. Lust was erg langzaam met het over de brug komen van foto's en toen we na een halve week iets kregen bleken ze linkjes naar Stockphoto.com te hebben gestuurd: daar kunnen jullie het vinden. Zoek het zelf maar uit. De kinderachtigheid van het begeleidend schrijven ('je moet er wel voor betalen') maakte dit een van de dieptepunten van het hele project.
Ik was vantevoren al bedacht op zo'n actie en had met een collega al enige foto's op een stocksite gebookmarkt. Die werden snel gekocht.
Toen moesten we teksten voor een bereidingswijze van de gerechten op de foto's verzinnen. En daarna moesten foto's worden opgespoord van alle losse ingrediënten waaruit de gerechten bestonden. Het werd een culinair dagje.
Toen waren de sappen aan de beurt. Ook hiervan moesten foto's komen. Ik heb mijn digitale camera gepakt en ben met een collega naar de lokale supermarkt gegaan en heb daar alle merken sinaasappelsap gekocht die we konden vinden. Bij de buurtslager hebben de we ontbrekende stukken vlees voor het gerechtengedeelte gefotografeerd.
We hebben nog een week lang sinaasappelsap gedronken bij NMG.
Programmatuur en bouw
Inmiddels was er al een halve week van de bouwtijd voorbij. De programmeurs hadden intussen koortsachtig een demo van een winkelwagentje -die ze eerder in dit traject hadden gemaakt- uitgebouwd tot een volledig functionerende supermarkt volgens het ijlings vervaardigde functionele ontwerp. De rest van de week hadden we nodig om de database met produkten (foto's, omschrijving, prijs etc.) te vullen en de supermarkt te bouwen in HTML en CSS.
Omdat er veel ingewikkelde tabellen en formulieren in een winkelsite voorkomen duurde het wel even voordat we alles toegankelijk hadden gebouwd en ook konden onderbouwen waarom we het zo gedaan hadden.
Als laatstewerdenr de pagina's weer voorzien van commentaar en gekoppeld aan de meest relevante richtlijnen.
TNO Human Factors
De beide demosites werden na voltooiing onderworpen aan een test van het TNO Human Factors Research Institute. Het resultaat was bedroevend. Niet omdat we het zo slecht hadden gedaan, maar dan heb ik het hier over de schijnbaar amateuristische manier waarop de testresultaten werden gebracht. Eén of twee A4-tjes per website, met daarop een algemeen verhaal vol met dingen die we zelf ook wel hadden kunnen bedenken. Het ging vooral over kwesties van smaak en een beetje over gebruikersvriendelijkheid en er werd slechts weinig gerept over toegankelijkheid.
Bovendien kwamen sommige opmerkingen letterlijk in beide rapporten voor.
Wat mij betreft zonde van het geld, maar het was vast nodig om nog een gevestigde naam aan het inmiddels met rasse schreden prestigieus wordende project te verbinden...
Fig.5-8: screenshots van de evolutie van de Profimarkt, de winkelsite
Standaardinterfaces
Met de standaardinterfaces heb ik het minst te maken gehad van alle voorbeeldsites. In een vroeg stadium heb ik veel schetsen nagebouwd om te oefenen op toegankelijk bouwen en om Lust feedback te geven op hun ontwerpproces.
Vergaderingen
Verder ben ik bij vele vergaderingen betrokken geweest waarin de vorm en functionaliteit van de standaardinterfaces bedacht en uitgewerkt werden. Omdat er bij elke vergadering op een gegeven moment steeds een nieuwe deelnemer was (redacteur, accountmanager) was het soms vooral veel herhaling van discussies en gesprekken die al lang besloten waren.
Er werd besloten om vier standaardinterfaces te bouwen. De invalshoek van de vergaderingen was steeds: hoe kunnen we laten zien wat er mogelijk is binnen de strakke regels van de richtlijnen.
- Daarom was het belangrijk om minstens één standaardinterface helemaal volgens het W3C te bouwen.
- Voor een andere was de invalshoek precies andersom: we gaan niet kijken naar het W3C, maar we proberen een site te ontwerpen die voor alle mensen toegankelijk is. Dat we aan het eind van dat proces uiteindelijk uitkomen bij het W3C is dat niet erg; het is alleen maar een bevestiging van de geldigheid van de richtlijnen van het W3C.
- Een derde interface ging uit van het idee dat mensen van te voren eenmaal moesten aangeven wat ze in een website wilden hebben (beeld, geluid, tekst, etc.) en dat dit gegeven dan steeds gebruikt kon worden. Visueel werd dit dan voorgesteld als een aantal mappen waaruit de benodigde ingrediënten voor de website werden gehaald en samengesteld.
- De laatste interface zou een blik in de toekomst werpen en helemaal uit (bestuurbare) video bestaan.
Lust heeft alle interfaces zelf uit moeten werken en bouwen. Dit had o.a. tot gevolg dat de eerste versie helemaal niet toegankelijk was (en wie moest dit weer goedmaken? Juist.).
De video is het meest uitgewerkt, want dat was natuurlijk het leukste onderdeel. De derde optie is belabberd uitgewerkt: een absoluut niet toegankelijk plaatje waarop je kunt klikken en dan zie je een nieuw plaatje. De teksten op deze plaatjes zijn niet eens goed leesbaar voor mensen zonder handicap. Deze standaardinterface is niets anders dan twee schetsen waarvan niet eens de moeite is gedaan ze toegankelijk te laten lijken.
Commentaar
De interfaces zelf zijn slecht becommentarieerd. Op elke pagina staat hetzelfde vage vormgeefverhaal en er wordt niet specifiek ingegaan op de huidige pagina. Ook hebben ze de pagina's voor het gemak gewoon maar naar bijna alle richtlijnengelinktt als relevante richtlijnen bij die pagina. Dit commentaar behoeft dus nog steeds enige herziening. Op het moment is niet echt duidelijk wat we nou willen aantonen met deze standaardinterfaces.
Fig.9-11: screenshots van de evolutie van een nieuwsinterface (interface 1)
naar boven