Definisjonen på CSS er: et stilark språk som brukes til å legge opp innhold på en nettside på en ønsket måte.

For å forstå hvordan dette fungerer kan det være verdt å ta en titt på CSS zengarden . Her kan du se hvordan det samme innholdet forandrer utseende ved bytte av stilark. Du finner ikke gode nettsider i dag uten et stilark som bestemmer design og brukervennlighet.

CSS er et levende språk som utvikler seg hele tiden. Funksjonaliteten i CSS kontroleres av W3C som setter en standard som nettlesere skal følge.

Først godkjenner W3C nye funksjoner og metoder, så implementerer nettleserne disse i de neste versjonene. Desverre tar denne prosessen ofte lang tid, spesielt med Internet Explorer.

Det jeg har lyst til å vise her er måten vi kan animere innhold ved hjelp av CSS3. Dette kan være et bra alternativ til JavaScript og Flash. Dessverre er det noen nettlesere (Internet Explorer) som har vanskeligheter med å vise dette. Bruker du en eldre versjon av Internet Explorer anbefaler vi deg å enten oppdatere til siste versjon eller laste ned Firefox eller Chrome.

Funksjonene jeg vil vise ligger i metodene:

• Transforms (Transformerer et objekt)
• Transition (Animerer et objekt over tid)
• Animate (Animerer et objekt over tid, denne metoden er litt mere avansert)
• Box-shadow (Legger indre eller ytre skygge på et objekt)

Eksemplene under er overdrevet for å vise CSS funksjonen bedre. Du ville sjeldent brukt disse nye stilene på samme måte.

Transformering av objektene

Som du ser fra tabellen over er denne metoden støttet av alle moderne nettlesere. Under ser du et par eksempler på forskjellig bruk av transformeringsmetoden.

Animasjoner med CSS3 på Metronet

Vi er veldig glade for det engasjementet alle viser rundt WordPress. Vi i Metronet lærer gjerne av andre og vi deler gjerne av den kunnskapen vi selv sitter på. Drivkraften med kunnskapsdeling og communitybasert utvikling er selve kjernen i Open Source og vi er veldig glade for at det begynner å bli et såpass stort engasjement rundt WordPress i Oslo og Norge forøvrig.

Er du interessert i WordPress er du velkommen med i Oslo WordPress MeetUp Group. Vel møtt!

Økt engasjement rundt WordPress på Metronet

Here we will describe through an example how to seamlessly show the correct version of the website depending on which device is being used to access it and still giving the possibility to the user to choose manually which version he wants to see. We will build our example in 2 parts:

1. How to automatically detect whether the browser accessing the content is from a mobile device or a laptop.

2. How to let the user choose whether he wants to see the mobile version or the full version of a website using PHP session variables.

Part 1. Detecting whether the device accessing the content is mobile or not

Lets say we have a website http://www.example.com and that we make another much simpler website for being the mobile version of it ( http://www.example.com/mobile ).

We would like that when accessing the url example.com from a mobile device ( mobile phone, pda, etc ) then the request is automatically redirected to the mobile version of the site.

For accomplishing this we have to detect which type of device is accessing our website.

After some research, a god way for device detecting is to make use of the WURFL database. WURFL is a database available on the web that collects information about all the mobile devices out there. The WURFL project has APIs for several programming languages. We will be using the PHP API Package for WURFL.

1. Download the PHP API Package for WURFL and unpack it in the root of your webproject.

2. Download the latest WURFL Database file

3. Place the latest WURFL db file into the folder: your_project/wurfl_api/examples/resources/

4. Open the configuration file your_project/wurfl_api/examples/resources/wurfl-config.xml and make sure that it uses the latest WURFL db file, search for the directive «main-file».

5. Now you are ready to use the API in your index.php

// Include the WURFL/Application.php file
require_once "wurfl_api/WURFL/Application.php";

// Provide the absolute or relative path to your wurfl-config.xml
$wurflConfigFile = "wurfl_api/examples/resources/wurfl-config.xml";

// Create WURFL Configuration from an XML config file
$wurflConfig = new WURFL_Configuration_XmlConfig($wurflConfigFile);

// Create a WURFL Manager Factory from the WURFL Configuration
$wurflManagerFactory = new WURFL_WURFLManagerFactory($wurflConfig);

// Create a WURFL Manager
$wurflManager = $wurflManagerFactory->create();

5. The API has methods for checking which device is being used and methods for figuring out whether the device is mobile or not

// Sending the whole http request you can detect which device is being used
$device = $wurflManager->getDeviceForHttpRequest($_SERVER);

// Check if the device is mobile or not and set the session variable accordingly
if ( $device->getCapability( 'is_wireless_device' ) == 'true' )
{
    //THIS IS A MOBILE DEVICE
     $is_mobile = true;
}
else
{
    // THIS IS NOT A MOBILE DEVICE
    $is_mobile = false;
}

6. Finally we do the redirection if the browser is mobile

if ( $is_mobile )
{
    header("Location: http://www.example.com/mobile");
    exit();
}

Part 2.  Using PHP session variables to shift between mobile and full version

Now, its very nice that mobile users get automatically redirected to the mobile site, but since the mobile site can be limited in content then this users should really be able to switch between the mobile and the full version of the site.

For this we add links at the top of both websites.

But we want the browser to remember which version of the site the user wants to see, so if he chooses to see the full version site, whenever he goes back to http://www.example.com he will be NOT automatically redirected to http://www.example.com/mobile . For accomplishing this we will use PHP session variables. Remember session variables persist for as long as the browser is open.

First, we need to be able to send some information to the server to tell him that we want to switch from one version to the other. We can do this by sending GET variables in the very same url of the link that takes the user to one version or the other.

So, in the full version, the url of the link for jumping to the mobile version will look like this :

http://www.example.com/?show_mobile=1
/* Remember this link should only appear if the browser
accessing the site is mobile. */

And, in the mobile version, the the url of the link for jumping to the full version will look like this :

http://www.example.com/?show_full=1

Then, at the beginning of of the index.php of our full version website ( http://www.example.com ) we try to detect this variable and set a session variable that will persist for the rest of the user’s visit:

if ( isset( $_GET["show_mobile"] ) ){
    $_SESSION["show_mobile"] = 1;
}
if ( isset( $_GET["show_full"] ) ){
    $_SESSION["show_mobile"] = 0;
}

So this variable is set, or reset only when the user clicks in one or the other link. Then we just have to check the session variable «show_mobile» to determine whether he should redirect the user to the mobile version of the site or not:

if ( $_SESSION["show_mobile"]  ){
    header("Location: http://www.example.com/mobile");
    exit();
}

Now we can put all of our example together, first we check the GET variables in order to determine if the user specifically wants to see one version or the other of the website. Then we check if still the session variable is not set, in this case we detect the browser accessing the page and set the session variable accordingly :

if ( isset( $_GET["show_mobile"] ) ){
    $_SESSION["show_mobile"] = 1;
}

if ( isset( $_GET["show_full"] ) ){
    $_SESSION["show_mobile"] = 0;
}

if ( !isset( $_SESSION["show_mobile"] ) ){

    // Session variable has not been set yet, then
    // we need to check which type of browser it is

    $device = $wurflManager->getDeviceForHttpRequest($_SERVER);
    if ( $device->getCapability( 'is_wireless_device' ) == 'true' )
    {
	// After detecting the device we set the session variable, so
	// we dont have to check for the device again and again for each
	// request
        $_SESSION['show_mobile']=1;
    }
    else
    {
        $_SESSION['show_mobile']=0;
    }
}

// Only when show_mobile is true we do the redirection.
if ( $_SESSION["show_mobile"]  ){
    header("Location: http://www.example.com/mobile");
    exit();
}

Redirecting to a mobile site may appear a simple task, but there are some subtle nuances that need addressing to allow a user to view the page as they wish. The approach above gives the user choice, which is important because although a Smart Phone may be classed as a phone, perhaps the screen is big enough to handle the full site.

How to redirect mobile browsers på Metronet

While discussing this with a developer friend of mine he directed me towards PhoneGap. Not does it only allow you to bypass having to write Objective-C to create iPhone apps but it also makes it possible to build apps for Google Android, Palm, Symbian and Blackberry using the same code. With Windows Phone 7 coming soon.

How is this possible? The developers at PhoneGap have built their own Javascript API which hooks into the APIs for all the different platforms, allowing you to access all the native features of the particular devices but by using the same codebase. You can see a list here of the platforms and features supported by PhoneGap. So essentially you can write your app using HTML, CSS and Javascript, upload it to PhoneGap’s build service then they send you back an app-store ready app for each device.

Although there are some negatives from this approach, such as not having full access to all the native features of the device, in my opinion the positives far outweigh this. You only need to know HTML, CSS and Javascript, which are pretty standard for most developers, and more importantly you don’t have to learn Objective-C or Java. As well as this you don’t have the need to develop for each device and (most importantly to me as a lazy tester) you only have to test once.

This approach won’t be for everyone as for more complex apps 100% access to the devices native API will be required. However, for developers who want an easy way to build cross device applications without having to dig into complicated languages such as Objective-C this seems like the perfect solution.

PhoneGap: An All-In-One Solution to Mobile App Development på Metronet

Sammendrag

Dette blir et langt innlegg, så jeg presenterer et executive summary for de som har dårlig  tid.

Det er ikke lett å velge én SEO WordPress plugin fremfor en annen. Utviklerne har lagt vekt på forskjellig funksjonalitet, og det finnes andre WordPress plugin man kan bruke dersom den man velger, mangler funksjonalitet (for eksempel behandling av sitemap.xml eller mulighet for å editere .htaccessfila). Jeg har forsøkt å sammenfatte funksjonaliteten så enkelt som mulig, og sett delvis bortifra at man kan legge inn andre plugins for å få dekket manglende funksjonalitet. Skulle jeg henvist til alternative WordPress plugins på alle mangler, hadde dette faktisk blitt verdens lengste blogginnlegg…

Av disse tre plugins for søkemotoroptimalisering som jeg har testet, fremstår All-in-One SEO Pack som den med minst funksjonalitet. Den dekker basisbehovet, men er ikke særlig fleksibel dersom du kan, og ønsker bruke, din SEO-kunnskap utover basic nivå. Dersom du ønsker å virkelig optimalisere bloggen din for søkemotorene (Google, Bing og Yahoo), anbefaler jeg at man bruker en av de to andre.

Det viser seg være vanskelig å velge en vinner. WordPress SEO har inkludert mye elementær funksjonalitet som mangler hos SEO Ultimate. Men problemet for førstnevnte er at det SEO Ultimate mangler, får man enkelt ved å installere andre plugins. SEO Ultimate består av mer original funksjonalitet. Så om jeg måtte velge blandt to gode SEO plugins for WordPress, lander jeg på SEO Ultimate. Nedenfor følger min begrunnelse.

Plugin-statistikk

Det fremgår av tabellen nedenfor rimelig klart hvilken av de tre SEO plugins som er den mest populære. All-in-One SEO Pack har desidert flest nedlastninger. WordPress SEO er forholdsvis ny, og scorer meget bra på rating.

I gjennomgangen av disse alternativene til SEO plugin til din WordPress blogg, endte jeg opp med godt over 100 funksjonaliteter de tilbyr. Veldig mange funksjonaliteter går igjen i alle tre. Ikke unaturlig, da de er lager av samme grunn; gjøre din WordPress blogg mest mulig søkemotorvennlig.

Grunnleggende funksjonalitet

Det er et minimum av krav man bør ha til en plugin for søkemotoroptimalisering i WordPress. Disse funksjonene kommer blandt annet til syne mens man redigerer artikler (jeg definerer artikler som innlegg og/eller sider, og bruker de respektive navn om jeg kun snakker om én av dem):

Ett minstekrav til en SEO plugin til WordPress er at man kan definere egne titteltagger og meta beskrivelser på artikler man skriver

Alle tre plugins har slik funksjonalitet. Ser man nærmere på den grunnleggende funksjonaliteten som er tilstede når man skriver innlegget, skiller to av dem seg positivt ut. Bildene nedenfor viser at All in One SEO Pack kun tilbyr helt basic manuelle tilpasninger når man skriver artikler. Både SEO Ultimate og WordPress SEO har med ytterligere funksjonalitet. SEO Ultimate får plusspoeng for inkludering av Rich Snippet, NoIndex, NoFollow, mens WordPress SEO får plusspoeng for pen forhåndsvisning, samt en rekke kul funksjonalitet som 301-redirects og robots-kommandoer som noindex og nofollow.

Alle har som sagt grunnleggende funksjonalitet, men WordPress SEO går nok seirende ut av denne runden.

All-in-One SEO Pack (klikk for større bilde)

SEO Ultimate (klikk for større bilde)

Wordpress SEO (klikk for større bilde)

Avansert funksjonalitet

Litt mer avansert funksjonalitet bør man sette pris på, dersom man jobber med søkemotoroptimalisering av WordPress-blogger. Det første man legger merke til, er at All-in-One SEO Pack ikke får sin egen sidemeny i venstremargen, men inkluderes i menyen «Innstillinger». Både WordPress SEO og SEO Ultimate får sine egne menyer i venstremargen, hvor sistnevnte virker mest imponerende ved første øyekast (venstre del av bildet nedenfor). Meeeeen man skal som kjent passe seg for å skue hunden på ulven i fåreklær…

Menyvalg for hhv SEO Ultimate og WordPress SEO

Når vi kommer til avansert funksjonalitet for vår WordPress plugin for søkemotoroptimalisering, faller All-in-One SEO Pack fra. Den har for få ekstra features som kunne gjort meg oppspilt. Den har også endel mangler slik jeg ser det, med mine søkemotoroptimaliserte øyne. Som nevnt tidligere i dette endeløse innlegget, kan man alltid finne andre plugins som tar seg av manglende funksjonalitet, men jeg anbefaler enhver WordPress-blogger til å bytte ut sin All-in-One SEO Pack med enten SEO Ultimate eller WordPress SEO. Men hvilken skal man velge?

Finaleheatet

Her skal jeg være forsiktig med å konkludere, da begge de to gjenværende plugins har mye godt ved seg. Velg plugin for søkemotoroptimalisering utifra hvilke funksjonaliteter nedenfor du setter mest pris på.

Begge de to SEO-plugins har tilrettelagt for:

• Verifisering i Google Webmaster Tools, Bing Webmaster Toolbox og Yahoo Site Explorer. Dette gjør at du slipper fikse dette i php-koden hver gang du bytter tema på bloggen.
• Editering av .htaccess-fil.
• Bruk av canonical URL’er.
• Egendefinerte titteltagger og meta beskrivelser for alle typer standardsider (404, tagarkiv, kategoriarkiv, forfatterarkiv etc.).
• Robots meta tagger. Begge har gode løsninger for å kunne sette noindex, noarchive, nofollow etc på enkeltstående artikler eller ha det som standard for deler av nettstedet.

WordPress SEO scorer ekstra for:

• Godt tilrettelagt for sitemap.xml.
• Mulighet for å sette opp automatisk generering av breadcrumbs.
• Muligheten til å importere settings fra plugins som All-in-One SEO, Headspace2, Robots Meta, RSS footer og Yoast Breadcrumbs. De tre siste er plugins som nå er inkludert som standarddel av WordPress SEO, og man trenger dem ikke lenger. Smart løsning at man også tilbyr å hente settings fra All-in-One SEO Pack, som er den klart mest utbredte SEO-plugin for WordPress p.t.
• Behandling av RSS-feeden din. Godt tilrettelagt slik at du kan legge til topp- og bunntekst som vises for de som abonnerer på RSS-feeden til bloggen din.
• At man ut-av-boksen kan minimere antall internlenker pr side. Link Sculpting er en SEO-gren, enten du tror på det eller ikke.  I tillegg gjør det bloggen din ren og pen. Trenger du virkelig tre måter å klikke deg frem til resten av innlegget (thumbnail, overskriften og les mer-lenken).
• Generelt mye automatisk 301 redirects der det kan passe.

SEO Ultimate scorer ekstra for:

• Logging av alle 404-sider som besøkes (og dermed genererer en URL). Dermed kan du enkelt holde oversikt over URL-er folk forsøker å komme til, men som av en eller annen grunn ikke eksisterer.
• Custom Post Type support (dette har også All-in-One SEO Pack støtte for). Custom Post Type brukes dersom man ønsker å definere andre typer artikler enn innlegg eller sider. Man kan for eksempel definere en ny type artikler som kan være album, review etc.
• Sin løsning hvor man enkelt kan se liste over artikler og arkiv, og herifra endre enkeltstående titteltagger og meta beskrivelser. Genial løsning.
• Rich Snippet – funksjonalitet. Genialt. Vi venter i spenning på et utvidet bruksområde.
• Competition Researcher. Menypunktet lar deg gjøre en rekke undersøkelser på nettstedet ditt. Hvilke sider har best titteltag, innhold, URL etc. i forhold til valgte søkefraser? Hvilke sider har flest utgående/innkommende lenker?
• Deeplink Juggernaut. Fantastiske funksjoner for automatisk oppsett av interne ankertekster. Sett opp nøkkelord og URL-er de skal peke til. Hver gang du skriver ordet, vil det lagres som en ankertekst til den aktuelle URL-en du har valgt på forhånd. Du kan selvsagt sette begrensninger på antall ganger den skal gjøre det pr innlegg etc.
• Linkbox Inserter. Sett opp en linkboks på siden din. Om brukeren ønsker lenke til artikkelen, kan du oppfordre de til å bruke html-koden i linkboksen, som du selvsagt har optimalisert med god tittel og beskrivelse. Hjelper deg med å få optimaliserte innkommende lenker fra eksterne nettsteder – kan det bli bedre?
• Slug Optimizer. Lag en liste over uønskede ord. Disse vil fjernes fra URL-er som genereres. Dermed vil URL-ene i større grad bli bestående av relevante søkeord. Ingen vits at ord som «er», «han», «hvis» og «i» skal stå i URL-en. Dette er i tråd med hva Matt Cutts mener om URL-struktur.
• Muligheten for å legge inn egendefinert kode i <head>-, <body>- og <footer>-feltet. Har man AdSenseskript, Google Analytics eller annen kode man ønsker skal ligge statisk på bloggen, uavhengig av om man bytter tema, er dette gull verdt.

Så hvilken WordPress plugin er best på søkemotoroptimalisering?

Både SEO Ultimate og WordPress SEO har mye god funksjonalitet. Metronetbloggen bruker i dag All-in-One SEO Pack, men kommer definitivt til å bytte til enten WordPress SEO eller SEO Ultimate. Spørsmålet blir hvilken?

Personlig syntes jeg at WordPress SEO har funksjonalitet i seg som burde vært standard også i SEO Ultimate. Obligatorisk funksjonalitet man må ta hensyn til om man jobber systematisk og seriøst med søkemotoroptimalisering. Utfordringen til WordPress SEO ligger i at den funksjonaliteten finner man enkelt gjennom andre plugins. SEO Ultimate har mer spennende og «ny» funksjonalitet inkludert. Så SEO Ultimate vinner en knepen seier, basert på sin uortodokse samling funksjonalitet. Men det fordrer altså at man installerer et lite knippe plugins til, for å være 100 % klar for søkemotoroptimalisering av WordPressbloggen sin.

Takk for meg og god helg!

Beste WordPress plugin for søkemotoroptimalisering på Metronet

Det artige og litt finurlige i arbeidet jeg bedriver, er at ofte ser jeg at små og enkle endringer vil løfte nettsidens rangering på et gitt søkeord fantastisk mye. 15 minutters arbeid kan resultere i en klatring i rangering fra 97. plass til 17. plass. Nå er ikke 17. plasser noe å spare på, hverken i OL, VM, Premier League eller i SEO-sammenheng. Det er heller ikke dette arbeidet som er utfordrende. Det utfordrende er å ta nettstedet fra 17. plass og inn på førstesiden. Det er her det virkelige arbeidet ligger.

Men disse små utfordringene er vi uansett avhengige av å rydde opp i. Og her kommer valg av publiseringsløsning inn. Og dette valget mener jeg er langt mer viktig enn hvem du velger til å designe nettstedet ditt. Ikke se deg blind på hva webutvikleren har produsert før og har på referanselisten, men spør han hva slags publiseringsløsning som ligger til grunn for denne produksjonen.

Etter noen år i bransjen har jeg opparbeidet meg en liten checklist for hva jeg mener er et absolutt minimum av krav man bør ha til sin publiseringsløsning.

• Muligheten til å skrive egne titteltagger alle undersidene
• Muligheten til å skrive egne meta beskrivelser på alle undersidene
• Unngå produksjon av duplikate URL’er
• Muligheten til å lage søkermotorvennlige URL’er
• Legge til informasjon om opplastede bilder (alt-tekst)
• Skrive egne ankertekster i tekstene sine
• Automatisk oppdatere sitemap når nytt innhold produseres
• Kunne lage canonical URL

Disse punktene er ting jeg mener er et absolutt minimum av hva man må kunne få tilpasse selv på eget nettsted, Dette er helt avgjørende for å få til gode rangeringer i søkemotorene. For å klatre det lille ekstra må man jobbe mer aktivt med søk, men grunnmuren for en søkemotoroptimalisert nettside ligger her. Kan du alt her, har du et godt utgangspunkt!

Om du skal lage nytt nettsted, og leverandøren kan svare JA på alle disse punktene, kan du trygt se på designforslagene de har laget.

Har du allerede et nettsted som du savner trafikk til, og nettsideleverandøren svarer NEI på en eller flere av disse spørsmålene, bør du vurdere kost/nytte av å kjøpe nytt nettsted.

Metronet sin web-avdeling jobber utelukkende med open-source publiseringsløsninger. De benytter stort sett publiseringsløsningene Silverstripe, WordPress og eZ Publish, litt avhengig av kundens kravspesifikasjon på det aktuelle prosjektet.

En av grunnene er selvsagt prisen. Det er gratis. Det tjener vi på i form av kutt i produksjonskostnader og det tjener kunden på i form av at det ikke følger med lisenskostnader. En annen fordel er at det er langt mer fleksibelt, slik at man enkelt kan opprettholde de kravene vi som jobber med organisk søk i Metronet stiller til produksjon av nye nettsider.

Krav til publiseringsløsning på Metronet

Det nye scriptet har følgende fordeler:

• Scriptet laster raskere enn det gamle scriptet grunnet at det kan lastes parallelt med resten av scriptene på siden (laster ca 17% raskere enn det gamle scriptet).
• Bedre datasamling og nøyaktighet.
• Færre side- og sporingsfeil grunnet eliminering av gamle problemer med lastingen av JavaScript.

Enkelt forklart er scriptet delt inn i 2 deler:

• Del 1 lagrer all nødvendig sporingsinformasjon.
• Del 2 lager logikken som gjør at det er mulig for de fleste nettlesere å laste Analytics scriptet parallelt med andre script på siden, som igjen reduserer nedlastningshastigheten på nettsiden.

Hvor plasseres det nye scriptet?

I motsetning til det gamle scriptet som skulle ligge et sted mellom <body> </body>, burde det nye plasseres nederst i <head> delen av kildekoden, altså rett før lukketaggen </head>. Denne plasseringen øker sannsynligheten for at informasjon vil bli sendt til Google Analytics før brukeren forlater siden.

For et års tid siden skrev Petter et innlegg om Google Analytics – tilpasset script. Denne tilpasningen gjorde det mulig å spore Norges største søkemotorer og kataloger som spesifikke søkemotorer i Google Analytics. Vi har nå gjort den samme tilpasningen for det nye scriptet.

Fordelen med å bruke Metronets tilpassede script er at vi oppdaterer og gjør endringer i listen over norske søkemotorer fortløpende, så enten det er forandringer i gamle aktører eller nye aktører på markedet, vil du som bruker alltid ha den siste oppdateringen.

Vil du bruke denne tilpasningen, kopierer du scriptet under og legger det nederst i <head> delen (som sagt tidligere, rett før </head> taggen). Deretter bytter du ut 'UA-XXXXXX-X' med din egen Google Analytics ID.

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXX-X']);
</script>

<script src="http://www.metronet.no/script/asynchronous/metronet-ga-f-s-mod.js" type="text/javascript"></script>


<script type="text/javascript">
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script');
ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);   })();
</script>


Trenger du hjelp eller rådgivning angående migrering til det nye scriptet er det bare å kontakte oss

GA Asynchronous tracking – tilpasset skript på Metronet

Hvordan klarer AttentionWizard å etterligne hva brukerne ser på?

AttentionWizard bruker meget avanserte AI (kunstig intelligens) algoritmer for å simulere hva brukeren ser og legger vekt på på en nettside ved første øyekast. Dette inkluderer bl.a. musbevegelser og fargekontraster.

AttentionWizard sine resultater skal være opp mot (og over) 75% korrekt sett i forhold til å sette sammen en fokusgruppe og følge synlighet og mus peker bevegelser på nettsiden. Etter endel testing syns vi det virker som verktøyet fungerer veldig bra.

I dette blogginnlegget viser jeg hvordan heatmapen generert av AttentionWizard for VG og Metronet. (Hvis en webutvikler hos VG leser dette og sitter på et «ekte heatmap» for VGs fokusgruppe, hadde jeg satt pris på om du tok kontakt slik at vi kunne få sammenlignet resultatet).

Heatmap for VG

Som du ser av bildet under, legger brukeren først merke til annonsen til høyre midt på siden, før blikket beveger seg opp til pilleboksen i banneren vaksineguiden.no, og videre ned på artikkelbildet midt på siden osv. (Jeg har lagt på større tall og piler i bildet for synlighetens skyld)

VG.no med heatmap. De varmeste områdene viser hva brukeren legger mest vekt på.

Det er ganske interessant å se hva brukerne først legger merke til. Og det er ikke alltid den øverste banneren som koster skjorta. Har du noe som står i kontrast med resten av siden vil det lettere bli lagt merke til.
Hadde toppbanneren hatt mer kontrast ville heatmappen sett annerledes ut.

Heatmap for Metronet

Fra heatmappen under ser vi at brukeren først legger merke til bildet mellom de to menyene, så videre til søkefeltet og blogg knappen, deretter ned til menyen under bildet, og videre til logoen i venstre hjørne osv.

Metronet.no med heatmap. De varmeste områdene viser hva brukeren legger mest vekt på.

Vi ser her at vi vil ikke ha problemer med å utheve enkelte budskap grunnet at vi har holdt oss til spesifikke farger og nyanser.

Situasjoner det kan være et nyttig verktøy

• I designprosessen av en ny nettside.
• Se nøyere på problematiske sider som konverterer dårlig.
• Se på eksisterende sider som skal redesidnes.

AttentionWizzard er for øyeblikket bare ute for betatesting, men hvem som helst kan søke om å bli en betatester hvor du da får 1 heatmap per døgn.

Hva er det brukerne dine ser på? på Metronet

Et internsøk har noen fantastiske nytteverdier;

1. For brukeren av ditt nettsted kan det være en kort vei til det de leter etter. Spesielt på store nettsteder, er det ekstremt brukervennlig å ha et velfungerende internsøk.
2. For webansvarlig kan det gi en pekepinn på hva brukerne er interessert i. Dermed kan dette presenteres i større grad på forsiden. Et godt eksempel er nettbutikker. Søkes det ofte etter et produkt, så legg det på forsiden, kanskje til og med på salg?
3. For webansvarlig gir det også en pekepinn på hva brukeren ikke finner intuitivt på siden. Dette kan også derfor være nyttig informasjon hvis man velger å restrukturere innholdet på nettstedet.

Tilbake til det konkrete tipset.

Klikk deg inn på oversikten over Nettstedsøk. Du finner den i menyen til venstre, under Innhold >> Nettstedsøk >> Søkeord. I denne rapporten vil jeg at du skal gjøre to endringer fra standardvisningen du blir presentert for (begge deler markert med rødt i figuren under). Velg Resultatvisning og % Søkeutganger under Resultat For Individuelt Søkeord.

Internsøk, sammen med % søkeutganger

Dette er altså bounceraten til søkeordene brukt i internsøket. Hvor mange søkte i søkefeltet ditt, for så å forlate nettstedet. De fant altså ikke det de var ute etter. Er søkeordet noe du ikke leverer, er høy % Søkeutganger helt ok. Er søket noe du leverer, bør du miste litt av nattesøvnen. Quickfixen er enkel; inkluder innhold som inneholder søkeordet, evt. sjekk om sporing av internsøk er satt opp korrekt.

Now go on, do your magic!

Analyse av internsøket – Hva skal du bruke det til? på Metronet

Som en tommelfingerregel bør man unngå alle former for redirects. Nettopp fordi man bør lede brukerne til den siden de forsøker å besøke. Men noen ganger må man rett og slett redirecte. Man eier mange domener, man har lansert nye sider med ny URL-struktur, man har byttet firmanavn og dermed også nytt domenenavn etc. Listen er lang, og det handler om brukervennlighet. Ikke la dine besøkende komme til døde, ikke-eksisterende sider.

Men å bruke korrekte redirects er også viktig for din rangering i søkemotorene. Søkemotorene har et gitt antall sider fra ditt nettsted indeksert, med tilhørende URL-er. Hva skjer så om du endrer URL-ene dine? Dersom man ikke skal miste rangering og nåværende indeksering, må man benytte redirects. En nettleser vil oppdage slike koder, og automatisk sende besøket videre dit du «beordrer» det.

Redirects har vært en rimelig heftig diskusjon på nettet lenge. Spesielt gjelder dette områder som handler om rangering i søkemotorene (Google). For en ting er hvordan nettleseren tolker en redirect. En annen ting er hvordan Googlebot (Googles crawler) tolker den.

Som en oppsumering av dette blogginnlegget, tyder alt på at Googlebot liker en 301 redirect klart best. Det finnes mange forskjellige måter å gjennomføre en redirect på. Det er blant annet avhengig av hva slags server nettstedet ligger på og hva slags språk man programmerer nettstedet i.

Nedenfor finner du et forsøk på å forklare de forskjellige redirectene. Kom gjerne med innspill og eksempler på god/dårlig bruk av redirects.

300 Redirect – Gir deg flere valgmuligheter

Med en 300 redirect vil man kunne sette opp flere alternative veier man vil sende søkeren. Man kan altså «sortere» innkommende trafikk basert på forskjellige variable (eksempelvis språk), og redirecte besøket deretter. Man kan og presentere søkeren for en liste av alternative valg.

301 Redirect – En permanent flytting av innhold

En 301 redirect er den mest vanlige formen for videresending/viderekobling. Denne benyttes i de tilfeller hvor endringen er permanent, altså i alle tilfeller hvor du endrer på sidestrukturen eller endrer domenet ditt. Dersom man implementerer en 301 redirect korrekt (for eksempel ved bruk av en .htaccess fil) vil man også tilfredstille søkemotorene. Ved neste gjennomgang av nettstedet ditt vet crawlerne at ditt nettsted har nye URL-er.

Du vil altså, før søkemotorene har indeksert de nye sidene dine, unngå døde sider i søkemotorene, at innkommende lenker sender trafikk til sider som ikke eksisterer lenger og at direkte besøkende (fra bookmarks, referrals etc.) kommer til en 404-side. Etter en ny crawling av nettstedet, vil søkemotorene være oppdatert på dine nye URL-er. Man beholder verdien fra innkommende lenker, med denne metoden.

Vær oppmerksom på at det er en viss risiko med alle endringer, men at dette er den tryggeste og mest optimale måten å endre på sidene sine eller domenet, og samtidig beholde trafikk og rangering fra tidligere.

302 / 307 Redirect – En midlertidig flytting av innhold

En 302 (307 er mer eller mindre samme type) redirect skal benyttes når det er en midlertidig flytting, og når man ønsker at brukeren skal fortsette å bruke original URL. Denne brukes (dessverre litt for) ofte. Googlebot vil også fortsette å lete etter nytt innhold på den originale URL.

En redirect av denne typen har en svakhet. I motsetning til en 301 redirect får man ikke med seg verdien av domenet med på flyttelasset. Dvs. PageRanken til det opprinnelige domenet vil ikke føres videre til det nye domenet.

Det diskuteres i det vide og det brede om dette fortsatt stemmer, men gjør man en 301 er man i alle fall på den sikre siden. I prinsippet fungerer en 302 på mange måter som en 301, men Googlebot vil for eksempel fortsette å crawle gammelt domene for innhold med en slik løsning. Med en 301 redirect vil Google forstå at du har flyttet permanent, og slutte å crawle etter innhold på tidligere adresse.

303 Redirect – Når du vil unngå F5-fellen

Et eksempel der en 303 redirect kan være god, er ved utfylling av skjemaer on-line. Hvis et nettsted har et skjema som fylles ut, og man ender opp på en takk-for-utfyllingen side eller lignende, vil det ofte være en 302 redirect som ligger her. Problemet med dette, er at dersom siden blir refreshet (ved for eksempel at brukeren trykker på F5), vil man få innsendt enda et skjema. Dette unngås, om man benytter en 303 redirect.

305 Redirect – Ved bruk av Proxy server

En Proxy server er (i ekstremt kortversjon) et slags filter eller mellomledd mellom deg og den siden du vil besøke. Eksempelvis kan man for å få logge seg på intranettet til arbeidsplassen hjemmefra, benytte en proxy server. Dersom man har tillatelse til å nå nettstedet, benyttes en 305 redirect. Dersom man IKKE har tillatelse, vil man få opp en feilmelding, og evt. informasjon om hva som mangler for å nå frem.

Redirects – hvordan flytte nettsidene dine på Metronet