Öredev 2011 har passerat oss på sin väg in i historiens dimmor.
Med lite tur har den gett mig lite ökad intellektuell massa.
Får hoppas det, för från hälsoperspektivet har den antagligen också gett mig ökad massa, ett inte lika önskvärt tillskott.
Tallriksmodellen à la Öredev:
God mat: 100, Kaffe: 100, Te: 100, Läsk: 100, Bullar: 100, Smågodis: 100, Motion: 0.
Javascript
Jag inriktade mig lite på Javascript. Och det var roligt att hur hela js-världen närmar sig den vanliga programmeringskulturen och anammar goda förebilder, som TDD och Clean Code i allmänhet.
Några punkter att fundera över:
Vilka dom-ramverk (jquery, yui etc) ska vi använda?
Vilka mvc-ramverk (sproutcore, angular, backbone m.fl.) ska vi använda?
Hur modulariserar vi våra javascript så att det blir logisk och lättunderhållet?
Vilka testramverk (js-test-driver m.fl.) ska vi använda?
I vilka lägen är det motiverat att skriva test- eller beteendedrivet?
Hur lär vi oss att skriva bättre js-kod?
Hur packar vi ihop våra javascript så att det blir få anrop och korta laddtider?
Hur ser vi till att den ökande mängden javascript inte ger upphov till säkerhetshål?
Med mera…
Agilt
De agila föreläsningarna jag var på gav mig också en del tankar.
Flera av dem pekade på risken att falla tillbaka i icke-agila metoder fast man formellt följer en agil metodik. Dan North gav en ganska trovärdig förklaring i sin keynote “Embracing Uncertainty – the Hardest Pattern of All”.
Han menar att vi avskyr osäkerhet att vi hellre utfärdar en helt felaktig prognos än lever i ovisshet. Därav kommer krav på processer och rapporter (som den här) och med det ökar oflexibiliteten och det produktiva arbetet minskar.
Det passar ganska väl in i herr Norths fredagsdragning “Patterns of Effective Deivery” där han pekade på tendensen att plocka tillbaka delar av vattenfallmetoden, med dess delvis illusoriska förutsägbarhet och framför allt en klar blame-chain.
Om du hamnar i en process med en tveksam prognos känns det bättre att ha en klar roll- och ansvarsfördelning så det syns vems fel det var…
UX
Slutligen var användarupplevelsen ett tema på Öredev.
Många pekade på hur viktigt det är att ha med användarupplevelsen från början av projekten.
Och en viktig poäng är att det inte räcker att lyssna på användaren.
Du måste bestämma dig vilka dina användare är och hur du vill att din sajt ska fungera. Det går inte att alltid lyssna på användare för då kan de förstöra din sajt.
Fundera på hur du vill att användaren ska agera och umuntra det i design och gränssnitt.
Fundera sedan på hur du INTE vill att dina användare ska agera och motarbeta detta.
Tänk också på att användaren ibland säger att de vill ha en sak men i själva verket gör en annan.
Men framför allt: Respektera dina användare och se till att de enkelt och utan irritation kan göra det du har lovat dem.
