Hva er en falsk dør og hvordan fungerer det?

Vi skal se hvordan vi kan bruke en landingsside for å validere markedsinteresse før vi bygger en førsteversjon av produktet. En slags pre-MVP. En premvepe.

Dette kalles en fake door test, eller en falsk dør. Det er rett og slett en nettside som gir uttrykk for at et produkt er tilgjengelig uten at det egentlig er det. Etter landingssiden er ferdig sprer vi den i relevante kanaler. Det kan være Google AdWords eller forum der du forventer å finne kundene dine. Det trenger ikke koste penger. Deretter måler vi hvor mange av de besøkende på siden som prøver å kjøpe, laste ned eller interagere med produktet. Dette gir oss et bilde av den reelle markedsinteressen.

Større bedrifter er ofte redd for å skade merkevaren sin gjennom tester som dette, og kan i så fall bare kjøpe et relevant domenenavn og teste under en ikke-eksisterende merkevare.

Ukjente startups kan lage falske dører i sitt eget navn med lav risiko.

Innholdet på nettsiden varierer, men er ment for å etterligne en vanlig landingsside med innsalg og beskrivelse av produktet. Noen viser pris, andre ikke. Tenk etter hvilken del av produktet du mener skal være avgjørende for kunden og legg fokuset der. Siden må også ha en knapp eller annen call to action (CTA) som gir besøkende på nettsiden inntrykket av at de foretar seg en handling. Dette er typisk "kjøp", "registrer" eller "last ned".

Det er opp til hver enkelt om man vil dra prosessen lenger og se om besøkende for eksempel er villig til å legge igjen kortinformasjon eller epostadresse. Desto mer virkelighetsnært, desto mer reell blir dataen i den andre enden.

Falske dører har også andre bruksområder enn salg. Vi kan også lage falske dører til "nye funksjoner" i eksisterende digitale produkter. Da kan vi spørre besøkende hva de forventet å finne bak døren, og på den måten hente nyttige bidrag til produktutviklingen.

Så hvordan bygger man en falsk dør i praksis?

For en utvikler bør en falsk dør oppfylle tre krav. Den skal være rask å sette opp, gjøre det godt på søkemotorer og generere data vi kan bruke til å ta gode beslutninger.

For å gjøre det enklere å sette opp en slik test, har vi laget en mal som kan tilpasses de fleste produktidéer for en rask markedstest.

Denne kan settes opp på under én time, og du finner den på vår Github.

Selv brukte vi totalt to dager fra konsept til siden var responsiv og klar. Målet er ikke å gjøre alt perfekt, men å gjøre veien til resultater så kort som mulig.

Fra dette punktet og ut, vil artikkelen ta for seg beslutningene som dannet det tekniske grunnlaget for løsningen vår. Forhåpentligvis bidrar denne artikkelen til at flere kan engasjere seg i hvordan teknologiene vi velger påvirker brukeropplevelsene våre. Det tekniske puslespillet består hovedsakelig av tre brikker:

1. Et system for å håndtere innholdet på siden.
2. En måte å sørge for at siden gjør det godt i forskjellige søkemotorer.
3. En måte å håndtere data slik at vi kan lære av testen.

Kristoffer klarer seg ikke uten Sanity

torsdag 11. juni 2020

Sanity – Håndtere innhold på siden

Sanity er første brikke i dette puslespillet. Det er et system hvor innhold som tekst og bilder kan endres i et brukervennlig brukergrensesnitt.

Når vi jobber med kunder, er dette en utmerket måte å la dem endre og legge til tekst selv.

For deg og meg, er det fortsatt behagelig å endre teksten i Sanity fremfor direkte i koden.

Gatsby, React, Server side rendering og static site generators

For at nettsiden din skal komme høyt i søkeresultatene må søkemotorer som Google klare å lese og "forstå" hvordan nettsiden er satt sammen.

Populære rammeverk som React, Vue og Angular bidrar til å gjøre det enklere å programmere komplekse web-sider, men gjør det samtidig vanskelig for søkemotorene å lese.

Dette finnes det to løsninger på: Server Side Rendering og Static Site Generators. Vi bruker Next.js som eksempel på SSR, Gatsby til Static Site Seneration og React som javascript-rammeverket.

Om du er nysgjerrig på forskjellene på klientside, serverside og statisk genererte sider forklarer jeg det kjapt under. 👇

Rendring på klientsiden

"Det står en matbod på torget som selger burritos. Dagens løsning fungerer slik at alle kunder får ingrediensene (data fra Sanity i vårt tilfelle) lempet i fanget og en oppskrift for hvordan de setter dem sammen (React). Dette er mer tidkrevende for kunden, men mange setter pris på den interaktive opplevelsen. Michelin-guiden (søkemotorene) derimot forventer høyere service og vil ikke tilberede maten selv. Derfor blir matboden utelatt når guiden oppdateres."

Dette er nytt i Node, Storybook og React

tirsdag 18. august 2020

I eksempelet over ser vi hvordan rendring på klientsiden skaper problemer for søkemotorer. Det betyr derimot ikke at dette er dårlig, fordi det lar utviklere bygge mer kompliserte og interaktive applikasjoner.

I stedet for å ha en HTML-fil for hver underside, vil nettsiden stappe nytt innhold i den ene HTML-skall-filen fortløpende rett i nettleseren.

Brukere vil dermed ikke oppleve at hele nettsiden laster, men heller at noen deler av siden bytter ut innhold. Se for eksempel på facebook.com hvor navigasjonsbaren og chat blir værende når man navigerer mellom sider.

Det er altså to utfordringer med denne måte å bygge nettsider på:

1. Siden nettleseren kun mottar byggeklossene og en oppskrift (Javascript-modulene), blir brukere nødt til å vente. Da blir de gjerne presentert med en hvit skjerm, skeleton screens, eller en loading-skjerm.
2. Når du bruker React og lignende rammeverk hvor all HTML-en genereres av javascript på maskinen til brukeren (client-side), er alt som sendes fra serveren, en helt tom HTML-fil. Denne HTML-filen mangler nøkkelord, beskrivelse, og metadata nødvendig for at søkemotorer skal kunne lese den.

Server-side rendering (SSR) med Next.js

"Det står en matbod på torget i byen som selger burritos. I matboden jobber én superkjapp kokk. Når en kunde bestiller en burrito, tar kokken lefsen (React) og fyller den med tomat, agurk og kjøtt (data fra Sanity), og gir den til kunden (HTML-fil sendes)."

Server side rendering vil si at serveren setter sammen nettsiden før den sendes til nettleseren din. Dette gjør serveren ved å ta frem oppskriften og lage en burrito ved forespørsel. På utvikler-lingo sier man at serveren genererer HTML-filer fra Javascript og et API i respons til en http-forespørsel. I vårt tilfelle har vi en side skrevet i React og bruker Sanity som API.

Når noen går inn på for eksempel hjemmesiden (en http-forespørsel), henter serveren (Next) data fra API-et (Sanity), syr det sammen med Javascript-filen (React) og genererer en HTML-fil som sendes tilbake til brukeren. Denne prosessen løser to problemer:

Når denne HTML-genereringen skjer på serveren, går det kjappere for brukeren å laste inn siden, og søkemotorer klarer å indeksere siden fordi de får tilsendt en side med alt innhold.

Utfordringen med SSR er at det må settes opp en egen server som håndterer all denne genereringen. Da er det viktig å ha folk som sørger for at den alltid er oppe, og at den kan håndtere plutselige trafikkøkninger.

Bruk Wordpress som headless CMS, med Kurts Gatsby-løsning

mandag 3. august 2020

Static site generators

"Før dagen begynner lager et sentralt kjøkken alle de ulike burritoene på menyen og kjører dem til burrito-boder fordelt gjennom hele byen (CDN-nettverk). Når en kunde vil ha en burrito går de til nærmeste bod og mottar en ferdigprodusert burrito med en gang."

I motsetning til Server Side Rendering, genererer en Static Site Generator alle HTML-sidene på forhånd. Om det er en nettside med; hjem, kontakt oss og 20 artikler, genereres alle før siden går live på nettet.

Når en bruker går inn på for eksempel umble.no/blogg/vi-lar-oss-bedra-i-mote-med-markedet, har den allerede blitt generert og en helt vanlig webserver sender denne uten å måtte sy sammen javascript og API-kall til HTML. Dette har flere fordeler:

• Det er ikke nødvendig å administrere servere eller opprette sikkerhetskopier.
• Det er sikrere, fordi statiske filer er read-only. Det er ingen kode som kjøres, og derfor ingen smutthull som kan utnyttes. Dermed kan du overlate sikkerheten til proffene som leverer verktøyene vi bruker. Sjekk derimot i forkant at du benytter gode aktører!
• I motsetning til SSR hvor det er én server ett sted i verden, kan denne publiseres på et CDN (Content Delivery Network) hvor det er mange servere fordelt i alle verdens hjørner. Hver gang noen går inn på siden, er det nærmeste server som tar i mot forespørselen og sender nettsiden tilbake. Dette gjør at alle i hele verden vil få en kjapp opplevelse av nettsiden din, ikke bare de som bor i nærheten av den ene serveren.

I likhet med Server Side Rendering, løser ikke Static Site Generators alle utfordringer uten problemer.

Den største utfordringen er at byggetiden øker med antall sider du har på nettstedet.

Er det en stor nettside med 1000 sider, og du vil opprette en til, vil neste publisering bygge 1001 sider. Dette kan bety 20 min for hver oppdatering av innhold. Er dere mange som publiserer vil det ende med en evig loop av bygging (én løsning på problemet er incremental builds).

I vårt tilfelle med tre sider, er Static Site Generation med Gatsby midt i blinken.

En ny build tar ikke lang tid, ingen server må vedlikeholdes og vi får med de to hovedfordelene som både Server-side rendering og Static site generators har: raskere lasting av siden hos brukeren og søkemotorer klarer å lese siden.

Slik får hun mens-appen POW! helt anonym

torsdag 12. mars 2020

Plausible

Ok, det var litt teknisk, men nå har du forhåpentligvis en litt bedre forståelse for hvorfor vi bruker Gatsby. Likevel må vi ikke glemme at målet med siden er å validere om folk ønsker å bruke eller kjøpe produktet.

For å finne ut av det trenger vi data, og derfor et analytics-verktøy.

Ryggmargsrefleksen hadde vært å bruke Google Analytics, men vi trenger ikke alle funksjonene Google Analytics har å by på.

Vi trenger nettsidetrafikk og hvor mange som registrerer seg. Vi valgte heller å gå for Plausible. De leverer et enkelt produkt som har ryddet bort mye støy uten å gå på bekostning av målet vårt. Dette gir oss et enkelt dashbord vi kan måle suksessen med.

En annen enorm fordel ved å bruke Plausible, er at de ikke samler inn persondata og prioriterer personvern.

Med GDPR, CCPA , LGPD og PECR kreves det at man har cookie-varsler og personvernerklæring som forteller hva du bruker persondataen til. Dette må du ha med Google Analytics, men ikke med Plausible, siden de ikke bruker cookies (kan være greit å diskutere med en advokat 🔎📜).

Det betyr at vi kan lage en nettside uten distraherende pop-ups, samtidig som vi kan klappe oss på skulderen for å være bra mennesker.

Mange AdBlockers forhindrer dessuten Google Analytics i å samle bruksdata, noe som resulterer i at vi får feilaktige resultater på testene våre. Dersom du henvender deg til et segment der bruk av AdBlockers er utbredt kan dette ha stor påvirkning.

DigitalOcean, AWS og Azure - hostingen vi velger i 2020

fredag 31. juli 2020

Netlify

Alle brikkene i puslespillet jobber sammen.

Sanity tar seg av innholdet til siden, Gatsby setter den sammen og Plausible måler aktivitet.

Den siste brikken er å dele nettsiden med verden.

Dette gjør vi med Netlify. HTML-en blir generert fra Gatsby, og denne genereringen skjer på serverne til Netlify.

Når genereringen er ferdig, lastes HTML-filene opp til Netlifys CDN-servere fordelt over hele verden, og nettsiden er nå live på internett.

Om det er besøkende fra Tyskland eller USA spiller ingen rolle på hastigheten, fordi hver bruker vil få nettsiden levert av serveren nærmest dem.

Fra nå av, vil alle kode-oppdateringer i Gatsby eller innholdsoppdateringer i Sanity bli dyttet ut på nettsiden, uten at du trenger å styre med servere. Denne arbeidsflyten har spart oss for mye tid og frustrasjon.

I denne artikkelen har jeg forsøkt å vise hvordan man kan begynne å forstå om markedet er interessert i produktet eller tjenesten din.

Det finnes utallig flere metoder for å validere idéer, dette var kun én av dem.

Neste steg blir å bygge videre på den innsikten denne landingssiden har gitt dere. Alt handler om å bygge billige tester tidlig i prosessen, hvor risikoen for at produktet eller tjenesten feiler er høy. Etter hvert som man lærer mer og mer, vil risikoen for at produktet feiler bli mindre. Først da kan man med berettiget selvtillit bruke mer tid og penger på å utvikle et mer funksjonsrikt produkt.

Templaten kan du se i disse to eksemplene:

Denne er tilpasset kun gjennom Sanity: https://landingpage.umble.no/

Denne har vi kodet mer på for å tilpasse knappene og designet : https://landingpage2.umble.no/

Koden ligger her: https://github.com/Umble-tech/dummy-landing-page

Hvordan lage en nett­butikk i 2020?

- Har ekstremt god erfaring med Shopify! sier én. - For låst! sier en annen. 🤷

fredag 4. september 2020