Kategoriarkiv: JavaScript

@media 2010

VN:F [1.6.9_936]
Betyg: +1 (1 röst)

2 dagar av @media 2010 London avverkade

Här följer en lista på några av de presentationer jag följde.

  1. Ganska tekniktung start med Brendan Eich, @BrendanEich grundare av JavaScript, läser man Twitterflödet #wdx så var jag tydligen inte ensam om att tycka det.
  2. Doug Schepers (@shepazu, med konferensens i särklass största pollisonger) om ”SVG today & tomorrow”, inspirerande och underhållande.
  3. Rachel Andrew (@rachelandrew) om css3. Ganska basic dragning om webbläsarstöd och grundläggande ”How To”, dock bra driv i dragningen och tydligt att hon har koll på sitt område. Givande när hon kom in på w3c standard och de olika stadier som en ny teknik (css3) går igenom innan den når ”rekommenderad” status. Här finns material från presentationen
  4. Simon Willison (@simonw) om ”Building Crowdsourcing application”, mycket insprerande om ”Crowdsourcing” och hur vi enkelt kan använda redan existerande tekniker som sociala medier google docs, etc. Ger några exempel från sin egen verksamhet på The Guardian men också på hur det kan fungera i allvarliga situationer som jordbävningen på Haiti
  5. Marc Boulton (@markboulton) i mitt tycke den bästa av dagens dragningar om ”Designing grid systems”. Historsikt perspektiv på det 2000-åriga arv formgivare bär med sig i ryggsäcken jmf den nya miljön som skärmrepresentation innebär. Trycker på vikten av ett synsätt på design som utgår från innehållet och bygger utåt, inte en begränsande kanvas. Refererar till Ethan Marcotte artikel i A List Apart Responsive web Design som en av de senaste årens ”must read”.
  6. Dagen avslutas med en panelutfrågning bestående av Jeremy Keith (@adactio) med fyra bisittare. Berör områden som, vad en designer är, hur bemöta krav från kund om IE6 stöd, samt bla. html5 och vad det är och inte är, med referenser till tidigare års hype runt web 2.0 och Ajax.  Jag avrundar med två av de bättre citaten från dagen, en definition på vad html5 är:Simon Willison: ”AJAX means it uses Javascript, HTML5 means it’s not Flash”.Jeremy Keith: ”HTML5 means it doesn’t work in IE6

Dag två startade med en riktigt bra och engagerande dragning av Andy Clarke (@Malarkey) om hur vi inte bör låta oss begränsas av inte fullt så avancerade webbläsare utan designa för de mest kapabla och sedan hantera de andra. Om hur vi kan hantera IE6 med hjälp av universiellt css, helt enkelt strippa ie6 från all avancerad form. Måste tillstå att tanken är lockande, läs Andys resonemang här. Detta följdes upp av Remy Sharp (@rem) om html5 javascript APIS, mycket demos på vad som är möjligt att göra.

För den som vill läsa ett något mer strukturerat inlägg om @media 2010 så har Peter Gasston gjort en mycket bra sammanfattning

/johan liw

Käpphästar är till för att veva med…

VN:F [1.6.9_936]
Betyg: +9 (9 röster)

…så nu tar vi ett par varv ”Progressive Enhancement” igen.

För ett par veckor sedan skrev Mathias ett inlägg om css 3 och hur den standarden kan komma att påverka webben. Om vi lyfter diskussionen något från det rent tekniska till att handla om hur vi hanterar marknadens olika webbläsare och hur de renderar sidor på olika sätt hamnar vi snart i diskussioner som rör s.k. Progressive Enhancement (PE).

Vad är då Progressive Enhancement?

(fritt översatt från wikipedia)

  • Innehålllet skall vara tillgängligt för alla webbläsare
  • Grundläggande funktioner skall vara tillgängligt för alla webbläsare
  • Strikt, semantisk html är bäraren av allt relevant innehåll
  • Formgivning sker genom externt CSS dokument
  • Avancerad/utökad funktionalitet sker genom diskret, externt länkad JavaScript, webplatsen måste gå att använda utan JS.
  • Respektera skillnaderna i besökarnas olika webbläsare

Vad får det för betydelse i vårt dagliga arbete?

I teorin betyder det att man startar med en enkel, semantiskt korrekt HTML som rymmer allt väsentligt innehåll (se bild 1). På detta lägger man sedan ett lager design i form av CSS för att sedan avsluta med ett yttre lager funktionalitet/upplevelse i form av JavaScript. Vi strävar efter att alla ska få en tillfredsställande upplevelse vid besöket, besökare med mindre avancerade webbläsare möts av en enklare, men fullt användbar, webbplats medan besökare med mer kapabla webbläsare får både ”pukor och trumpeter”.

m-m

(Bild 1, lånad från den utmärkta artikeln Understanding Progressive Enhancement av Aaron Gustafson)

I praktiken så fungerar det tyvärr inte riktigt på detta sätt. Vi levererar idag nästan alltid all ”extra” upplevelse till majoriteten av alla webbläsare även till de webbläsare som inte förstår implementeringen (läs IE 6-7). Vad som händer är att vi initialt har ambitionen att arbeta med PE men när det kommer till kritan och vi står där och ska testa i mindre kapabla webbläsare arbetar vi in ”pukorna och trumpeterna” även i dessa med hjälp av extra HTML/CSS och avancerade JavaScript trix, detta tillintetgör hela idén med PE

Hur vi bör göra

Inställningen till det visuella ögongodiset bör ses som en typ av belöning till de webbläsare som stödjer den avancerade kod som gör det möjligt snarare än något som saknas eller inte fungerar i de webbläsare som inte ännu är riktigt är med i matchen.
Häri ligger mycket av förändringen i inställningen, en design är inte felaktig för att den ser annorlunda ut i IE7 och vi har inte varit slöa då vi inte levererat en pixelperfekt lösning i alla webbläsare. Vi belönar, visuellt, användare med mer kapabla webbläsare, medan besökare med mindre kapabla webbläsare får en fullt användbar webbplats med lite mindre ögongodis.
Jämför tex. bild 2 och bild 3 här nedan. Bild 2 är hur Twitter ser ut i Internet Explorer 7, notera de kantiga hörnen på boxar etc. Jmf. sedan med Bild 3, Twitter i Safari. Nu kanske man ska akta sig för att uppskatta tidsåtgången för att implementera alla de runda hörn som finns på Twitter (Safari) så att de fungerar även i IE 7, men jag gör det ändå. Min uppskattning är att man enbart på dessa detaljer spar minst en arbetsdag css/html.

twitter-ie7

Bild 2: Twitter i Internet Explorer 7 utan runda hörn

twitter-safari

Bild 3: Twitter i Safar, med runda hörn

Förutom det lilla räkneexemplet ovan, ger Progressive Enhancement:

  • En mer robust sida: snarare än att använda ”Graceful Degradetion” där man först skapar en fullt fungerande sida för avancerade webbläsare och sedan arbeta sig bakåt och fixa sidan för mindre kapabla webbläsare fokuserar man på att först skapa en solid grundsida som fungerar överallt.
  • Mer nöjda användare: Starta med att se till att alla får en fullt fungerande bas, besökare med mindre kapabla webbläsare, mobila enheter eller enheter för speciella behov blir nöjda för de får rena, snabba, fullt fungerande sidor. Besökare med mer kapabla webbläsare får ovanstående samt även ett mer polerat, upplevelseorienterat besök.
  • Reducerad utvecklingstid: Man behöver inte lägga tid på att få allt identiskt i alla webbläsare.
  • Reducerad underhållstid: Om en ny webbläsare släpps eller en ny teknik lanseras är det enkelt att lägga till denna utan att behöva justera och eventuellt förstöra befintlig kod.
  • Längre hållbarhet: Kunden får en webbplats som håller sig fräsch längre, när besökaren uppdaterar sin webbläsare och återkommer till sidan så möts hon/han ev. av ett uppdaterat gränssnitt utan att vi behövt göra något, det finns ju redan där från början bara det att besökaren inte sett det.
  • Sist men inte minst: Vi sprider lite glans över oss själva då vi visar att vi ligger i framkant när det gäller front end design.

Nu får det vara slutvevat för denna gång. Här nedan har jag samlat några länkar för den som vill läsa mer i ämnet. För dig som inte riktigt känner att du vill/orkar läsa mer om detta vill jag starkt rekommendera denna sammanfattning: Do websites need to look exactly the same in every browser?

Läs vidare »