Native or Responsive?

Link til artikkel:

https://uxmag.com/articles/native-or-responsive

En artikkel jeg fant på uxmag.com en magasin side for UX (user experience design) diskuterer om man bør bruke Native eller responsivt design for mobil.

Native apps kan ta fullt nytte av alle funksjonene til mobilen, men responsivt design er enda et godt valg i mange situasjoner.

Det har alltid vært et gap mellom native og responsivt design i iOS, men nå som det er blitt et større gap med hardware, video, stemme gjennkjenning og mer. Dette har ført til at det er mer spenning mellom native og responivt design.

Native leder foreløpig over responsivt design. For bare noen år siden ville det være galskap å si noe avvisende mot responsivt design. Med de nye gevinstene med HTML5 og dens framtidige forbedringer, responsivt var sett på som like bra som nativ. Tilogmed Facebook hadde en responsiv app i første iterasjon.

Derimot noen år etter at HTML5 lovde å eleminere forskjellene mellom responsivt og native, med natives design storeutvikling. Så er nå Native fra et design og UI perspektiv blitt mye bedre å bruke for mobiler.

Så da er kampen over?

Ikke helt, likevel om native gir et bedre design og UI/UX så har responsivt and HTML5 nesten 50% adopsjon i de meste markeder. Grunnen til dette er at native er mye mer kostbart å lage.

Før var det svært dyrt å lage for android at det ble ungått i sin helhet av de fleste. Da ble man enten tvunget til å lage en responiv mobil side eller lage en iOS app.

I dag er det ganske anderledes. Android har blitt mye bedre. Nå er det faktisk mulig å ta i betraktning prisen. Så nå er valget mellom en responsiv nettside eller en iOS og en Android app. Så spørsmålet er om du ønsker 2 lag som arbeider på hver sin side, eller et lag som arbeider på en responsiv side. Dette kan ha stor konsekvens på firmaet sine ressurser.

Responsiv har derimot ikke nært så mange evner som native har, for å ta ibruk mobilens funsjoner. Photo og musikk apper må lages native.

Du kan klare å lage en bra app med responsiv design, men viss du faktisk ønsker at applikasjonen skal føles som den er en del av mobilen din så er nok dette umulig med responsivt design.

Konklusjon

Med følgene av at mobilen innovasjon fortsetter å akselerere, så vill forskjellen mellom responivt og native programmering forsette å gro, og vill åpne for store forskjellige funksjoner. Heldigvis så er det et enkelt valg i mellom om mobilen er i fokus eller ikke. Viss mobilen er i stor fokus så er native det rette valget, mens ellers så vill nok responsivt funke fint.

Nielsen Norman Group sine artikler om brukergrensesnitt

Nielsen Norman Group sine artikler om brukergrensesnitt

NNG er et konsulentfirma som omhandler brukergrensesnitt og UX på nettet. På nettsiden deres http://www.nngroup.com/articles/ har de flere artikler som kan hjelpe med å lage velfungerende og responsivt design for brukerne av nettsiden din.

Jeg har valgt to artikler som jeg skal skrive om:

  • Why designers think users are lazy: 3 human behaviors
  • Audience-based navigation: 5 reasons to avoid it

Den første omhandler om hvordan man som designer fort får følelsen av at brukerne av designet er dumme eller late og dermed ikke bruker nettsiden korrekt.

Den andre artikelen omhandler hvordan sider som skifter på linker og categorier ettersom vilken role du er på siden. F.eks. Student, lærer og generelt, kan ofte føre til for høg innsats og frykt i brukeren.

Why Designers Think Users Are Lazy: 3 Human Behaviors

Mange blir ofte lei av at brukerne av siden deres mangler forståelse for hvordan bruke siden effektivt, eller at brukerne ikke finner fram til det de ønsker å finne på siden. Dette fører til frustrasjon til designeren, og ender ofte med at brukerne blir sett ned på. De kan blant annet bli kalt dumme eller late.

Istedet for å anklage brukeren bør man heller forstå grunnen for brukerens handling. De 3 største oppførslene som gjør at det ser ut som brukeren er lat, er egentlig det perfekte eksemplet av effektiv menneske oppførsel som man bør ta i betraktning når man lager design.

  1. Enhets stahet
  2. Impuls oppførsel
  3. selektiv oppmerksomhet

Brukere har en tendens til å velge banen som bruker minst innsats. All oppførselen til brukeren representerer situasjoner der brukerens oppfattede fordel er for liten for den oppfattede kostnaden. Dette fører til at brukeren vill gjøre upassende valg.

Enhets stahet

Blir forklart i artikkelen som en uvillighet til å bruke et annen enhet, når flere er tilgjengelig og potensielt mye mer passende for situasjonen. Det føles at det tar for mye innsats i å skifte til en annen enhet for dermed å navigere til programmet eller nettsiden man brukte tidligere for å få fordelen med større bilde og kvalitet. For en person med Enhets stahet blir dette set på for alt for tungvindt.

Viss brukeren kalkulerte tiden og innsatsen som ble brukt i motsetning til hvor mye som kunne blitt spart, så ville som oftest det optimale enheten bli valgt viss det var mye som enda måtte gjøres nå eller i fremtiden på prosjektet. Men viss det bare var litt til som måtte gjøres vant som oftest å fortsette å bruke det upassende enheten. Mennesker planlegger som oftest bare i den nærmeste horisonten og følger heller sin menneskelige intuisjon som da vill være å fortsette å bruke det upassende enheten.

Impuls oppførsel

Et eksempel for impuls oppførsel vill være å gjøre noe på en tung måte når et enklere alternativ er allerede tilgjengelig og fører til et bedre resultat. Grunnen til å gjøre dette kan være for tre grunner:

  • Personen fant den vanskelige metoden først
  • Det gikk ikke opp for personen at den var en bedre og enklere alternativ for å gjøre oppgaven.
  • Metoden fungerte godt nok.

Dette reflekterer også hvordan mennesker balanserer oppfattede fordel i motsetning til oppfattet innsats. Likevel om det ville gå mye raskere å bruke et annet alternativ til oppgaven så føles det for brukeren at dette tar for mye innsats.

Selektiv oppmerksomhet

Selektiv oppmerksomhet er når man fokuserer på et særlig objekt og ignorerer all annen informasjon som blir sett på som ubetydelig. Dette brukes av oss dagelig for å filtrere hva vi skal bruke vår kognitive hjerne på. Dette kan være svært brukbart i mange situasjoner, men kan også føre til flere rett under nesa på deg opplevelser. I design kan dette føre til at brukeren ikke legger merke til elementer, disse kan da både være brukbare eller unyttige. Viss det elementet som var viktig blir ignorert kan dette skade brukeren siden de ikke får brukt siden korrekt.

Løsninger for web designere

  • Alle viktige oppgaver må være enkle å gjøre på alle enheter.
  • Ikke anta at brukerne will aktivt bytte mellom mobil og data for å gjøre bestemte oppgaver.
  • Tillat brukere å enkelt synkronisere informasjon mellom plattformene, så folk eventuelt lærerer at de kan bytte fra mobil over til datamaskin uten mye ekstra arbeid.
  • Bruk oppførselsstudie og analyse av brukerne for å finne de mest bruke veiene folk tar for å gjøre en oppgave. Viss den enkleste ikke er den mest tatte, arbeid for å få den mer enklere å finne og å bruke.

Bruk heller slike design løsninger istedet for å kalle brukeren late. Oppførselen til brukerne er et produkt av evolusjon og kultur, og er derfor vanskelig å skifte. Det er derfor viktigere å orientere siden slik at den passer for brukerne, en å be dem om å endre seg.

Audience-Based Navigation: 5 Reasons to Avoid It

Publikums-basert navigasjon er når man man spesialiserer siden for forskjellige type brukere. Dessverre så er disse løsningene som oftest problematiske for brukeren.

Teorien er at hver bruker vet hvilken gruppe de tilhører og vill bare trenge funksjonene som er på denne gruppen. Men dette i tankene håpes det at brukeren sparer tid med å ikke bli eksponert til de andre funksjonene som den ikke har bruk for.

Til tross for disse tilsynelatende fordelene, brukervennlighets problemer med rolle-baser navigasjon er svært alminnelig. Under er de fem mest kjente problemer som oppstår i følge artiklenes studier.

  1. Brukerne vet ikke hvilken gruppe de skal velge.
  2. Brukerens spørsmål angående om kategorien vill ha informasjon om gruppa eller for gruppa
  3. Å tvinge folk å selv-indentifisere seg lager et ekstra steg før folk kan gjøre det de ønsker.
  4. Brukerne føler seg utrygg for at informasjonen de får se kan være feil eller uferdig.
  5. Nettsider med publikums-basert navigasjon har ofte overlappende inhold, som fører til mere å gå igjennom for brukerne og de som holder siden oppdatert.

Hvordan jeg lærte meg HTML, CSS og JS

Siden jeg tok et årsstudium i medieproduksjon og sosiale medier i mo i rana fikk jeg tillatelse til å hoppe over først året på Media, Ikt og Design her på Volda. Dette førte overaskene nokk til at det oppsto noen problemer for meg på andreåret. Det største problemet er nok min mangel på programmerings kunnskaper i HTML og mangel på erfaring med å bruke Dreamweaver. Det skal jo sies at jeg har brukt Dreamweaver litt før, men dette var da bare med bruk av mal og lignende.

Så når vi endelig begynte med skoleoppgaver på skolen møtte jeg på et hinder jeg ikke har opplevd i media faget før. Jeg har ikke peiling på hva de snakker om i undervisningen. Før jeg viste ordet av det måtte vi lage en nettside og skrive våre favoritt CSS-triks til neste time. Da skjønte jeg at jeg måtte ta noe skippertak for å ikke falle bak klassen.

Lynda

Jeg startet med å få meg et abonnement på Lynda.com en fantastisk nettside jeg har brukt tidligere til stor suksess. Jeg søkte deretter opp Dreamweaver og fant en tutorial som het «Dreamweaver CC Essential Training». Denne tutorialen går igjennom steg for steg hvordan jeg skal lage en nettside, men forventer at du allerede kan HTML og CSS. Videoen anbefalte meg å starte med å se «Web Design Fundamentals» Som lærer meg om HTML,CSS og JavaScript. Siden jeg mangler grunnkunskapene for å programmere ville jeg starte på bunnen slik at jeg får en bedre forståelse for hvordan jeg skal gå videre i Web Design.

Kapittel 1 – Utforsking av Web Design

Siden HTML, CSS og JS egentlig bare er tekst som er formatert på en slik måte at nettleserne våre kan forstå dem, skriver jeg kodene i Notepad, eller rettere sagt Notepad++. Grunnen til at jeg bruker Notepad++ er fordi den har noen funksjoner som gjør det lettere å programmere.

Her er en ganHello worldske enkel Hello World! Html fil jeg lagde på noen få minutter.

Resultatet er ganske primitivt, men det er en svært lærerik oppgave som har lært meg de grunnleggende elementene av en HTML fil.

CSS

cssInne i Head taggen skrev jeg <style> dette sier i fra at jeg nå skriver i CSS. CSS som tidligere nevnt betyr «cascading style sheets», og bestemmer hvordan elementer på siden ser ut.

Det anbefales egentlig å skrive CSS og JavaScript i egne dokumenter, men siden dette bare er en test går det fint foreløpig å ha alt i samme dokument.

Jeg har skrevet to elementer som jeg ønsket å skifte egenskapene til, body og h1. H1 er en del av body, men siden css er cascading så oppdateres denne informasjonen nedover dokumentet. Så bodyen blir først rød, deretter skifter jeg bare headeren til å før fonten Arial eller viss den ikke er tilgjengelig, den standarde sans-serif fonten. Deretter skifter jeg headerens font til 32 pixel og fargen til svart. Siden fargen ble skiftet til svart igjen så blir headeren ikke rød som resten av bodyen.

Slik ser siden foreløpig ut:

ss+(2015-09-18+at+01.43.07)

JavaScript

JavaScript i motsetning til HTML og CSS er ikke nørdvendig for å lage en bra nettside, men den åpner opp for mange muligheter i web design. JavaScript er et koding type kalt script. Da trenger man å skrive in en tag som heter <script> inn i dokumentet. Vi vill ikke putte denne like høgt oppe i dokumentet som style fordi nettleseren vil da slutte å laste ned siden og vil starte å lese skripten før den leser resten av siden. Dette ønsker vi ikke så derfor putter jeg <script> etter alt de viktige i teksten men skriver det rett før </body>

JavascriptPuh… her har jeg bynt med god gammeldags programmering med if, else, var og hele pakka. Dette er en script som har laget en knapp under teksten på siden som skal skifte tekst fargen på bodyen mellom rød og grønn.

Dessverre fungerer ikke koden :/ siden jeg har fulgt tutorialen på Lynda fra punkt til prikke så skjønner jeg ikke hva jeg har gjort feil. Har nå sendt melding til læreren for å spørre om hjelp.

Forhåpentlig følger en oppdatering snart.

En dag senere:

som jeg nettopp har fått opplevd, så er programmering en svært nøyaktig prosess.

Ser du forskjellen i mellom disse to kodene?

1

2

Til og med en så liten feil som å skrive en liten bokstav istedet for en stor bokstav kan føre til at koden ikke fungerer. Å uten et hjelpe program for å finne ut feilen i koden kan dette føre til flere timers skattejakt i de større nettsidene.

Klikk her for å se den enkle nettsiden jeg lagde.

Neste blogg kommer jeg antagelig vis til å hoppe over til Dreamweaver slik at jeg kan ta igjen resten av klassen.

Historien bak CSS

Hva er CSS

CSS står for Cascading style sheets. Style sheets forklarer til nettleseren hvordan siden skal leses slik at man får et ønsket utseende på nettsiden.

CSS ble designet hovedmessing for å separere nettsidens utseende fra resten av nettsiden. Dette fører til at man kan lettere åpne tilgjengeligheten av nettsiden til forskjellige typer skjermstørrelser og plattformer. CSS åpner for skredersying av nettsidene, og kan gjøre hver side unik.

CSS filen kan bli brukt på flere sider samtidig for å gi dem et enhetlig utseende. Dette gjorde at man ikke lenger trengte å skrive inn de samme kodene i hvert dokument.

 

Historie

CSS først foreslått av Håkon Wium Lie oktober 10, 1994, og to år senere var CSS1 klar for lansering. Det var derimot flere problemer som ikke var blitt tatthånd om i CSS level 1 som medførte i at CSS2 ble laget november 4, 1997.

 

W3C

Mai 12.1998 ble CSS 2 publisert av World wide web consortium som den anbefalte standarden på nett. W3C er en organisasjon som ble startet samme året som css ble foreslått av Håkon Lie. Hovedmålet til denne organisasjonen var å utvikle protokoller og standarder for teknologien som brukes på World Wide Web (WWW).

 

CSS 2.1

Det var flere ting som kunne forbedres i CSS2 så det ble laget en ny versjon kalt CSS level 2 revision 1 ofte henvist som CSS 2.1. Denne versjonen fikset på mange små feil i CSS2 og tok bort dårlige støttede funksjoner.

Fra 2004 til 2011 ble CSS 2.1 flere ganger forvandlet for å holde seg opp til standarden til W3C. 7 Juni 2011 ble endelig CSS 2.1 publisert av W3C som en anbefalt style sheet.

 

CSS 3

I motsetning til CSS 2 som var en stor spesifikasjon som definerte forskjellige trekk til
dokumentet, så var CSS3 splittet om i flere separate dokumenter kalt moduler. Hver av disse modulene legger til nye egenskaper eller forbedrer egenskapene til CSS 2. Det var viktig å holde CSS 3 kompatibel med CSS 2 slik at alle nettsidene på nettet fortsatt kunne leses av nettleserne.

 

CSS 4

På grunn av at nye egenskaper ble nå laget i moduler var det ikke noen grunn lenger for å lage en integrert CSS4 spesifikasjon. Det finner derimot moduler som blir sett på som level 4 på grunn av deres nyskapende funksjoner.