Zie ook:

Dinsdag 25 november - DDS 3.0/De oude stad

Deze eerste workshop begon wat verwarrend omdat de uitgangspunten niet helemaal duidelijk waren. Was het de bedoeling dat we zouden gaan praten over een nieuwe interface en daarbij 3.0 even vergeten, of zouden we het hebben over het verbeteren van de bestaande interface. En hoewel de stemming aanvankelijk meer behoudend was, bleek gaande de bijeenkomst toch dat meer mensen in de richting van een nieuwe interface gingen denken, ook al bleef het behoud van 3.0 en het verbeteren daarvan ook voortdurend onderwerp van gesprek. Wat nieuwe functionaliteiten betreft was iedereen het snel eens. Het idee van de rugzak (zie de aparte workshop daarover) bijvoorbeeld was al eerder gelanceerd op een bijeenkomst vorig jaar, en het vinden van een concept waarbinnen bewoners meer aan de stad kunnen veranderen en de stad meer toegesneden kan worden op de behoeftes en interesse van de individuele bewoner, was ook al eerder genoemd.
Maar de bijeenkomst bestond niet (of althans niet alleen) uit het herhalen van zetten. De vraag of de stadsmetafoor nog steeds bruikbaar was , was snel beantwoord. De metafoor is rijk genoeg om daarbinnen nieuwe concepten te kunnen ontwikkelen, en bovendien blijkt nadenken over DDS zonder de stadsmetafoor net zoiets als nadenken over de omvang van het universum. De metafoor kan echter wel nog op veel meer verschillende manieren worden gebruikt. Zo werd voorgesteld weersomstandigheden in de stad te introduceren, en dag en nacht. Dergelijke elementen zouden ook de dynamiek van de stad kunnen vergroten.
Als iedereen het ergens over eens was, dan was het wel dat: de stad zoals hij nu is, is te statisch, te rigide. Het woord dynamiek viel dan ook met grote regelmaat. Hoe kun je een stad bouwen die zichtbaar in beweging is, een stad waarin veel verandert en veel gebeurt? Een oplossing zou ondermeer kunnen liggen in het beter zichtbaar maken van mensen in de stad. "Wie zijn hier" is nu een functie die is verstopt achter een button, maar je zou bijvoorbeeld ook een kaart van de stad (en van pleinen) kunnen maken waarop de aanwezigheid van andere mensen grafisch is weergegeven. Bij een van de andere workshops werd geopperd bedrijven of instellingen niet langer een gebouw/taartpunt op een plein te geven. Gebouwen staan immers niet op pleinen, gebouwen staan om pleinen. Een plein moet een gemeenschapsruimte zijn waar iets gebeurt, waar mensen overheen lopen en elkaar tegenkomen, en waar elk moment van de dag iets anders gebeurt. De achthoek als gemeenschapsgebied in plaats van kantorencomplex.
Bij het ontwerpen en bouwen van de oude interface (3.0) was hard nagedacht over het implementeren van communicatiemogelijkheden binnen een informatie-omgeving, wat onder meer resulteerde in de cafés. Voorgesteld werd om de grote uitdaging van een nieuwe interface juist in het realiseren van het omgekeerde te zoeken: het onderbrengen van informatie in een communicatieomgeving.
Met betrekking tot het ontwerpen van een nieuwe interface werd voorgesteld een tweesporenbeleid te voeren: upgrade enerzijds DDS 3.0 en voeg nieuwe functionaliteiten aan de oude stad toe die eventueel in een later stadium een onderdeel van een nieuwe interface zouden kunnen worden, en zet daarnaast een tweede traject uit dat uiteindelijk moet resulteren in een geheel nieuwe interface. Binnen dat tweede traject zou dan fundamenteler kunnen worden nagedacht over de stad en zouden de oude uitgangspunten nog eens getoetst kunnen worden. Kloppen die nog? Kunnen de concepten waaruit zich 3.0 ontwikkeld heeft nog dienen als uitgangspunt. Veel van de onderwerpen die bij deze eerste bijeenkomst werden besproken kwamen uitgebreid terug in andere workshops. Over deelonderwerpen dus in de overige verslagen meer.

Woensdag 26 november - Technische trends

Bij de eerste bijeenkomst over de oude stad werd opgemerkt dat bij het ontwerpen van 3.0 iedereen erg optimistisch was geweest over de verwachte bandbreedte. Dat bleek tegen te vallen. Nu bij het nadenken over een nieuwe interface staan we opnieuw voor de afweging voor welke bandbreedte we een stad ontwerpen. De oplossing daarvoor zou kunnen liggen in het vinden van slimme manieren om De Digitale Stad op meerdere niveaus beschikbaar te maken. Niet in de zin van een light en een full fat interface, maar meer door slimme manieren te ontwikkelen waarop je dezelfde informatie beschikbaar kan maken voor verschillende gebruikers. Iemand met een 14k4 modem krijgt dan een stad te zien die is aangepast aan de verbinding die die gebruiker tot zijn beschikking heeft. Plaatjes zijn kleiner en worden in lagen geladen zodat sneller iets zichtbaar wordt, de belangrijkste informatie wordt als eerste op de pagina gezet, evenals de links, zodat mensen niet ongeduldig wegklikken als ze niet snel genoeg resultaat zien. Je zou dat kunnen bereiken door een cgi-script te maken dat de verbinding peilt die iemand heeft, zodat je DDS customized aan kan bieden. Hoewel concepten waarin er maar één interface is die toch op verschillende manieren toegankelijk is op een aantal technische problemen stuit, is het denken in die richting waarschijnlijk toch de oplossing: DDS light en full fat in eenzelfde interface. Dat is de enige manier waarop je kunt ontsnappen aan het bouwen van een stad die minder aantrekkelijk is omdat hij ook toegankelijk moet zijn voor mensen met bijvoorbeeld een 14k4 modem.
Het idee werd geopperd om als DDS een CD-rom te ontwikkelen. Hierop zou bijvoorbeeld de plattegrond van de stad kunnen staan, zodat die niet apart geladen hoeft te worden. En hierop zouden ook allerlei zware applicaties kunnen draaien die niet alleen vanaf het net ontsloten kunnen worden, althans voor de meeste gebruikers niet. Voor een project als Transparant Amsterdam bijvoorbeeld zou een CD-rom een aantal grote voordelen hebben. En zo zijn meer hybride vormen te bedenken.
Het werken met dynamische html en layers wordt ondersteund door Netscape Communicator en biedt een aantal interessante mogelijkheden, zoals onder meer te zien is op de homepage van Netscape. Maar de vraag is in hoeverre ook de Internet Explorer diezelfde technologie ondersteunt. Hoe dan ook, het werken met layers maakt het mogelijk menu's veel compacter aan te bieden en de vormgeving inzichtelijker te maken. Voordeel van dynamische html in vergelijking met java is dat het relatief snel is. Nadeel dat er grote verschillen zijn in de talen die de Explorer en de Communicator spreken. Je moet een stad ontwerpen die voor beide browsers toegankelijk is, en dat betekent dat een aantal mogelijkheden voor het hart van de stad niet bruikbaar zijn, ook al kun je plekken blijven ontwerpen die geschikt zijn voor één van beide browsers. Maar de interface helemaal afstemmen op de mogelijkheden van bijvoorbeeld Communicator zou onwenselijk zijn.
De discussie rond plugins concentreerde zich vooral rond Shockwave (director). Voordeel is dat in Shockwave een aantal dingen wordt geïntegreerd, zoals de Real Player en Flash. Tweede voordeel is dat Shockwave sneller is dan java. Nadeel blijft natuurlijk dat Shockwave een plugin is. Explorer installeert hem automatisch, maar dat geldt weer niet voor Communicator. En er was onenigheid over of je wel in zou moeten zetten op Shockwave. Waarom zou java zich niet verder ontwikkelen en verbeteren? Of waarom zou Shockwave niet op den duur naar de achtegrond verdwijnen?
Veel tijd hebben we besteed aan Vocaltec, een communicatieprogramma dat is aangekleed (of deels nog aangekleed wordt) in de DDS-vormgeving en dat bewoners in staat stelt met elkaar te chatten in tekst, geluid, beeld en waarin een gezamenlijk drawboard is opgenomen dat twee mensen (of een groep) in staat stelt bestanden uit te wisselen en er met elkaar aan te werken.

Donderdag 27 november - Fundament/Autorisatie

De voornaamste vraag bij deze workshop was hoe we systemen zoals we die bij Prommitt en Stickit gebruiken (groepensystemen) toegepast kunnen worden in een nieuwe interface. Kunnen we bijvoorbeeld een groep bewoners een gemeenschap laten vormen rond een plein of rond een thema of gemeenschappelijke interesse door gebruik te maken van een dergelijk systeem? En kunnen we een dergelijke groep dan ook het beheer geven over die plek in de stad en de mogelijkheid zich op die plek duidelijk te manifesteren?
Het grootste deel van de workshop ging over het DDS paspoort, een beetje analoog aan de manier waarop dat bijvoorbeeld bij Firefly gebeurt: iemand heeft een persoonlijk profiel en dat profiel is opgeslagen in dat paspoort. Daarin zijn iemands interesses, vrienden en bijzonderheden opgenomen. En het paspoort reist overal met de bewoner mee. Dus ook al bevindt de bewoner zich in zijn grote browservenster niet in De Digitale Stad, toch blijft hij via dat paspoort aanwezig en zichtbaar. De "wie zijn hier" functie kan er aan worden gekoppeld en allerlei systemen waarmee direct contact gezocht kan worden met een andere bewoner van wie je hebt opgegeven dat die tot je vriendenkring behoort. Een dergelijk syteem lijkt weer erg op de functies die programma's als ICQ, Ichat of Powwow bieden.
Hoewel we de pagina's van Communityware bezochten (een systeem waarin afzonderlijke groepen beschikken over verschillende manieren van communiceren die op zich weer erg lijken op nieuwsgroepen en irc), bleven de meesten het meest enthousiast over Vocaltec. Nadeel daarvan is dat het een apart programma is en Communityware via je browser toegankelijk is, maar een nadeel van Communityware is juist weer dat het in vormgeving niet bepaald aantrekkelijk is en bovendien allemaal met java is gemaakt.
Op de agenda stonden ook de plusdiensten die DDS zou kunnen gaan bieden. Het was al eerder geopperd: voor een bepaald bedrag per maand kun je bewoners meer bieden dan ze nu standaard gratis krijgen. Meer schijfruimte bijvoorbeeld, of de mogelijkheid Real Video te gaan gebruiken op je homepage. Maar de vraag of we dat nu wel of niet wilde werd al snel overschaduwd door een gesprek over virtuele financien. In plaats van mensen te laten betalen voor plusdiensten, zou je bewoners die diensten ook kunnen laten verdienen. Voorgesteld werd om een virtuele munteenheid in te voeren in de stad die als betaalmiddel dienst kan doen, en dus ook voor het betalen van plusdiensten. Munten kunnen verdiend worden door bepaalde dingen te doen in de stad. Bijvoorbeeld door je aan te melden als hulpvaardige bewoner die door andere bewoners om raad gevraagd kan worden. Soms weet je waar je geld mee kan verdienen, en soms merk je pas achteraf dat een bepaalde handeling geld oplevert. Het zou dus tevens een spelelement in de stad brengen, en het zou de sociale samenhang kunnen vergroten, als je het gewichtig uit zou willen drukken: er is nu een directe reden om actief te zijn in de stad. Je krijgt er immers iets voor terug.
Het idee van een virtuele economie heeft ons de rest van de middag beziggehouden. Alle consequenties van de invoering van een virtuele munt hebben we nog niet kunnen overzien.

Maandag 1 december - Ontsluiten, functionele interface

Wat voor functionele systemen zijn er denkbaar om informatie goed mee te kunnen ontsluiten? Dat was de vraag die centraal stond binnen deze workshop. Bij het ontwerpen van een zoeksysteem voor DDS zou je kunnen denken aan zoiets als Transprant Amsterdam. Daar kun je over een kaart van de regio navigeren, kun je in- en uitzoomen op plekken op die kaart en kun je een uitgebreide legenda raadplegen waar informatie over allerlei verschillende onderdelen van die kaart te vinden is. Een erg functionele interface kortom, die in een aangepaste vorm ook voor DDS gebruikt zou kunnen worden. Je kunt dan navigeren over de plattegrond van de stad, en door te klikken zie je welke informatie achter welk deel van die plattegrond schuilgaat. Maar het systeem zou ook kunnen werken als een soort kaartenbak, waar elke organisatie een stukje in schrijft. Een museum kan dan bijvoorbeeld haar site beschrijven en binnen het zoeksysteem is ook een deel van die site zichtbaar. Een dergelijk zoeksysteem zou zelf kunnen groeien, zonder dat een hoge redactionele inspanning noodzakelijk is om het goed te laten functioneren. Hoewel, dat bleek toch niet helemaal waar te zijn. We kwamen terug op wat iemand tijdens de eerste bijeenkomst zei: DDS moet ook een selectie maken op het aanbod op het net die interessant is voor de bewoners van de stad. Als je een bepaald blad koopt, of lid wordt van een bepaalde omroep, dan weet je welke selectie er voor je wordt gemaakt. Je koopt de selectie. Zo zou het ook bij DDS moeten zijn.
Zoals bij vrijwel elke workshop kwamen we ook hier weer terug op het customized gebruik van de stad. De één heeft behoefte aan een superfunctionele interface die hem of haar direct naar de gewenste informatie voert. Diegene heeft weinig behoefte aan allerlei extra's die het zoeken vertragen. Het andere uiterste wordt vertegenwoordigd door degenen die helemaal niet op zoek zijn naar specifieke informatie, maar juist behoefte hebben aan een avontuurlijke manier om door de stad te dolen. En tussen die twee uitersten zit nog een hele groep.
Verschillende gebruikers stellen dus verschillende eisen, en dus zou de stad zo divers mogelijk gemaakt moeten worden. Zowel een superfunctionele interface als een superavontuurlijke interface moeten naast elkaar bestaan. Elke bewoner zou gebruik kunnen maken van hetzelfde systeem, maar iedereen kan dat zoeksysteem naar believen aan- of uitkleden.
Maar niet alleen zo'n navigatiesysteem zorgt ervoor dat informatie sneller toegankelijk gemaakt kan worden. Hier komen we ook weer terug bij het idee van de paspoorten waarin een profiel van de gebruiker is opgenomen. Dat profiel werkt tevens als filter, en is dus ook een voorbeeld van een functioneel, want snel informatie ontsluitend systeem. En bij het nadenken over een functionele interface gaat het niet alleen over de mate waarin informatie snel kan worden ontsloten, maar ook over wat je de ontsluiting van communicatie zou kunnen noemen. Welke mogelijkheden zijn er met andere bewoners in contact te komen? Kun je direct met elkaar praten? (Zie voor de discussie over manieren van communiceren ook het verslag van de bijeenkomst over de rugzak/toolkit)

Dinsdag 2 december - Toolkits en rugzak

Wat moet er in de DDS-rugzak zitten? Elke bewoner van de stad heeft standaard de rugzak bij zich, waarin een aantal belangrijke functies ondergebracht is. Het paspoort zit erin (meer daarover in het verslag van de workshop over autorisatie en user settings), maar er kunnen ook nog een aantal andere dingen in. Zoals bijvoorbeeld een organisor, een agenda waarin aan de hand van je profiel door allerlei organisaties geschreven kan worden. Als je opgeeft interesse te hebben in de activiteiten van De Balie, dan worden de dingen die daar plaatsvinden automatisch in je agenda gezet. En bovendien werkt die organisor ook als een adressenboek. Iedereen die je op het net kent staat erin. Dat adressenboek zou op zijn beurt ook weer kunnen werken zoals bijvoorbeeld ICQ, waarin je eveneens een lijst hebt van iedereen die je kent en waar je meteen kunt zien welke van de mensen die je kent online zijn. Binnen 1 klik kun je dan met ze praten.
In de rugzak zouden verder allerlei tools moeten zitten die je nodig hebt in de stad of die het verblijf in de stad leuker maken. Een tool om geluid en beeld mee te bekijken bijvoorbeeld, een tool om je homepage mee te bouwen of veranderen (webedit), een tool om je post te kunnen lezen (webmail), een portomonnee waarin je je virtuele munten kunt opbergen, et cetera.
Elke bewoner van DDS krijgt een rugzak met standaard inhoud. Met een standaard gewicht ook. Elke tool die je er extra instopt verhoogt het gewicht van je rugzak. Bekijk ook het voorstel voor een rugzak dat Peter van der Spek op het net heeft gezet.
De grootste uitdaging van het rugzakconcept is het systeem zo te maken dat ook bewoners hun eigen tools kunnen bouwen. Die nieuwe tools zouden dan niet alleen bruikbaar moeten zijn voor de ontwerpers ervan, maar voor iedereen in DDS. Iedereen die naar de "toolshop" komt, kan daar kiezen uit een reeks rugzakonderdelen die deels zijn gemaakt door DDS en deels door bewoners van de stad. Een dergelijk concept lijkt heel sterk op dat van de metro, waar mensen ook zelf onderdelen kunnen bouwen (de metro kan je vinden via "dds.dds.nl:902"). De enige bezwaren die aan een dergelijk systeem kleven zijn van technische aard. Hoe kun je bewoners laten programmeren zonder dat daar gevaar aan verbonden is voor de rest van de stad?

Woensdag 3 december - Homepage

Een poort bouwen voor een stad die nog niet bestaat is onmogelijk, en dus zaten we bij deze bijeenkomst tamelijk vast aan de bestaande interface. Want ondanks dat we voor de nieuwe stad een aantal nieuwe uitgangspunten hebben geformuleerd de afgelopen dagen en een aantal wenselijke vernieuwingen hebben gedefinieerd, is er nog geen nieuw concept waarbinnen de poort van de stad een andere functie krijgt.
Voor de entree van DDS geldt hetzelfde als geldt voor de gehele interface: statisch, rigide en niet dynamisch. Maar wat zijn de alternatieven? Het is de meest opgevraagde pagina van DDS en zou het pronkstuk van de interface moeten zijn, en echt de poort moeten vormen naar alle delen van de stad. Maar tegelijkertijd is het juist bij de homepage van essentieel belang dat iedereen die makkelijk op zijn of haar scherm kan krijgen. De pagina mag beslist niet te zwaar zijn. Maar daar zijn wellicht creatieve oplossingen voor te verzinnen. Een voorbeeld van een heel licht ontwerp staat op de pagina van Webmix. Kijk eerst daar en kijk vervolgens naar het plaatje op het oorspronkelijke formaat. Door op een economische manier om te gaan met plaatjes kun je een veel snellere homepage maken.
Een tweede oplossing zou kunnen liggen in het customizen van de pagina voor verschillende soorten gebruikers. Want de restricties die je jezelf oplegt door alleen maar een lichte pagina te bouwen kunnen er ook voor zorgen dat je bij het ontwerpen in de problemen komt. Is het mogelijk om een superlichte pagina te maken die er ook nog eens heel aantrekkelijk uitziet? Het is een uitdagende gedachte, maar de vraag blijft of het mogelijk is iets echt moois te maken op die manier. De tweede oplossing zou dus kunnen liggen in - opnieuw - het customizen van de pagina: elke gebruiker krijgt een andere pagina te zien (zie over dit onderwerp ook het verslag van de workshop Technische trends).
Je zou bijvoorbeeld een entreepagina kunnen ontwerpen die bestaat uit in totaal tien lagen. Wie een 14k4 verbinding heeft krijgt alleen de eerste drie, wie een 36k6 heeft de eerste zes en wie een ISDN-verbinding heeft alle tien. Als bewoner kun je dan ook zelf kiezen voor het soort pagina die je wil. Wil ik een pagina die snel is geladen en alle hoofdfuncties bevat die de aangeklede versie ook heeft? Dan kies ik voor "laad alleen laag 1". Ben ik een bezoeker die alle extra's wil zien en gebruiken, dan klikt ik "laad alle lagen". Het lagenconcept zorgt er in ieder geval voor dat je jezelf niet hoeft te beperken in het zo aantrekkelijk mogelijk maken van de entreepagina.
Je zou ook kunnen denken aan het gebruik van interlaced jpeg bijvoorbeeld, en dan niet alleen voor de entreepagina, maar misschien wel voor de hele nieuwe interface.
Wat ook door iedereen belangrijk werd gevonden is dat de entreepagina actuele informatie bevat. De poort van de stad moet meer uitzicht bieden op de stad die er achter ligt. Dat zou je ook van toepassing kunnen laten zijn op het uitzicht dat je nu hebt over de stad vanaf die pagina, maar het gaat hier voornamelijk om actuele informatie over wat er gebeurt in de stad of wat er is veranderd. En bovendien moet je kunnen zien wie er op het moment dat jij op de entreepagina bent onder de poort door de stad in gaan.
Ook werd het idee gelanceerd om kunstenaars de opdracht te geven binnen de vaste vormgeving van de pagina een poort voor de stad te ontwerpen. In die opzet zou een deel van de pagina in vaste DDS-vormgeving te zien zijn, waarbinnen ontwerpen voor verschillende poorten geplaatst kunnen worden die zijn ontworpen door kunstenaars. Elke maand zou de stad dan een andere poort hebben.