Archive for the ‘responsive’ Category

Bra slideshare om att designa för touch

maj 23, 2014

 http://www.slideshare.net/shoobe01/30min-fingers-touchpeoples

Annonser

Design principer för animation

april 9, 2014

Här har författaren försökt skriva några övergripande principer för animation. Det finns inte så mycket skrivet om detta faktiskt…

 

http://www.beyondkinetic.com/motion-ui-design-principles

Poups och responsive

februari 16, 2014

Conditional loading behövs för att använda sig av popups på större skärmar.
Brad Frost om detta: http://bradfrostweb.com/blog/post/conditional-lightbox/

Länk leder till ny sida i mindre skärmar, pop ups i större
Man kan koda så att länken har sitt default beteende i en mindre skärm, dvs öppnar ny sida och att man i större skärmar öppnar upp samma innehåll i popup via ajax via conditional loading

Fäller ut i mindre skärmar och popup i större.
Samma som ovan, man scriptar olika.

 

Skärmavbild 2014-02-16 kl. 19.15.40

Designa för större skärmstorlekar

januari 27, 2014

Bra artikel – designa efter innehållet när man skalar upp  –  ska man läsa eller se bilder?
http://alistapart.com/article/surveying-the-big-screen

Också tänkvärd, men inte fulltäckande på något sätt
 http://webdesign.tutsplus.com/articles/general/life-beyond-960px-designing-for-large-screens/

 

Droppa bilder i browsern för att se hur de ser ut i olika devices

augusti 6, 2013

På den här smarta sajten kan man droppa bilder för att se hur de ser ut på olika devices. Det finns iOS och ett par Androids, sen lovar det att det ska komma flera så småningom

mockuphone.com/

 

Skärmavbild 2013-08-06 kl. 09.13.35

Ghostlab / Adobe Edge- testa sajter

augusti 5, 2013

Ghostlab
Har precis testat Ghostlab för första gången. Gick otroligt snabbt att installera och få igång. De devices som man vill testa på måste dock dela nätverk med datorn du använder dig av för att det ska funka. Nu orkade jag inte fixa WiFi på min iPhone för att connecta den…

Men hade föreställningen om att Ghostlab faktiskt hade virtuella devices som man kunde koppla upp sig mot och dela skärm med. Men så smaskigt var det tyvärr inte….

Adobe Edge Inspect CC
Adobe har också en produkt för detta, som heter Adobe Edge Inspect CC. Har dock inte testat den ännu…

http://html.adobe.com/edge/inspect/

Optimistisk interaktion = visa effekt av interaktion direkt.

augusti 5, 2013

Luke W har skrivit bra artikel om ”performing actions optimistically”, dvs tala om för användaren direkt att något har hänt, när hen interagerat med gränssnittet, OAVSETT om det har det eller inte.

Exempel:

Instagram ändrar sin ”like” knapp till ”liked” direkt. Man väntar alltså inte på att servern svarar. Om det skulle misslyckas på vägen så tar man itu med det då, istället för attha en delay mot gränssnittet.

Varför då? Jo, t e x så är svarstiden ibland dålig i mobila nätverk, därför bör man tala om för användaren att deras förfrågan är på väg att behandlas /har tagit effekt oavsett om den har utförts eller inte.

Ett annat exempel, som gått ett steg längre.

I en appen Polar så kan man skapa omröstningar (polls). Så fort man skapat en så sparas den lokalt och syns SOM OM den redan låg ute.  Under tiden så försöker appen skicka iväg den till servern och den försöker flera gånger innan den talar om att det inte lyckats. Det skulle vara intressant att få detaljer om hur länge den väntar i tid innan den talar om att nätet inte fungerar!

Brad Frost om Adaptive web design

april 4, 2013

Brad Frost pratar  på Smashing Conference 2012 i Freiburg om ”Beoynd Media Queries: An anatomy of an adaptive web experience.”

http://vimeo.com/55076713

Brad dissikerar ett exempel på mobile first responsive design.

Responsive design:
Fluid Grids, flexible media and media queries.
Men Brad tycker att det är ett problem att man har definierat det som en klarhet och blir fundamentalister. Bara det är responsive så blir det bra.

Responsive web design är bara ett subset av vad adaptive web design är. 

Men uttrycket har i sig en massa saker som är viktiga för att skapa en bra web. Te x content strategi.

Principer för att skapa Adaptive web design:

  • Ubiquity,
  • Flexiblitity
  • Performance
  • Enchancement
  • Future-friendly

Ubiquity: ”Vara närvarande överallt”
Vi har pc, mobiler, tablets idag och snart är det bilar, kylen osv… Vi vet inte vad som kommer sen. Därför är ubiquity internets superpower.
Flexibility:
Performance: 71% mobil users förväntar sig att mobile sites laddar lika fort om inte snabbar än på desktop.
74% mobile visitors lämnar en site om det. Men de flesta sidor i dag väger över 1 MB. 86% sites skickar samma content till mobiler som till desktop. Tänk på att sidorna inte ska vara för tunga! Under 5 sekunder att skicka iväg. Good performance is  good design.
Enchancements
– du behöver inte skicka all content till alla!.
Starta där du hittar den minsta gemensamma nämnaren för alla användare. Dra in kommentarer och relaterade bilder när de behövs och ladda inte in i onödan.
Future-friendly
Omfamna och acceptera att vi inte kan förutse vad framtiden bär med sig. Vänkta tills kunderna säger: Kylskåpet då?

Dissikera bit för bit:
Logo: Gör logon större säger kunderna. Om det är ngn bild som ska skickas upp i flera bilder är det logon.
Navigering: Där när man behöver den. Låt inte menyn äta upp hela ytan, te x lägga ut den på flera rader på mobilskärmen.
Search form:
Search är viktig. om du har en nav som är 5 nivåer djup, se till att du har search. Klicka på ”Serach # och popa ut en sökruta.
Product overview:
Visar produkt, vad den kostar och hur populär den är. 79% använder sig av telefonen för at bestämma sig om de ska ha produkten.
Product images:
Om man ska ha carousels – Tycker Yahoo är bra. Föregående + nästa och imellan så finns det antalet och vart du är. Zappos – visar hint av nästa bild. Men använder sig inte av enchancement. Vissa mobiler kan inte se den?
Kassa:
Ta upp rätt keybord, te x nummer för födelsedagar.
<input tupe=”number” pattern=”0-9*”/> (alltså keybord för att slå mobilnummer)
Social buttons: 
De är tunga. Tar 19 requests och 246, 7K. Tar inte med det per default, utan lägg istället in länkar. Prograessive enchancements.

Content:
Långa sidor på mobilen: Vi scrollar igenom en content typ i taget, tex en artikel.. Oftast blir det väldigt långt eftersom man staplar alla kolumner under varandra. Men hur vet då användaren att content finns där? Visar exempel på Obamas sajt, där man kan scrolla i all oändlighet. Visa istället användaren att det här finns om du är intresserad och de får själva ladda in om de är intresserade. Använd conditonal lodning, dvs progressive disclosure – hinta om att conent finns och ge det sedan till dem.”
Footer navigation. Krymp ihop.

Glöm inte att man på mobilen kan ringa direkt!. ”call tool” – <a href=”tel: 070…>ring</a>
Back to top link: Japp

 

 

Design patterns för e-handel – responsive + mobil

december 21, 2012

Smashing har skrivit artikel, med lite dumpar och ideer om design patterns för mobil e-handel.

Intressant är att 67% är mer benägna att handla via mobilen om man gör sajten anpassad för formatet.

http://uxdesign.smashingmagazine.com/2012/12/19/boost-your-mobile-e-commerce-sales-with-mobile-design-patterns/

Jeremy Keith: The Spirit of the Web

december 11, 2012

Jeremy pratar på Smashing Conferens 2012 om The Spirit of the Web.
Här finns videon på Vimeo.

Referat från föreläsningen:Har webben en själ?

Webben är routers, servers, inte ett cloud.  Men det vårt att förklara vad webben är. För vissa är det shopping och andra är det information.

”The web is agreement”.Vi kommer överens om att använda standarder, protokoll osv.

Men, filer, URL, HTTP…

POST är det viktigaste verbet. handlar om adda saker, deleting saker.
GET är inte delete.

Basecamp använde delete links. Men google accesselorator tool som folk hade installerat hämtade länkar i förväg och så plötsligt så deletades deras filer… Så helt fel att använda länkar för deletes. det är post.

Log out är inte heller länkar utan knappar!

GET – man hämtar filer. Mest html filer,css, javascript som vi hämtar. Vi pratar om webbsidor, webb app. Men de här sidorna kan presenteras på olika devices och vi vet inte vilken kapacitet, storlek, nätverkshastighet som betraktarna har. Webben handlar inte om att skaparna har kontroll, utan en massa saker vi inte vet. Förr bestämde vi att alla sajter skulle vara 640*480, sen 800*600 och därefter 1024*768…
Kontroll är inte en del av webbens själ!

Läs ”A Dao of Web Design” av John Allsopp som han skrev för 12 år sedan på A List Apart. Handlar om att acceptera att vi inte vet hastighet, skärmstorlekar och att vi inte har kontroll som designers och utvecklare.

Photoshop – innan du ens har börjat så måste du ange storlek. Så innan du ens kommit igång så kräver verktygen att du ska vara i kontroll. CMS gör också antaganden av hur content ska vara och se ut.

Style Tiles – använd inte layout och inte bestämd storlek. Börja med de individuella bitarna som ska skapa sajten, som byggstenar. Som ett mood board. Jeremy visar upp ett bibliotek med html/css element.

Börja med content istället för skapa ett ramverka att hälla i content i. Börja inifrån och ut med responsive design. Det betyder inte att man ger upp kvalitet för att man ger upp kvalitet. Responsive är mer en konversation mellan användare och content.
”My website will meet you wherever you are”

”Fluid is in the spirit of the web” – jeremy visar den första webbsidan som gjordes i olika skärmstorlekar.. (bara text förstås.)

Keeping a website responsive. Progressive enchancement, starta med det lägsta och ge nya devices allt det där som de klarar av i olika lager. Byggstenarna är strukturer, beteende och presentation. Tex vid javascript – fråga webbrowsern om den förstår geolocation och om den klarar det så bygger vi vidare på det. Progressive enchancement är att  webbsidor behöver inte se likadana ut i varje browser. Då accepterar man att man inte längre har kontrollen. Testa istället om det fungerar.
Men du kan inte testa på alla devices… Jeremy köpte en massa och de låg bara där, så han skrev på Twitter att de var fria att använda. Inom 24 -4 8 h så hade massa andra kommit över med deras devices till hans labb i Brighton. Share är just vad som är internets spirit. GitHub är absolut sharing, där du kan ta upp ngn annans arbete och använda det.

Responsive images. Vi började med hacks och workarounds, men det funkar inte i längden, därför behöver vi en standard (Srcset) eller filtypernas format (JPEG2000) ska vara responsive i sig. Men just nu måste vi använda oss av hacks och javascript.De flesta hacksen följer dessa regler – börja med den lilla formatet och ladda sedan ned det stora om det behövs. Men vi vill ju inte ladda ner båda båda två. Men tänk så här:

I CSS kan du säga att den lilla bilden ska skalas upp till en större bild, men du kan via javascript sedan byta ut bilden till det stora. För användarens är upplevelsen bra även om man laddar ner två. För de får ju snabbt upp en bild, om än den först ser lite hackig ut innan den byts ut mot den nya som laddats ner. Kommer ni ihåg lowsrc? Visade en mindre filstorlek medan man laddade ned den större bilden. Det är samma sak här, som när vi inte hade höghastighets internet.
Jeremy lägger inte ned energi på att göra olika bilder, utan på att göra filstorleken på bildstorleken mindre istället. Använder ”content-is-first” metod. Vad är viktigast i bilden? Ansiktet? Ok, då kan du göra det andra mer blurrigt och spara på kb. Förr i tiden hade vi ett mål på 100 Kb per, men nu är vi uppe på 1 mB istället. Vi har alltså samma problem nu med responsive som förr då vi hade sämre hastighet på nätet. Det värsta som finns är när ngt är slött och tar lång tid att ladda ner – performance!

Steve Sauders.

Conditional loading for files. Vilka MÅSTE vara med i på webbsidan? Lägg sedan till saker. Jeremy lägger till mer grafiska element med javascript. Te x video att titta på. Reducera antalet http requests.  Tänk inte att ni måste ha med Bootstrap, jQuery osv. Vänta tills ni har problemen! För CSS finns det massor av ideer för att minska storlek request te x; CSS Sprites, base-64 encoding, gradients, rounded corners. Det här är varför man pratar om MOBILE first

Glömt inte att URL är delar av hur man hittar fram till dokumentet, dvs filstrukturen och vad sökvägen har döpts till. Ex: /things/add/
URLer är definitiv internets själ.