Det spørgsmål har inspireret mig, efter at Stephen Anderson delte sine insights om ”The art and science of Seductive Interactions” til den internationale user experience konference UXLX 2011 i Lissabon.

Spørg dig selv: Hvad ved vi egentligt om mennesker? Vi er nysgerrige, Vi kan ikke lide forandring, Vi søger efter mønstre, Vi organiserer ting, Vi er selvcentrerede, Vi er dovne, osv. osv. …Men hvor ofte bruger du faktisk det  i dit web design?

”Seduction: The process of deliberately enticing a person to engage in some sort of behaviour, frequently sexual in nature”

Stephen Anderson pointe er, at vi kan gøre vores interaktionsdesign forførende ved at bruge den viden vi har om den menneskelig psyke. På den måde kan vi designe et digitalt produkt, så det bliver det sjovt og engagerende for brugeren at interagere med og at den handling, der samtidig udføres, understøtter forretningsmål.

Et eksempel er procent baren fra Linkedin. Et ganske lille interface element, der har gjort at den gennemsnitlige ‘completeness’ er steget markant. Hvorfor? Fordi den forfører os ved at udnytte, at vi reagerer positivt på at opgaven er brudt ned i mindre steps, at der er levels og at der efterfølgende er en belønning.

Det kan lyde banalt og åbenlyst, men hvis vi for alvor skal udvikle interessante interfaces, der motiverer og engagerer vores brugere er det værd at lade sig inspirere af psykologien i forhold til hvad der virker.

Stephen P. Anderson slideshare: The art and science of seductive interactions

---

Er du interesseret i at vide mere om hvilke digitale trends vil præge vores kunders hverdag i 2012?

Få de seneste input om indholdsstrategi, interaktionsdesign og kreative arbejdsprocesser i et inspirationsoplæg præsenteret af to af 1508s strategiske User Experience designere: René Lundgaard og Louise Klinker.

Tilmeld dig til Morgenboosteren om digitale trends i 2012.

“¦ removing manual operations related to Sitecore releases.

For the last year we have been focusing on integrating our Sitecore solutions in a Continuous Integration environment. We now have two larger Sitecore solutions and many smaller ones in the environment, where we can build, test and deploy environments, including Sitecore Items. We have gone through some iterations of the environment and find that we are ready to share some of our experiences.

Continuous Integration

The main purpose of continuous integration is to have an environment where code is build and tested at every commit, secondarily the build can be pushed to TEST or QA environments. The ultimate goal, for us, is to be able to test, validate and push Sitecore Sites from development to production, without any manual steps.

Continuous Integration and Sitecore

A Sitecore solution is composed of three parts, 1) the code 2) the database build by the developers (templates, layouts etc) and 3) the user content that is stored under sitecore/content and sitecore/media. The code is easy to integrate in a automated build, tests and deployment since this is the main goal of most CI setups, but where it gets more challenging is when the Sitecore Items get involved. Without the Sitecore Items in the CI setup there remains several manual parts for a release cycle.

Automating Sitecore builds and release cycle

CruiseControl.NET has been chosen as build server platform and custom NAnt tasks are used in the build scripts for search and replace, robocopy and Sitecore Item control.

Item Versioning and (Auto)Serialization

Sitecore Items is a big part of a solution and the first requirement is that the Items can be put under Source control and versioned correctly, the native implementation from Sitecore is based on a manual “œdump” of what the developers choses to save to disk.

In a multi-developer environment this lead to developers dumping the whole sitecore database at each checkin, and reverting the full database takes over 10 minutes sometimes 30 so this was not done before each development session.

When renaming and deleting Items, this setup lead to Items being re-added to the tree after they had been deleted by another developer, because the other developers had not removed them before they themselves made a item dump and checked in.

What was needed was a synchronization model for keeping the file system up to date with Sitecore without user involvement, thereby the only files the developer checks in are the ones he has made changes to. This has been done by developing an auto serialization that attaches to the Item events and e.g. deletes the file if the Item is deleted, or serializes content items if there releted template is changed. We do not yet import file changes fully automated to Sitecore, for the fear of loosing work in case of merges and conflicts, but it would be a natural way to go.

This module means that we now have a stable model for versioning our sitecore item development, this was a base requirement for moving forward.  We have full traceability on the system development since every developer runs his own Sitecore code and database and both code and items are versioned.

Build Flow

We have done several iterations of the build scripts. Our latest iteration pushes the files before changing the configurations, and performs testing directly on the target system.

Repository Branching Strategy

Our latest project phmetropol.dk sometimes involved up to 8 developers, and 60+ change requests in some releases. For controlling this we created code branches in our repository for UAT and PROD. UAT had the latest code that was for final customer validation (UAT = User Acceptance Testing) and PROD contained the latest released code. This setup gave us the possibility to keep active development in the main trunk (incl. Sitecore Items) and releasing well tested code+Items in the UAT branch with a potential fix or two, and finally being able to hot fix (incl. Items).

Without version control on the Sitecore Items, we believe, such releases would have had major risks for errors.

that needed testing and We have also tried where the test was done locally before the files where moved, where items where separated from the build files but we had the need to introduce repository branching for adding a UAT and PROD build, and the configuration management when involving staged setups made the model complicated.

Configuration Management

The Sitecore solutions we have build in our environment have all involved staged setups, we have found two strategies for controlling the configuration under automated build.

Staged build and environment creation

genvej.nu is created with two websites in the Visual Studio project, one site for CMS and a site for the Front site, config files for both environments are checked in and most of the rest is copied from the Visual Studio build process from bin/ressources/layouts etc. to front. The only things the build script had to change was the environment elements in each web.config.

Staged and environment creation

phmetropol.dk was our next project we wanted to create the staged files based on the cms files only, for keeping the development environment more streamlined. This means that we, from the NAnt build file, first created a staged copy of the source, changed the config to match a staged setup (using include files for overriding where possible) and last customized based on the target environment.

This worked well in our development stage but when we saw the need to introduce the UAT environment and build this setup has become a bit complicated to maintain.

Sitecore Items

Controlling Sitecore Items in the build process required that we had them under version control and branched. Once this is in place the next step is to push them around on our different environments.

For reverting and packaging a Sitecore context is required, we have therefore implemented a web service in the Sitecore admin level, that gives us access to reverting, serializing and packaging features. Combined with a NAnt task we can control items deserialization or packing from the build script.

We have initially implemented a full revert or partial, that we can control through a web service on the Sitecore environment to give us Sitecore context. In a default cycle the only path we revert are template and layouts, but we can also revert all of Sitecore in both core and master, the problem is that this takes up to 30 minutes, so our default behavior is only the main elements.

After some iterations, we are currently looking at a model where we push the items to the target using robocopy and use the change log to revert only the affected items on Sitecore, we have done a proof of concept and this feature is in active development. This will mean we can revert sitecore items on each build because it will be done very fast. In the process we har also evaluating ideas for partial reverts on the developer machines but in that area we have yet to find the best model.

Once reverted and tested we can package e.g. template and layouts, and save a package that is then used for deployment to production, or backup.  When deploying we never take items related to Content or Media, every other Item is excepted to come from our controlled builds and packages. We have had some surprises with Web forms for marketers and Sitecore/system in this context but we will keep that for another post.

Testing

Basic code test is implemented with NUnit and could be run after the build is done on the build server. We have chosen to deploy the site first so we can run functional tests involving page clicks and search results for tests. For allowing tests on the Site we have used WatiN.

For making functional tests on controlled data and not client content we have introduced two parallel sites in development, one used in the building of NUnit tests that validate main functionality and the other used by the client to build their content. In the development phase we let the clients build up data on the qa environment and we actually fetched data with our tool web service that we pushed to our test server so we could see more real content in the test environment and still have a semi stable environment for client qa.

Other levels of testing and quality control have been implemented using FxCop, StyleCop and TotalValidator and NArrange in the development cycle.

Conclusions

We have used a reasonable amount of time building this setup. We are now able to construct larger Sitecore solutions, with tests, branching and a release cycle with full source control and minimal manual processes.

In our next project we hope to take the last step and implement continuous deployment, so production is updated straight from our build server. We also expect to implement Web Config Transformation now available with Visual Studio 2010.

We see a Continuous Integration environment as a natural part of a large Sitecore solution and an important move towards a release process.

We would like to know about your expirences on Continuous Integration, so please leave a comment or blog post.

Jan Hebnes, Head of .Net development

I sidste uge lagde vi et link til vores foreløbige prototyper til det kommende 1508.dk på Twitter. Interessen var stor. Mere end 200 har efterfølgende været inde og se nærmere på vores work in progress.

Og hvorfor nu begynde at linke til ufærdige stregtegninger over et kommende website? Det er der flere grunde til.

For det første: Why not! Prototyper over vores kommende website kan ikke siges at være vores største forretningshemmelighed. Derimod tænkte vi, at det måske ville være interessant for andre at følge med i, hvordan vi selv udvikler web. Specielt bliver det interessant at se, hvor stor udviklingen fra de første skitser til den færdige løsning bliver.

Feedback. Måske vi kunne få gode input fra dig. Fx, hvorfor er der ikke et videounivers? Hvor er Feedback-funktionaliteten? Hvor er prototypen over den mobile udgave osv”¦ Det kunne jo tænkes, at vi ikke havde overvejet alt og kunne blive klogere. Hermed ikke sagt, at det bliver brugerne som kommer til at definere vores kommende site.

Test-trial for vores kunder. Vi har længe tænkt på, at vores kunder løbende skal tweete eller blogge om processen med at udvikle eller relancere websites. Det er vores erfaring, at en af de største udfordringer ifbm. nye webprojekter for større organisationer er at skabe intern opbakning og opmærksomhed. Kun på den måde kan websitet (og den totale online tilstedeværelse) få den centrale placering i organisationen, som det i 9 ud af 10 tilfælde fortjener. Her er det oplagt løbende at være i dialog med både interne og eksterne interessenter, så gode råd, fordomme, irritationer o.l. kan tages i opløbet. Vi oplever dog også en vis frygt for denne åbenhed. “Vil det ikke blot medføre unødig brok?”, “Afdelingscheferne bliver jo sure, hvis ikke deres forretningsområde bliver en del af globalnavigation” osv. Min holdning er dog, at denne involvering i processen er det, der skaber gode resultater.

Nu tager vi vores egen medicin og glæder os til at evaluere, hvordan det kommer til at spænde af.

<

p class=”MsoNormal”>Projektchef Rasmus Rudolf Christiansen

//Designkonceptskitse//

500 webdesignere/webudviklere var samlet i Boston til 2 dages konference med fokus på design, kode og indhold.

Udover 1508″™s 2 webudviklere, var en håndfuld hollændere, et par svenskere og tyskere, de eneste europæere blandt amerikanske ligesindede.

2 hovedbudskaber: Fleksibelt webdesign CSS3 – brug det, nu!

Fleksibelt webdesign I mange år har vi designet og udviklet til kendte platforme/klienter. Så længe vi holdt os inden for 1024×768, og var sikre på at det vigtigste indhold var over “™folden”™, kunne vi nogenlunde sikre den gode brugeroplevelse. Men med det mobile webs eksplosive fremgang og tilgang af nye devices som iPad, notebooks og lignende er vi nu nødt til at tænke anderledes. Vi skal nu komme brugeren i møde ligegyldigt hvilken platform, der vælges at browse websitet på.

I en lang periode har den mobile brugeroplevelse været nedprioriteret. Tit tilbyder man bare brugeren en nedskaleret udgave at websitet, hvor brugeren tvinges til at zoome og scrolle sig frem til sit mål. Men hvis man virkelig ønsker at ramme en bred målgruppe, skal mobilløsningen tænkes ind fra starten. En god øvelse er derfor at starte med det mobile design. Her tvinges man til at minimere sin struktur og informationsarkitektur, og stille skarpt på hvad der er allervigtigst for kunden/brugeren?

Udover at være en udfordring ift. informationsarkitektur stiller den device-tilpassede webløsning store krav til designet og HTML-koden, for at skulle kunne rumme alle skærmformater fra 480×320 (iPod) og opefter. Er det muligt at lave et design/kode, der kan tilføje/fjerne website-elementer alt efter bruger/device uden at det ødelægger helhedsindtrykket? Spændende udfordringer!

CSS3 ““ brug det, nu! CSS3 har, for mange udviklere, længe været skatten for enden at regnbuen. Men så længe majoriteten af brugerne har siddet på forældede browsere, har argumentet for at benytte den nye standard ikke været der. Oftest har man tilgodeset de brugere, der sad på de svageste klienter (Internet Explorer) for at sikre den samme oplevelse for alle brugere. Det bliver der lavet om på nu, hvor web-browsing bliver flyttet over på den mobile klient og dermed fra Internet Explorer på PC til Safari og Opera på smartphone. Både Safari og Opera er moderne browsere, der understøtter mange af de nye features.

CSS3 bliver aldrig en færdig implementeret standard på alle browserklienter. De forskellige browsere tilføjer og fravælger de funktioner fra CSS3 de finder bedst. Derfor blev der fra talernes side kraftigt opfordret til at tage den nye standard i brug og gøre op med den gamle tvangstanke om at alle brugere, ligegyldig hvilken browser, skal have den samme oplevelse. Dette er med til at fastfryse udviklingen. I stedet skal man sikre at alle bliver tilgodeset og får en god oplevelse, men de der sidder på nyt, opdateret software bliver præmieret med ekstra lækkerhed.

En taler på konferencen kom med et glimrende eksempel, der kommer fra TV-branchen. Da man gik fra sort/hvid til farve-programmer, sad mange seere stadig med forældede sort/hvid-skærme. Men oplevelsen for dem var den samme som altid, da signalet stadig kunne fortolkes. Først når de så samme program hos naboen, kunne de se forskellen. Det samme vil ske nu for webbranchen. Do websites need to look exactly the same in every browser?

Stor oplevelse Alt i alt har det været to utrolig inspirerende dage med fantastiske taler fra web-verdenens sande konger og bannerførere. Og en skøn oplevelse at være i selskab med 500 ligestillede, der alle taler samme sprog (HTML/CSS).

Sjovt var det også da 1508″™s design til Syddansk Universitet pludselig tonede frem på Jared Spools oplæg  “œAnatomy of a Design Decision” . Jared Spool havde lavet et eksempel på det han kaldte Genius Design (hvor man designer noget, der har været designet før). Analysen omhandlede universiteter og deres look-and-feel. Stort set alle benyttede sig af det han kaldte “Girls under trees” ““ tema. Herunder 1508.

/Jonas Damsgaard Olsen, senior webudvikler

Gennem webevolutionen har der været en tendens til et skifte frem og tilbage mellem backend og frontend. Afhængigt af hvilken, der i perioderne var sværest at duplikere, har vigtigheden af enten algoritmer eller data haft et forretningsmæssigt fokus frem for den anden forårsaget af udbud og efterspørgsel.

Under Web 1.0 dominerede beskyttede programmer og organisationerne med de bedste softwarefunktioner (backend, algoritmer osv.) var styrende, mens selve dataen generelt ikke var i særligt fokus. Dette skyldes sandsynligvis en tankegang dannet i en tid med lidt lagerplads, processerkraft og derved muligheder ““ samt inden massebrugerens aktivitet på internettet.

Med Web 2.0 skiftede tendenserne og ændrede organisationernes fokus til den anden side af ligningen: data. Open source resulterede i et paradigmeskift væk fra de traditionelle software- og forretningsmodeller, og lukket “ejerskab” betragtes herefter næsten som et fejltrin i en webproduktion. I denne frontend-periode var fokus på erhvervelsen af data og hvordan disse informationer kunne udnyttes til en kommerciel fordel. Som et resultat opstod mange services, der forsøgte at bevare sin fordel gennem brugertilknytninger og sociale relationer.

For Web 3.0 tegner sig nu endnu et fokusskift, denne gang tilbage til backend og software igen. Modsat i Web 1.0 opfordrer det teknologiske potentiale i det semantiske web til at gøre data både frit tilgængelig og struktureret, hvorved der skabes nye muligheder for anvendelsen. Dette er et paradigmeskift væk fra tankegangene om beskyttelse og ejerskab ““ karakteristisk for både Web 1.0 og Web 2.0. Med udgangspunkt i Web 2.0s frontend tilbyder den semantisk backend markante forbedringer af eksisterende produkter og services ““ og medfører således alternative indtjeningsmuligheder i Web 3.0.

Som et pendul svinger tendenserne efter Web 3.0 således frem mod Web 4.0 og peger på frontend igen. Der eksisterer endnu en masse teorier og bud på et kommende Web 4.0, hvilket gør emnet til et helt kapitel for sig. Det vil derfor blive behandlet i et separat blogindlæg, der tegner tendenser og fremtidsforudsigelser for næste årti i webudviklingen.

Nye brugstendenser medfører nye markedsvilkår

Med de sociale egenskaber introduceret i Web 2.0 ændrede peer-produktionen på eksisterende markedsvilkår og forretningsmodeller for Web 1.0. Blogs, chat-rum, wikis, søgemaskiner, auktioner, reklamer, P2P download og personlig transmittering repræsenterede nye måder at underholde, kommunikere og interagere på internettet. I hvert tilfælde bliver den traditionelle passive køber af redaktionelt stof og reklamevarer til en aktiv, deltagende rolle i værdiskabelsen. Som en uundgåelig følge, trues de traditionelle måder at drive forretning online.

For de virksomheder, der tilpassede sig de skiftende tendenser (udnyttelse af Web 2.0″™s masse-samarbejde), medførte det nye enorme forretningspotentialer. For individer og små producenter opstod der ligeledes en ny forretningsæra ikke tidligere set. Brugerne blev selv en del af økonomien ““ et enormt globalt netværk af specialiserede producenter af viden, der deler og udveksler services for underholdning, livsnødvendigheder og læring. Dette beskriver den magt almindelige mennesker som forbruger, medarbejder, online-communitymedlem etc. i dag besidder for at skabe innovation og ny værdi på det globale marked.

Et nyt økonomisk demokrati opstår med Web 2.0, hvor vi alle har en ledende rolle. Det tager udgangspunkt i at være åben overfor omverden, skabe innovation i sammenspil (særligt med kunderne) og dele tidligere beskyttet ressourcer (som f.eks. data, viden og ekspertise). Således opstod nye forretningsmodeller i overgange fra Web 1.0 til Web 2.0, hvorved mange af reglerne for konkurrence krævede en omskrivning. For Web 3.0 stiller de nye tekniske muligheder og vilkår for værdiskabelse at krav til revurdering eller tilpasning af traditionelle forretningsmodeller for webindustrien.

Traditionel reklameindtjening udfases

Indtægtskilden for mange kommercielle sites i Web 1.0 og Web 2.0 har gennemgående bygget på en generel webforretningsmodel: Ved at forøge trafikken på et website, forøges tilsvarende indtægten fra reklame. Den blandede indholdsgenerering i Web 2.0 har dog haft negative indflydelse på værdien: “Most rely on display advertising – a.k.a. banners – to make money. But marketers have cooled to display ads on the web, and they’re especially skeptical of such advertising on social-networking sites.” [fra artiklen Web 2.0 is so over. Welcome to Web 3.0].

Web 2.0″™s brugergenerede indhold skaber så mange websider med varierende sidevisninger, at der ikke længere kan forlanges samme pris som f.eks. på portaler. Eksempelvis kan Yahoo!s nyhedssite taksere ca. 30 gange mere for en bannerreklame end Facebook, sandsynligvis pga. at målgruppen er mere specificeret og visningen af den enkelte reklame højere. Hvis en bannerreklame eksisterer på 1.000 websider, vil i gennemsnit mellem to og fem klikke på banneret for at lære mere. Dertil kommer, at disse to-fem ikke partout resulterer i salg.

Med mindre eksisterende produkter og forretningsmodeller tilpasser sig egenskaberne til de kommende webtendenser, risikerer de at låse sig fast og lide samme skæbne som under dot-com krisen i Web 1.0. Reklamebannerne er et eksempel på, at eksisterende forretningsmodeller risikerer at miste sin værdi, når teknologien og brugerne ændre på virksomhedernes omverden.

To primære tendenser for Web 3.0 peger mod: dels at udnytte den fulde styrke af digital globaliseringen og dels servicering af kunderne én til én gennem personalisering. Læs meget mere om disse tendenser i kommende blogindlæg – så hold dig tæt.

Siden introduktionen af et World Wide Web tilbage i 1989 har mængden af tilgængelig information på internettet steget hastigt. Denne tendens skyldes primært udviklingen af de brugercentrerede webservices, der opstod under fællesbetegnelsen Web 2.0. Funktionaliteter for upload af tekst, billeder, video og lyd gjorde alle brugere med adgang til en internetopkobling samt webbrowser i stand til at agere redaktør og deltage i genereringen af indhold.

I dag tegnes efterhånden en kurve for informationsmængden, der sætter de eksisterende søgeværktøjer ude af stand til tilfredsstillende at sortere i denne voksende mængde af tilbud. Dette skyldes især, at browseren ikke kender dig og dine behov, men blot præsenterer et resultat på baggrund af søgning efter nøgleord. Effektiviteten af søgning efter informationer på nettet og produktiviteten for brugerne, spås fremover en nedgang pga. det stigende sorteringsarbejde frem til den relevante information. Lad os tage et eksempel:

Forestil dig at du skal på en klassisk date med biograftur og efterfølgende middag. Du er i humør til en komedie og italiensk mad. Du åbner en webbrowser og benytter Google til at søge efter oplysninger om film og restauranter. Du vil gerne vide, hvilke film der spiller i biografer i nærheden af dig, så du bruge lidt tid på at besøge forskellige biografhjemmesider og læse korte beskrivelser af de enkelte film, inden du foretager dit valg. Desuden ønsker du at se, hvilke italienske restauranter, der ligger tæt på hver af disse biografer, samt læse nogle kundeanmeldelser for restauranterne. I alt skal du sortere i en lang liste af søgeresultater og besøger en stribe websteder, før du er klar til at gå ud af døren.

I dag er vi således ved at nå til et informationsmæssigt mætningspunkt, der skaber behov for en ny strukturering og repræsentation af information. Opgaver som søgningen efter film og restauranter skal gøres meget hurtigere, nemmere og mere målrettet for den enkelte bruger. Dette begrunder et generationsskift i webudviklingen og overgangen til nyt stadie ““ Web 3.0.

Web 1.0 havde fokus på at få folk og virksomheder online. Web 2.0s “Social Web” fokuserede på at skabe forbindelser og relationer mellem mennesker online. Web 3.0 vil fokusere på det “Semantiske Web”, der medfører nye og mere intelligente måder at præsentere og koble viden online. I eksemplet ovenfor vil du, i stedet for adskillige søgninger og hjemmesidebesøg, blot kunne skrive din forespørgsel i browseren, hvorefter World Wide Web gøre resten. Inden en date skriver man blot: “Jeg ønsker at se en sjov film og derefter spise på en god italiensk restaurant tæt på min bolig. Hvad er mine muligheder?” Browseren vil analysere din forespørgsel, søge på internettet efter alle relevante svarmuligheder og derefter organisere resultaterne for dig ud fra relevans ““ udelukkende med udgangspunkt i dig og din profil.

Kontekstbaseret søgning

En browser i Web 3.0 vil således fungere som en personlig digital agent. Når du søger på internettet lærer browseren, hvad du er interesseret i og indsamler informationer om f.eks. din økonomiske og sociale situation fra forskellige kilder. Jo mere du bruger internettet, jo mere vil din personlige agent lære om dig og jo mindre specifik behøver du være i din søgning. I sidste ende vil agenten selv kunne registrere i din kalender at du skal på date, hvorefter den finder og opstiller relevante tilbud baseret på dine præferencer.

De præsenterede tilbud baseres på baggrund af en samlet brugerprofil af dig, der konstant opdateres, krydsrefereres og er optegnet ved hjælp af de “digitale fodspor” brugeren sætter. Hver gang man foretager et køb med dankort, browser hjemmesider, lokaliseres via GPS, sender en mail, registreres til en konference og besøger lægen etc., opsamles data og sammensættes til en brugerprofil, der så korrekt som muligt danner et billede af dine konkrete præferencer.

Spørgsmål om overvågning, misbrug og sikkerhed dukker naturligt op som relevante diskussionsemner og problemområder, men som man så det for både Web 1.0 og Web 2.0 vil det altid være muligt at finde løsninger på udfordringerne, så længe fordelene eller behovene er store nok. For 10 år siden havde de færreste af os vel drømt om at ordne vores banksager via internettet og tjekke vores saldo på mobilen. Der arbejdes derfor ihærdigt på at finde løsninger gennem bl.a. udviklingen af nye standarder og metoder ““ der leder til nye muligheder for forretningsområder og ““modeller.

I fremtidens Web 3.0 vil vi opleve et Semantisk Web, som kan vurdere kvaliteten af vores søgninger og svare direkte på de spørgsmål vi stiller. Computerne kommer således til at være aktive og vurderende medspillere. En seriøs samtalepartner så ingen længere behøver trykke på knappen “Jeg prøver lykken” i Google. Med potentialet for Web 3.0 vil du kunne læne dig tilbage og lade den semantiske teknologi gøre arbejdet for dig. En semantisk søgemaskine har forbedret muligheder for at anvende og reagere på de informationer mennesket og computeren udveksler online. Derfor kan søgningen benytte private informationer såsom: antallet i familien, afstanden fra hjem til arbejde, privatøkonomi etc. Webagenten indsamler, analysere og præsentere data for dig på en måde, der gør en sammenligning af mulighederne overskuelig, hurtig og relevant ““ kun for dig!

I går afholdte vi et gå-hjem-møde hos 1508 om emnet. Gå-hjem-mødet blev streamet live via Bambuser, og du har mulighed for at se optagelserne her. Du kan også se billeder fra arrangementet på Flickr, eller vende tilbage her på 15all, hvor jeg i kommende blogindlæg vil jeg gå mere i dybden med de teknologier og mindsets der skal til, for at Web 3.0 kan blive en realitet. Det er bl.a. et fokus på nye digitale repræsentationer af viden, den tekniske udvikling og webstandarder, samt bud på nye krav til de eksisterende forretningsmodeller.

Forestil dig, at du i din digitale kalender skriver hvornår og hvor du holder ferie. Herpå finder computeren skræddersyede tilbud om flyrejse, ferieforsikring, forslag til seværdigheder, restaurantbesøg osv. Altsammen tilpasset den profil, som du via dine fodspor på nettet har skabt af dig selv.

Web 3.0. handler om intelligente søgemaskiner, der kan analysere dine behov ved at krydse oplysninger fra Facebook, Twitter, netbank m.m. – og knytte de relevante forbindelser. Med web 3.0. ændres internettet fra at være et sted, hvor viden er manuelt tilgængelig til at være et sted, hvor den er fortolket, udvekslet og behandlet. Fordi det er lettere at finde en nål i en høstak, hvis høstakken er sorteret efter antallet af nåle.

1508 holder et gå-hjem-møde om emnet den 9. juni 2009 kl. 15-17. På mødet fokuseres på det fundamentale paradigmeskift fra informations- til viden-centrerede tendenser, der leder til nye muligheder for effektivisering, brugeroplevelse samt forretningspotentiale online.

Hvis du har lyst til at deltage, kan du tilmelde dig på 1508.dk.

God underholdning hvis du vil føle dig som kongen af St. Germain

http://www.najle.com/idaft/

Tak til Robin

Normalt kan du få mig til at tale i flere timer om hvorfor wiki“™er er noget af det bedste der er sket for videndeling. Og normalt jeg er ovenud glad for at vi har en wiki som intranet her i 1508.

Men jeg bliver lidt støt når jeg får følgende besked når jeg logger ind i vores wiki.

Bad username or password?

Jeg synes da både mit brugernavn og mit password er godt. Det kan godt være jeg skrev det forkert, men derfor er det jo stadig et godt brugernavn. Der er vi i hvert fald uenige.

Der er stor forskel på om der menes forkert (altså ‘wrong’), ikke gyldigt (altså ‘invalid’) eller dårligt som de skriver her.

Man skal som designer af website og anden form for brugerinteraktion altid huske på at udforme sin feedback til brugerne på en måde så de giver mening, og er fuldstændig entydige.

Hvis det wiki”™en forsøgte at fortælle mig, var at det brugernavn og/eller password jeg indtastede var forkert, kunne det jo bare sige det. Den behøver ikke at fornærmer mig ved at agere smagsdommer.