Asynkron webkommunikation

Hvis du udvikler websites, vil du æææælske Internet Explorer Developer Toolbar Beta. Go get it! DOM Explorer og Ruler er vidunderlige.

Programmet for efterårets CMS-arrangemet, CMF2005, er netop offentliggjort. Tjek cmf2005.dk/schedule og tilmeld dig.

Det bliver det største CMS-guru line-up på dansk jord til dato.

Technorati tag: cmf2005

I meget lang tid har vi brug mange og meget lange ord for at fortælle, hvad vi laver på Synkron. Men en dag kom jeg til at tænke på, hvad jeg kigger efter, når jeg selv leder et produkt på nettet. Produktet selv. Ikke lange beskrivelser i ord.

Derfor er vi begyndt på at vise det i stedet for blot at skrive om det. De forskellige demo’er er lavet ved at bruge programmet Camtasia Studio, der blot optager, hvad du laver på skærmen, og eventuelt også hvad du siger. En præsentation på et par minutter tager et par minutter at optage og et par minutter at gemme og lægge ind på dit site.

Ruby on Rails har i øvrigt også fine (og lange) video-demoer. Se selv.

Det seneste nummer af Dansk Magisterforenings blad, Magisterbladet, har et meget interessant tillæg om ansattes ytringsfrihed. I tillæget er en artikel af Line Reeh om konflikten mellem ansattes blogging og hensynet til virksomheden. Hvor går grænserne for, hvad medarbejdere må blogge om? Må de blogge? Har virksomheden en politik for medarbejderes bloggging?

Jeg synes ikke, at situationen er anderledes, nu hvor medarbejdere kan bruge weblogs til at udtrykke sig. Det har altid været gældende, at man har et ansvar for det, man udtrykker. Fredrik Wackå citeres da også for, selvom man hører historier om medarbejdere, der fyres på grund af deres blogging, så er der sikkert mange flere, der fyres for at udtrykke sig kritisk i andre sammenhænge.

På Synkron har vi ikke en blog-politik, fordi vi regner med, at vores medarbejdere er smarte nok til selv at sætte en grænse for, hvad der kan siges i offentlighed. Om de siger det på en weblog, i en mail, et online forum eller spray’er det på en mur på Nørrebro er underordnet. Jeg synes ikke, mediet er interessant i denne sammenhæng.

Du tænker sikkert, “hvorfor skulle jeg også det?”. Men på langt de fleste sites findes systemtekster, der ikke skrives af kommunikationsfolk, og som aldrig læses korrektur på. Grunden er, at de kun kommer frem ved fejl, og når man selv har planlagt sitet, ved man jo, hvordan det skal betjenes, og derfor ser man ikke fejlbeskederne. Udviklerne bliver overladt til sig selv, når der skrives fejlbeskeder.

Ligesom sælgere og ledere, har udviklere ofte et pragmatisk forhold til sproget.

Et eksempel: Tag nu TV2′s nye site Videnzonen. Den fungerer kun i Internet Explorer. Det er i sig selv en dårlig forretningsmæssig beslutning. Prøver man at se sitet med Firefox, så får man fejlbeskeden:

Denne ressource er kun supporteret for Internet Explorer
For at tilgå ressourcen benyt venligst ovenstående browser

Jeg har ikke bedt om nogen ressource, og jeg skal ikke tilgå noget som helst, tak. Jeg vil bare se et site.

Ikoner er gode i webdesign, når de er entydige. Derfor skal du aldrig bruge små flag som ikoner for sprog på et website. Det var den korte version af denne posting.

Den lidt længere kommer her…

Mange sites bruger små flag som ikon for sprogvalg, både små, hjemmegjorte sites og store internationale. Du ved, hvad jeg snakker om. Problemet er, at et flag refererer til et land og ikke et sprog. Bare lige for at illustrere forskellen, så tænk på Schweiz. Landet har fire officielle sprog, og ét af dem er tysk. Tysk er desuden officielt sprog i Tyskland, Liechtenstein, Østrig, Luxembourg og Belgien. Hvad betyder et tysk flag så på et website? For tyskere betyder det uden tvivl “tysk”, men for østrigere betyder det “information til tyskere”.

Problemet er ikke så stort, når flaget repræsenterer et land, hvor de fleste, der taler sproget, bor. Et dansk flag fungerer fx godt. Men tænk lige på engelsk eller spansk. Hovedparten af engelsk- eller spansktalende bor udenfor England eller Spanien. Spansk er officielt sprog i mindst 23 forskellige lande.

Nogle sites bruger ikke ikoner for sproget, men skriver det med ord i stedet. På Danish Crown er det blevet så forvirrede, at de bruger forkortelsen GB for engelsk sprog og D for tysk. Adresserne for de to sprog siger det hele: “www.danishcrown.dk/?language=gb”. Sprog lig med Great Britain.

Sagen er, at der er meget stærke følelser forbundet med sprog og national identitet. Så når du bruger et britisk flag for engelsk, så pisser du omkring 300 mio personer i USA af (her dog inklusiv de spansktalende). Skriv hellere sproget på sprogets eget navn som fx Cannondale.

Jeg byder hermed velkommen til dagens gæsteblogger, Martin Mouritzen, der har skrevet følgende ultrainteressante artikel om sine overvejelser om design af den næste generation af et CMS. Tankerne tager udgangspunkt i Martins arbejde med hans eget system, Siteloom

Først og fremmest tak til Andreas for at tvinge mig til at skrive den her post, han syntes åbenbart at mine idéer er så fjollede, at jeg skal gøres grin med af alle hans læsere.

Egentlig var “artiklen” starten på oplæg til diskussion med Andreas, men nu håber jeg at DU smider dine tanker i kommentarene

Jeg har brugt det sidste stykke tid på at forberede mig mentalt på udviklingen af næste version af GUI’et til “mit” CMS SiteLoom, og har i den forbindelse brugt en del tid på at undersøge, hvad der er på markedet nu, samt fundere over hvad der kan, og ikke kan, fungere i en web-applikation.

Lige nu har SiteLoom et forholdsvist simpelt GUI [Screenshot], hvor der er:

• En menu med store ikoner øverst, hvor man kan tilgå alle hoved-funktionaliter fra
• En undermenu, som skifter alt efter hvilket hoved-menupunkt man er inde under
• Et hierarki, hvis indhold afspejler det område man er inde under.
• Et “indholdsområde” hvor selve redigering foregår.

Med andre ord ligner SiteLoom rimeligt meget et normalt Windows program (hvilket også var idéen), efter min opfattelse følger de fleste denne eller lignende tankegang.

Det fungerer sådan set også fint nok at ligne et normalt Windows-program, desværre virker det kun til et vist punkt, pludselig er programmet vokset til en sådan størrelse at der mangler plads i menuen, eller at en bruger f.eks. vil redigere i 2 sider samtidig, eller lige skal se om en bruger eksisterer, selvom han er igang med at skrive en nyhed til websitet.

Problemet er at det i de fleste web-applikationer er super-svært at “multitaske”, Windows (og andre operativsystemer for den sags skyld) løser problemet ved at det er nemt at åbne flere programmer, også selvom det er samme program. Problemet er hovedsageligt at siden de fleste CMSer er web-baserede, er der ofte et så stort overhead forbundet med at åbne 2-3 “CMS vinduer”, at det bare ikke rigtigt fungerer, derudover er der andre eksotiske udfordringer, som at f.eks. drag’n'drop ikke muligt over 2 forskellige vinduer pga. sikkerhedsindstillinger i de forskellige browsere.

En anden og måske mere central ting er at Windows har skrivebordet, startmenuen, taskbaren, system-trayen samt diverse tastatur-genveje til at hjælpe brugeren med at skifte rundt mellem applikationer. Hvis du har flere internet-explorer vinduer åbne med dit CMS bliver det hurtigt svært at finde rundt i, fordi du højst sandsynligt også har andre Internet Explorer vinduer åbne, og titlen på browerser-vinduet er typisk bare “CMS Administration” eller noget i den stil, og derfor mangler man det hurtige synlige overblik når man skal skifte mellem vinduerne.

De sidste par dage har jeg tænkt en del over hvordan man kan løse problemet, og er nået frem til et par løsninger, som alle har deres fordele og ulemper.

1) Fortsætte som hidtil.
Det er nok både den nemmeste og mest kedelige løsning. Den nuværende måde er måske nok bøvlet, men fungerer for de fleste.
Problemet med løsningen er at jo mere tid du investerer i den jo sværere bliver det som regel at skifte senere, derudover er der også chancen for at du kommer håbløst bagud på markedet.

2) Gør CMS’et til et pseudo-operativsystem
Den anden mulighed, som jeg pt. er mest tilbøjelig til at lægge mig op af, er at kopiere noget af funktionaliteten fra forskellige operativsystemer, f.eks. Start-menu, skrivebord (med ikoner), task-bar og system-tray.
Fordelen er at folk kender det, og at du i dit CMS kan lave små “programmer” som man kan åbne flere versioner af – Hvis folk klikker på “Skriv nyhed” 2 gange, så bliver der simpelthen bare åbnet 2 “Skriv nyhed” vinduer, præcis som man ville regne med at der ville ske hvis det var et ikon på skrivebordet.
Ulempen er desværre at folk allerede har en start-knap, taskbar og system-tray, og det vil derfor højst sandsynligt skabe noget forvirring hvis du i browseren laver din egen version som ligger lige op over.
– Måske kunne man præsentere de åbne “CMS-programmer” på en anden måde og slippe for det her problem.

3) Rigtige applikationer
I den helt anden grøft kan man begynde at portere sit CMS til rigtige applikationer, og derved opnår man alle fordelene fra nr. 2 på en mere logisk måde for brugeren.
Problemet her er at det vil tage en pokkers masse udvikling, derudover skal man pludselig til at supportere flere udviklings-sprog da desktop-applikationer sjældent er skrevet i samme sprog som selve CMS’et er skrevet i.
Derudover vil det for slutbrugeren højst sandsynligt blive et krav at man SKAL køre Windows og installere diverse ting på sin computer før man kan redigere på websitet – Alt sammen ting som ikke er issues i den nuværende webbaserede løsning.

Som sagt er der fordele og ulemper ved de forskellige løsninger jeg har skitseret, og der er nok en masse ting jeg ikke har tænkt på – Hvis du sidder og tænker på et eller andet nu, så smid dine tanker i kommentarene og lad os diskutere lidt

Step Two har en interessant artikel om sammenhængen mellem antallet af CMS-brugere og hvor avanceret CMS’et skal være.

Jeg synes, at det har bølget frem og tilbage, om virksomheder vælger en central eller decentral strategi for vedligeholdelse af indholdet. Da virksomheder begyndte at erstatte flade HTML-sites med CMS, var det attraktivt, at alle i organisationen kunne blive webmastere. CMS-leverandører solgte på denne præmis, og kunderne købte. For de fleste virksomheder gav det problemer. Dels var systemerne ikke egnede til at blive brugt af alle i virksomheden, fordi brugervenligheden ikke var tilstrækkelig, og dels var alle personer i virksomhederne ikke i stand til at formidle på et tilstrækkeligt godt niveau. At besidde den rigtige viden er ikke et tilstrækkeligt kriterium til at kunne formidle den.

Mange virksomheder gik siden tilbage til en central model, hvor en enkelt webredaktør fik ansvaret for publicering af alt indholdet på sitet. Selv meget store, internationale virksomheder bruger den model i dag.

For mange virksomheder er det optimale nok en kombination af de to strategier: At lade indhold blive tilføjet til systemet decentralt og blive publiceret centralt. Og her er Step Two’s pointe rigtig: Når man skal rulle et CMS ud til mange i en organisation, skal man passe på med at få et alt for avanceret CMS. Forretningsbrugere skal have det absolut mest simple interface til at levere indhold til CMS’et.

Men man får mere ud af at tænke CMS’et i to forskellige områder: Indholdsproduktion og -publicering. Jeg mener, at et godt CMS skal have et ekstremt simpelt interface til indholdsproduktionen men et avanceret interface til indholdspubliceringen. Det er ikke nok bare at bede om et simpelt CMS, når det skal bruges af mange brugere…

Eller hvad?

Ovenpå sommerferiens radiotavshed genoptager jeg denne blogs sporadiske postings. Derfor vil jeg gerne benytte lejligheden til at spørge dig, kære læser, om, hvad du synes om webloggen. Din feedback er vigtig for mig.

Lad mig vide, om du finder den relevant. Læser du af almen interesse eller i forbindelse med dit arbejde? Ævler den for meget. Er der for mange eksempler/cases eller for meget teori. Hvilke emner vil du gerne læse mere om? Vil du anbefale andre at læse denne weblog? Hvorfor (ikke)? Bliver der postet for sjældent? Bør der være gæste-skribenter? Gør (non-)designet ondt i dine øjne?

Lad mig høre, hvad du mener. Skriv en kommentar! (der trækkes desværre ikke lod om en iPod Shuffle blandt besvarelserne, men alle belønnes med en bedre weblog).

Så er podcasting ikke længere forbehold den nørdede undergrund. DR har netop åbnet for, at du kan hente udsendelser ned i MP3, loade dem over på din iPod (eller ringere efterligning) og blive klogere, bedre og smartere, mens du cykler, køber ind eller bare idler. What’s not to like?

Eller: Hold op med at fortælle mig, at tilgængelighed er godt. Fortæl hellere hvordan man får det.

På dette tidspunkt er du sikkert blevet tudet ørerne fulde at, at Tilgængelighed Er Godt For Dig. Hvis ikke, så læs eventuelt min tidligere posting om samme. Hvis du er for doven til at læse den artikel, er her den korte version: Tilgængelighed er godt, fordi man når en større målgruppe (privat virksomhed) eller fordi man opfylder et anbefalede retningslinier fra IT- og Telestyrelsen (offentlig myndighed).

Jeg synes, der mangler gode anvisninger på, hvordan man rent praktisk anskaffer sig tilgængelighed, så her er altså en artikel, der forklarer det (når jeg i denne artikel skriver “tilgængelighed”, så mener jeg de tekniske betingelser for adgang til indhold på et website. Jeg tillader mig forresten at antage, at der ligger et CMS bag dit site.

Man opnår tilgængelighed sådan:
10 Lav en tilgængelighedsstrategi
20 Analysér nuværende situation
30 Forankr og uddan
40 Implementér tilgængelighed
50 Test
60 Fix
70 GOTO 50

Lav en tilgængelighedsstrategi

Hvis du ikke begynder med at lave en strategi, så lad helt være med at begynde på projektet. Strategien skal svare på følgende spørgsmål:

• Projektets målsætninger. Skal der opfyldes krav fra IT- og Telestyrelsen? Ønsker man flest mulige besøgende? Ønsker man adgang for bestemte enheder? (telefoner PDA’er etc). Forventer man stigning i on-line omsætning eller reduceret tidsforbrug i manuelle arbejdsgange?
• Omfang af ambitioner. Hvilke(n) standard(er) skal opfyldes? (X)HTML, WAI A/AA/AAA, Section 508?
• Ressourcer og budget. Hvor mange penges afsættes til projektet? Hvilke kompetencer findes i organisationen? Skal der uddannes interne personer eller skal projektet outsources?

Analysér nuværende situation

Lav – eller få lavet – en tilgængelighedstest. Testen skal omfatte ALLE sider på sitet. Bobby er et godt værktøj til at gennemføre testen. Desværre et en maskinel test ikke tilstrækkelig. For eksempel er der krav om, at billeder skal have en sigende ALT-tekst. Bobby kan naturligvis ikke vurdere, om en ALT-tekst er sigende i forhold til billedet. Derfor er det nødvendigt med menneskelig vurdering på en række punkter.
Det kan være en god idé at få lavet testen af en ekstern leverandør, fordi den menneskelige vurdering kræver god viden på området. Sensus og Dansk Center for Tilgængelighed laver fx denne type af tests.

Forankr og uddan

Der skal være placeret et klart ansvar for tilgænglighed. Det nytter ikke noget, at den webansvarlige tror, at webudvikleren sørger for, at sitet er tilgængeligt – mens webudvikleren regner med, at den webansvarlige siger til, hvis han/hun vil have tilgængelighed. Ansvaret for tilgængelighed bør ligge åbenlyst hos den webansvarlige. Men det er ikke tilstrækkeligt: Webudviklere bør have den tekniske kompetence, og webforfattere bør være klar over, hvordan man lægger indhold ind i systemet på en tilgængelig måde. Måske har de adgang til HTML-koden i afsnit, måske kan de lave tabeller, måske kan de indsætte billeder. I alle tilfælde er der specielle forhold at være opmærksom på, når sitet skal være tilgængeligt. Hjælp alle med relation til websitet i organstionen med retningslinier for arbejdet med systemet.

Implementér tilgængelighed

Jeg antog jo tidligere, at der ligger et CMS bag dit site. I så fald skal der nok implementeres tilgængelighed flere steder i systemet. Det er vigtigt at kigge bag det publicerede site og på det system, der genererer sitet.
Dels skal alle skabeloner tweakes, så de fremover genererer tilgængeligt output. Lad være med at lave et selvstændigt sæt skabeloner til en tilgængelig variant at sitet. Der er flere gode grunde. Desuden skal der ses på det eksisterende indhold i systemet. De fleste WYSIWYG-editorer laver formattering med HTML. Det betyder, at indholdet kan være “forurenet” af utilgængelig kode. Eventuelt kan der laves en søg-og-erstat på alt indholdet i databasen. Editoren skal følgeligt også tilpasses, så den fremover ikke genererer utilgængeligt indhold. Endelig skal der helt sikkert tilføjes alternativt indhold for ikke-tekstligt indhold som billeder, lyd, video, Flash og så videre.
Hvis CMS’et tillader det, bør man overveje at tilpasse det, så det fremover støtter forfattere i at lave tilgængeligt indhold. Det kan være at spørge efter ALT-tekster til billeder og muligvis lave on-the-fly validering af sider, der skal publiceres.
Hvis dit site ikke publiceres af et CMS, og der er mange sider, ved du, hvad du skal lave resten af året…

Test

Test resultatet af implementeringen. Husk både maskinel test og menneskelig vurdering. Bruges ekstern leverandør af den første, diagnosticerende test, bør samme leverandør også lave testen efter implementering.

Fix

Regn med at første implementering ikke fanger alle tilgængelighedsproblemer. Der er mange faktorer at styre på samme tid. Der vil derfor næsten helt sikkert være fejl at udbedre. Re-fix og re-test indtil resultatet er tilfredsstillende.
Planlæg også at følge op med regelmæssige mellemrum. Lav – eller få lavet – eventuelt en tilgængelighedstest hvert halve år. Når den første, store implementering af tilgængelighed er gennemført, vil der typisk kun være småting at rette fremover.

Kollektiv rapport fra begivenheden: Technorati
…og det visuelle bragt til dig fra Flickr.

Mange CMS’er driver i dag blot et web-site, hvor de i stedet kunne have drevet en forretning på nettet. Jeg mener ikke nødvendigvis en forretning som det sted, hvor der sælges varer eller tjenester, men den grundlæggende måde at drive sin virksomhed eller organisation på.

Lad os indrømme det. Når vi kigger på indholdet af de fleste web-sites, indeholder de for det meste blot information. Der er beskrivelser – ofte udtømmende – af produkter, nyheder om nye kunder, produkter eller medarbejdere, og der er beskrivelse af virksomheden selv. Siderne er, takket være CMS’et, konsistente i designet, og indholdet er måske endda opdateret. Hvad er problemet så?

Problemet er, at hvor sitet kunne tjene penge til virksomheden, spare penge ved at flytte manuelle arbejdsgange til nettet og skabe gladere kunder ved at tilbyde bedre service på nettet – ja, så ligger sitet bare dér og koster penge.

Problemet er, at mange sites er drevet af en web-afdeling, en web-master eller lignende, der har til opgave at lave et pænt og opdateret website, mens den egentlige opgave burde være en helt anden: At understøtte virksomhedens forretningsprocesser på nettet.

For nogle år siden talte man om, at virksomheden skulle på nettet. Det betød, at virksomheden skulle have et website. I dag er dette udsagn nødt til at have en anden betydning, nemlig at virksomhedens processer skal på nettet. Se på dit eget website. Synes du, at det afspejler jeres forretning eller er det bare jeres profilbrochure?

Web-sitet skal bringes ind på direktionsgangen eller bare ind til direktøren, hvis det skal til at handle om forretning. Det skal gribes strategisk an og ikke bare være noget, der er gjort, fordi det skal gøres.

Lad være med at planlæg en revolution i virksomheden, men find ud af, om jeres website ikke kan understøtte jeres forretning (bedre). Det vigtigste er, at de forskellige forretningsmæssige ansvarlige personer i virksomheden inddrages i projektet. Isoleres web-sitet i web-afdelingen, bliver det aldrig til mere end et pænt website.

Hvis du er web-ansvarlig, så er det afgørende, at du får en grundig forståelse for virksomhedens forretning. Spørg personalechefen, hvordan man håndterer ansættelsesprocessen, jobopslag, behandling af ansøgninger, besvarelser etc. Tal med salgschefen og find ud af, hvordan man skaffer sig nye kunder (leads). Find ud af, hvordan jeres kundesupport håndterer henvendelser og sager. Hvordan håndterer jeres marketingchef udsending af invitationer til seminarer og samler tilmeldinger efterfølgende?

Når du har en god forståelse af jeres vigtigste forretningsprocesser, så er det nødvendigt at opstille en strategi for web-sitet. Hvilke mål skal web-sitet opnå? Med hvilke ressourcer? Hvordan vil man måle målopfyldelsen? Det er de tre vigtigste parametre i at indtænke web-strategien, hvis web-sitet skal kunne understøtte virksomhedens forretningsprocesser.

Bragt i Synkrons nyhedsbrev Juni 2005

Opgaven er som følger:

Du har på arbejdet modtaget en pakke med en mobiltelefon fra Sony Ericsson i Danmark. Problemet er bare, at pakken er fejlafleveret! Adressen er rigtig, men telefonen skulle være sendt til en anden kunde. Du skal nu gå ind på Sony Ericssons site og finde en mailadresse, så du kan kontakte Sony Ericsson og forklare dem problemet. Det haster! Den anden kunde har brug for sin mobiltelefon hurtigt.

Skriv en kommentar om, hvor lang tid, du brugte på opgaven.

Mange (alle?) arrangementer om CMS i Danmark har primært drejet sig om at få leverandører til at komme og vise produkter og eventuelt cases frem – altså i PowerPoint, ikke i virkeligheden. Selv kan jeg ikke længere kende forskel på en præsentation fra Sitecore, Dynamic Systems eller Web500. Jeg vil skyde på, at udbyttet for deltagerne er minimalt, fordi ambitionerne for dem, der afvikler arrangementet simpelthen er for lave. Som leverandør er der frit slag for at fyre en 25 minutters salgstale af, så det gør man naturligvis. At man så stadig kan fylde en sal med 100 personer til slavisk gennemgang af 6 sæt slides fra forskellige systemleverandører, er mig altså en gåde…

Enter Content Management Forum Annual Conference 2005. Arrangementet samler CMS-leverandører, konsulenter, eksperter og brugere til deling af viden om strategi, projekter, teknologi og kommunikation. På deltagerlisten finder du blandt andre Tony Byrne (CMS Watch), Martin White (Intranet Focus) og – i al ydmyghed – moi.

Content Management Forum Annual Conference 2005 finder sted 8. – 10. november 2005 i Århus. Arbejder du med CMS på et strategisk niveau, så er du nok nødt til at overveje, om du ikke skal deltage.

Følg med på Technorati: cmf2005

Danmarks Radio afslører:

Begrebet weblog eller blog, som det også kaldes, er i fuld fart frem på internettet

Her på fabrikken har vi to (hoved-)kontorer i Danmark. Det ene er i Århus, og det andet er i Købehavn. Vi bruger alt for mange penge – og tid – på at tage over til hinanden for at holde møder, men nu har vi altså hooket de to mødelokaler op med Apple iSight. Det er en meget billig løsning (to Mac mini og to iSight kameraer), og det fungerer overraskende godt. Både billede og lyd er acceptabelt, og det har kun kostet os omkring 10.000. En løsning hos en professionel leverandør af konferencesystemer ville koste fra 60.000, men mere typisk det tidobelte.

For os skaber det sammenhæng i organisationen. Har to medarbejdere brug for at snakke i realtid, kan de lige gå ind foran kameraerne i mødelokalerne og få styr på sagen. Skal der holdes større møde med personer i begge afdelinger, gør vi det nu i begge mødelokaler med kamera sat til.

Politikere brugte weblogs i sidste valgkamp, men til hvad? Til at blive valgt øjensynligt. Hvad er så problemet? Problemet er, at en fantastisk mulighed for sammenhæng mellem borgeren og dennes repræsentat i Folketinget ikke udnyttes. Som medium er webloggen et stærkt dialogskabende værktøj. I politisk sammenhæng giver det mulighed for, at politikeren kan dele sine tanker og holdninger (postings) med vælgerne, der kan reagere på dette og indgå i dialog (comments). Borgerlig offentlighed med strøm på, eventuelt.

Når politikere så alene bruger webloggen med henblik på at blive valgt, så sender de samtidigt et signal om, hvad der vejer mest tungt: At blive valgt eller dialogen med vælgerne. Lisbeth Klastrup har en god weblog om valgblogs. Find din politiker på listen og tjek, hvad var vigtigst for ham eller hende…

Er din politiker ikke på listen, så se, hvad jeg mener hos Rikke Hvilshøj eller Lone Dybkjær eller Benedikte Kiær.

Den nye Google Web Accelerator er ikke længere tilgængelig for download.

Thank you for your interest in Google Web Accelerator. We have currently reached our maximum capacity of users andare actively working to increase the number of users we can support.

Alle, der tror, at det nærmere drejer sig om den massive kritik af sikkerhedsproblemer, ræk venligst hånden op.

Der er rapporter om, at brugere finder sig logget ind på sider/tjenester som andre brugere, webapplikationer, der uden videre sletter indhold og frygt for, Google samler fortroligt materiale.

Du bør tænke to gange, før du installerer Google Web Accelerator. Jeg installerer i hvert fald først, når der er fuld klarhed over, hvad applikationen virkelig gør på min maskine med min information.

Hvorfor er alle CMS’er “førende“?