indexed, skribent på Indexed.dk

4 tips til at vælge det helt rigtige domæne første gang

Det kan være en jungle at vælge et nyt domæne – her kommer 4 gode råd til at komme igang

Når man skal lave sin egen hjemmeside, så er et af de første, og måske også vigtigste beslutning, at vælge det rigtige domæne.

Et domæne er noget, der er meget svært at skifte senere hen af grunde, som vi kommer ind på senere i artiklen, og derfor er det vigtigt, at man vælger det rigtige domæne første gang, så man ikke skal hen og skifte senere.

I denne artikel får du derfor 4 tips til at vælge det helt rigtige domæne første gang!

Hvorfor er det svært at skifte domæne?

Der er fundamentalt tre grunde til, at det er svært at skifte domæne

Din SEO-værdi

Den værdi og de placeringer du ”optjener” i Googles søgeindeks, er bundet op på dit domæne. Hvis du skifter dit domæne risikerer du at miste meget af denne værdi. Lå du f.eks. nr. 1 på ”køb lejlighed i Aarhus”, vil du sandsynligvis miste denne placering, hvis skifter domæne og flytter dit indhold til et nyt domæne. Man kan redde en del af ens seo-værdi ved at lave redirects af ens gamle sider til det nye domæne, men det kan sjældent redde det hele 100%.

Dit brand

Hvis du har haft det samme domæne i mange år, så vil folk huske dig og associere dig med dette domæne. Heldigvis kan du lave redirects, så når folk taster dit gamle domæne ind i browseren, så føres de til dit nye domæne. Det tager dog ofte lidt tid for folk at huske dit nye ”navn”, og har du markedsføringsmateriale på print og online, så skal du også huske at få dette ændret og opdateret.

Flytning af hjemmeside

Hvis du skifter domæne, så skal du også flytte din hjemmeside til dette nye domæne. Det er som sådan ikke svært, men er du ikke teknisk anlagt, vil du få brug for hjælp. Hjælp koster penge, og derfor vil der også være en betydelig udgift til selve flytningen af hjemmesiden.

Lad os se på de tips, som kan hjælpe dig ved at undgå et eventuelt domæneskift.

Tip 1 – Vælg et domæne der ikke låser dig til et bestemt emne

Når du vælger dit domæne, skal du tænke fremad. Hvad skal din side indeholde nu og i fremtiden? Det er her vigtigt, at du ikke vælger et domæne, som er for specifikt til det du vil med din side lige nu. Vil du f.eks. sælge sokker, så skal du ikke kalde den sokkeshoppen.dk, da du på den måde låser dig til sokker.

Tænk hvis du om et par år også vil sælge underbukser. Ja så er sokkeshoppen.dk et rigtig dårligt navn, da det indikerer, at her sælges der altså sokker og ikke andet.

Vælg derfor et domæne, som ikke låser dig til et bestemt emne eller produkt, hvis du ved, at der potentielt vil komme andet på domænet i fremtiden.

Tip 2 – Vælg noget der er kort og catchy

Brand- og domænenavne, som er nemme at huske, er ofte korte og catchy, typisk kun to stavelser. F.eks.:

  • Volvo
  • ebay
  • Google
  • Fiat
  • Nestle

Ja man kunne blive ved.

Hvis du kan finde et super domæne, på kun to stavelser, så vil det være rigtig godt, da det er nemt for folk at huske og indtaste i browseren, når de skal gå direkte til din side.

Tip 3 – Undgå æ ø og å

Internettet har det rigtig dårligt med de danske bogstaver æ, ø og å. Derfor skal du ikke vælge et domæne, der indeholder disse bogstaver, da det vil give dig problemer i forhold til SEO og teknikken på din hjemmeside senere hen. Du kan til nøds bytte f.eks æ ud med ae eller å ud med aa, men det anbefales ikke.

Tip 4 – Vælg et passende TLD

Et TLD (Top Level Domain) er endelsen på dit domæne. Hvis du har en dansk hjemmeside, som udelukkende er henvendt danskere, så giver det mest mening at vælge ”.dk”. Er din side engelsksproget og henvendt til folk i udlandet, så giver det måske bedst mening at vælge et ”.com” domæne.

Undlad desuden at vælge et dansk domænenavn og et udenlandsk TLD. Hjemmeskobutikken.com lyder f.eks. helt underligt. Her vil hjemmeskobutikken.dk være bedre.

Når du har fundet et domæne, som du synes passer til det du vil have på din side nu og i fremtiden, skal du ind og tjekke, om det overhoved er ledigt. Det kan du f.eks. gøre med søgeren fra Billig-Webhosting.dk, hvor du kan finde og købe domænet hos den billigste udbyder.

Er domænet ikke ledigt, må du tilbage til tegnebrættet, og se om du kan finde på noget andet, der også lever op til de 4 tips beskrevet i denne artikel.

4 nemme hastigheds tip til hjemmesider

De her emner er dem som vi typisk berører når vi skal ind og vedligeholde en eksisterende hjemmeside. Problemet er som regel at siden ikke kører super hurtigt og vi skal gøre noget ved dette uden at investere en større mængde af timer.

1. Optimering af billedestørrelse og opløsning

Nok den største og mest oversete faktor når det kommer til hastighedsoptimering. En klassisk fejl er at tage et billede på sin smartphone og lægge det direkte op på hjemmesiden. Sådan et billede fylder måske et par megabyte og har en opløsning der er langt højere end selv de største skærme på markedet.

En hjemmeside kan typiske have følgende fordeling af data:

  1. HTML dokument: 50kb
  2. CSS: 100kb
  3. JS: 200kb
  4. Billeder: 500kb-10MB

Ligger der 10MB billeder på siden er html+css+js delen på 350kb derfor uvæsentlig og kan vi få halveret datastørrelsen på billeder er vi nede på 5MB hvilket stadig er en del men dog en forbedring.

Manglende cache er den næststørste faktor når det kommer til hastighed 

Det vi gør er derfor følgende: 

  1. Reducering af opløsning – typisk er max 1200px i bredden fint for billede galleri på desktop og f.eks. 400x px i bredden fint for mobil
  2. Reducering af fil størrelsen. Benyt jpg da dette format fylder mindst og er mest udbredt og her kan vi komme ned på 100-400kb per billede og langt mindre for thumbnails.

Hvordan dette gøres bedst afhænger af dit system og opsætning. På wordpress f.eks. kan man installere smush pro og ønsker du at gøre det manuelt kan du prøve kraken hvor du nemt kan uploade dine billeder og får en zip fil tilbage med de komprimerede.

2. Aktivering af cache på statiske filer

Manglende cache er den næststørste faktor når det kommer til hastighed. Cache af html betyder at den ikke skal genereres ved hvert request men istedet kan der serveres en cached version. Når serveren generere en ny version skal koden eksekveres, databasen kaldes for data og html bygges. Dette går som sådan hurtigt nok men tager det alligevel 500ms så er det lang tid iforhold til en cached version som tager 50ms. Altså en faktor 10x besparelse. Derudover sparer man serveren for en hel masse resourser hviklet får det hele til at kører lidt hurtigere. 

3. CDN til resourse filer

Dette trick er mest velegnet til sider med meget trafik eller til sider som er meget tunge i forhold til statiske filer. CDN står for Content Delivery Network som er eksterne servere placeret over hele verden som hjælper med at levere dine billede filer frem til slutbrugeren. Disse filer kopieres over på deres netværk så de vil reelt kun blive hentet fra din server een gang og herefter kun fra CDN netværket.

Dette sparer rigtig meget båndbredde på serveren og den kan bruge sine resource på andre ting istedet. Derudover kan et CDN netværk være med til at leverere filer fra servere der er tættere på brugeren. Dvs. at en bruger fra Tyskland vil få billedet fra en tysk server og ikke fra f.eks. en amerikansk server.

4. Optimering af databasen

Frontend på hjemmesiden er optimeret men uanset hvor heftig cache der er på og hvor lidt det hele fylder så duer det ikke hvis serveren skal bruge adskillige sekunder på at leverer et HTML dokument til slutbrugeren. Nulstilles cachen så vil serveren blive bragt i knæ fordi den skal genopbygge det hele, det vil gøre setup skrøbeligt. Koden og databasen skal derfor fungere optimalt sammen.

Da omkodening er ret omkostningstung, risikofyldt og som regel slet ikke nødvendigt, så kigger vi på databasen istedet. I relationsdatabaser som MySQL har vi noget der hedder index. Det svarer kort fortalt, til et index i en telefonbog med angivelse af A, B, C osv. Ofte så mangler disse i en database da det er et område mange udviklere slet ikke har fokus på. Et tjek af databasen og angivelser af disse index kan få et meget langsom side til at køre hurtigt igen.

Afslutning

Listen er ikke udtømmende, langt fra, men det er de punkter vi altid selv starte med at tjekke når vi hastighedsoptimere hjemmesider uanset om det er wordpress, prestashop, drupal og andre. Principper fungere nemlig på alle typer af hjemmesider.

Sådan udformes en kravspecifikation til IT projekt

Sådan kommer du igang med din første kravspecifikation på web projekt

Indholdsfortegnelse

Denne oversigt vil kravspecifikationen være opdelt i og du kan bruge den som skabelon. Til afslutning kan en template downloades som kan benyttes i egne projekter. Denne skabelon indeholder et simpelt eksempel på hvorledes den kan dække over en hjemmeside.

  • Hvad er en kravspecifikation?
  • Hvad koster mit projekt at bygge?
  • Beskriv virksomheden bagved
  • Liste med de tekniske krav og funktionalitet
  • Hvad der helt specifikt skal inkluders som krav
  • Ikke funktionelle krav
  • Wireframes og flow

Hvad er en kravspecifikation?

En kravspecifikation er et dokument som beskriver funktionaliteten over et givent IT projekt og ud fra dette kan projektet estimeres og implementeres af udviklere. Et eksempel og andre krav kan du se på erhvervsstyrelsen.

Hvad koster mit projekt at bygge?

Et typisk spørgsmål fra projektejer efter en kort gennemgang på 2 min. Herefter svarer projektlederen: Hvad skal det kunne?

For at give projektejer et reelt og fair svar sætter man sig ned og beskriver i detaljer hvad der skal bygges, hvordan det skal se ud, hvordan det skal fungere samt hvilke problemer det skal løse. Det er derfor ikke et holdbart svar at sige 100 timer efter en gennemgang på 2 min. I softwareudvikling er der mange sorte kasser hvor man ikke ved hvad der er indeni før kassen åbnes. Et smugkig i kassen og efterfølgende beskrivelse i kravspek. vil give et godt estimat af opgaven.

Forretningsforståelsen af virksomheden er faktisk det vigtigste punkt for at projektet skal blive en success

Beskriv virksomheden bagved

En liste med krav giver ikke meget mening hvis ikke forståelsen bagved også er med. Derfor er det første afsnit i høj grad også det vigtigste da det skal indeholde en beskrivelse af virksomheden, historien bag ved og hvorfor projektet nu er nødvendigt. Indledningsvis i dokumentet har man derfor en problemformulering som beskriver det problem der ønskes at løses.

  • Beskriv hvilken problemstilling projektet skal løse
  • Beskriv historien bagved virksomheden
  • Forklar jargon og tekniske vendinger som benyttes af virksomheden i kravspecifikationen
  • Beskriv hvem målgruppen er for projektet dvs. hvem skal bruge produktet?

Forretningsforståelsen af virksomheden er faktisk det vigtigste punkt for at projektet skal blive en success. Ja hvorfor det? En udvikler som får at vide han skal bygget feature A, bygger den bare og kan så risikere at blive mangelfuld. Får udvikleren istedet at vide:

  • A. Hvad han skal bygge
  • B. Hvorfor han skal bygge det
  • C. Hvilket problem det skal løse

Så er sandsynligheden langt større for at han også kommer i mål med det som projekt ejeren ønsker.

Liste med de tekniske krav og funktionalitet

De enkelte krav og features bør listes på en nummereret liste så det er nemt at referer direkte til et punkt enten fra andre krav eller når man kommunikerer sammen. Når nye punkter tilføjes eller ændres efter påbegyndelse bør man tilføje dem som et tillæg og versionsstyres. Rediger derfor ikke i en endelige kravspecifikation for ellers vil nummer formatteringen også ændres. Mangler du inspiration til indholdet findes der en god liste med punkter her.

En nummereret liste form ser sådan her ud

  1. krav
  2. krav
    1. underpunkt med krav
    2. underpunkt med krav
  3. krav se figur 1
 De enkelte krav og features bør listes på en nummereret liste så det er nemt at referer direkte til et punkt 

Her er et eksempel på hvordan billeder kan vedhæftes. Giv denne mockup navnet figur 1 og referer til den i teksten.

Hvad der helt specifikt skal inkluders som krav

Hvis vi helt konkret tager udgangspunkt i beskrivelsen af en kontakt formular. Så lad os forestille os at i version 1 af kravspecifikationen så noteres der at siden skal indeholde en kontaktformular og at denne skal sende kopi til xx@xxx.dk. Dette krav er overordnet ok, men der er også mange faldgruber for udvikleren og sansynligvis bliver der ikke udviklet det som der præcist forventes af kunden. Derfor skal sådan en kontaktformular uddybes for at undgå tvivl. Lad os tage udgangspunkt i dette eksempel.

Eksempel på kravspecifikation for kontakt side:
  1. Kontakt side
    1. I hovedmenu samt footer skal der være link til kontakt side
    2. På kontakt side skal der være kontaktformular med følgende felter: Navn på afsender, email på afsender, besked fra afsender
    3. Ved udfyldelse af kontakt formular skal der sendes en email til modtager og kunden skal modtage en bekræftigelse på mail
    4. Kontakt formularen skal validere at felter er korekt udfyldt før brugeren kan submitte formen
    5. Efter succesfuld udfyldelse skal brugeren sendes videre til en bekræftigelseside hvor der kvitteres med modtagelse
    6. Ved eksekvering skal der sendes event til Google Analytic
    7. På kontakt siden skal der udover formular også være virksomheds info som adresse, tlf. email og markering på Google Maps samt åbningstider, se figur 1


Figur 1

Her er der i eksemplet taget udgangspunkt i desktop versionen men der bør tilføjes punkter som beskriver den mobile version samt tilhørende mockup.

Her er der i eksemplet taget udgangspunkt i desktop versionen men der bør tilføjes punkter som beskriver den mobile version samt tilhørende mockup.

Det kan måske virke som udpensling af feature og tage tid at beskrive men det vil spare sig ind på implementeringsfasen for udvikleren ved præcist hvad der skal bygges. Udvikler vil derfor spare tid på spørgsmål til projektleder og projektejer og vil med større sandsynlighed ramme plet i første runde. Projektleder og projektejer vil også spare tid på tests, fejlmelding og feedback. Software udvikling er per definition en meget dyr process så kan man reducere denne vil den samlede omkostning for projektet også reduceres.

Det gælder derfor i disse beskrivelser at være specifik på hvad der ønskes og ikke hvordan det skal implementeres. Et krav som at kontakt siden skal være brugervenlig er ikke specifikt og kan fortolkes på mange måder.

I dokumentet kan der være et selvstændigt afsnit som beskriver projektplanen. Her angives hvilke dele der ønsker udviklet først og en nogenlunde timeframe for dette. Et Gantt chart er oplagt til dette.

Gantt chart som viser tidplan over forløbet

Når projektet nærmer sig den sidste fase bør der være en accept test til at verificere at alle krav er opfyldt. Der findes en lidt dybere udspecificering her på wikipedia.

Kravspecifikation skal beskrive funktionalitet og wireframes for både desktop og mobil version da disse kan og vil adskille sig

Ikke funktionelle krav

Nogle krav kan være ikke funktionelle, dvs. de angiver ikke en specifik funktionalitet. I dette afsnit angiver vi derfor de krav som er lidt mere “bløde”. Som eksempler kan nævnes:

  • Hjemmeside skal fungere på en tablet og mobil via responsivt design
  • Hjemmeside skal være hurtig og svartid på under 1 sek. i gennemsnit for alle sider
  • Der skal være høj sikkerhed
  • Den skal fungere i nyeste versioner af IE11, Edge, Chrome, Firefox og Safari

Da f.eks. en hjemmeside bliver vist på et hav af forskellige browsere, enheder og skærmopløsninger bør man anvise hvilke den typisk bør fungere optimalt på og hvilke man accepterer en graceful degradation så hjemmesiden stadig fungere men kan se lidt anderledes ud eller helt mangle en given funktionalitet.