Archive for september, 2012

Öppna intranät

september 28, 2012

http://www.havochvatten.se/.

Demo från Örebro kommun:

http://nyintra.orebro.se/intra/klickbarprototyp/index.html

Annonser

UX Patterns

september 26, 2012

http://patterntap.com/

http://developer.yahoo.com/ypatterns/

http://ui-patterns.com/

Experience Map

september 20, 2012

Adaptive Path skriver en artikel om Experience Maps

Design patterns – responive

september 13, 2012

Här en en superbra sida som visar med kodade wireframes vad som händer med olika grids och element när de krymper i bredd:

http://bradfrost.github.com/this-is-responsive/patterns.html

Bra slide om responsive

september 11, 2012

Bra tips om att man tex ska ha ”Tillbaka till toppen” knapp längst ned på mobila sidor. Att man ska se till att koda så att iphone plockar fram siffertangentbordet om det är siffror som ska fyllas i för ett inputfält. Eller att man ska tänka på att man designar för touch. Gör man en slider med bilder, visa en bit av nästa bild längst ut i kanten. Då ser man att det finns mer som man kan dra fram.

http://www.slideshare.net/bradfrostweb/beyond-media-queries-anatomy-of-an-adaptive-web-design

Responsive bilder

september 5, 2012

Kontext att förhålla sig till när man skapar responsive bilder:

  1. Bandbredd
  2. Dimensioner i spalter beroende på brytpunkter
  3. Upplösning
  4. Interaktion: Touch, mouse, keybord

Olika lösningar:

?? skriver om olika metoder att välja bland för att skapa responsive bilder.
http://dev.opera.com/articles/view/responsive-images-problem/

Adaptive images – kräver Apache, php och javascript

http://adaptive-images.com/

Bygger på extra .htc fil och php fil där man skriver in vilka media queries man efterfrågar. Kräver Apache, php och GD-lib (vanligtvis default med php). Och javascript naturligtvis…

Hur det funkar tekniskt:

  1. När användaren kommer in på sajten för första gången, så skapas en session och en javascript cookie sparas med besökarens screen resolution.
  2. Browsern letar igenom html sidan efter img taggar och skickar en request till servern för varje bild, tillsammans med info från cookien.
  3. Apache servern kikar i sin tur i htc filen för att se om det finns speciella instruktioner för img taggen.
  4. Htc filen talar i sin tur om att apache servern ska skicka iväg requesten till images-php filen för att formatera om bilden.
  5. Php filen tittar på vilken screen resolution som användaren har och kollar sedan vilka brytpunkter som har definierats för att ta den som passar bäst.
  6. Om bilden behöver skalas om, så kollar den först om en lämplig bild redan finns cachad. Annars så skalar den om bilden och cachar den.

Dessutom så fixar den också biffen om ingen cookie finns. Den skalar om ändå. Plus att man kan välja att servera bilden som en high DPI image för de devices som har Retina Display (enligt apple så många pixlar/inch så att människans öga inte kan uppfatta dem)

<picture> – element finns ej. förslag från commitee…

Finns en Responsive Image Group från W3C som rekommenderar använding av picture-taggen.


<picture alt="a picture of something">
<!-- Matches by default: -->
<source src="mobile.jpg" />
<source src="medium.jpg" media="min-width: 600px" />
<source src="fullsize.jpg" media="min-width: 900px" />
<img src="mobile.jpg" />
<!-- fallback for non-supporting browsers -->
</picture>

Nackdelar med <picture> är att det är mycket kod, kan inte kolla av bandbredd, inte framåtkompatibelt eftersom det krävs mycket vid en redesign. Du kan inte göra om bilderna ”automatiskt” utan måste göra handpålägg.

<meta> – ingen support ännu

<head>
<meta name='case' data='breakpoint1' media='min-width:350px' />
<meta name='case' data='breakpoint2' media='min-width:1000px' />
</head>
<body>
<img src='/content/images/{case}/photo.jpg' alt='' />
</body>

Fördelar med meta:
Inte så mkt kod, ingen css direkt i koden, head laddas innan body, lätt vid redesign,

Nackdelar med meta:

Kan inte användas vid minor breakpoint, eftersom tänkt vid major, svårt för browser företagen att implementera enligt artikel…

max-width:100%; – Flexibel bild


.content img{
max-width:100%;
}

Fördel att det alltid tar rätt bredd och skalar automatiskt vid fluid layot. Men tar inte hänsyn till bandbredd eller till att innehållet i bilden kanske hade behövts skäras om för minsta formatet.

data-src; – Flexibel bild

http://nicolasgallagher.com/responsive-images-using-css3/

<img src="image.jpg" alt="" data-src-600px="image-600px.jpg" data-src-800px="image-800px.jpg" />
And the related CSS:</code>

@media (min-device-width:600px) {
img[data-src-600px] {
content: attr(data-src-600px, url);
}
}

@media (min-device-width:800px) {
img[data-src-800px] {
content: attr(data-src-800px, url);
}
}

Nackdel med metoden är att man inte kikar efter pixel densitet, man laddar in flera bilder, tvingar användaren att skapa flera bilder – men det kanske är positivt…

jQuery

Formatera om bildsliders så att de blir responsive med jQuery plugins.

http://www.catswhocode.com/blog/tips-and-best-practices-to-develop-responsible-websites

Responsive webbdesign: Undvik fallgroparna

september 5, 2012

Översatt och sammanfattat från:
http://www.netmagazine.com/features/five-responsive-web-design-pitfalls-avoid

  1. Straffa inte användare för att de surfar med en annan device
    Dvs, tag inte bort content. De laddas ändå in om man gömmer det med CSS.
  2. Tänk på bandbredden
    Tydligen väger sidorna i Barack Obamas kampanj 4 MB per styck. Så se till att ta bort server side om det är tunga sidor. Användaren orkar inte vänta mer än högst 5 sek.
  3. Ignorera inte kontexten som en device sätter
    Kom ihåg att det är olika om användaren interagerar med mus eller via touch.
  4. Ge inte samma upplevelse för alla
    Glöm inte att det i mobilen finns gps-lokalisering, kan ringa direkt mm
  5. Designa inte efter device bredder
    Vi vet inte om browsern är lika stor som skärmen. När användaren hamnat på en sida via en länk från appar som facebook och twitter, så lägger de på en ram runt.
    Se istället till att brytpunkterna sker efter content, så designar du också för morgondagens devices.

WAI – area tillägg till HTML för att hjälpa funktionshindrade

september 1, 2012

Här finns en bra sammanfattning om vad WAI-area är för något (från 2008):

http://dev.opera.com/articles/view/introduction-to-wai-aria/

WAI-area har tagits fram för att hjälpa de teknologiska hjälpmedel som finns för funktionshindrade att tolka webben. Framförallt handlar det om att kunna stöjda ny teknik som används på webbplatser som AJAX (ladda in delar på webbplatser), beskriva roller av element och vilka states de har.

I HTML 4 kunde man enbart sätta tabindex på elementen; input, textarea, object, link, button, select och textfield. Här expanderar man så att man kan sätta tabindex på alla element med hjälp av wai area. Dock kan man också i HTML5 använda sig av tabindex på alla element…

Te x så ska stödjande verktyg kunnas tolka t e x sliders med hjälp av wai-area. Detta är ett role attribute som talar om vad elementet är: role=slider. Man kan också tala om vad värdet är just nu (area-valuenow), vad som är max (aria-valuemax) och minsta värdet (aria-valuemin).

Role kan också användas för att definiera olika ytor. Nu för tiden finns det ju i HTML 5 article, nav osv, men man kan tex tala om att här finns det banners: Role=banner. Tror i alla fall att screenreaders läser nämnda HTML 5 element…

Aria-live används för att tala om när olika delar av en sida uppdateras, te x för att  man hämtar nytt content från servern. Här kan man tala om det utan att fokus flyttar sig från där man är. Finns olika states att använda sig, men inte säker på hur de fungerar av det jag läste.

Webbläsare som stödjer wai aria är:

Opera 9,5+
FF 1,5+
IE 8 beta
Safari

Screenreader som stödjer:
JAWS 7.1 +
Windows Eyes 5,5 +
NDVA
Zoomtext 9+

A list apart skriver om samma ämne 2010:
http://www.alistapart.com/articles/the-accessibility-of-wai-aria/

”vi kan göra komplexa widgets – så som pulldown menyer, tabpaneler, hierarkisak träd och sliders accessibles genom att mappa elementen till roller, properties och states.”

Dock undrar man i artikeln om man kan använda sig av detta förbehållslöst?

Tex så har IE 7 ej stöd för detta. Sedan skriver de vidare att WCAG 2, i sin tur menar att om man använder sig av wai area så kan innehållet möjligtvis bli tillgängligt. Varför skriver de så då?

Bland annat för att matchning mellan skärmläsare och browser inte säkert stämmer överens. Man skriver i mer detalj i artikeln om varför sliders, tab panels osv är dåligt… Men det läser jag en annan gång och skriver om…:)

Statistik från W3C: http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

  • Firefox 1.5 and Firefox 2.0 partially supports WAI-ARIA, however it requires the use of namespaces, and doesn’t support the use of Liveregions.
  • Firefox 3+ contains better support for WAI-ARIA, including Liveregions.
  • IE8 partially supports WAI-ARIA.
  • JAWS 8 and Window-Eyes 5.5+ partially support WAI-ARIA.
  • Jaws 10+ supports WAI-ARIA.
  • FireVox, a self-voicing extension to Firefox, also supports WAI-ARIA via direct DOM access.
  • NVDA partially supports WAI-ARIA

    Något som är intressant är att Susanna Laurin från Funka.nu menar att man både kan använda sig av ajax och modala fönster för att både skärmläsare och browsers har blivit tillräckligt bra. Föreläsning om WCAG 2.0 av Susanna Laurin