Tag: mobile

Sparekassen Thy har valgt altid at være ved kundens side, via en ny mobil app. SejKo har leveret en iOS og Android app til både tablets og telefoner.

Appen giver direkte kontakt til ens rådgiver, og mulighed for at følge med i nyheder og begivenheder.
Alle data og push-notifikationer kan Sparekassen Thy styre fra platformen, hvor de også redigerer deres hjemmeside.

Teknisk er appen bygget som hybrid app, som gør det muligt at målrette både iOS og Android platformene fra en fælles kodebase – hvor man ellers udvikler to vidt forskellige apps; en til hver platform. Dette gavner både udviklingsprocessen og vedligeholdelsen af appen. Både i tid, pengene og projektstyring – da man ikke behøver at arbejde med forskellige udviklings teams.
Kodebasen er udviklet i det robuste framework, Ember.

Sparthy app, kontakt

Sparthy app, pushnotifications

Sparthy app på smartphone og tablet

Download appen Sparthy på Apple AppStore eller Google Play.

0

I denne uge står Incendium på messe i Oslo. Et af deres “no-config-just-click” produkter der ses her, er streaming appen IncidentShare, som SejKo har udarbejdet. En ‘native’ Android mobil app, der live streamer video direkte via ens IncidentShare konto. Mere herom kommer senere 🙂

0

Det gode ved app- og webprodukter der bliver udarbejdet her hos sejKo, er at man som kunde selv kan bestemme fokusområdet; nogle produkter fokuserer på udseende, andre på funktionalitet, andre igen på tilgængelighed. Man skal tage beslutninger i livet; ikke for ofte gå på kompromis!
Ikke at gå på kompromis med tilgængelighed af en hjemmeside på mobile enheder, er en god idé i disse dage, hvor hjemmesider bliver betjent oftere fra mobiler end fra PC’er.

I denne artikel tager vi en gennemgang af hvordan man kan optimere sin hjemmeside til mobile enheder.

Har du travlt? Læs opsummeringen. Er du frisk på alle detaljer? Fortsæt:

Det er klart at et website som fungerer på en desktop PC (i samme tilstand) ikke vil fungere på en mobil – og omvendt. I praksis er der heller ikke kun de to muligheder; der er også tablets, og mobiler for den sags skyld, i forskellige dimensioner og ‘pixeltætheder’.
Udfordringen man møder først, er selvfølgelig skærmplads – i forhold til forskel i skærmstørrelsen. Den næste udfordring har mere med ordet ‘mobil’ at gøre, når man taler om ‘mobile browsing’; nemlig begrænsning af netværk når man er på farten – båndbredde.

Skærmplads udfordring

På større skærme kan man vise mere info, mere navigation, vise større billeder, have stor afstand mellem elementerne og bruge afstanden til et bestemt udtryk (imago m.v.).
På mindre skærme er man udfordret på alle de punkter At træffe (fra)valg er hovedopgaven.
Hvor man ved et layout for større skærme, skal designe overskuelighed i alt det skal komme på skærmen, skal man ved et mobil layout designe efter intuition og proces flow: det hele kan ikke vises på én skærm på én gang.

Båndbredde udfordring

Fra webudviklingens dag 1 har målet og udfordringen været en hurtig ‘loading-time’. Kravet til hjemmesiderne er vokset i takt med den voksende båndbredde. De nuværende hjemmesider er ikke længere udviklet til en 56kb betal-pr-minut modem, nu vi er vant til 20-50 eller 90 mb fibernet. Selvom mobilbredbånds hastigheder er vokset, er det ikke det samme som fx 50 mb fibernet up- og download.
Når man er på farten, kan ens båndbredde også variere og eventuelt falde helt ud.

En hjemmeside består hovedsageligt af HTML sider, CSS og Javascript filer og billeder. Da de første 3 nævnte blot er tekstfiler, er det billeder der som regel fylder mest. Jo større billederne er, jo mere båndbredde de kræver.

Flere mobile enheder er i dag også udrustet med en ‘high-density’ skærm, som fx. Apples såkaldte ‘retina’ skærm. D.v.s. at ‘pixel-tætheden’ er to gange tættere, så øjet oplever billedet skarpere. Men det betyder også at billeder skal være to gange så store, ellers ser det sløret ud!

Hvilke muligheder har man når man vil optimere til mobil?

Lad os nu se på hvordan man kan optimere sit website til mobil betjening. Jeg nævner dem trinvis, hvor vi for hver trin dykker et niveau dybere i mobiloptimeringen. Løsningen til dit projekt afhænger af, hvor meget af ressourcerne der skal bruges til mobiloptimering.
Men inden jeg kommer med løsningsforslag, tager vi lidt tilbage i tiden…:

Lidt historie…

Det første man kigger på når man vil supportere mobile enheder er at tage hensyn til den mindre skærmplads. Omkring årtusindskiftet designede man som regel hjemmesider efter en fast bredde af den mindste skærmdimension man vil understøtte, fx 640×480, større skærme fik bare mere tom plads at se.
I det årti hvor Nokia og Ericsson var hotte kunne man browse indhold fra nettet på ens telefon via XML feeds i en WAP browser. Men da Apple lancerede den første smart-phone, iPhone, i januar 2007, var der pludselig en seriøs mobil browser, der understøttede alt det gode og det nye. Det betød at ens hjemmeside nu kunne betjenes fra en mobil telefon, undskyld, smart-phone! Inklusiv hjemmesidens interaktivitet og brugeroplevelse! En ny verden havde åbnet sig. Apple indtog nu mobil- føringen og da Google udkom med Android OS, kom der flere nye spillere på markedet. Der var pludselig et hav af smartphones og tablets, alle i forskellige størrelser.

Med mindre andet er angivet, skalerer en mobil browser en hjemmeside ned så den passer i bredden – ellers skal brugeren scrolle både vertikalt og horisontalt. Men en standard hjemmeside er ret dårligt at betjene i den lille skala.
På grund af nye features i de ‘moderne browsere’ (der i blandt mobil browsere!) opstod omkring 2010 det nye boss-word indenfor web verden, nemlig “responsive layout”. Det blev løsningen på understøttelse af diversiteten i skærmstørrelser.

Responsive layout

Et responsive layout er et layout der tilpasser sig skærmbredden, procentvis. Man definerer et par ‘break-points’. Baseret på dem, viser / skjuler man bestemte elementer, eller viser dem på en anden måde (fx under hinanden i stedet for ved siden af hinanden).

Responsive layout

Et responsive layout er grundlæggende for mobiloptimering. I dag er det blevet ‘de facto standard’ og næsten ingen hjemmesider bliver leveret uden et responsive layout.
OK, så dit site vises altså pænt på forskellige mobile enheder. Men dermed sagt er det ikke nødvendigvis optimeret til mobil. Tvært imod; de fleste tilgængelige ‘templates’, ‘themes’ m.v. er lavet til en flot visning på PC skærme, så kunden ser glad ud når den færdige hjemmeside bliver afleveret – med flotte store billeder. Men ofte bliver de samme store billeder brugt til mobil layoutet, blot nedskaleret…

Tænk og design ‘mobile-first’

Mange hjemmesider bliver designet med PC skærme som udgangspunkt, men fungerer også på mobile enheder. Men når man optimerer til mobil (nu hvor der er flere besøgende fra mobil end fra PC), skal man nok tænke omvendt: Mobile-first!
Hvordan ser hjemmesiden ud på mobil, hvordan navigerer man på mobil, hvad er flowet i funktionaliteten på mobil, hvor ‘tung’ skal hjemmesiden være? Når det er udtænkt som første prioritet, kan man tænke over hvordan dette site ser ud på en desktop PC, som anden prioritet. 🙂

Statiske filer, komprimering, cache og CDN

En webside består af en HTML fil (en dynamisk fil som webserveren sammenstiller ud fra en database baseret på et ‘request’), og flere statiske filer som Javascript, CSS og billeder.
Man kan optimere alle disse filer, så de kræver mindre båndbredde.

Billeder skal ikke være større end nødvendigt i dimensionerne og kan få en passende JPEG komprimering – hvis det i det hele taget skal være et JPEG billede: JPEG er godt for billeder med mange farver (som fotos) hvor PNG er bedre for billeder med få farver (som logos). Så er der også SVG billeder; mere om dem lidt senere.

Javascript og CSS filer kan minimeres, så de fylder mindre i filstørrelse. I nogle tilfælde kan man gøre det direkte fra sit CMS, i andre tilfælde skal udvikleren kreere dem når han udgiver sin software.

HTML filen kan, afhængig af systemet, også komprimeres ved at fjerne ‘white-spacing’.

For at reducere tiden på ‘latency’ vil det give mening (når man har mange besøgende) at ‘cache’ sin dynamiske HTML fil. Det betyder at når webserveren generer en dynamisk HTML fil ud fra databasen (fx hvilke items skal fremgå i navigationen, hvilket item er aktiv, indholdsartikelen, hvad vises i højre kolonne etc. etc.), gemmer webserveren denne ‘cached’ HTML fil i fx 20 min. D.v.s. at hver gang der kommer en ny besøgende indenfor 20 min., serverer webserveren den cachede fil, så den ikke skal efterspørge databasen og danne en ny HTML fil.
Statiske filer, som Javascript, CSS filer og billeder, kan blive cached af browseren, så de ikke skal hentes fra webserveren hver gang – de ændres meget meget sjældent. 🙂

Netop fordi statiske filer som Javascript, CSS filer og billeder ændres så sjældent, kan man argumentere for at der ikke er nogen grund til at de ligger på din webserver, som formentlig er optimeret til at generere HTML output ud fra din database. Såkaldte Content Delivery Network (CDN) servere er netop specialiseret i at servere statiske filer, hurtigt!
Ulempen er, at ens hjemmeside ligger spredt over 2 servere, som kræver lidt ekstra arbejde når hjemmesiden skal opdateres, men det er endnu et trin i et hurtigere website, og dermed optimering til mobil betjening.

Cut-the-crap

Når en hjemmeside har været på banen i et par år, er der en god chance for at der lige så stille er kommet udvidelser på i form af plugins m.v. Det resulterer ofte i ekstra processser og ekstra Javascript og CSS filer der skal hentes.
Det kan godt kræve en grundig gennemgang; bruger vi dem stadigvæk, gør de stadig det vi ønsker, gøres det smart, fylder de meget, kan vi slå nogle sammen ved at lave dem selv og forfra? Kort sagt, er der ofte ekstra fyld på et lidt ældre website.

Ingen sliders

Overvej også din slider på forsiden! Ud fra Search Engine Optimization (SEO) perspektiv er en forside slider ikke den bedste idé (er bl.a. langsom og skubber primær indhold ned fortæller SEO eksperten Yoast). Især ved mobil skal du huske at, du pålægger brugeren at hente fx. 5 billeder ned, som brugeren slet ikke har bedt om. Især når siden ikke er designet mobile-first, er det formentlig 5 kæmpe billeder!
Skal der topgrafik til, kan der sikkert nøjes med 1 billede, så spares der 4 billed downloads, og brugere ser formentlig ikke flere end det ene alligevel. 🙂

Smart grafik, retina

Så det er grafikken der fylder? Ja, især på hi-density (retina m.v.) skærme, hvor grafikken skal være dobbelt størrelse.
Man skal se på hvilken type grafik man skal / kan bruge:

  • Et foto skal være et rasterbillede som JPEG.
  • Et logo er som regel bedst i PNG (rasterbillede), men med en stigende browsersupport er SVG også værd at overveje. SVG er ikke raster, men vektor baseret. Vektorerne gør at grafikken kan skaleres op og ned uden at den mister skarphed, som et rasterbillede vil gøre. Og det betyder at én og samme vektor grafik kan vises i alle størrelser, retina skærm eller ej!
  • Piktogrammer / ikoner kan også fungere som SVG, men der kan også anvendes en af de tilgængelige piktogram / ikon ‘fonts’. Det er blot en skrifttype, hvor der ikke er tegnet bogstaver men piktogrammer. Skrifttyper er vektor baseret og derfor kan piktogrammerne skaleres op og ned, og ser lige skarpe ud! Og er nem at anvende og justere!

Selvom du vil være ‘retina-ready’ og understøtte pixeltætheden af hi-density skærme, er det en god idé at ens kode kan adskille disse skærme fra de traditionelle. Dette for at undgå at enheder med traditionelle skærme henter større billeder ned end de har brug for. CSS er rigtig effektiv her.

Der findes også tekniker til at hente billeder ned for en bestemt grafik, afhængig af ens skærmstørrelse, og dermed styre billeddimensioner af det man downloader.

‘Lazy-loading’ er en teknik, der først henter billederne når de fremgår i ‘view-porten’. Med andre ord, når en bruger skal se dem, fx når han er scrollet dertil, i stedet for at alle bliver downloaded på én gang.

One-pager

Har du en lille hjemmeside, kan du overveje en ‘one-pager’: Alt dit indhold som normal er fordelt over flere sider, bliver vist, fordelt over sektioner på én side, ‘forsiden’. Din navigation linker til ‘anchors’ på denne side, og dermed har hver ‘side’, undskyld ‘sektion’, sin egen URL, og er dermed SEO venlig. Det vil spare brugerens ‘requests’ til webserveren og dermed ventetid.  Ved at scrolle lidt, vil brugeren måske se indhold han ellers ikke vil have set. 🙂
Men husk at den lange side ikke skal være fyldt med (stor) grafik, som fx parallax scrolling sektioner (, skjul dem for mobil). Lazy-loading for billeder kunne være et godt tiltag.
Apropos, parallax scrolling på mobil kan få en side til at ‘hænge’ lidt.

Single Page Applications

Den ultimative løsning til mobiloptimering!!
En Single Page Application (SPA) er én enkel (ikke webserver genereret) HTML side, hvor alt er styret af Javascript. Siden i sig selv kender ikke nogen indhold, det bliver hentet fra en API, i baggrunden, for hvert ‘request’.
Hermed sparer man alt ‘over-kill’ en traditionel side har: En traditionel side er ‘stateless’, det vil sige at når man fx klikker på “Kontakt” i navigationen, bliver der lavet en ny forespørgsel til webserveren, siden forvinder, og den nye side bliver henten ned, inklusiv header, footer, navigation, kort sagt næsten alt som du allerede havde på den forrige side – du vil egentlig bare hente Kontakt indholdet…
En SPA henter netop kun den information, du beder om – i baggrunden. D.v.s. siden bliver ‘stående’, indholdsområdet bliver skiftet ud.
Siden fungerer egentlig som en ‘mobil-app’, der bliver hentet fra nettet. (Hvis man vil, kan man bruge den samme kode til en rigtig ‘mobil-app’, lavet som ‘hybrid-app‘!!). Brugeren vil også opleve dit site som en app. En SPA egner sig også rigtig godt til interaktivitet!
Fordi man udvikler en SPA med et app ‘mind-set’ skærer man også alt til benet; cut-the-crap. Appen bliver ikke generet af nogen webserver (det gør kun APIen), og serveres derfor lynhurtigt, den kan caches af browseren og kan rent faktisk blive serveret fra en CDN.
Man kan give alt indhold sin unikke URL, d.v.s. at brugere altid kan bookmarke, og søgemaskiner kan indeksere indhold fra din SPA.
Bemærk: da søgemaskiner ikke kan udføre klient kode som Javascript, skal de ‘proxies’ videre til en app / service som leverer dem indholdet pre-renderet på siden, eller lave en simpel Ember FastBoot install hvis du bruger Ember.JS. Husk at tage den del med!

En SPA skal ikke forveksles med en one-pager, da en one-pager er genereret af en webserver (hvor blot alt indhold er sat ind på én side)

Flexi

Bruger man Ember.JS som framework til ens SPA, kan man bygge sit layout op via add-on Flexi. I et responsive layout som vi kender det, loader man en frygtelig masse ‘markup’ (=HTML kode) og i ens CSS bestemmer man hvad der vises og skjules, afhængig af brugerens skærmstørrelse.
Men i en SPA loader man templates ‘on-the-fly’ på klienten (ikke på webserveren). Flexi giver en udvikler mulighed for at loade specifikke templates for specikke enheder / skærmstørrelser. Det vil sige at man hermed også sparer på overflødig template-kode som giver en endnu hurtigere rendering.
Med Flexi i sin SPA, kan man spare alt det overflødige væk man kan komme i tanke om. 100% Mobil optimering!

“M.” [ɛm dɑt]

“M.” er blot et ofte brugt subdomæne for et mobil site, som fx “m.youtube.com”. Anvender man sådan en opdeling, kan man understøtte mobile enheder fuld ud med sin SPA på ét domæne (fx “m.your-site.com”) og køre sit ‘almindelige’ site for desktop browsers på sit oprindelige domæne (fx “www.your-site.com”). Bedste fra (og for) begge verdener!
Man ‘redirecter’ besøgende fra mobile enheder på www.-sitet, til m.-sitet. Med et velovervejet URL-design kan man sende brugere fra en URL til dens equivalent på m-.sitet.
Men den opmærksomme læser vil bemærke at “M.” ikke er ‘mobile-first’ tænkning: Så skulle mobil sitet være tilgængelig på “www.your-site.com” og desktop sitet på fx. “desktop.your-site.com”, eller “d.your-site.com”. Start en ny trend: “D.”!!!

Ulempen med “M.”, eller “D.” for den sags skyld, er at der nu er to ‘codebases’ man skal vedligeholde. Men som du nok har forstået, kommer en gennemført mobiloptimering ikke faldende ned fra himlen. Hvor vidt man vil gå, er en prioritering!

Mobil optimering opsummeret

En god oplevelse af en hjemmeside på mobilen er et krav i dag. Udfordringer ligger i mindre skærmplads og mindre (stabil) båndbredde. Der er flere løsningen, alt afhængig af ens budget eller ens fokus på mobil optimering.
Vi har talt om:

  • Responsive layout
  • Tænk og design ‘mobile-first’
  • Statiske filer, komprimering, cache og CDN
  • Smart grafik, retina
  • Cut-the-crap
  • Ingen sliders
  • One-pager
  • Single Page Applications
  • Flexi
  • “M.” [ɛm dɑt]

Et responsive layout er starten, og standarden i dag. En god tilgang er ‘mobile-first’ tankegang.
Man kan finjustere sin eksisterende hjemmeside ved at gennemse sine ‘statiske filer’, og skære overflødigt indhold væk.
Den ultimative løsning er en Single Page Application (SPA).
Eventuelt kan man have et website til desktop besøgende og et separat website med en SPA til mobile besøgende.