Hva avgjør prisen på et nettsideprosjekt?

Skrevet av

Pris er, og vil for de aller fleste prosjekter før eller siden være et tema. Og i den sammenheng tenker jeg det er mer naturlig å stille seg spørsmålet «hva avgjør eller påvirker prisen på et nettsideprosjekt?» heller enn «hva koster en nettside?». Derfor vil jeg kort fortelle litt om hva som kan avgjøre omfanget, og dermed påvirke prisen på et nettsideprosjekt.

Og jeg vil først si at det er helt naturlig at man både kan bli overrasket. Og reagere på prisen på et nettsideprosjekt hvis man ikke er vant til å jobbe med denne typen prosjekter. Og akkurat av den grunn pleier jeg å innlede alle samtaler med potensielle kunder med at de aller fleste prosjekter jeg jobber med starter på rundt 30.000.

Grunnlaget for alle prosjekter

Med utgangspunkt i at alle prosjekter er skreddersydd for kunden (og ikke omvendt). Medfører dette alltid jobb med en workshop, og wireframes i forkant av design og videre markup og implementering av løsningen. Derfor tilsier erfaringen at det alltid går med i underkant av en ukes jobb. Uansett type prosjekt. Hvorfor? For å ikke risikere å være så presset på tid/budsjett at hverken jeg eller kunden blir fornøyd med resultatet.

Så, hva påvirker omfanget og prisen på de prosjektene jeg jobber med?

Antallet forskjellige innholdspresentasjoner, ofte omtalt som maler

Hovedside, en liste- og detaljside for produkter, og rene tekstsider er eksempler på forskjellige innholdspresentasjoner eller maler. Alle disse krever merarbeid i forskjellige faser i prosjektet. Men er også svært hensiktsmessig for å få en konsekvent presentasjon av eksempelvis produkter.

Funksjonalitet for påmelding/bestilling eller andre former for innsamling av data

Påmeldinger eller mer eller mindre avanserte bestillingsskjema bidrar ofte til å øke et prosjekts omfang. Men på den andre siden kan gode forespørsels eller bestillingsskjema spare mottakeren for mye tid og mange e-post frem og tilbake for å avklare standardsspørsmål.

Butikkfunksjonalitet med eller uten betaling

Om man vil, eller ikke øker som regel nettbutikk omfanget i et prosjekt vesentlig. Uansett om det er få eller mange produkter, og betalingsløsning trenger å være en del av løsningen eller ikke.

Integrasjoner

Selv om man «bare» skal hente og sende noen ekle data til og fra et eksternt system. Tilsier alt av erfaring at dette medfører vesentlig merarbeid enn om løsningen bare legger til rette for at innholdet skal publiseres direkte i løsningen. Men naturligvis, her kan det være tid og penger å spare i hverdagen når nettsiden skal vedlikeholdes.

Øvrig bistand

Trenger dere en fotograf, bistand til å utarbeide og publisere innhold? I mange tilfeller vil dette være en god ide for ikke å legge unødvendig press på interne ressurser, og heve sluttresultatet.

Hva kan man gjøre for å redusere kostnaden?

Det vil alltid være mer eller mindre hensiktsmessige måter å redusere et totaltbudjett på. Som regel pleier anbefalingen å ende på å gjøre nettsideprosjektet i flere faser, med utgangspunkt i et «må ha» i første omgang. Og heller legge til ytterligere funksjonalitet senere når budsjettet tillater dette.

Ta gjerne kontakt for å diskutere et prosjekt.

Skal jeg ha en blogg eller nyheter på mitt nye nettsted?

Skrevet av

I utviklingen av et nytt nettsted har jeg mer en gang diskutert om en blogg eller nyheter skal være med på nettstedet. Utfallet av diskusjonen varierer, så det er ingen fasit. Men det er uansett viktig med en bevisstgjøring på de valgene som gjøres. Her oppsummerer jeg kort noe av det du bør tenke på før du tar stilling til om nettstedet ditt skal ha en blogg eller nyheter.

Klarer vi å vedlikeholde det?

Det er det enkleste og første spørsmålet du bør stille deg. Hvis det er urealistisk at noen i bedriften kan følge det opp på regelmessig basis. Burde det gi en føring for om det er noe dere burde satse på. Når nyeste blogg-innlegg eller nyheter er et par år gammel. Vil jeg så godt som alltid påstå at det er bedre at de ikke er der.

Hvor ofte skal jeg publisere?

Lag en realistisk plan. Flere har hevdet at en gang i mnd. bør være et minimum. Og egen erfaring tilsier at dette egentlig kan være mer en nok for en liten bedrift som hver uke har tidsfrister å overholde for kundene.

Den realistiske planen bør også innebære å sette av tid for å utarbeide innholdet, og potensielt mer tid i starten for å komme i gang med arbeidet..

Hvem skal bloggen eller nyhetene kommunisere til?

Jeg har alltid mye lettere for å la meg overbevise når hovedhensikten er tilføre verdi og kunnskap til kundene. Det finnes sikkert mange gode grunner til å vise seg frem for bransjekolleger. Men for meg som langt i fra er noen ekspert på hverken kommunikasjonsstrategi eller innhold. Er det et å ha mer fokus på kunden enn på seg selv et enkelt utgangspunkt som aldri blir feil.

Hvordan gjennomføre det i praksis?

Når dere har tatt beslutningen om at dette er en god ide, hvordan skal det da gjennomføres i praksis? Et enkelt tips er å sette av en fast interval i kalenderen som en påmindelse for den regelmessige publiseringen slik at det ikke går i glemmeboken. Sett gjerne et varsel noen dager i forveien slik at ideene kan surre litt i bakhodet.

Og lag deg en liste der du skriver opp alle ideene du har til nyheter eller blogginnlegg, og skriv kort opp nye ideer med en gang de dukker opp. Å skulle sette seg ned med «blanke ark» hver gang er neppe effektivt. Og er nok en mye større terskel enn å bare plukke et ferdig tema, og skrive det ut..

Og til slutt, et tips for de realistiske

For et stund tilbake hadde jeg den nevnte diskusjonen med en kunde. Og resultatet av dette, ble basert på deres selvinnsikt. At vi implementerte en løsning der nyheter på hovedsiden på nettstedet ble skjult når siste nyheter var mer enn et halvt år gammel.

Hvorfor velger jeg nesten alltid WordPress for mine kunder/prosjekter?

Skrevet av

Det finnes en jungel av forskjellige publiseringsløsninger og leverandører som kan hjelpe deg til målet med en nettside. De aller fleste komplette prosjekter jeg jobber med innebærer som regel en skreddersydd løsning i WordPress, og jeg skal her kort fortelle hvorfor.

Et godt utgangspunkt for fleksibel og brukervennlig publisering

WordPress er, og har en god stund vært den største platformen for nettsider på internett. Og selv om det alltid er mulig å være kritisk til enkelte egenskaper i en løsning. Er det naturlig å tenke seg at hovedårsaken til utbredelsen er at WordPress er enkelt, fleksibel og tilgjengelig løsning for veldig mange.

Og uavhengig av om man vil basere seg på et ferdig tema (som jeg ikke jobber med). Eller å skreddersy et eget tema. Er det uansett enkelt å komme i gang med en fleksibel løsning. Der brukerne raskt kan komme i gang med innholdspublisering.

Lett å skreddersy og utvikle ønsket funksjonalitet

Det finnes en utallige kilder og ressurser som bidrar til at det er relativt enkelt å lage. Og skreddersydd funksjonalitet i henhold til kundens behov. Det finnes også en rekke utvidelser som bidrar til å effektivisere utviklingen av nye løsninger. Der i blant Gravity FormsAdvanced Custom Fields og WooCommerce. Eksemplene bidrar med fleksible skjemaløsninger, skreddersøm av publisering og nettbutikk som enkelt kan videreutvikles eller utnyttes for å oppnå ønsket funksjonalitet.

Men når utvidelser er nevnt, mener jeg også at en viktig del av utviklingen av en WordPress-løsning er å vurdere om utvidelser er hensiktsmessig. Eller om litt mer skreddersøm er bedre, enn å bruke en utvidelse som ikke helt dekker kundens behov..

Kompetanse

Jeg har i større og mindre grad jobbet med WordPress de siste 8 årene. Noe som medfører at jeg godt kjenner til løsninger, muligheter og ikke minst begrensninger som medfører at det vil være naturlig å vurder andre løsninger vil være et bedre valg. Og det er neppe noen stor overraskelse at man jobber mest effektivt og hensiktsmessig med det man kan best.

Ikke alltid beste løsning..

Jeg skal ikke påstå at WordPress alltid er den perfekte løsningen for prosjektet. Og jeg er heller ikke redd for å innrømme det, og heller råde kunder til å velge andre løsninger. Noen ganger vil man konkludere med at WordPress kanskje ble den beste løsningen innenfor budsjettet. Og andre ganger igjen vurdere om man kan samarbeide om et prosjekt på struktur, design og ferdig markup som andre implementerer. Eller rett og slett et prosjekt som det ikke er relevant å involvere seg i.

WordPress-oppgraderinger

Hvorfor, og ikke minst hvordan oppgradere WordPress?

Skrevet av

Mange brukere av WordPress har på et tidspunkt logget seg inn for å oppdatere nettsiden, og fått beskjed om at det er oppgraderinger tilgjengelig. Flere av Blåis sine kunder har tegnet en avtale for å slippe å tenke på oppdateringer og sikkerhet. Men flertallet velger selv å vedlikeholde (eller ikke vedlikeholde) sin WordPress-løsning. Det er derfor naturlig å kort forklare hvorfor, og hvordan man bør gjøre oppgraderinger av WordPress og tilhørende utvidelser.

Hvorfor oppgradere?

Det er flere ting å oppnå ved å oppgradere WordPress. Men sikkerhet er og blir hovedargumentet. Hver gang du oppgraderer gjør du det vanskeligere for andre å ta kontrollen eller hacke nettsiden din. Men oppgraderinger gir deg også bedre ytelse samt ny og bedre funksjonalitet.

Dropper du over tid å oppgradere din WordPress-versjon vil kjente sikkerhetsfeil ligge åpne og klare for personer med uærlige hensikter.

Hvordan oppgraderer jeg WordPress selv?

Når du logger deg inn i WordPress blir du veiledet gjennom oppgraderingsprosessen, men hva gjør du i forkant og etterkant av oppgraderingen for å sikre deg mot uønskede hendelser. Her er en steg for steg guide til oppgradering:

  1. Ta en full backup av alle filer og database. Et verktøy som eksempelvis BackupBuddy kan settes opp til å ta en backup av hele nettstedet ditt, og legge de i en Dropbox-mappe eller på Google Drive som en zip-fil. Eller lage en zip-fil som du kan laste ned uten behov for å logge deg inn via FTP eller databaseverktøy.
  2. Gjør oppgraderingene i WordPress og tilhørende utvidelser.
  3. Gjør en manuell gjennomgang av nettstedet og sjekk at siden vises som de skal.
  4. Gjør en manuell test av påmeldingsskjema, bestillingsskjema, nettbutikk og tilsvarende funksjonalitet for å sikre at alt fungerer som det skal etter oppgradering.

Normalt fungerer disse oppgraderingene uten problemer. Men, skulle det dukke opp problemer kan det være fornuftig å starte med denne artikkelen, eller ta kontakt for å få hjelp til å løse utfordringene.

Vil du slippe å tenke på alt dette?

Da kan løsningen være å tegne en oppgraderingsavtale for nettsiden din. Da blir stegene nevnt over gjort regelmessig, og kjente sikkerhetsfeil blir raskt rettet. Oppgraderingsavtalen innebærer også jevnlig gjennomgang og forbedring av sikkerheten for nettstedet ditt. Ta gjerne kontakt for å diskutere en oppgraderingsavtale for ditt nettsted.

WordPress tema

Hvorfor jeg ikke jobber med et ferdig tema/«theme» til WordPress

Skrevet av

Når man jobber med løsninger basert på WordPress dukker det fra tid til annen opp forespørsler om hjelp og endringer på tema/«theme» til WordPress, som er lastet ned gratis eller kjøpt. At slike forespørsler dukker opp er langt i fra overraskende. Det er relativt lett å finne bedrifter som satser på akkurat denne tilnærmingen for sine prosjekter og kunder.

Og, det er helt greit. Men ikke slik jeg jobber, og jeg forklarer her kort hvorfor:

Fokuset på kundens behov, fremfor temaets muligheter

Jeg mener at en hver nettsideprosess må starte med å kartlegge kundens behov. For å ta utgangspunkt i de behov og utfordringer som skal løses med nettsiden. Ved å basere nettsiden på en «ferdig» løsning må man i mye større grad finne ut hvordan kundens behov kan tilpasses de muligheter som ligger i tema. Å forklare hvorfor det som regel ikke er en hensiktsmessig tilnærming er neppe nødvendig.

Utfordring med vedlikehold over tid

Selv om det finnes dyktige og dedikerte utviklere som fikser feil, videreutvikler og vedlikeholder de «ferdige» temaene til WordPress. Har jeg like vell sett at enkelte har utfordringer med vedlikehold og oppgraderinger over tid.

For mange muligheter?

Mange av de aktuelle temaene har også funksjonalitet som sidebyggere/«page builders». Noe som tidvis gir nesten ubegrenset med muligheter. Dette kan gi en uoversiktlig publiseringsprosess for de som skal vedlikeholde nettstedet, og kan medføre lite konsekvent publisering av innhold.

Ytelse..

Det finnes nok også dessverre noen eksempler på at ytelsen på nettstedet langt i fra er optimal. Rett og slett fordi de ubegrensede mulighetene noen ganger medfører tung og litt for omfattende kode. Om dette er tilfelle eller ikke for det aktuelle temaet man velger er naturligvis veldig vanskelig å ta stilling til for de fleste før det er kjøpt, og tatt i bruk.

Men, det kan være en god løsning..

Men, tross alt dette som helt klart havner i kategorien mindre positivt: Jeg ser absolutt at de har sin funksjon, og ikke minst er et effektivt verktøy for å få opp en nettside på et begrenset budsjett, på kort tid. Og det kan gi brukere med litt teknisk innsikt en rekke muligheter de bare kunne drømme om i andre verktøy.

Men, jeg velger altså en annen tilnærming. Fordi jeg mener det gir det beste resultatet for mine kunder.

Hvorfor bruke wireframes i prosessen med din nye nettside?

Skrevet av

I prosessen frem mot en ny nettside står alltid wireframes (sporadisk omtalt som trådskisser på norsk) sentralt i arbeidet. Og her er forklaringen på hvorfor.

Først, hva er wireframes?

Enkelt forklart er en wireframe den strukturelle oppbygningen av nettsiden med alle elementer, uten design. Wireframes utarbeides alltid i oppstart av prosjektet. Og bidrar til å synliggjøre kartlagt informasjonsstruktur, navigasjon og innhold. Noen ganger forklares også wireframes enkelt og greit som nettsidens oppbygning med «grå bokser».

Så, hvorfor?

  1. Et effektivt verktøy for å kommunisere brukeropplevelser. Spesielt for å syliggjøre elementers oppførsel på forskjellige skjermflater som mobiltelefon, tablet og større skjermer.
  2. Danne et grunnlag for elementer som designes, og muliggjør å utarbeide en designskisse i form av en stilskisse. Denne stilskissen kan videre påføres for alle maler uten at det er nøvdendig å utarbeide detajskisser for alle innholdspresentasjoner.
  3. Gjøre det enklere å holde prosjektet innenfor budsjett og tidsfrister når innholdselementene som skal designes og implementeres er kartlagt før dette arbeidet starter.
  4. Gjøre prosessen med tilbakemeldinger på design mer effektiv og konkret, siden elementers plassering og oppførsel er kartlagt tidligere i prosessen.
  5. Muliggjør brukertesting tidlig i prosessen.

Kort oppsummert, det danner grunnlag for en bedre og mer effektiv prosess, og reduserer uklarheter. Og ved å lage wireframes som responsive prototyper blir brukeropplevelsen for forskjellige skjermstørrelser enkelt synliggjort tidlig i prosessen. Og feil eller mangler kan lukes bort før design og utviklingsarbeidet starter.

Papir og tusj

På mindre detaljer, videreutvikling og som verktøy under en workshop kan wireframes med papir og tusj være en svært god og effektivt verktøy. Både for å kartlegge elementer som skal wireframes. Og noen ganger for raskt å løse konkrete utfordringer som kan implementeres direkte. Det er også et verktøy de aller fleste kan ta i bruk, og muliggjør at kunder kan formidle sine meninger og tanker.

Veien til et nytt nettsted

Skrevet av

Det kan være mange veier til ferdig lansert nettside. Blåis jobber ut i fra et utgangspunkt at løsningene skal være tilpasset kunden (og ikke omvendt). Med dette som utgangspunkt må prosjektet gjennom en del steg som det er viktig at du som kunde kjenner til, og prioriterer tid til.

Tilbud/Budsjett

Alle prosjekter starter med en gjennomgang av krav, ønsker og behov som må dekkes av løsningen. Som regel ender det opp i en liste over innholdspresentasjoner og funksjonalitet, kort beskrevet i et tilbud. Alternativt som et budsjett og en prioritert liste med funksjonalitet. Begge deler med utgangspunkt i en tilbudsaksept og en kontrakt slik at formalitetene er på plass før arbeidet starter.

Workshop

Prosjekter starter alltid med en workshop. Workshopen har som hovedmål å kartlegge og strukturere innhold, definere mål, og avklare prosjektets rammer og fremdrift. Naturligvis med utgangspunkt i overnevnte tilbud eller prioriteringsliste.

Wireframes

Med utgangspunkt i workshopen utarbeides det wireframes for å sikre at alle innholdselementer er kartlagt og prioritert. Wireframes synliggjør også elementers oppførsel på forskjellige skjermstørrelser.

Design

Normalt utarbeides det et designforslag for en eller flere av de sentrale sidene på nettstedet for en eller flere skjermflater, eksempelvis hovedside og produktpresentasjon. Designforslaget har som hensikt å presentere nettsidens stil og uttrykk, og ikke å kartlegge alle innholdselementer til minste detalj.

Markup/Frontend (HTML/CSS m.m.)

Når designutkastet er godkjent blir stilutrykket tilført alle maler når det kodes markup. Markup testes og optimaliseres for alle skjermflater.

Implementering i WordPress

Ferdig markup implementeres i WordPress. WordPress tilpasses kundes behov, og forskjellige innholdspresentasjoner skreddersys for enkel og fleksibel publisering i hvert enkelt prosjekt.

Opplæring og gjennomgang av løsningen

Det blir gitt opplæring i bruk av nettsiden, og gjennomgang av alle detaljene i løsningen. Videre hjelp blir også gitt underveis i publiseringsarbeidet ved behov.

Publisering av innhold

Kunden arbeider med publisering av innholdet på nettsiden, gjør man det for første gang kan man bli overrasket over hvor mye jobb innhold er.

Feilretting

Dukker det opp feil eller mangler rettes disse fortløpende når feilene meldes inn. For fastprisprosjekter er feilrettingen inkludert så sant de meldes inn innen 2 mnd. etter prosjektets ferdigstillelse.

Lansering

Lansering gjøres når kunden anser nettsiden som klar.

Support, oppgradering og videreutvikling

Når prosjektet er ferdig kan du avtale videre support, oppgradering eller videreutvikling ved behov. Eller du kan gjøre alt selv, eller sammen med andre. Det skal uansett være ditt valg hva du ønsker!

Full frihet over egen løsning, hvis du ønsker det!

Skrevet av

Hvem eier rettighetene, og får jeg full tilgang til den ferdige løsningen? Mitt svar er alltid at den ferdige nettsiden er din, og du får full tilgang og frihet til å endre alt du selv måtte ønske – hvis du ønsker det.

Burde det ikke være en selvfølge? Responsen fra enkelte kunder tilsier at deres erfaring er noe annet.

Utgangspunktet for dette er ganske enkelt: Når du gjennomfører et nettsideprosjekt bør full frihet, og kontroll over egne løsninger være en forutsetning. Ikke fordi du nødvendigvis skal ha mulighet til å endre utseende eller «fikse litt» på koden til nettstedet ditt. Men fordi det gir deg mulighet til å videreutvikle og samarbeide med andre, hvis du ønsker det. Og fordi det å «låse fast» kunden til til en leverandør og/eller løsning normalt bare en fordel for den som selger løsningen. Burde ikke også tilbakevendende kunder være noe man gjør seg fortjent til?

Men det handler også om din sikkerhet. Hva gjør du hvis du i en lengre eller kortere periode risikerer å ikke kunne få den hjelpen du trenger.

Hva gjør Blåis for å sikre deg som kunde full frihet over din løsning?

  • Kunden har selv alle avtaler med webhotell/domener m.m. direkte med anbefalte (eller selvvalgte) leverandører.
  • Markup basert på Foundation og publisering basert på WordPress (+ Advanced Custom Fields, Gravity Forms m.f.). Løsninger som andre raskt kan sette seg inn i, og videreutvikle.
  • Full tilgang til alle markupfiler, designfiler og øvrige originaler det skulle være interessant å få tilgang til.

Samtidig får også kunder som ønsker tett oppfølgning, jevnlig oppgradering av sine WordPress-sider og supportavtaler dette. Men viktigst av alt, det skal være ditt valg!

Nordenskioldbreen på Svaldbard