Action point teorien et udviklet af Geoffrey Brown[1] i 1999, og tager udgangspunkt i, at et website skal fokusere på brugerens mål med at besøge websitet. Ved brug af action point teorien vil brugeren få en mere positiv oplevelse, og derigennem vil websitet med større sandsynlighed blive besøgt igen, frem for at brugeren prøver et konkurrerende website.

Teorien har fire delelementer.

1.      Action point

2.      Entry point

3.      Action path

4.      Exit point

Ad 1.

Et action point er et sted på websitet, hvor brugeren har opnået et givent mål. I forbindelse med en butik, vil det være idet en ordre afgives. Et website kan godt have flere forskellige action points, men det understreges, at pointet ligger ved opnåelsen af målet, og ikke på vejen til det. Action points kan hænge sammen med exit points. Ved en loganalyse kan man naturligvis ikke se en hitliste over sider, hvor brugeren har opnået sit mål, men til gengæld kan man analysere top exit pages, og derigennem få et billede af mulige steder, hvor brugeren opnår sit mål, og derfor forlader websitet. Man kan dog ikke pr. definition antage, at en action point og et exit point er det samme. Brugerne kan vælge at forlade websitet af mange andre grunde end et opnået mål. Derfor må kan foretage en vurdering af exit listen, og sammenholde den med de steder, man forventede et action point.

Ad2.

Entry points er områder, hvor brugeren typisk vil tilgå websitet. Optimalt vil man sige, at det er forsiden af websitet, men det vil være utopisk at tro enhver bruger, vil komme denne vej, f.eks. ved at indtaste URL’en i browseren. Det kan være en tilfældig side, fundet på en søgemaskine, et link fra en webside, vedrørende en speciel del at websitet, henvisninger i e-mail kampagner m.m. Man må derfor sikre, sig at de mest sandsynlige entry points vil indeholde henvisninger til action points, for at maksimere chancerne for, at den pågældende side kan fange brugerens interesse, og understøtte det mål brugeren forfulgte da vedkommende tilgik websitet.

Ad 3.

Action paths er de veje, en bruger logisk set kan følge for at nå et mål. Idet langt de fleste websites indeholder global navigation internt på websitet, er der naturligvis et uendeligt antal veje, men i dette tilfælde fokuseres der på de logiske stier, en bruger kan følge i relation til sit mål, og derfor mod et action point. Metoden til at finde disse action paths inkludere ekspertevaluering og loganalyser. Ved ekspertevaluering kan det noteres, at Steve Krug har lavet et diagram over en mulig sti simuleret over en indkøbstur hos en almindelig isenkræmmer. Diagrammet viser nogle af de overvejelser, man kunne tænkes at gøre sig i sin søgen efter et bestemt produkt, mens man vandre op og ned af gangene hos isenkræmmeren[2].  Der er altså brugt en kobling, mellem de overvejelser man gør sig i den fysiske dimension, til dem man gør sig, når man surfer. Denne kobling virker fornuftig, set i lyset af Schanks scenes og scriptlets, som jo netop er mål orienterede. Ved at trække på oplevelser man med stor sandsynlighed har haft tidligere, maksimere man chancerne for, at disse kan benyttes som prototyper i den nye shopping situation.

Målet med at arbejde med action paths er, at minimere vejen fra entry point til action point. Jo kortere man kan gøre denne, jo hurtigere vil man lade brugeren opnå sit mål, ergo vil brugeren få en mere positiv opfattelse af websitet og muligvis benytte løsningen igen, skulle der opstå et nyt behov for at købe lignende produkter.

Specielt i forbindelse med e-mail vil det være muligt at minimere en action path. En mulighed er ”single click purchace”, hvor e-mailen indeholder reklame for et produkt, og ved at klikke på produktet går brugeren direkte til check out området på websitet, med denne ene vare i indkøbskurven. Alternativt kan man on-line helt gå uden om check out og indkøbskurv, som beskrevet på www.amazon.com[3].

Ad4.

Et exit point forekommer ved de sider, brugere forlader websitet. Det er vigtigt at brugeren får sluttet cirklen på en positiv måde, og uden løse tråde i form af tvivl eller uopnåede mål. Exit points kan spores gennem loganalyser, som ud fra en kvantitativ opsummering eksempelvis rangere top 20 exit sider. Man bør dog, som nævnt i ad. 1, tage det forbehold, at analysen ikke altid bør tages bogstaveligt. Det giver imidlertid et billede af, hvor brugere generelt forlader websitet, og i kombination med den rute brugeren har taget, kan man vurdere om der kan ændres på de action paths, der findes, eller om der kan være et interfaceproblem. Ved exitpoint vil der være relevant at tilbyde brugen mulighed for at forfølge nye action points. Idet det tidligere action point her er opnået, har brugeren kun to muligheder: Forlade websitet eller gennemløbe endnu en action path. Det er dog uhensigtsmæssigt at tilbyde det samme action point igen til brugeren, da det indbyder til, at brugeren ”løber i cirkler”, hvilket ikke er en optimal strategi for brugeren. I stedet bør man henvise til andre action points som f.eks. produktopdateringer m.m., som efter et køb kan være valide action points, da de har relation til det tidligere købte produkter. I visse situationer kan det dog være relevant at tilbyde cirkulære action points. Dette er især gældende ved produkt sortimenter som musik og bøger. Her kan man referere til relaterede produkter, og derved skabe en positiv indkøbscirkel. Havde det været en motorsav, ville det højst sandsynligt være mere relevant at tilbyde sikkerhedsudstyr eller værktøj til vedligehold af saven, end andre save. Et eksempel på brugen af sådanne action paths er www.Amazon.com hvor der i relation til en bog, vises hvilke andre bøger andre brugere, som købte bogen, også købte.

At syndikere indhold handler om at dele informationer på tværs af domæner. Der findes flere typer af indholdssyndikering, baseret på ejerforhold, kilde, visualisering og teknologi. For selv at se et eksempel på syndikering kan Danmarks Radio fremhæves med deres gratis nyheds blok.

1: Ejerforhold
Når indhold syndikeres skal der altid defineres et forhold omkring ejerskabet af det pågældende indhold. Er der ikke det, vil ophavsretten altid ligge hos den oprindelige forfatter. Typisk kan syndikering være bundet i et abonnement, hvor modtageren betaler et månedligt beløb for at vise indholdet på eget website. En anden mulighed er at købe ophavsretten med, hvorefter modtager overtager ophavsretten. Er disse ting ikke aftalt inden syndikeringen påbegyndes kan det på sigt få alvorlige konsekvenser.

2: Kilde
Når der først er etableret et ejerforhold, skal kildeforholdet addresseres Dette kan typisk foregå på tre måder. I DR’s eksempel forbliver kilden hos afsender, og visualiseres blot hos modtager. Det har to ulemper. For det første kræves det at afsender er on-line. Går DR ned (usandsynligt, men for eksemplets skyld) vil modtagerens brugere få en fejl i det område hvor indholdet skule have været, og ydermere kan indholdet kun vises på samme måde som afsenderen ønsker det. Der er altså et kraftigt afhængighedsforhold til afsenderen. Den anden mulighed er at modtager gemmer indholdet lokalt på egen server, hvilket både giver fordele og ulemper. Fordelen er at indholdet kan bruges og visualiseres efter forgodtgbefindende i overensstemmelse med ejerforholdet. Ulempen er at hvis afsenderen revidere indholdet, og "publicere" en ny udgave af det, vil modtageren ikke få den nye revision da der her arbejdes med en kopi. Indholdet vil da være forældet (og hvis der benyttes links i indholder vil disse måske også være brudte). Sidste mulighed er indholds-synkronisering. Dette er en udviddelse af mulighed numer to, hvor modtager i et fast tidsinterval forespørger afsenderen om revisioner af syndikeret indhold. Der er mange muligheder med denne metode, men det kræver dog af de to systemet som skal kommunikere sammen er meget integrerede. Idet indholdet kan have fået nye ID’er hos modtager kan det være en teknisk udfordring at finde det indhols som skal opdateres, i hvilke sprogversioner og i hvilke sprog? Det er imidlertid en teknologisk barierre som man kan programmere sig ud af, hvilket dog kan være beskoteligt på kort sigt, man vil sikre indholdets integritet på lang sigt (og således måske ende med at være en besparelse). Der er naturligvis også mulighed for at kombinere de tre former med hinanden. F.eks. Kan modtager hente indholdet "on-demand" og parse det ind som eget indhold (en kombination af metode et og to). Dette vil dog indeholde begrænsningerne fra metode 1 og kræve mere datakraft fra både afsender og modtager (hvormed løsningen bliver mindre skalerbar), men fordelene fra metode to og tre.

3: Visualisering
I eksemplet med Danmarks Radios nyheder er visualiseringen baseret på en tabel og et stylesheet hentet fra DR’s website gennen en URL. Dette bevirker at modtageren ikke kan ændre udseendet på indholdet, med mindre indholdet parses. Gøres dette vil det højst sandsynligt krænke ophavsretten, da en af grundende til at DR tilbyder servicen naturligvist er at brede kandskabet til DR’s nyheder on-line (hvorfor DR logoet også er en del af indholdsblokken). Der er dog andre muligheder. Et kunne være at lade stylesheetet være relativt, og derefter lade modtageren lave sit eget. Der vil dog kræve at modtageren selv kan gøre dette, hvilket man nok ikke satser på hos DR, så de vælger "den simple" metode. Slutteligt kunne man nøjes med at sende "rent" indhold og eventuelt benytte XML til at tagge det med. Det vil åbne op for, at modtager kan arbejde videre med de "rå data" og præsentere dem efter forgodtgefindende og i forskellige sammenhænge. I sådanne tilfælde kræver ophavsmanden ofte at der benyttes kildeangivelse. Et eksempel på en sådan service er InfopaQ’s netavis.

4: Teknologi
Indhold skal naturligvist bæres af et medie. På internet kunne man forestille let sig HTTP (men FTP kunne også bruger i tilfældet med synkronisering). Formatet skulle umiddelbart være til at gætte sig frem til i form af XML. Der kan ydermere tænkes at benytte en DTD til at strukturere XML’en, for at gøre indholdet lettere syndikerbart og lettere for modtageren at arbejde men.

W3C har en del materiale om dette på deres website. Andre teknologier der kan tænkes over er .net applikationer, som natyrligvis også kan benytte f.eks SOAP.