Shortcut

Fra motorrommet til App Store

2010-11-09T08:38:39Z

I 3 hektiske sommermåneder i 2010 lagde Shortcut en iPhone app for DEFA. I denne artikkelen belyser jeg noen erfaringer som kan være nyttig for andre som går med en app i magen. Bli med behind the scenes under utviklingen av DEFA app-en!

Det er nå engang slik at de fleste menn har et visst begrep om hva DEFA driver med; det er fordi at DEFA har lange tradisjoner med å forsyne bilmarkedet verden over med tilleggsprodukter til bil, slik som bilalarmer, sporere (trackere), motorvarmere og kupévarmere. Hos DEFA er en kald vinter en god vinter.

Shortcut ble kontaktet av DEFA i slutten av april 2010 med en briljant idé: DEFA ønsket å lage en app som kunne:

Motta bilalarmer som pushmeldinger
Gi brukeren full kontroll over motoroppvarmingen
Fortelle brukeren hvor bilen til enhver tid befinner seg

Vi mente da – som vi gjør nå – at en app med nevnte funksjonalitet vil kunne øke bruksverdien av DEFAs bilprodukter dramatisk. Målet var at denne iPhone app-en skulle representere akkurat det intuitive brukergrensesnittet som DEFAs bilprodukter fortjener.

4 måneder til deadline!

Den opplagte arenaen for å vise frem en slik nyhet for automotive-industrien var Automechanika 2010, en messe som ble avholdt i Frankfurt i september. Da startskuddet for utviklingen av DEFA app-en gikk, var denne messen følgelig fattige 4 måneder unna.

Heldigvis hadde DEFA gjort mye godt fotarbeid før vi ble kontaktet. De mest fremtredende skjermbildene i app-en var stort sett ferdig designet. Nå gjenstod å vekke skjermbildene til liv ved å forestå navigering mellom skjermbildene, legge inn kommunikasjon med DEFA sine servere, og håndtere alle tilstandene man kan komme opp, eksempelvis med ustabilt nettverk.

Mai ble preget av hektisk møtevirksomhet. Det gjaldt for DEFA å få formidlet hvorledes man ønsket at brukeropplevelsen skulle være, og hvilke prioriteringer man la til grunn. Det gjaldt for Shortcut å få bidra med sin kompetanse innen interaksjonsdesign. En (multi)touch plattform er noe ganske annet en web.

Etter noen innledende avklaringsmøter hvor de involverte fikk snakket med hverandre, sett hverandre i hvitøyet og ledd litt sammen, sendte DEFA over Photoshop-filer til våre utviklere. Jobben med å ta det grafiske uttrykket fra tegnebrettet til XCode kunne begynne.

Shortcut ønsker svært gjerne å være ansvarlig for utformingen av design og brukeropplevelse, men slik ble det ikke i dette prosjektet, Work hadde allerede gjort den før/for oss.

(Quite) a Few Good Men

Siden man aldri må snakke om problemer, så ble det en utfordring at team-medlemmene var spredt over halve Norge. DEFA hadde en prosjektleder for GUI i Sandvika, Shortcut hadde sine folk og lokaler i Oslo sentrum, DEFAs API-utviklere befant seg i Trondheim og DEFAs egen merkevarebygger, Work AS, holdt til på Majorstua i Oslo. I tillegg satt DEFAs to produktsjefer (for hhv. WarmUp og Security også i Sandvika) I et slikt landskap blir kommunikasjon et probl- jeg mener en utfordring. Basecamp to the rescue!

Basecamp

E-post er et aldeles glitrende kommunikasjonsmiddel…når 2 mennesker skal kommunisere med hverandre. I et prosjekt med et halvt dusin mennesker er e-post uegnet. Dette først og fremst fordi man risikerer at informasjon og ressursfiler fortapes i innboksen til team-medlemmer. Her er noen flere grunner til å se etter andre kommunikasjonsformer:

E-postkommunikasjon støtter ikke tråder (eller gjør det i beste fall dårlig). Dette gjør at meldingene kan stå uten en kontekst som vil hjelpe leseren til å gi den mening.
Det er krevende for prosjektleder og andre å vite hvilke ~~problemer~~ utfordringer øvrige team-medlemmer befatter seg med,
Etterhvert som prosjektet skrider frem, blir det vanskelig å vite hvilken grad av gyldighet historiske e-poster med respektive vedlegg har.
E-post gjør prosjektet sårbart fordi backtracking grunnet uforutsett fravær blir vrient … og i noen tilfeller ulovlig.

Veien, lyset og livet er et prosjektstyringsverktøy. I DEFA-prosjektet benyttet vi det web-basert verktøyet Basecamp, som med fokus på kommunikasjon mellom mennesker står i skarp kontrast til eksempelvis Microsoft Projects.

Less is more!

Det er ofte fristende å tilby brukeren av app-en informasjon og funksjonalitet fordi vi kan. Det er fort gjort å glemme å spørre seg “-kan dette skrelles bort, i brukervennlighetens navn?” Et eksempel fra DEFA-prosjektet var årsaken til en bilalarm: Det er nemlig slik at opphavet til en bilalarm kan stamme fra en glassknusesensor, et akselerometer, en dørsensor eller en bevegelsessensor. Dette kan vi vise brukeren. Men er det interessant? Konklusjonen vi kom til er at det ikke er verken interessant eller relevant, og i DEFA app-en velger vi istedet å fokusere på kjernefunksjonaliteten.

Automechanika med et skrik

Gjennom sommermånedene jobbet vi mye fra våre respektive arbeidsplasser, noe som fungerte bra ettersom vi;

hadde hatt tilstrekkelig face-time den første tiden av prosjektet
alle brukte Basecamp flittig

App-en ble bygget stein for stein, og alle de features vi ønsket oss i beta-versjonen (Automechanika-versjonen), ble klare.

Veien videre

Det skal bli spennende å se hvordan app-en vil bli mottatt når den blir kommersielt tilgjengelig i Appstore en eller annen gang i 2011. For å snakke for meg selv så havner denne høyt oppe på “må ha det, bare må ha det”-listen. For meg handler det om kontroll: Tenk å kunne ligge i sengen og få bekreftet at bilen står der den burde stå. Og tenk å kunne justere tidspunktet for når bilen skal være varm dagen etterpå. Og tenk å vite at dersom en skurk stikker av med bilen min – så får jeg push melding om det! Fantastisk! ...Selv om sistnevnte opplevelse kanskje ikke er fullt så fantastisk.

Les mer her

Med bilen i lomma

2010-10-14T10:55:05Z

På Automechanika-messen i Frankfurt i September presenterte den norske industrikjempen DEFA den nye iPhone-appen DEFA Link.

DEFA Link skal lanseres i 2011 og er DEFAs første satsing på bruk av smarttelefoner til å fjernstyre forskjellige komponenter i DEFAs bilalarmer, bilvarme og sporingssystemer.

Ide, konsept og brukgergrensesnitt er utviklet av WORK og DEFA. Shortcut har bidratt med programmering og gjennomføring av selve iPhone-appen.

Bilalarm

Fra iPhone-appen kan man kontrollere bilalarmen, og man kan til og med motta varsling i tilfelle innbrudd eller dersom bilen blir stjålet.

Bilvarme

Motor- og kupévarme kan settes opp på lik måte som man bruker vekkeklokkefunksjonaliteten på iPhone. For eksempel kan man stille inn slik at bilen (både motor og kupé) er varmet opp til kl 7 på hverdager og kl 9 på helgedager.

Sporingssystemer

Hvis man er usikker på hvor man har parkert bilen, eller om bilen har blitt tauet vekk eller stjålet, kan man bruke sporingssystemet for å få opp et kart der man kan se hvor bilen befinner seg.

Infopanel

På appens infopanel kan man lese av ute- og innetemperatur rundt bilen, sjekke om man har husket å plugge inn strømkabel for bilvarme, og lese av batterispenning.

Les mer om konseptet på DEFAs websider

Trafikanten på iPhone setter spor

2010-05-04T10:15:01Z

Trafikanten på iPhone genererer nesten like mange oppslag mot sanntidssystemet til Trafikanten som alle andre plattformer til sammen.

Trafikanten Labs har offentliggjort trafikktall for sanntidsoppslag som bekrefter noe vi lenge har trodd, nemlig at Trafikanten på iPhone ikke bare er en applikasjon som er lastet ned av svært mange brukere, men at det også er en applikasjon som brukes av svært mange brukere.

Av alle oppslag som gjøres mot sanntidssystemet til Trafikanten utgjør oppslag fra Trafikanten på iPhone 47 prosent av trafikken. Vi snakker her ikke om iPhone-applikasjonen i forhold til andre mobilplattformer, men iPhone-applikasjonen i forhold til andre mobilplattformer, mobilsidene til Trafikanten og nettsidene til Trafikanten til sammen.

Trafikanten på iPhone var Shortcuts første iPhone-applikasjon, og den ble til fordi den var noe av det vi selv ønsket oss aller mest da vi fikk hver vår iPhone. Vi gleder oss over at så mange har nytte av appen, og gratulerer Trafikanten med en knallsuksess!

Shortcut flytter

2010-03-01T09:57:56Z

Idag har vi flyttet fra Rådhusgaten. Våre nye lokaler ligger i Nedre Slottsgate 13. Ovenfor Steen & Strøm. Rett ved Karl Johan.

Etter to hyggelige år med vekst i Rådhusgaten, trengte vi større plass. Og nå har vi endelig funnet det nye Shortcut HQ. Fra idag sitter vi i Nedre Slottsgate 13.

Vi sees!

Er all iPhone-oppmerksomhet god oppmerksomhet?

2010-09-08T10:29:28Z

Flere av de dyktigste, norske iPhone-utviklerne møttes tirsdag forrige uke for å snakke om det de gjør best. Men i tillegg til å snakke om seg selv, nevnte flere den fallgruven som finnes når man lager dårlige apper. En ren reklame-app. Og flere eksempler ble vist. Det ble sagt at en slik app virker mot sin hensikt, og ødelegger for merkevaren. Stemmer det?

Jeg holdt et innlegg på Scandinavian Futures 2010 i januar. Der snakket jeg litt generelt om iPhone og nevnte (som jeg alltid gjør) at det finnes to typer apper: Time Killers (underholdning) og Time Savers (nyttige). Men denne gangen nevnte jeg også en tredje type applikasjon, som jeg valgte å kalle Ad-Apps. Appvertising er et annet begrep som brukes.

Killers and Savers
Jeg ønsket å gjøre oppmerksom på forskjellen på kvalitets-apper og billige reklame-apper. Dette behovet kom kanskje fra at det stod feilaktig i Scandinavian Futures-programmet at Shortcut og jeg hadde laget iDeli-appen. Det har vi ikke gjort.

Riktignok var vi i dialog om den for en god stund siden, men vi var for ambisiøse på hva en slik app burde være. Og følgelig ble vi for dyre. For å illustrere hva jeg opplever som «ikke godt nok» med Ad Apps viste jeg også noen skjermbilder. bla. fra iDeli:

Deli de Luca har en flott logo, som gjør seg godt som app-ikon. Men utformingen og funksjonaliteten videre er ikke like heldig. Hovedfunksjonaliteten i appen er bonger. Bongen jeg har fått her er «Vis i kassen og få en kaffe, te, kakao e.l. for kun kr 5,-» Bongen gjelder én gang. En uke senere kan man få en ny bong. Idet bongen brukes, og man går videre blir man presentert et reklame-board. Jeg ble eksponert for et gutteblad og et jenteblad som selges på Deli de Luca.

Verken nyttig eller underholdende
Jeg har hørt at denne appen er en suksess som Deli er fornøyd med. Men personlig har jeg vanskelig for å tro at folk vil benytte skrivebordsplass på iPhonen sin til dette. Og enda mindre at man husker eller gidder å dra opp disse app-bongene i lengden. Men kanskje er det slik at alt som skjer på iPhone idag er spennende og gøy. Uansett. Og det føles kanskje kult å flashe iPhonen sin i kassa? Men nyttig er den ikke, og heller ikke særlig underholdende.

For ett år siden skrev jeg en artikkel om reklame på iPhone, etter å ha vært på Westerdals reklameskole og snakket om apper. Det jeg lærte av reklamestudentene var at de ønsket å lage funksjonelle, nyttige apper. Ikke dårlige. Det kunne virke som om de var like kravstore som når de tenker ut den nyeste, mest spennende, innovative måten å formidle et (salgs-)budskap. De ville gi iPhone-brukeren den samme kvaliteten. Designet skulle være godt, men opplevelsen og funksjonaliteten var helt avgjørende for om appen var verd å produsere.

Mot sin hensikt!
På iPhone i Norge-seminaret forrige uke ble det gjentatt flere ganger hvor galt det kan være å lage en dårlig applikasjon. Mange ønsker å lage iPhone-apper for å «være på» enda en kommunikasjonsflate. Og det er klart det er gøy å sette firmalogoen sin inn i et applikasjonsikon. Og enda mer tilfredsstillende å se selskapet i iTunes Store senere. Men ikke glem at det ikke stopper der.

Brukerne som laster ned og installerer din applikasjon forventer å ha glede av appen. Ikke bare én gang, men igjen og igjen. Og iPhone-brukere er flinke til å kjenne igjen halvveis-produkter. De ser når det er tatt dårlige, billige beslutninger på bekostning av funksjonalitet og brukeropplevelse. De oppfatter at appen ikke lever opp til merkevaren, men tvert imot trekker den ned. Og da er det vel bedre å la være?

Velg kvalitet (eller la være)!
Idag hørte jeg på nyhetene at Odd Reitan kan love oss billigere mat. Dette takket være egenproduksjonen dagligvarehandelen har begynt med, som First Price ol. Det er trist at vi ønsker å konkurrere på pris. Jeg skulle virkelig ønske at Reitan heller kunne love oss bedre kvalitet og bredere utvalg. Kommet med noe nytt. Overasket oss.

Hvis du er stolt av produktet til selskapet ditt, stolt av hva dere får til, stolt av kundetilfredsheten, stolt av kvaliteten, ikke begynn å kompromisse på iPhone. Det merkes. Har ikke ditt selskap anledning til å levere noe fullgodt til iPhone, kan det virkelig være bedre å vente med det prosjektet. Bruk heller tiden og kreftene på å tenke ut hvor fantastisk appen skal bli når den først kommer. All PR er kanskje god PR, men alle brukeropplevelser er ikke gode opplevelser. Og noen bør vi være foruten.

Når du lager en app, spør deg selv:
• Kommer jeg til å bruke denne appen? • Ønsker jeg meg dette? • Kommer jeg til å stolt vise den frem? • Er denne appen awesome? Hvis svaret er nei på ubehagelig mange av de spørsmålene, bør du kanskje revurdere innholdet i appen?

iPhone i Norge

2010-01-20T14:05:24Z

Det er halvannet år siden iPhone kom til Norge og App Store ble lansert. På tide med et seminar.

Idag finnes det ikke noe samlende fagmiljø for iPhone-utviklere i Norge. Vi i Shortcut tror det er uheldig, både for oss utviklere og for kvaliteten på appene som lages. Derfor har vi tatt initiativet til «iPhone i Norge», et seminar om den norske iPhone-bransjens erfaringer så langt. Og vi har vært så heldige å få med oss noen av de dyktigste iPhone-utviklerne i Norge.

Seminaret holdes tirsdag 9. februar, 09:00-12:00 på The Mini Bottle Gallery (Kirkegata 10, 0152).

Se program og meld deg på her: «iPhone i Norge»

Ikoner - Én for alle, alle for én

2010-09-10T12:57:34Z

For et halvannet år siden var jeg overbevist om at det var i nettleseren softwareutvikling kom til å være mest spennende. Googles og 37Signals’ produkter var allerede noe jeg var avhengig av. Og jeg ønsket sterkt å være med å lage slike webapplikasjoner. Enda mer ønsket jeg å tegne ikonene deres.

Å tegne et ikon er vanskelig og tidkrevende, og ofte resulterer det i mange ideer og skisser som hadde passet perfekt til en større samling. En ikon-suite. Ihvertfall har det vært min erfaring. Og det er klart, lager man en spesiell effekt, boks eller manér på et ikon, kan det lett overføres til flere. Og vips, er man mer produktiv og ideene kommer tydeligere frem.

I Shortcut hadde vi noen gode, noen løse og noen enkle konsepter til webapplikasjoner sommeren 2008. Mye halvferdig hobbyprosjekter som aldri så dagens lys. Og det er sikkert like greit. Men blant disse app-ideene, fant jeg nylig skisser på ikoner vi kanskje skulle jobbe videre med. Jeg tenkte da at alt kunne formes om til en kube, og at innenfor en slik klossete ramme ville den visuelle sammenhengen bli tydelig nok. Her er de skissene:

Jeg skal ikke si så mye om disse ikonene. Ikke annet enn at bussen øverst i midten, har i ettertid blitt til Trafikanten-ikonet på vår iPhone-applikasjon. På den tiden hadde vi en alternativ reiseplanlegger til Trafikanten.no. En annen ting som er artig for meg, er at jeg har fått levd ut kubedrømmen med logoen til vår eksisterende web-applikasjon Gitorious.

Den mest kjente ikon-suiten idag, og gjennom tidene, er vel Microsoft Office-ikonene:

De har endret seg mye gjennom tidene, men noen nøkkelelementer har blitt værende: W-en i Word, kakediagrammet i PowerPoint, Access-nøkkelen osv. Og kanskje enda viktigere, de har beholdt fargene sine. Word er blått. Adobe har ikke vært like standhaftig med sine ikoner:

Her er de siste ti årenes utvikling. Fra de gode gamle foto-/kunstlignende ikonene, innom de svevende gladhippie-illustrasjonene til deres Det Periodiske system-inspirerte ikoner av idag. Det eneste de har klart å holde på gjennom utviklingen er fargepaletten. Nesten. Men Adobe har vært flinke til å lage ikoner som henger veldig godt sammen i en pakke, hver gang. De samme rammene, effektene, fargeintensiteten og detaljnivå. Vi ser at de hører sammen. (Det florerer også med hjemmelagde, flotte alternativer – 35 Best Adobe Doc Icons set for Designers – og det er kanskje ikke rart, Adobe-suiten er jo design-suiten.)

Design-giganten Apple, tar lettere på den enhetlige oppgaven, kan det virke som:

Deres «Office»-pakke iWork, ser noe sprikende ut. Og det samme er det med iLife-pakken, ingen rød tråd verken i navn, farge, ramme eller substans. For selv om de er fine sånn som de ser ut, ville det ikke kostet mye å legge på en bakgrunnsfarge eller lignende. Så ville vi skjønt at det var iWork, og de kunne enkelt levere nye produkter til deres suite. Se bare på hvordan 37Signals har fikset det:

Enkelt og greit. Ikonene inni ligner ikke, men med denne landskaps-glasskulen, kan de ikke misforstås. De er 37Signals. Og dette er jo flotte webapplikasjoner, og de som inspirerte meg i utgangspunktet til mine skisser vi så på. Men idag er det kanskje iPhone-ikoner som opptar meg mest. Og også på iPhone finnes det noen gode suiter med lekre ikoner. Finest er kanskje Tapbots sine:

Se så søte roboter! Dette er flotte greier, og designet inni applikasjonene er minst like fint. Verdt å ta en titt på. En mye enklere løsning, men like fungerende og tydelig, er å velge et par filtere og kjøre symboler gjennom det. Slik App Cubby har gjort:

Her er det nok ikke vanskelig å utvide med flere ikoner. Og det er vel bra? App Cubby har også skrevet om hvordan de kom frem til dette, for de som er interessert.

Vet du om noen ikonsamlinger du synes er fine? Legg gjerne igjen en kommentar med en link.

Ett år i App Store, noen betraktninger

2010-09-09T10:36:54Z

Det er nå ganske nøyaktig ett år siden jeg for første gang, var med å lansere en iPhone-app i App Store. App Store har satt en ny standard på hvordan software kan distribueres og den er med rette oppskrytt. Men i løpet av dette året har har jeg stadig oftere stilt meg spørrende til hvordan denne butikken fungerer i praksis. Jeg har hatt en snikende følelse av at App Store har gått fra å være vår beste hjelpende venn, til å bli enda en masete tulling.

Her blander jeg epler og pærer. Når jeg sier den er vår beste venn, tenker jeg på backenden. Det geniale systemet hvor alle utviklere kan registrere seg og lansere produkter. Produkter som blir tilgjengelige for millioner av brukere over hele verden. Aldri før har det vært mulig å distribuere programmer så enkelt, så profesjonelt. Men når jeg snakker om en masete tulling, har jeg frontenden og dets innhold i tankene.

Nylig fikk App Store en designoppdatering, noe som gjorde det enda penere, og som fremstiller appene enda mer attraktivt. Og App Store er pent. Men med over 100 000 apper står den ovenfor en enorm utfordring: Hvordan finne appen vi ønsker? Alle appene slår hverandre ihjel med lignende ikoner og fengende navn. Selv om vi har 20 underkategorier, sorteringsmuligheter og søk, er det nesten umulig å finne frem. Men det finnes to hjelpende hender: Brukeranmeldelser og topp-lister. Og det er disse jeg har problemer med.

Brukeranmeldelser
Det var Trafikanten-appen jeg og mine kollegaer i Shortcut debuterte med. En app vi selv tok initiativ til ifjor høst, fordi vi selv ønsket oss denne tjenesten i lomma. Trafikanten var enig, men syntes at vi gapte over litt mye i førsteomgang. De ville fokusere på sanntid og deres kjernebrukere: Osloborgere som reiser kollektivt daglig. Et par måneder senere, for ett år siden, var appen en realitet. Og bare ti timer etter lansering var Trafikanten den mest populære gratisappen i norske App Store. Og brukerne virket fornøyd. I begynnelsen hadde appen fire og en halv (av fem mulige) stjerner i gjennomsnitt.

For meg som er vant til å jobbe med webløsninger oppleves særlig én ting radikalt annerledes med apper i App Store: Tilbakemeldingene. Jeg har aldri sett noen egne arbeider bli så systematisk vurdert. Dette var gøy en god stund. Mange ga fem stjerner, og mange ga én. En tydelig polarisering oppstod. Spennende.

Men idag, ett år senere, er mitt inntrykk at anmeldelsene i App Store fungerer som diskusjonsforum i sin værste form. Og at stjernegivningen ikke er særlig systematisk likevel. Folk diskuterer og krangler og mye grums kommer frem. Det har til tider vært morsomt å lese hvordan de som hater at Opplysningskontoret for kjøtt synes det er en ubrukelig app fordi den bare har kjøttretter. Men det har vel gått litt for langt når det dukker opp drapstrusler? Det er selvsagt MatPrat-appen som har sørget for denne debatten. For Trafikanten sin del har den stadig økende klagestrømmen kommet av at appen bare dekker kollektivtrafikken i Osloområdet. Noe som står tydelig i beskrivelsen i App Store. Likevel florerer det av bunnkarakterer fordi den ikke dekker busser i andre byer.

Dette virker kanskje sutrete, men jeg har også et poeng. Når Trafikanten fungerer ypperlig for de som bor i Oslo, er det ikke hjelpsomt at den har en veldig lav score, som skyldes mangel på innhold den ikke skal eller har lovet å levere. Tvert imot gjør det sitt til at ratingen blir ubrukelig. At debatten i anmeldelsene er en salig blanding av Svisj (NRK) og Holmgang (TV2) sine seer-SMS, gjør det heller ikke bedre. (Bare det at anmeldelsene blir brukt som som debattforum er jo i seg selv et tankekors.)

En annen ting er at app-leverandøre selv gjør hva de kan for å manipulere ratingene ved å opprette nye brukere som gir sine egne apper toppkarakterer. Se bare på de første anmeldelsene av hver applikasjon. De gir fem stjerner samtidig som de gjentar funksjonaliteten i appen. Smart, men søplete. (Klikker man på brukernavnet bak en slik anmeldelse vil man se at det er ytterst få apper de har anmeldt, og at alle har toppkarakter.)

Topplistene
Kanskje den mest populære featuren i App Store er Topplistene. Man kan se hvilke apper som er mest populære akkurat nå. Hver kategori har også sine egne lister. Det finnes to typer av disse listene, de med gratis-apper og de som lister opp apper det koster noe å laste ned. Og rangeringer er gøy. Konkurranser er gøy. Hvem er best? Hvilken app er mest brukt?

Men det er ikke bruk lista gjenspeiler, det er nedlastinger. Og dette gjør disse listene mer eller mindre tilfeldige. En morsom og tydelig trend har vært at de fleste norske apper har hatt gleden av å pryde toppen på disse listene. Dette fordi norske brukere tester ut alt som kommer som er norsk. Men hva som blir værende på iPhonen sier lista ingenting om.

App Store-listene har samme syklus som platelistene. Men VG-lista er konstruert for å øke salg av musikk, ved å sørge for at musikk har kort levetid. Det er alltid en ny topplåt, og artistene kan alltid selge nye singler. Men slik ønsker vi vel ikke at programvareutvikling skal være?

Forrige uke kom nummersøktjenestene 1881 og Gule Sider med hver sin app, og et par uker før det lanserte 180.no sin. Alle har ligget øverst på lista, og blitt lastet ned av nesten samtlige iPhone-eiere i landet. Jeg lastet også ned alle, og synes de er veldig bra. Likevel kastet jeg to av dem. Jeg trenger jo ikke tre like apper? Nå har allerede disse begynt å dale på listene, naturligvis. Bør da f.eks. 1881 gjøre som Rihanna og lage en ny singel, en ny app, slik at de topper lista igjen? Neppe.

Med et prosjekt vi jobbet med skjedde noe spesielt, en konkurrent av Shortcut tok kontakt med en av våre kunder og fortalte at de kunne garantere en topplisteplass innen 24 timer etter lansering. Så den gitte kunden burde heller ha valgt å jobbe med denne leverandøren. Har listene blitt så viktige? Er det bedre å klare å manipulere nedlastingstallene enn å lage den best mulige appen? Jeg synes ikke det. Men samtidig ser jeg viktigheten av å synes i App Store. Og det er nesten bare gjennom de listene man blir synlig.

Jeg håper iPhone-app-produksjonen aldri flater helt ut og blir like uinteressant som reklameverdenen. Men nå føler jeg at vi er på vei dit, og at noen aktører virkelig drar i den retningen. Og deler av App Store hjelper heller ikke til.

Selv skulle jeg ønske at App Store viste hvilke apper som faktisk ble liggende på telefonene våre og antall ganger de faktisk ble startet. Noe slikt ville sikkert vært mulig å sende til Apple når vi synkroniserer med maskinene våre. Men både Apple-motstandere og datatilsynet ville vel gått av skaftet, selv om løsningen ville blitt bedre? Kanskje er det bedre med en masete tulling av en venn?

Adecco Job Finder, vår tredje app

2009-12-15T12:09:49Z

Adecco er Norges største bemanningsselskap med over 8000 medarbeidere i jobb, over hele landet. Adecco tilbyr midlertidige og faste stillinger i norsk næringsliv og offentlig sektor. Nå er disse stillingene tilgjengelig rett i din iPhone.

Adeccos Job Finder er vår tredje applikasjon, og nok en gang har vi gjort vårt ytterste for å gjøre opplevelsen så smooth og elegant som mulig. Vår filosofi er at alle produkter bør være av høy kvalitet helt ut til fingerspissene. Og her har vi ikke holdt igjen på noe.

Les mer på Adeccos egne nettsider »

Last ned fra iTunes App Store »

Her kan du tilogmed vinne en iPhone »

Fremtiden i våre hender: Augmented Reality

2010-09-10T13:00:02Z

I sommer var jeg vitne til augmented reality for første gang. Det var et YouTube-klipp av en iPhone-applikasjon som finner frem i Londons t-bane-stasjoner. Jeg kunne nesten ikke tro mine egne øyne. Fremtiden var her! Jeg hadde ønsket meg noe slikt helt siden jeg så Terminator som liten. Først flere måneder etter at jeg så YouTube-klippet stilte jeg spørsmål til innholdet i denne nye utvidete virkeligheten. Viser vi bare det vi ikke trenger å vise?

I tilfelle du ikke vet hva augmented reality er, her er Wikipedias definisjon: «Utvidet virkelighet er en teknologi som kombinerer data fra den virkelige verden med virtuell data som blir lagt oppå virkeligheten, for eksempel ved bruk av grafikk og lyd. Man får et filter av informasjon lagt på virkeligheten.» Mao. et slags lag med ekstrainformasjon som legger seg oppå det vi normalt ser.

Target: Terminator
For meg er det selveste Terminator som har lagt lista for denne ekstrainformasjonen, noe jeg synes best illustreres med bilder fra Guns N’ Roses’ musikkvideo fra oppfølgeren Terminator 2. I musikkvideoen har Schwarzenegger-roboten i oppgave å tilintetgjøre bandets medlemmer. Se bare her:

Etter litt leting finner han bandet, dataene slår fast at dette er «Target: Guns N’ Roses». Og vi får et lite hint om at nord er opp, sør er ned osv.

Siden dette er en overmenneskelig klok informasjonskilde får vi også se at musikken spilles drøyt høyt: «Decibel overload».

Etter konserten, mot slutten av musikkvideoen, finner Terminator bandet backstage, og alle medlemmene blir gjenkjent og presentert ved navn (og mye annen fuzzy data?): «Target: Slash».

Men da Axl Rose blir gjenkjent, ender det hele med at det ville være å kaste bort ammunisjon, å tilintetgjøre dem: «Assessment: Waste of ammo». (Se musikkvideoen på YouTube: You Could Be Mine.) Og det er slik vi vil ha det. Nyttig data som tegner opp grafikk, gir oss statistikk, navngir personer, kommer med konklusjoner, forteller GPS-posisjoner og viser oss masse annet vi ikke visste. Og det er det som er poenget, dataene må jo være noe vi ikke vet, som vi ikke kan se.

Slik ser en augmented reality-iPhone-applikasjon ut.

Skilt oppå skilt
London-applikasjonen har enkle skilt som dukker opp og forklarer hvor du skal gå for å ta de forskjellige linjene. Kjempefin grafikk, fantastisk teknologi og imponerende fra ende til annen. Men om du har vært i London og tatt undergrunnen, vet du godt at det er et av det best informerte stedene som finnes. Enkle, selvforklarende og fargerike skilt henger overalt og forteller deg nettopp hvor du skal gå. Hvis det er ett sted vi ikke trenger et datalag over synet vårt, er det nettopp der. Det gjelder forøvrig alle t-banenett, de har god informasjon. Og alle flyplasser. Vi kommer ikke til å ta opp mobiltelefonen vår hvis vi ikke finner gaten (engelsk uttale) på Gardermoen, vi ser opp et lite øyeblikk og leser nærmeste skilt.

I tillegg til t-bane-appene har en annen augmented reality-app fått endel oppmerksomhet her i landet, og det med rette. Agens har utviklet en imponerende app for Gule Sider. Den er ikke tilgjengelig ennå, så jeg har ikke prøvd den. Men jeg har sett teaser-filmen.

Se på dette stillbildet, fra Youngstorget. «Her har vi 7-Eleven» sier videoen, og det er det vi kan lese på den gule boksen i applikasjonen. Men hvis du har stått utenfor en 7-Eleven, vet du godt at de er ganske godt opplyst med egne skilt. At applikasjonen også kan vise oss McDonald’s, Åhléns og Posten blir like intetsigende. Dette er informasjon bybildet pøser på oss enten vi vil eller ikke, hele tiden. Jeg trenger ikke å holde opp en mobil for å se dette. (Se teaser-filmen på YouTube.)

Se også hvordan forrige nevnte London-app sin produktside ser ut for «Your New Eye». Hjelp til å finne Starbucks, Pizza Hut, Subway osv. All denne informasjonen viser appen når du er ovenfor t-banestasjonen. Ting vi ser så altfor tydelig opplyst fra før. Og det er det som skuffer meg litt. Når vi endelig har denne muligheten til å vise metadata, håper jeg vi kan bruke det til noe mer nyttig enn å gjenta skiltingen som allerede finnes. Det meste jeg har sett til nå har vært gjentagelser av skilt som allerede finnes.

Her er noen bilder fra Grønland i Oslo, tatt for flere år siden. Hvis vi skal lage en skjerm man kan holde foran øynene her, burde vel den inneholde noe annet enn det vi allerede ser?

Historien viser vei
Alt dette er tanker jeg har grunnet på en stund, så plutselig leste jeg en artikkel på digi.no om hva Universitet i Oslo gjør med denne nye teknologien. Hør bare her: «Prosjektet har utviklet en applikasjon til iPhone 3GS som gjør det mulig for en bruker å se hvordan omgivelsene man beveger seg i har sett ut tidligere, eller hvordan de kan komme til å se ut i framtiden, basert på hvor i området brukeren beveger seg og i hvilken retning mobilen holdes.»

Meget spennende, og det ser også ut som en fantastisk applikasjon. I dette landskapet finnes det ingen skilting eller enkle grafiske forklaringer, men en gang i tiden lå det et vikingskip her. Og dét visste jeg ikke. Nå snakker vi! Tenk å gå rundt i Oslo og se hvordan det var før, eller hvordan det skal bli. Jeg gleder meg, og min tro på at fremtiden er her allerede idag har kommet tilbake.

Shazam
La meg nevne en spøkete idé en kollega av meg har hatt. Kjenner du til Shazam? Det er det programmet som kan fortelle deg hvilken sang og artist du hører på. Den gjenkjenner lydene. Min kollega ønsker seg Shazam for jenter. Tenk deg at du holder opp telefonen foran noen jenter ute på byen, og mobilnummer, navn og fødselsadresse dukker opp. (Applikasjonen må selvfølgelig også kjenne igjen gutter.)

Vel, noe slikt finnes. Idag kan både de digitale kameraene vi bruker og fotoprogrammene våre, kjenne igjen ansikter. Og sammen med de andre mulighetene vi har sett på mobiltelefonene, er dette ikke til å tro.

(Se filmen om TAT augmented ID her.)

Så hvis dette er augmented reality anno 2009, venter jeg søvnløst på alt det spennende vi skal få se i 2010.

Shortcut selger mobilselskap

2009-11-24T16:13:42Z

Etter et kortvarig kjærlighetsforhold til Apparat AS, har vi bestemt oss for å selge selskapet videre til Aspiro.

På denne tiden i fjor kjøpte vi det vesle teknologiselskapet Apparat. Kjerneteknologien i Apparat var en smidig mobilplattform implementert i Ruby on Rails.

Etter å ha tatt godt vare på Apparat i snart ett år, har vi bestemt oss for å selge det videre til noen som kan vie selskapet og kundene enda mer oppmerksomhet.

Den nye eieren er Aspiro. Aspiro er en markedsleder innen mobil, og er kanskje mest kjent for sin musikksatsing med Wimp.

La oss skrote alle blogger og bygge et helt nytt Twitter

2010-09-10T13:14:12Z

Jeg får en følelse av at noe ikke stemmer når jeg tenker på hva en blogg er. Hvordan den fremstår, hvordan jeg leser den og alt arbeidet som ligger bak. Det virker veldig omfattende og overdrevent. Og det er Twitter sin skyld at jeg tenker dette.

Etter at jeg ble komfortabel med Twitter har jeg tenkt at slik burde en blogg fungere også. Slik burde alle blogger fungere, sammen. Og nå når Twitter har kommet med lister i tillegg, er jeg ikke tvil: Noen burde samle alle blogger i ett felles Twitter-lignende system. Twitter er bare to features unna å være et overlegent bloggverktøy:

• Ingen sperre på 140 tegn. Det er den sperren som gjør Twitter til den suksessen det har blitt. Det er på grunn av den at vi har så lett for å twitre. Men det er også den som gjør det helt umulig å skrive en blogg artikkel. Selvsagt. • Mulighet for bilder og video. Mange artikler er avhengig av bilder. Og bilder kan gjøre en hvilkensomhelst tekst lettere og lese, og mer underholdene. Skulle man blogget på Twitter, måtte det være mulig å plassere bilder og video der du ønsker.

For ordens skyld, jeg ønsker ikke å endre selve Twitter. Det er alle bloggene jeg tror kan forbedres. Og jeg mener alle blogger på hele internett. La meg punktvis gå gjennom hvordan jeg tror det ville blitt. Og hvis du er enig i at dette høres ut som en bedre løsning, kanskje vi kan prøve å få til noe sammen?

1: Tilgjengelighet
Idag er det ganske lett å sette opp en blogg på blogger.com, med Wordpress eller lignende. Men det er ikke i nærheten av den lave terskelen Twitter har. Hadde publiseringsverktøyet virket som Twitter, ville veien til lansert artikkel vært mye kortere. Og mange flere ville begynt å blogge.

2: Innholdet
Det vi er ute etter når vi går inn på en blogg er artiklene. Og tekstene, selve innholdet, vil nok forbli uforandret. Vi kommer til å ha de samme tingene på hjertet, uavhengig av systemet rundt. På godt og ondt.

3: Fagmiljøene
Hva da med de større fagbloggene? Mange kjenner bedre til bloggene Signals vs. Noise eller I all enkelhet, enn de kjenner skribentene. Svaret er lister. Nå kan de samme miljøene knytte seg sammen med en felles liste, og det er bare det navnet leserne trenger å huske for å følge hele fagmiljøet. Listene er ypperlig til dette, bortsett fra en ting. Idag fungerer Twitter-listene ganske likt spillelistene i Spotify. Brukerne kan fritt navngi, legge til personer og dele dem med andre. Uten å spørre. Men jeg ønsker meg noe lignende et album i Spotify, hvor det er musikerne/plateselskapene som bestemmer. Jeg tror skribentene bør få mer kontroll og bevissthet på hvilke lister de publiserer til. Men jeg er ikke sikker, begge deler burde kanskje være mulig? Les mer om lister på Mashable.

4: Egen identitet
Kanskje den viktigste delen av din bloggidentitet er navnet på bloggen. De fleste har et fengende og oppfinnsomt navn man skal like og huske. Dette forsvinner heldigvis ikke. Navnet du hadde på bloggen, blir selvfølgelig navnet på den nye lista. Men designet er noe jeg tenker gjerne kan gå tapt, uten at det vil være et stort tap. Idag har alle blogger et unikt design, spennende fargepalett og en gjennomført logo. Det er gøy å lage logotyper, og finne på nytt design, men jeg tror ikke bloggen din skal være stedet hvor man får utløp for det. Det er også et tankekors at alle som lager en blogg designer nok en artikkelside med fokus på lesbarehet, gode linker og korrekt html. Vi finner opp hjulet på nytt og på nytt. (Med et åpent API er det heller ingenting i veien for at du inkluderer nettopp din bloggstream, eller liste, på din egen webside. Så kan du designe den der. Men vit at folk kommer til å lese den et annet sted uansett.)

5: Konteksten
Hva med de andre linkene man har på en side? Om oss, forsiden og kontakt? De er ikke av direkte interesse. Twitter har vist oss at en mini-bio fungerer mer enn godt om man trenger vite mer enn det som står i artikkelen. Der kan det selvfølgelig være en link til nettstedet ditt også.

6: Bloggleseren
Idag er det fortsatt mange som leser blogger på vanlige websider (ikke RSS-lesere). Men jeg gjetter at situasjonen er omvendt når det gjelder Twitter-poster. De fleste bruker nok en Twitter-klient fremfor twitter.com. Og slik skulle jeg ønske at det var med blogg også. At man brukte en egen bloggleser-klient for å lese artiklene. Og, for de som vil savne designjobben som forsvant under punkt 4. Med det API-et som må ligge til grunn, har de muligheten til å designe en helt egen leser, med logo, farger, typografi og alt.

7: Skriveverktøyet
Det fine med bloggleser-klienten jeg nettopp nevnte er at den i tillegg vil være publiseringsverktøyet. Det er helt naturlig på Twitter, og slik det burde det være med blogg også.

8: SEO
Søkemototoptimalisering tenker jeg blir søkemotorens jobb, ikke bloggens. Bloggen skal bare produsere perfekt, semantisk HTML, med gode titler og riktig tagging, så får Google rangere etter beste evne. Og det er vel slik det egentlig skal være?

9: Bannere & AdWords
Mange ønsker å tjene penger ved hjelp av annonser på bloggen sin. Det er ikke noe jeg ønsker å ta hensyn til. Men de kan jo ha sin egen webside med masse bannere og streame sin egen blogg (som jeg nevnte i punkt 4). Eller de kan lage sin blogg-klient (fra punkt 6), og fylle den med reklame.

Er du enig?
Det fungerer veldig bra idag med RSS-lesere. Vi kan abonnere på hva vi vil, ha favoritter, slette abonnement og samle i mapper. Og vi kan lage spennende artikler og nyskapende bloggdesign med Wordpress. Men det er vel langtfra så smertefritt som å sette opp en Twitter-konto og begynne å twitre på en to tre? Hvis du er enig, kom igjen, la oss lage et nytt Twitter med ubegrenset antall tegn og mulighet for å plassere bilder og video. We might be on to something here!

Hvordan skal iPhone-ikonet ditt se ut?

2009-07-12T14:50:09Z

Etter å ha jobbet uker, kanskje måneder, med en iPhone-applikasjon, kan suksessen stå og falle på hvordan man designer det 57×57 pixelstore ikonet. Virkelig? Jepp. Urettferdig? Kanskje. Enkelt? Ikke i det hele tatt.

Det finnes over 50 000 av disse små skrivebordsikonene tilgjengelig i App Store i dag. Noen er pixelperfeksjon av høyeste kvalitet, de fleste andre er amatørmessige i sin utforming og idéløse i sitt motivvalg. I denne artikkelen skal jeg prøve å beskrive hva som gjør et godt ikon. Det trenger ikke å være perfekt, men det må vite hva det vil og hvilke oppgaver det står ovenfor.

Ikonets første oppgave er å bli sett i App Store, og gjøre brukeren interessert. Jeg har tidligere beskrevet hvordan jeg velger å installere en applikasjon på grunnlag av ikonet, og jeg er neppe alene. Ikonet må skape en interesse på kort tid, da man fort skummer over mange samtidig.

Vær funksjonell!
Når ikonet først har fått seg et skrivebord å pryde, begynner den egentlige jobben. Oppgaven er å være enkel å finne når brukeren ønsker det, men ellers være tilbakelent og ikke-prangende. Det er kanskje mange som tror at det er viktig å skille seg ut her også, slik at det synes godt, gir god reklame og oftere blir brukt. Men sånn er det ikke. Ikonet skal bare stå til tjeneste når eieren ønsker å finne nettopp det. Det er applikasjonen bak som vil avgjøre hvor ofte det blir brukt.

Her er endel eksempler på ikoner. Noen som fungerer godt og mange som er veldig stilige. Er det noen du synes fungerer dårlig? Noen du synes ødelegger for andre? Eller er vanskelig å finne?

Noen er kanskje finere enn andre, mer spennende. Men hvilke ikoner klarer å fortelle deg hva applikasjonen handler om. Hva den gjør? Det er den viktigste av alle oppgaver, er det ikke? Apple sine egne applikasjoner kan være en god rettesnor. Se på min favoritt: Phone. Det skal godt gjøres å ikke forstå hva det er. Jeg ønsker at ikonene vi i Shortcut lager blir like intuitive. Her er noen eksempler jeg synes er gode:

Jeg har tillatt meg å ta med vårt eget Trafikanten-ikon, da jeg selv opplever dette som veldig funksjonelt i mitt daglige bruk. Dette er uegoistiske ikoner, som bare sørger for å gjøre applikasjonens funksjonalitet synlig, uten å tenke på firmabranding, designfeinschmekkeri eller artige ideer.

Det som kjennetegner disse ikonene er ett universalt, tydelig og ensfarget symbol, oppå én sterk bakgrunnsfarge. Men å lage slike er ikke like enkelt som man skulle tro. Her er noen eksempler jeg synes har et forbedringspotensiale.

Jeg synes de prøver litt for hardt. Tenk hvor mye lettere Google Earth hadde vært å kjenne igjen, om det var vår gjenkjennelige jordklode. Eller om Countries ikke hadde hatt et politisk kart, men tydelig skilt mellom land (kanskje grønt) og vann (kanskje blått). 100 Pushups og MachDice lider av å skulle ha applikasjonsnavnet med i ikonet. Og Units kunne kanskje valgt ut ett målesymbol, ikke tre? Når det gjelder blyanttegneprogrammet No.2 så er det kanskje jeg som er for streng? Det er jo kjempefint, men jeg skulle gjerne sett en versjon med sterkere kontrast mellom trestrukturene.

Bedre er bedre
Heldigvis kan man alltid forbedre ikonet sitt. Man er ikke låst for alltid etter en lansering. Her er to eksempler på applikasjoner som er endret:

Facebook sitt tredje ikon kommer sannsynligvis med neste oppdatering. De begynte med et ikon med to ansikter, en gutt og en jente, for nettopp å illustrere hva de var. Smart. Dessverre konkurrerte det med kontaktlisteprogrammet el., vil jeg tro. De endret det i hvert fall til F-en i logoen sin. Noe som for meg hjalp. Det ble lettere å kjenne igjen. (Og det er litt sårt å innrømme, siden jeg stort sett snakker negativt om å dra inn ens logo i app-ikonet.) Tredje versjon, med F-en mot høyre, er en del av deres stadige designendringer, og vil gjøre det enda lettere å kjenne igjen for Facebooks mange daglige brukere.

AP News var tidlig ute med sin applikasjon, og syntes nok dette var så spennende at de døpte seg om til Mobile News og la logoen sin inn som et pressekort i hatten. Heldigvis har de skjønt at iPhone-eierne vet at det er en mobil de holder i hånden. Og at det er AP-logoen de ser etter ikke en cowboylignende hatt.

Ikke ødelegg for andre!
La du merke til det ene ikonet som skilte seg mest ut i det store bildet innledningsvis? Scroll gjerne opp og ta en ny titt på dem, det er nemlig ett som er helt annerledes. Ett som går sine egne veier, på bekostning av de andre, og på bekostning av iPhone-eieren selv. I hvert fall er det noen som mener det. I artikkelen Your Icon is Wrong kan du lese og se mye klokt om hvorfor man ikke skal bryte med å være en firkant med runde hjørner.

Det er Guitar Toolkits plekter som gjør det i første eksempel. Og pressehatten til AP News i siste eksempel. De har maskert ut symbolet sitt mot svart, slik at det får sin helt egne, unike form. Noe som ser veldig fint ut for seg selv, men som ødelegger helhetsopplevelsen. Verdens verste argument blir gyldig her: «Hva hvis alle skulle gjort det, det ville ikke gått.» Det ville i hvert fall ikke blitt særlig oversiktlig.

Våre egne
Det er alltid lett å komme med meninger om andres arbeider. Vanskeligere er det å lage noe selv. Vi i Shortcut legger alltid lista veldig høyt på våre produkter, og går gjerne flere runder før vi blir fornøyde. I tillegg har vi kunder med egne, reflekterte meninger, gode ideer og spesiell kjærlighet til sin designprofil. Det kan fort bli mange kokker bak et lite ikon, men heldigvis ender det alltid godt, bare man tar oppgaven seriøst.

Her kan du se et lite utdrag av skissene til våre to lanserte ikoner, Trafikanten og MatPrat:

Vi ønsket både å ha med profilen til MatPrat og et symbol som viste at dette handlet om mat. Og etter noen runder ble vi enige om det kjente kniv og gaffel-symbolet. Deretter prøvde vi oss frem med designprofilen og endte med å beholde den røde streken fra logoen. Det har blitt et fint symbol synes jeg, og jeg håper det er noe MatPrat kan bruke i andre sammenhenger også.

Da jeg begynte arbeidet på Trafikantens ikon hadde jeg fått et ganske strengt og vanskelig krav: Trafikanten-tusenbeinet skulle med! Jeg prøvde og prøvde, men det var helt umulig å ha et fargerikt tusenbein samtidig som det skulle se nyttig og informativt ut. Det skulle ikke ligne et pekespill for barn under fire år.

Senest for bare noen dager siden blusset den diskusjonen opp igjen hos teamet som jobber med Trafikanten på iPhone. Og heldigvis blir bussen værende.

Hvorfor buss? Jeg skulle gjerne hatt en trikk. Jeg synes trikk er litt mer spesielt og litt stiligere. Men over 90% av stoppestedene Trafikanten dekker er busstopp. Så da ble det et enkelt valg. (For vi kunne vel ikke valgt flere symbolder vel?) Når jeg nå står på en bussholdeplass og ser opp på lysskiltet vet jeg at vi valgte rett.

Ikke bare for applikasjoner
Det første året iPhone var ute (i USA) fantes ikke App Store, og det var ikke mulig å skrive egne applikasjoner for iPhone. Man kunne bare lage nettapplikasjoner, kompliserte nettsider. Men man kunne lage like fine ikoner som bokmerker til nettstedene. Og fortsatt er det slik.

Derfor ser jeg ingen grunn til at ikke ethvert nettsted tar seg bryet med å lage et slikt ikon. Her er et lite knippe jeg liker godt. Legg merke til 37Signals’ Campfire, de har gjort en ekstrainnsats for å blende inn sammen med Apples egne ikoner, noe jeg har skrevet om tidligere.

Mine favoritter
Som designer som sitter dagevis med pixeljusteringer kan jeg ikke la være å bli imponert over det gode håndverket som har blitt lagt ned i noen av disse ikonene. Når jeg ikke tar hensyn til funksjonalitet, eller applikasjonen eller avsenderen eller noe annet enn de 57×57 pixlene, er dette mine favoritter:

Har du noen du liker, legg gjerne inn en link i kommentarfeltet under. Og trenger du hjelp med ditt ikon, ta kontakt så hjelper vi alt vi kan.

Hvorfor timeføring ikke kan automatiseres

2009-07-03T13:58:47Z

De fleste utviklere jeg kjenner har på et eller annet tidspunkt laget sitt eget timeføringssystem fordi de var misfornøyd med det de er pålagt å bruke. Målet er ofte å automatisere det som ser ut til å være en meningsløs aktivitet, denne posten handler om hvorfor timeføring faktisk er en meningsfylt aktivitet.

Det ser ut som et brudd på DRY (Don’t Repeat Yourself) å skulle fortelle hva man har gjort flere ganger. For eksempel oppsummerer jeg endringer jeg har gjort i koden gjennom versjonskontrollsystemet. En ide kunne dermed være å bruke dette til å lage en (automatisk) rapport over dagens aktiviteter:

git log --since="8 hours ago"

vil lage en helt kosher liste over features jeg har laget idag, hvorfor skulle ikke dette være nok for å rapportere hva dagen handlet om?

Den enkleste delen av timeføringen er hvor mange timer man har jobbet. Formelen er omtrent slik:

klokkeslettet når jeg går hjem
- klokkeslettet jeg kom
- dødtid/surfing/whatever
= fakturerbar tid

Den andre delen er å fortelle hva man har gjort. På samme måte som testene vi skriver beskriver hva programmet gjør på en bedre måten enn implementasjonen (fordi den har et annet utgangspunkt og muligens, hvis testene er veldig bra, et annet publikum) er timeføringen en oppsummering av hva dagen har handlet om.

Har du hørt den gamle historien om mannen som kom til en byggeplass i oldtidas Egypt? Han så masse mennesker som dro på digre steiner, noen sto og dirigerte, og andre satt i skyggen fra et palmetre. Mannen går bort til den første slaven han ser, og spør “Hva gjør du?”

Er du dum? Ser du ikke at jeg drar på denne digre steinen?

Mannen var ikke helt fornøyd, og nærmet seg en annen slave med samme spørsmål.

Jeg har fått beskjed om å flytte denne steinblokken fra den plassen der borte opp på haugen der.

Fortsatt ikke helt fornøyd gikk han bort til en tredje mann.

Jeg bygger en pyramide, svarte mannen på samme spørsmål.

Så forskjellig kan man altså beskrive nøyaktig samme aktivitet, og likevel kommunisere helt forskjellige hensikter.

Tenk deg at når du skal beskrive hva du har brukt timene dine på (som noen antakelig betaler dyrt fort), at du skal oppsummere hvilken verdi du har levert idag.

Istedet for en liste av typen:

Added new checkbox in signup form
Refactored authentication logic

kan samme aktiviteter oppsummeres som:

Made it possible for users to log in with the same username/password that they use in the legacy system.

Den siste formuleringen forteller ikke bare hva du har gjort, men hvilken betydning dette har. For kunden som skal bla opp for timene dine vil dette helt sikkert oppleves som mer verdifullt enn en liste med kodeendringer. Samtidig er min opplevelse at denne prosessen gjør meg mer bevisst på

betydningen av det jeg har gjort
retningen prosjektet tar
verdien jeg leverer

Også på dager da jeg har knotet og ikke klart å levere så mye kode kan det tenkes at jeg har gjort noe verdifullt, denne prosessen gjør meg bevisst på dette. Og skulle det komme en dag da du har levert hundrevis av kodelinjer og likevel ikke klarer å formulere hvilken verdi dette gir, kan det tenkes at du ikke har fokusert på de riktige tingene.

Prøv det, jeg tror du vil like det!

Trafikanten på Android: noen ord fra utvikleren

2009-06-24T11:58:08Z

Nå som katta er sluppet ut av sekken og Trafikanten for Android er sluppet er det vel på tide å dele mine erfaringer med utvikling for Android.

Siden jeg skaffet meg en dev phone like før jul har jeg i ledige stunder puslet med det nærmeste jeg kommer et “Hello World”-prosjekt: Trafikanten. Jeg tok utgangspunkt i Trafikanten på iPhone og hadde som mål å få noe som ligner så mye som mulig til å kjøre på min Android-telefon.

Først installerte jeg Eclipse, siden Google lager plugins som gjør Android-utvikling mye enklere enn å gjøre alt for hånd. Til å begynne med forsto jeg ikke allverden av hva som foregikk under panseret, men fant meg på sett og vis til rette i Eclipse – selv om det sammenlignet med XCode er et monster. De helt grunnleggende funksjonene i Eclipse, så som å skrive tekst, er en merkelig involvert prosess, og det tok ikke lang tid før jeg savnet Textmate. Etterhvert har jeg forstått at man kan få til det samme i andre editorer som man gjør i Eclipse, de aller fleste funksjonene er dekket av verktøy som følger med Android SDK-et. Neste Android-applikasjon kommer jeg nok til å utvikle i Emacs, og bygge meg en Rakefile som automatiserer bygging, debugging, signering og slikt.

Gjensynet med java var ikke den beste delen av opplevelsen, men rammeverkene fra Google er veldig bra. Spesielt er arkitekturen i Android gjennomtenkt og bygget for at man enkelt kan lage mashups som trekker funksjonalitet fra andre applikasjoner på telefonen. Applikasjoner kan være tilbydere (provider) av data overfor andre applikasjoner, som gjennom REST-baserte URLer får tilgang til data fra din applikasjon. Android legger heller ingen begrensninger for hvor dypt ned i operativsystemet man dukker; din applikasjon kan gjerne være en erstatning for SMS-applikasjonen dersom brukeren ønsker å heller bruke din SMS-applikasjon enn den som følger med operativsystemet.

Vi ble enige om å distribuere kildekoden til applikasjonen på Gitorious, og gjorde det igår. Det føltes da pussig å ikke skulle distribuere applikasjonen også, så jeg satte meg til og forsket på hva som skal til for å få en applikasjon på Android Market. Også her har Google valgt en helt annen tilnærming enn Apple: man generer sitt eget private/public keypair som man bruker til å signere applikasjonen – det er altså ingen søknadsprosess til Google for å bli godkjent som utvikler. Man må riktignok registrere seg – noe som koster 25 dollar – men hele denne prosessen er automatisert.

Når jeg så hadde laget og signert en versjon av applikasjonen (som tok i underkant av en halvtime, inkludert lesning av dokumentasjon) gikk jeg inn på Android Market og bladde meg fram til .apk-fila jeg hadde laget og signert. Nettsida ga umiddelbart informasjon om at jeg trengte etpar ekstra tagger i manifest-fila mi (som angir miniumsversjon av SDK-et), og så snart dette var rettet fikk jeg beskjed om at applikasjonen nå var publisert.

Dette tok meg rett og slett på senga, jeg hadde regnet med noen dager eller uker med godkjenning før appen var tilgjengelig. I morges hadde jeg bestemt meg for å ta appen bort – siden jeg ikke følte den var ferdig ennå – men kunne se at et femtitalls brukere allerede hadde installert applikasjonen. Jeg la derfor heller inn beskjed om at appen ikke er ferdig, og lovet å komme med oppdateringer.

Om du har en Android-telefon skal du kunne scanne denne strekkoden for å installere Trafikanten på telefonen din:

Trafikanten for Android?

2009-06-24T09:11:12Z

Som en gave, nei, en hyllest til alle Android-entusiaster i Norge har Marius laget en versjon av vår iPhone-app Trafikanten for Android.

Vi har en Android liggende på kontoret. Den ser ut som en uformelig gjenstand fra Forsvarets overskuddslager, men den er faktisk helt brukbar. Og spesielt nyttig er den når man installerer Trafikanten for Android.

Vi tar gjerne imot bidrag fra utviklere som ønsker å gjøre applikasjonen enda bedre, og derfor har vi lagt den ut som åpen kildekode på Gitorious. Der kan du lage din egen klone av applikasjonen, gjøre endringer lokalt, og deretter sende inn dine endringer som en merge request.

Kanskje ditt bidrag vil gjøre Trafikanten for Android bedre enn Trafikanten for iPhone?

Gitorious' løpende designoppgradering

2009-06-18T13:20:33Z

Denne uken fikk Gitorious en tilsynelatende helt ny forside. Det er første steg på veien mot en total ansiktsløftning av vårt open source-system.

På Gitorious’ egen blogg kan du lese om hvilke valg vi har tatt, og hvorfor: A word from the designer

Og her kan du se den nye forsiden: Gitorious.org

Bidra, ikke bare bruke

2009-05-25T12:17:47Z

Fri programvare benyttes i økende grad i offentlig sektor. Men hvordan tenker det offentlige å bidra tilbake?

Regjeringens vedtak om økt bruk av fri programvare, altså programvare som leveres med en lisens som tilgjengeliggjør kildekoden for modifikasjoner og tilpasninger, har ført til resultater: Fornyings- og administrasjonsdepartementet informerer om at bruken av fri programvare i offentlig sektor øker, og at 6 av 10 statlige virksomheter nå benytter fri programvare.

For å gjøre fri programvare lett tilgjengelig for offentlig sektor, har Nasjonalt kompetansesenter for fri programvare (Friprogsenteret) etablert Delingsbazaren. Delingsbazaren skal stimulere til økt synliggjøring av løsninger basert på fri programvare, og da fortrinnsvis programvare som er utviklet med offentlige midler.

Delingsbazaren gjør livet enklere for potensielle brukere av fri programvare. Men Delingsbazaren gjør det ikke enklere for bidragsytere å bidra med dokumentasjon, kodeendringer, bugfikser, oversettelser og lokale tilpasninger. Og fri programvare er avhengig av massiv deltagelse fra uavhengige bidragsytere for å oppnå kvalitet som kan overgå kommersiell programvare.

Gitorious

Utfordringen for initiativtageren i prosjekter med åpen kildekode består i å gjøre kildekoden lett tilgjengelig for innsyn og videre bearbeiding, samt å legge til rette for samhandling mellom forskjellige bidragsytere. Shortcut tilbyr en slik løsning med Gitorious, og på Gitorious har vi fått med oss Qt Software som på denne måten åpner for bidrag til sine prosjekter fra eksterne bidragsytere.

Vi oppfordrer Regjeringen til å ikke bare stimulere til økt bruk av fri programvare, men også å skape en bedre delingskultur ved å fokusere på samhandling rundt fri programvare-prosjekter.

Det er bedre med ett program i hånda, enn ti på taket

2009-05-21T17:54:05Z

Et spørsmål vi ofte blir stilt når vi jobber med iPhone-programmer er: Hva med alle de som ikke har iPhone? Det er et godt spørsmål. Svaret er at de brukerne når vi ikke uansett. De bruker ikke mobilen sin.

Apples iPhone er bare én av mange mobile plattformer, og iPhone-brukerne er i et stort mindretall. Hvorfor ikke lage løsninger som når flesteparten?

Hva med Mobile Java-applikasjoner som de aller fleste kan installere?
– Det er veldig få som faktisk ville gjort det.

Men hva da med Symbian, Android eller Windows Mobile?
– Vel, de brukerne er det faktisk enda færre av, enn iPhone-brukere.

I slutten av mars var jeg på en konferanse i Berlin. Temaet var kollektivtrafikkinformasjon på mobile enheter og jeg var der for å snakke om Trafikanten på iPhone. Deltagerne var trafikkselskaper fra hele Europa, og de hadde gjort all slags forskjellige tiltak for å nå ut til publikums mobiltelefoner. I dag har jo alle reisende muligheten til å installere applikasjoner, surfe på wap-sider eller sende og motta SMS, uansett hvor man befinner seg. Så mulighetene for å få fortalt når bussen kommer er absolutt til stede. Og løsningene finnes.

Sveits’ største reiseselskap SBB hadde en veldig interessant plansje på dette (over). Her ser vi oversikten over de forskjellige teknologiene de har løsninger for, og bruken av dem. Og noen antagelser om bruk i fremtiden. Vi ser at det er bare et fåtall som har iPhone, mot mengdene som har andre mobiltelefoner med Java-muligheter. Likevel er det flere som laster ned informasjon gjennom deres iPhone-applikasjon. Og deres analyse sier at det er iPhone-bruken som vil vokse, ikke bruken av de andre løsningene.

Samme visa hver gang
Lignende erfaring hadde alle selskapene som hadde prøvd seg med å lage egen løsning for iPhone. Inntil de lanserte på iPhone hadde de en jevn vekst av brukere. Og de brukerne var fornøyd. Men etter lansering av et iPhone-produkt kunne ikke dataene sammenlignes. iPhone-bruken stod i taket fra dag en, langt, langt over en sms-, eller java-applikasjonsbruk. Og det samme tyder tallene til Trafikanten her i Oslo på. De populære tjenestene Trafikanten på mobilen, Trine i Farta og andre, kan ikke måle seg med bruken av iPhone-applikasjonen.

Ser vi på datatrafikken generelt er jo iPhone i en særklasse blant mobilene. Digi.no kalte iPhone for operatørenes nye melkeku. Flickr opplever at det mobilkameraet som laster opp flest bilder er iPhone. De norske 1881-iPhone-tilpassede sidene viser til at ¾ av deres mobilbrukere gjør søk på iPhone. På vanlig nettsurfing er det jo etterhvert ganske kjent at iPhone er overlegen.

La meg nå minne oss på at det faktisk ikke er så mange som har iPhone. De bare bruker den mer. Mye mer. Derfor disse utslagene i statistikken. Hvorfor er det slik? Hva er så spesielt med iPhone, eller eierne av den? Det skal jeg ikke gi et fyldig svar på nå. Jeg vil bare påpeke at den er veldig lett å bruke og at programmene ser elegante og fine ut.

Konklusjon
Min konklusjon blir derfor dette: Ønsker du å treffe mennesker, er iPhone svaret. Ønsker du å treffe flest mulig gadgets, kan kanskje en Java-applikasjon være en løsning? Bare vit at det du lager ikke vil bli brukt. Noe en samtale med kjæresten min bekreftet nylig. Hun misunner meg Trafikanten-applikasjonen stadig vekk, selv om hun har en Sony Ericsson hvor hun kan installere noe tilsvarende. Men det kommer hun aldri til å gjøre, det blir for vanskelig. Uansett hva som blir laget for hennes telefon, kommer hun aldri til å få sett det.

Hvordan musikkhøyskolen lærte meg å unngå knuste vinduer

2009-05-18T14:36:04Z

Jeg har føttene mine godt plantet innenfor mange ulike grener. Grenene jeg bruker mest tid på er programmering og musikk. Når man driver med to helt forskjellige ting til samme tid, er det alltid gøy å oppdage fellesnevnere.

Dette er historien om hvordan musikkhøyskolelærdom gjorde meg til en bedre programmerer.

Noe av det mest krevende som pianiststudent på NMH var innstuderingen. Man skulle tro at fingergymnastikken var det vanskeligste. Likevel, den mentale utholdenheten man trengte for å lære seg side etter side fulle av noter var av en annen verden, og noe av det mest krevende jeg ble utsatt for i løpet av min tid som pianostudent. Å spille raske løp opp og ned tangentene ble mer som en joggetur. Overkommelig og enkelt å forholde seg til. Å lære seg sytten sider med en betraktelig høyere prosent av blekk enn hvitt papir, derimot.. Usj.

Dette førte til at man ble nødt til å finne effektive innøvingsmetoder. Vi stod heldigvis ikke på bar bakke; innstudering var et eget fag, hvor jeg og resten av pianostudentene i mitt kull møtte opp i klasserommet for ukentlige lektyrer i notelesing og memorisering. Dette var likevel ganske generell lærdom vi fikk i disse timene, og det ble dermed opp til den enkelte av oss å finne ut hva som passet best for våre individuelle vaner, ønsker og behov.

Etter noen måneder, klok av skade, fant jeg frem til en metode som viste seg å forbli den mest effektive av dem alle. Den gikk som følger:

Lær hele stykket godt nok til å kunne spilles gjennom uten nevneverdige kriser.
Legg det bort i to-tre dager, øv på noe annet i dette tidsrommet.
Plukk opp stykket igjen, spill det like godt som det ble spilt i steg en.

Det interessante er at det var ikke steg to i seg selv, altså ventingen, som utgjorde noen forskjell. Magien lå i vissheten om at jeg skulle ha en pause i noen dager (steg to) for å så kunne spille det like godt igjen noen dager senere (steg tre). Det førte til at jeg jobbet mye mer fokusert og grundig i steg en, og passet nøye på at alle fraser og løp og akkorder og fortendeler ble innøvd godt nok til å tåle disse to-tre dagene med tid borte fra stykket.

Jeg har nylig oppdaget en sammenheng mellom denne innstuderingsteknikken og programmering.

En programmerer mener stort sett ekslusivt en av disse to tingene:

Programmerer A: Det er lurt å noen ganger starte et prosjekt helt på nytt, og fjerne all koden man allerede har, slik at man kan begynne med blanke ark. Da kan man ta i bruk de nyeste teknologiene, bli kvitt dårlig og gammel kode, gjøre endringer i det grunnleggende rammeverket i koden o.l.
Programmerer B: Det er lurt å aldri starte et prosjekt helt på nytt, men heller kontinuerlig oppdatere kodebasen og holde den i god stand. Da kan man også lett ta i bruk nye teknologier, oppdatere gammel kode og gjøre endringer i det grunnleggende rammeverket i koden, akkurat som når man kaster alt starter helt på nytt, fordi man har en såpass solid og fleksibel kodebase.

Lærdommen fra musikkhøyskolen fører til at jeg holder med Programmerer B.

Hvis man som Programmerer A vet at man om et år eller to kommer til å kaste all koden man har, og starte helt på nytt, kan det føre til at man ikke bryr seg så mye om kvaliteten på koden man skriver — den skal jo uansett kastes en eller annen gang i fremtiden.

Hvis man derimot er Programmerer B, og vet at man gifter seg med all koden man skriver, og aldri kommer til å starte på nytt, men blir nødt til å forholde seg til den samme kodebasen hele tiden, kan det føre til at man bryr seg mer om kvaliteten på koden man skriver — man skal jo tross alt leve med den en stund.

På samme måte som vissheten om fremtidige kvaler viste seg å fungere godt når jeg innstuderte pianostykker, fungerer vissheten om at man skal leve med koden man skriver i all fremtid på samme måte. Det fører til at man jobber grundigere i nåtiden, slik at man forenkler sin egen fremtid.

Dette berører også Broken Window-teorien (derav artikkelbildet). Den sier at det er betydelig forskjell på å ikke ha noen knuste vinduer i et hus, og å ha ett knust vindu. Ett knust vindu fører fort til flere knuste vinduer, og da man har lett for å bli forsømmelig og tenke «ja, ja, det er jo allerede et knust vindu her, et til kan da ikke gjøre noen stor skade». Så baller det på seg.

Å vite at man i fremtiden kommer til å kaste all koden man har, er i seg selv et «broken window». Akkurat som med knuste vinduer, tenker man «Ja, ja, koden skal jo kastes uansett, så litt dårlig kode akkurat bare her kan da ikke gjøre noen stor skade».

Noen ganger er det likevel best å kaste alt man har og begynne på nytt. Hva man skal velge, er situasjonsbetinget. Jeg er likevel sikker på på at det er usunt å som en standard skulle starte på nytt, da det kan føre til late programmerere. La det heller være unntaket å starte på nytt.

Gitorious.org er nå et Shortcut-prosjekt

2009-05-12T09:11:12Z

Gitorious.org ble startet som et nettsted for open source-prosjekter i 2007 av Johan. Etter at Johan Sørensen – som var med å starte Shortcut – har brukt fritiden sin på Gitorious er Gitorious nå et Shortcut-prosjekt. Lørdag fikk Gitorious en rekke nye features, og mandag startet Qt Software, tidligere Trolltech, publisering av sin kildekode på Gitorious.org.

Johan har allerede blogget om “endringene i Gitorious på Gitorious-bloggen”, og skrev igår om at Qt Software legger ut kildekoden sin på Gitorious.org.

Trolltech ble kjøpt opp av Nokia ifjor. Deretter annonserte de at Qt ville bli tilgjengelig under GNU Lesser Public License – som innebærer at programvare som linker til Qt ikke trenger å lisensieres med samme lisens som Qt selv. Qt Software annonserte også at de ville åpne for at eksterne utviklere kunne gi bidrag til Qt, noe som altså ble mulig fra og med igår.

Fra og med igår ble det altså mulig å komme med bidrag til kildekoden til Qt, og det tok ikke mange minuttene før de første bidragene kom inn. Mens jeg skriver dette er det kommet inn 13 bidrag til Qt på Gitorious, og det under ett døgn etter at kildekoden ble lagt ut. Vi har de siste månedene jobbet sammen med Nokia Norge for å få på plass en løsning som både er enkel for de som gir bidrag og sikrer de juridiske kravene rundt slike bidrag. The Register skriver om hvordan Nokia dropper papirarbeidet rundt bidrag til Qt.

Selv om Gitorious selv fortsatt er 100% fri programvare, og kan installeres på din egen server, tilbyr Shortcut nå profesjonell hosting av Gitorious for selskaper som ønsker en tilpasset og overvåket Gitorious-installasjon for sine fri programvareprosjekter. I den forbindelsen har vi oppgradert infrastrukturen Gitorious ligger på, slik at Gitorious kan ta unna de trafikkmengdene slike kunder medfører. Vi kommer med mer informasjon om dette tilbudet snart.

Gitorious har en mailingliste, en blogg og en IRC-kanal (#gitorious på freenode). Du kan også laste ned kildekoden til Gitorious.

Noen omtaler av relanseringen Gitorious:

Vi gratulerer Nokia Norge med en vellykket lansering, og følger spent med på bidragene som kommer til Qt framover.

Skjorte av silke. Bukse av lær.

2009-04-26T12:17:16Z

Vi har lagt merke til at flere nettsteder nå ønsker å tilby avgrensede områder som man kun får tilgang til mot betaling.

Prøve.no er ett nettsted som tilbyr teoriprøver for folk som skal ta lappen. Nettstedet ønsket å finne inntektsstrømmer som kunne supplere det dalende annonsemarkedet. Dermed ble det bestemt at man skulle begynne å ta betalt for noen av teoriprøvene, og Shortcut ble forespurt om vi kunne tilby en betalingsløsning som gjorde dette så enkelt som overhodet mulig for sluttbrukere.

Tradisjonelt har man benyttet kredittkort for betaling for innhold på web, og det er forståelig, da kredittkorttransaksjoner er relativt billig (kredittkortselskapene tar fra 3-5% gebyr) og det er teknisk sett enkelt å komme i gang med kredittkortbetaling, f.eks. ved å benytte ActiveMerchant.

Problemet er at brukere ikke velvillig benytter kredittkort til betaling av småbeløp. Derimot viser det seg at brukere er langt mer velvillige til å benytte mobiltelefonen til å foreta slike betalinger via SMS.

Etter at vi kjøpte mobilselskapet Apparat har vi begynt å tilby en slik betalingsløsning på vårt kortnummer 2210. Løsningen er i utgangspunktet generisk, der sluttbrukere sender en SMS til 2210 med kodeord KONTANT X for å motta en kode pålydende X kroner. Koden kan så benyttes til å kjøpe tilgang til lukkede områder på nettsteder. Nettsteder kan kjøpe sitt eget kodeord —Prøve.no har for eksempel kodordet PRØVE.

Etter avgjørelsen om at vi skulle ta betalt for deler av vår tjeneste ble tatt, tok det ikke lang tid å implementere Apparats Kontant-tjeneste. Allerede neste arbeidsdag hadde vi en fungerende betalingstjeneste på våre nettsider. Responsen fra våre brukere var umiddelbart positiv. Apparats APIer er svært enkle å jobbe med, og kan anbefales til alle.

Vegard Andreas Larsen Utviklingssjef for Prøve.no

SMS har med andre ord ikke avgått med døden ennå, og markerer seg nå som en viktig alternativ inntektskilde for nettsteder som tradisjonelt livnærer seg av annonsesalg.

10 ting jeg digger med Android

2009-03-25T08:52:28Z

Jeg skaffet meg nylig en Android Dev Phone, en mobiltelefon for utviklere med Googles frie operativsystem Android. Etter noen dagers bruk kan erfaringene mine oppsummeres med to lister.

10 ting jeg digger med Android

Barcode-scanneren. Android kan scanne strekkoder med det innebygde kameraet. Så snart du har en strekkode i fokus gjenkjenner Android denne. Hvis det er strekkoden til en bok du har scannet kan du bruke Googles book search for å søke i innholdet i boka. Hvis det er et annet produkt kan du søke etter anmeldelser og priser for produktet.
Applikasjonene avsluttes ikke når du lukker dem. Istedet sørger operativsystemet for å holde oppe de sist brukte applikasjonene. Dette betyr for eksempel at du kan varsles om nye meldinger på Twitter selv om du i øyeblikket bruker et annet program.
Veldig, veldig kjapp. Overraskende nok er denne telefonen mye raskere enn iPhone. Fra du åpner meldings-programmet til du kan begynne å skrive en SMS går det noen ca ett sekund; etter å ha brukt iPhone i et år er dette en overraskende opplevelse.
Veldig enkelt å komme igang. Når du skrur på telefonen blir du bedt om å oppgi brukernavn og passord til Google-kontoen din eller å opprette en ny. Telefonen henter da inn kontaktene dine, mailen din og kalenderen din på et minutts tid. Du trenger ikke manuelt synkronisere med Google, det skjer automatisk.
Bra, integrert brukeropplevelse. Der det å bruke kameraet fra en applikasjon på iPhone overlater kontrollen til den brukeropplevelsen Apple har diktert, virker det som Android gir utvikleren større frihet til å tilpasse brukeropplevelsen. Når strekkodeleseren starter kameraet vises en strek i midten av bildet, og kameraet trenger ikke utløses for å gjenkjenne en strekkode. Så snart det er en strekkode i fokus gir telefonen fra seg et pip (omtrent samme lyd som i kassa på Rimi) og slår opp hva strekkoden er.
Frihet: med Android kan jeg studere og endre kildekoden, se på filsystemet, laste opp eget operativsystem. Istedet for å lese API-dokumentasjon kan jeg se på kildekoden Google selv bruker i de innebygde applikasjonene på telefonen, inkludert telefonapplikasjonen. Uten at jeg har utviklet noen Androidprogrammer selv vet jeg at på jeg så snart jeg gjør det kommer til å møte utfordringer jeg ikke klarer løse på bakgrunn av dokumentasjonen som er tilgjengelig. Ved å studere kildekoden kan jeg finne ut hvordan noe er implementert, få vite om det er en bug i programmet og i så fall rette den.
Nettverksforbindelsene virker robuste. Det er for eksempel ikke noe problem å chatte mens man er på bussen
Intuitivt hvordan man bruker telefonen. Her har Google “stjålet” mye fra iPhone; som vant iPhonebruker er min første impuls når jeg skal gjøre noe å gjøre det på samme måte som jeg er vant til fra iPhone. Min erfaring er at dette som regel er akkurat slik det skal fungere.
Tilbake-knappen som tar deg tilbake på tvers av programmer. Om man klikker på en link i Twitterklienten kan man trykke tilbake-knappen for å komme tilbake til Twitterklienten fra nettleseren. Jeg vet at Apple-fans vil forsvare Apples valg av bare en knapp på telefonen sin til de går i grava, jeg tilhører de som synes det er praktisk med to knapper (og et hjul) på musa og dedikerte knapper der det gir mening med dedikerte knapper. Tilbake-knappen gir mening, og det å ha en ring- og legg på-knapp gir også mening på en telefon.
Programmer kan bruke funksjonalitet som ligger i andre programmer. Om ett program gir Twitter-funksjonalitet kan et annet program bruke denne funksjonaliteten uten å sende brukeren inn i dette programmet.

10 ting jeg ikke liker med Android

Hardwaren føles billig. Ettersom Android er et operativsystem er dette egentlig ikke kritkk av Android, men telefonen jeg har – som er produsert av HTC – har en distinkt plastikkfølelse. Den knirker litt, jeg har ikke lyst å miste den i gulvet og knappene virker litt billige. Forhåpentligvis vil andre produsenter lage Android-baserte telefoner som ikke virker like billige.
Dårlig batteritid. Det skal nok godt gjøres å få særlig mer enn 24 timers vanlig bruk ut av telefonen. GPS og 3G suger batteri.
Litt klønete å sette opp. I oppsettprosessen da telefonen skal hente kontakter og kalender kan man for eksempel ikke sette opp Wifi først. Om 3G-oppsettet som følger med telefonen ikke er riktig (det følger ikke med 3G-innstillinger for norske operatører) betyr dette at man må inn og sette opp APN-innstillinger før man får brukt telefonen.
Menyer og navigering. Android har alle programmene i en “mappe” som etterhvert blir ganske lang. Mange handlinger er skjult i en meny som man må klikke på Menu-knappen for å åpne. Her ligger iPhone langt foran, og riktigheten av Apples valg om ikke å ha menyer blir tydelig.
Lyder/varsler: med standardoppsettet på telefonen hører jeg ikke meldingsvarselet.
Mangler norske tegn på tastaturet, må – som på iPhone – holde inne a en stund for å skrive en “æ” eller “å”
Nettleseren er ikke like enkel å bruke som mobile Safari, man kan for eksempel ikke dobbelklikke på et avsnitt og zoome inn til riktig zoomnivå.
GPS-en er, som på iPhone, ikke helt pålitelig. Jeg vet ikke om dette er et utslag av at HTC har spart på komponentene i telefonen eller om det er programvaren som har feil.
Har ikke Trafikanten på Android-telefonen ennå. Dette høres ut som selvskryt, men jeg har de siste dagene blitt klar over hvor avhengig jeg har blitt av å kunne hente opp sanntidsdata fra Trafikanten på iPhone.
Telefonen er ikke til salgs i Norge ennå. Jeg mener Android er det nest beste operativsystemet for mobiltelefoner jeg har brukt, og tror det vil bli veldig populært så snart det er mulig å få kjøpt Android-baserte telefoner i Norge.

Dét var en kul dings!

2009-03-15T07:55:14Z

Svenske Yubico har laget en liten dings som kanskje kan erstatte disse “kalkulatorene” nettbanker og andre får oss til å gå med.

For noen år siden trodde mange at vi i framtida kom til å bruke smart-chips koblet til PCen når vi skulle signere dokumenter og betale regninger på nett. Identiteten din, i form av et digitalt sertifikat, på en liten chip du fikk tilgang til fra PC-en din.

Det “alle” var sikre på ville være den største utfordringen – nemlig å etablere rutiner, aktører og distribusjon rundt elektronisk ID – er idag langt på vei løst når Bank-ID nå er tatt i bruk av de fleste bankene. Likevel må vi fortsatt fram med kodekalkulatoren fra 90- tallet, skrapelodd med engangskoder eller SMS når vi skal betale regninger i nettbanken. Hvorfor?

Det store problemet med smartkortlesere er at kundene til en gjennomsnittlig bank bruker forskjellige operativsystemer og nettlesere, og forskjellige versjoner av dem. Den eneste aktøren jeg vet om tilbyr autentisering med Smartkortleser på PCen i Norge er Buypass, og deres løsning fungerer bare i Windows, bare med Internet Explorer. Buypass kan muligens velge å ikke ha noe å tilby de resterende 20 prosent av sine potensielle kundene sine, dette er nok langt vanskeligere for DnB NOR.

Når ingen i 2009 har levert en robust, kryssplattform smartkort-teknologi, tror jeg vi kan regne med at det ikke er smartkort vi kommer til å bruke for slike tjenestene noen gang de neste ti årene.

Svenske Yubico, derimot, har laget en dings som skal fungere på alle PCer (eller Mac eller netbook eller hva det nå skulle være) som lar deg plugge inn et USB-tastatur. Den lille dingsen deres hekter du fast i nøkkelknippet (noe ingen av disse skrapelodd/kodekalkulatorene kan), plugger den inn i USB-pluggen på PC-en din og trykker på når du trenger et passord.

Ettersom Yubikey er et tastatur skriver det – akkurat som et tastatur – ut en serie tegn når man trykker på den. Vanligvis klikker man seg inn i innloggingsfeltet på en nettside og trykker så på Yubikey-en sin. Den skriver da ut 20-30 tegn som inneholder en identifikasjon av deg (strengt tatt seg selv) pluss et engangspassord. Serveren som ønsker å autentisere deg sender dette inn til Yubicos servere, som forteller bekrefter at koden faktisk stammer fra Yubikey-en. Som kodekalkulatoren til nettbankene er engangspassordet bare gyldig en liten stund.

Dette i seg selv betyr jo at dersom noen stjeler Yubicoen din kan de logge seg inn på tjenester som bruker Yubico. Dersom man ønsker seg et ekstra nivå av sikkerhet legger man på et ekstra passord som du må taste inn, for å sikre seg mot dette.

Yubico har et API med kodeeksempler i de fleste relevante språk (Ruby inkludert) og SDKet deres er open source. Hver Yubikey koster fra 25 dollar og nedover (10 dollar hvis du kjøper mer enn 5.000).

Hvem var det som sa at man ikke kunne kombinere sikkerhet og brukervennlighet?

Hvordan estimere et iPhone-prosjekt?

2009-02-18T14:09:20Z

Vi fikk en mail fra noen studenter som skal gjøre en oppgave om tilpasning av et nettsted for iPhone idag. Dette spørsmålet fikk oss til å tenke gjennom hvorfor det er såpass vanskelig å gi et estimat på hva noe slikt vil koste, derfor legger vi ut svaret vi ga her.

Spørsmålet studentene stilte var i hovedtrekk hva det vil koste å lage en iPhone nettbutikk. Nettsiden skal være tilpasset iPhone, men slik vi forsto det er det snakk om å tilpasse en eksisterende nettbutikk til iPhone. Her er svaret vi ga:

Dessverre er det nok ikke mulig å gi et seriøst svar på spørsmålet deres uten å gå nokså dypt inn i problemstillingen. Men jeg kan si noe om hvordan vi vurderer omfanget av et slikt prosjekt, og litt om hva de forskjellige oppgavene består i:

Funksjonalitet

De færreste vil ha råd til å utvikle en nettbutikkløsning fra bunnen av, men måtte forholde seg til et standardprodukt man tilpasser sine behov. Det systemet man skal tilpasse vil legge mer eller mindre strenge føringer for hvordan presentasjon av varer, arbeidsflyt for bruker og selger og betalingsmekanismer fungerer. Om man ser på et produkt som Shopify gir disse ganske stor frihet, mens Mamuts nettbutikkløsning gir relativt liten frihet. Antakelig vil dere oppdage at systemet som velges er designet for bruk fra PC, som vil gi føringer for i hvilken grad man kan tilpasse brukeropplevelsen til iPhone.

Hvis man velger en løsning som Shopify burde det være mulig å tilrettelegge en mobil versjon som er svært forskjellig fra PC-opplevelsen; på den annen side betyr dette at en mindre del av koden er ferdiglaget – som igjen betyr mer arbeid.

Betaling

Dersom man skal ha betaling med kredittkort – noe dere helt sikkert vil ønske – legger også dette føringer for brukeropplevelsen og i hvilken grad man kan gjøre tilpasninger. Mange norske betalingsløsninger benytter seg av 3dsecure, som er et samarbeid mellom kortleverandørene (Visa, Mastercard mfl.) – som i Norge betyr at den som utsteder kredittkortet sørger for å sikre at du er rettmessig eier av kortet du betaler med.

Etter at de norske bankene nå stort sett har standardisert på BankID for denne prosessen, og BankID bruker en java-applet, betyr dette kort og godt at iPhone ikke vil fungere med 3dsecure (siden den ikke støtter java-applets). Jeg har ikke diskutert iPhone til kortbetaling med noen av de som leverer betalingsløsninger, men jeg antar at de har tanker om hvordan dette kan muliggjøres idag. Men antakelig betyr dette at man er nødt til å bruke andre alternativer; PayPal kan antakelig være et alternativ her.

Interaksjonsdesign

Folk bruker iPhone på helt andre måter enn en PC. For det første bruker man fingrene til å navigere og legge inn tekst, noe som generelt betyr at man bør kreve minimalt med inntasting av informasjon. Dernest vil bruksscenariet for iPhone være forskjellig fra PC: de fleste iPhone-brukere setter av alt fra et halvt minutt til etpar minutter til en “sesjon” på sin iPhone, mens PC-brukere sitter foran skjermen i timevis av gangen. Kanskje betyr dette at en netthandelsløsning for iPhone ikke er noen god ide i det hele tatt, at man heller bør forutsette at brukeren handler fra sin PC. I så fall kunne kanskje iPhone-løsningen brukes for å spore pakken sin – som er et bruksscenario som passer bedre i en iPhone-kontekst.

Om man velger å lage en netthandelsløsning bør man altså bruke en god del tid med papir og blyant og skissere hvordan man kan tilpasse brukeropplevelsen til iPhone; det som er helt sikkert er at dette må være ganske annerledes fra PC-opplevelsen, og det er få gode eksempler på nettbutikker for iPhone.

Visuelt design

De fleste bedirfter har et eksisterende visuelt uttrykk de bruker på trykk og web som de vil ønske å ta med til iPhone. Ettersom man har svært begrenset med plass til “pynt” på en iPhone-side kan man ikke bruke like mye dekor og grafiske elementer på en iPhone-side som en vanlig webside. Samtidig vil vi ikke miste gjenkjennelses-/brandingeffekten til bedriften, noe som krever at man gjør en grundig tilpasning av bedriftens visuelle uttrykk til iPhone. I arbeidet med Trafikanten brukte vi mye tid på å tilpasse Trafikantens grafiske elementer og uttrykk til iPhone: vi endte her opp med å få avgangsvisningen til å etterligne skiltene på holdeplassene, slik at brukeren umiddelbart skulle kjenne igjen innholdet i skjermbildet fra noe som var kjent for ham fra før.

Tilpasning av nettsider

Så, til slutt, den tekniske delen. iPhone bruker i likhet med PC-baserte nettlesere, HTML, CSS og javascript som byggeklosser. iPhone har imidlertid endel forskjeller: ingen mus (altså ingen effekter når man fører musepekeren over et område), mindre skjerm, en skjerm som kan roteres, ingen Flash og ingen java. Apple har også i sine human interface guidelines beskrevet noen best practices for hvordan webapplikasjoner bør tilpasses iPhone som de fleste bruker i større eller mindre grad. De fleste vellykkete iPhone webapplikasjoner følger idag samme mønster: man starter med en liste over innholdsgrupper der man kan drille seg nedover i innholdet til høyere og høyere detaljnivå – og så tilbake opp igjen etterpå.

Når man har gjort jobben med de første punktene grundig vil selve tilpasningen av nettsidene i hovedsak bestå i å implementere brukeropplevelsen i HTML/CSS/Javascript – noe som er relativt enkelt når man har gjort det før.

Som dere kanskje forstår er det derfor vanskelig å sette en pris på hva et slikt prosjekt vil koste. Det viktigste er at man ikke slurver med forarbeidet, men tar denne brukergruppen på alvor og tilbyr en løsning som er godt tilpasset situasjonen brukeren er i når han bruker løsningen. Oppsiden i det hele er at en godt tilpasset netthandelsløsning for iPhone vil ha et enormt konkurransefortrinn, og dermed kan ta markedsandeler fra konkurrentene. Der PC-baserte nettbutikker må konkurrere på marginene kan iPhone-baserte nettsteder konkurrere på kvalitet og brukerforståelse. Dette igjen bør kunne gi høyere lojalitet hos kundene.

Ta gjerne kontakt hvis dere har fler spørsmål!

RIP, IE6

2009-02-17T19:10:25Z

Finn.no har idag lagt ut en oppfordring til brukere av Internet Explorer 6 om å oppgradere eller bytte nettleseren sin. Dette er et flott utspill fra Finn.no, og jeg håper både Finn.no’s brukere og andre nettsteder tar oppfordringen.

27. august 2001 var dagen da Internet Explorer 6 så dagens lys for første gang. Jeg husker godt at jeg den gangen klødde i fingrene etter å få bruke de fantastiske nyhetene i IE6, alt fra en innebygget XML-parser til DHTML og iframes.

Nå har jeg selv aldri laget noe nettsted med glorete “best viewed with…”-ikoner som oppfordrer besøkende til å oppgradere nettleseren, maksimere vinduet, installere etpar plugins og kanskje justere skjermoppløsningen sin, men det var mange som la ut oppfordringer til besøkende om å oppgradere til nettopp IE6 – slik at utvikleren kunne få ta i bruk nyhetene IE6 brakte. Paradoksalt nok er det omtrent på samme måte vi nå tar farvel med IE6, gjennom at brukerne blir bedt om å oppgradere slik at vi ikke lenger trenger å ta hensyn til denne gamle nettleseren.

Det er noe helt allmenngyldig å lære fra dette, nemlig at ny teknologi alltid er mer spennende enn gammel teknologi, spesielt for oss som er opptatt av teknologi. Det er trolig mindre sannsynlig at bestefar bytter ut nettleseren sin så lenge den gamle fungerer for ham. Og denne nøkternheten til det som er nytt kan vi antakelig ha god nytte av å ta med oss, samtidig som vi skal være forsiktig med å sette opp for mange stengsler for de som besøker oss; stiller vi for strenge krav går de nok bare videre.

Siden Internet Explorer 6 kom ut har det skjedd mye på webben. Fra 2001 fram til 2007 var IE6 den suverent største nettleseren, i 2002-2003 hadde de forskjellige IE-versjonene opptil 95% markedsandel. Denne markedssituasjonen innebar at det i stor grad var Microsoft som definerte hva en nettleser skulle være. Idag er situasjonen en helt annen. Mozillas Firefox er den store nummer 2, og deretter en lang rekke nettlesere. Når denne situasjonen ikke er fullstendig uhåndterbar for oss som utvikler nettjenester er det fordi vi med rimelig sikkerhet kan anta at alle disse nettleserne følger samme standarder.

I en perfekt verden kunne jeg brukt én nettleser mens jeg utvikler en nettside og så vite at sidene vil se like ut i alle andre nettlesere. Og holder man seg til standardene vil dette i stor grad være tilfelle, med ett stort unntak: Internet Explorer 6. Jeg har vært på prosjekter der 1/3 av utviklingstiden har gått med til å få sidene til å se ut slik man ønsker i IE6. Opplevelsen er helt slapstick: du får noe til å fungere i IE6 bare for å konstatere at det ikke lenger virker i andre nettlesere. Når du får det til å fungere i andre nettlesere slutter det å virke i IE6. Tenk hva man kunne brukt den 1/3 av prosjekttida hvis man slapp å bruke den på IE6. Internet Explorer 6 koster samfunnet milliarder med kroner hvert eneste år.

Det som gjør at andelen IE6-brukere etter at IE7 har eksistert i etpar år fortsatt ikke synker raskere er trolig at mange bedrifter har standardisert på IE6, og at de ansatte selv ikke kan oppgradere nettleseren. Grunnen til at mange bedrifter tviholder på IE6 er at de har utviklet/kjøpt nettløsninger som bare fungerer i IE6, og dermed ikke kan bytte. (Grunnen til at det ble utviklet løsninger som bare fungerer i IE6 var alle de kule nye tingene IE6 brakte med seg). Og dette virker jo som et rimelig resonnement for disse bedriftene: det vil koste dem penger å bytte/endre disse systemene, dermed vil de fortsette å bruke IE6 så lenge de ikke tvinges til noe annet. Dette igjen påfører nettstedene kostnader med å støtte IE6, som bidrar til at man ikke trenger bytte.

Når Finn.no nå trolig har begynt utfasingen av sin støtte for IE6 betyr dette at de som surfer fra jobben med IE6 ikke lenger kan bruke Finn.no. Dette kommer til å skape press på IT-avdelingene, og blant de som utøver dette presset finner vi også beslutningstakere i bedriften. Når daglig leder ikke får søkt etter bruktbil fra jobben i lunsjpausen vil jeg anta de fleste IT-avdelinger får noe å henge fingrene i. Finn.no legger ved dette grepet problemet tilbake i det fanget der det hører hjemme, og jeg tror vi kan regne med å se andelen IE6-brukere på nettstedene våre synke drastisk de neste ukene. Er det ett nettsted alle bruker fra jobben er det Finn.no.

Hvil i fred, IE6.

Er reklame på iPhone OK?

2009-02-11T10:35:05Z

Shortcut var nylig på reklameskolen Westerdals og snakket om hva man bør være klar over når man skal lage applikasjoner til iPhone. Mange ting er lurt å være bevisst på og vi har opparbeidet oss mye kompetanse på dette. Men hva slags applikasjoner ønsker reklamestudenter å lage?

Rett før jul snakket vi med interaksjonsstudentene på Arkitekthøgskolen, som hadde et helt klart ønske om å lage innovative og funksjonelle applikasjoner. Samt noen morsomme. Nå, da jeg besøkte Westerdals, fikk jeg det samme inntrykket. Reklamestudenter ønsker seg også nyttige applikasjoner. Jeg var redd samtalen utelukkende skulle dreie seg om hvordan man best mulig kan profilere kommersielle aktører: «Hvordan lage god reklame på iPhone?»

Men er det noe å være redd for? Er det galt med reklameapplikasjoner, om de er nyttige og fungerer godt? Gilde kokebok er et godt eksempel på en nytteapp, som også gir god reklame. Den er super når jeg er fantasiløs i matbutikken. (Men litt verre er det hjemme på kjøkkenbenken, hvor ingen iPhone har adgang. Jeg søler for mye.)

Ikke like bra er Coca-Colas applikasjon. En bruskorkinspirert løsning, som minner mest om de populære amerikanske 8 Ball-ene. Kanskje er den morsom for noen, men for meg er den et eksempel på hva jeg ikke ønsker meg.

Nyttig og smart Vi har blitt kontaktet av reklamebyråer, med gode ideer til løsninger for deres kunder. Jeg håper flere av de tenkte applikasjonene en gang vil se dagens lys. Ideene er nyttige og smarte, og vil absolutt være noe folk kan trenge, så da gjør det vel ingenting om de er sponset?

Kanskje er vår egen Trafikanten-applikasjon også en slik reklame-app? Ikke vet jeg, jeg vet bare at mange tusen kollektivreisende i Oslo benytter seg av den hver eneste dag.

Shortcut vokser

2009-02-09T16:48:56Z

Finanskrisen er for pyser. Vi ansetter i gode og dårlige tider, og nå er en ny Shortcutter på plass.

Ragnar Henriksen er blitt ansatt som Shortcutter № 6. Ragnar er en førsteklasses utvikler med solid erfaring innen betalingsløsninger, Ruby on Rails og iPhone-utvikling. Men først og fremst er Ragnar en sindig og hyggelig fyr med like sterke meninger om utviklingsmetodikk og brukervennlighet som oss andre. Vi ønsker Ragnar velkommen og gleder oss til å løse spennende oppgaver sammen i tiden fremover!

iPhone, et selvfølgelig sted for arkitektstudenter

2009-02-08T16:47:21Z

I desember i fjor var jeg på Arkitekthøgskolen i Oslo (AHO) og snakket om iPhone-utvikling. Studentene hadde fått følgende oppgave: «App Store har nådd 10.000 applikasjoner. Hva blir de 10.000 neste?».

At det er på arkitekthøgskolen man får i oppgave å tenke på hvordan et program på en mobiltelefon skal være, høres kanskje rart ut. Jeg skal prøve å forklare det slik jeg har forstått det. Om det er helt riktig forstått, vet jeg ikke, men jeg liker min forklaring.

Vi som jobber med interaksjonsdesign vet at å designe software er mer likt å designe dashbordet til en bil, enn et platecover. Det er mer likt knappene på et stereoanlegg, enn en filmplakat eller en logo. Dette fordi software skal kunne brukes i tillegg til å sees og forstås. Og derfor ligger vår design under industridesign.

Det er industridesignere som lager ting, fysiske ting: Biler, mp3-spillere eller romdrakter. Og ingenting er vel mer fysisk, og må være mer funksjonelt, enn produktene arkitektene lager? Eneboliger, sykehus, parkanlegg, leilighetskomplekser osv. Derfor ligger ting-utdannelsen (industridesign) under arkitektur og pek-og-klikk-utdannelsen (interaksjonsdesign) under den igjen.

Med andre ord kan man argumentere for at, å lage en iPhone-applikasjon er mer likt å lage et hus enn en tegning.

Så hva med studentoppgavene?
Hans Gerhard Meier (lærer i interaksjonsdesign på AHO) skriver i en mail at det nå finnes noen veldig bra prototyper, etter innlevert oppgave. Så kanskje blir livene våre enklere eller morsommere fremover? Forhåpentligvis blir disse applikasjonene presentert på iPhonePool, et potensielt spennende sted Hans Gerhard nylig har lansert.

Det er et sted hvor vi alle kan laste opp ideer til nye iPhone-applikasjoner. Noe av poenget er at designere og utviklere skal kunne finne den kompetansen de mangler, for å få realisert sine ideer. Men man kan ikke være redd for eierskapet til sin idé. Som Hans Gerhard selv sier under FAQ: _«What if someone steals my idea?  – If this is a concern, your at the wrong address»_

Det jeg snakket om, da jeg besøkte Arkitekthøgskolen, var utfordringer vi i Shortcut har hatt med vår egen Trafikanten-applikasjon. Og hvilke muligheter vi har for videre utvikling. Om noen skulle være interessert kan hele Keynote-dokumentet lastes ned her (8,4 MB). (Her er PDF (6,1 MB), for de som ikke har Keynote.)

Få orden på økonomien, kjøp en iPhone App!

2009-02-03T08:12:12Z

For hundrede gang i mitt liv har jeg bestemt meg for å få orden på privatøkonomien min. Og med en iPhone i hånda, var første stopp på min rene sti, en ny app fra App Store: Pennies. Men tar den hensyn til småpenger?

Det finnes mange applikasjoner under Finance-kategorien, og det nytter ikke å lese om eller teste alle, før man velger. Selv går jeg etter ikonet. Jepp, jeg har en sterk tro på at de som bryr seg om utseendet på sitt eget produkt, også bryr seg om innholdet, funksjonaliteten, stabiliteten osv.

Pennies var det første pene ikonet som vistes, og etter å ha skumlest litt om det, så jeg at det ikke bare støttet $, £ og €, men også «some other currencies». Jeg håpet på vår egen krone, lastet det ned og ble gledelig overrasket. Krona var prekonfigurert på min norske iPhone. Og overraskelsen ble enda mer gledelig da budsjettene mine allerede var på minus. Jeg hadde allerede brukt penger.

Pennies hadde lagt inn at jeg i dag hadde brukt penger på programvare. Nemlig kjøpt Pennies. Smart, hva? Ikke like smart var det at utgiften var satt til 2,99 kr. mens programmet vitterlig kostet 17 kr. Men hvem teller? Ikke jeg, det er derfor jeg trenger et program som Pennies.

Uansett, etter en times bruk er denne appen absolutt å anbefale. Og om privatøkonomien fortsetter å være vannstyrt, ser den i hvert fall fin ut, der ute på det åpne havet…

Her er produktsiden Design by a Knife har laget!

Trafikanten - endelig på App Store!

2008-12-19T08:41:28Z

Fra alle oss i Shortcut, til alle dere som reiser kollektivt i Oslo: Trafikanten på iPhone

At vente på Apple’s godkjenning er litt som at vente på nissen, bortsett fra at man ikke vet akkurat når han kommer, men igår blev Trafikanten på iPhone lagt ut i App Store

Vi har selv brukt den veldig mye i praksis under utviklingen av den, og den er for min del en av de mest brukte applikasjonerne, som jeg skulle ha svårt at leve uten.

Trafikanten på iPhone versjon 1.0 er på mange måter det kom fram til som det absolut minimale vi trengte for at ha en brukbar applikasjon. At finne utav hvad som er “minimum” er langt fra det enkleste og det er noe vi har brukt en del tid på at finne utav.

Den har ingen innebyggt rutetabell, ingen tog-tider, ingen kart-visning og ingen reiseplanlegger. Men, den har sanntidtids-data rett i din iPhone, liste over sist brukte stasjoner, stasjoner i nærheten og muligheten at søke efter stasjoner. Dette er helt bevisst fra vår side og resultatet er det som finnes i versjon 1.0 er, i vår oppfattning, veldig bra. Fram for allt betyder det at vi kan få ut en brukbar applikasjon mye raskere enn om hadde haft med fler features i version 1.0.

Vi håper at Trafikanten er intressert i at fortsette utviklingen av Trafikanten på iPhone framover.

Det tok mindre enn en dag førr den blev nummer 1 på toplista i den norske App Store og vi takker alle som har lagt inn anmeldelser i iTunes, sent oss mail og kvittret om den, vi setter stor pris på alle slags tilbakemeldinger!

God jul!

Rubygem: Kodefargelegging i RedCloth

2008-11-28T13:15:41Z

Den flunkende nye Rubygemmen Redcloth with Coderay utvider RedCloth med et enkelt syntaks for å legge til fargelagt kode (syntax highlighting på fagspråket) i RedCloth-dokumenter.

Et kort eksempel på hvordan denne brukes:

Dette er litt *tekst*. Helt vanlig RedCloth. 
Dessuten, <source>@ruby_rocks = true</source>! Litt
mere kode:

<source:html>
<p class="cool">Dette er HTML!</p>
</source>

Det vil se omtrent slik ut (gitt at du har en CSS som ser omtrent slik ut):

Alt innholdet i <source>-taggene vil bli parset med kodefargeleggeren CodeRay. Den genererer en HTML-versjon av koden, med klasser du kan referere til i CSS-en din slik at du kan fargelegge kodeeksemplene. Du kan også spesifisere hvilket språk koden du vil fargelegge er, f.eks <source:html>

Ta en titt på denne siden for et eksempel på ferdig stylet kode.

Installer gemmen med gem install redclothcoderay. Referer til README-filen for en fullstendig guide i bruk og installasjon.

Funksjonalitet i to sekunder på iPhone

2008-11-28T11:41:38Z

Under arbeidet med vår første iPhone-applikasjon Trafikanten, dukket det opp flere spennende diskusjoner. En av dem handlet om hva som er mest brukervennlig i løpet av de to sekundene applikasjonen åpnes.

En Splash Screen er skjermbildet som dukker opp når et program lastes/åpnes. Dette gjelder på datamaskinen din, Nintendo Wii-en din og på iPhone. Skal man lage en applikasjon for iPhone, skal man følgelig også lage denne velkomstskjermen. Men hvordan skal skjermen se ut?

En PNG-fil, med full iPhone-skjermstørrelse (320×480px) som skal hete Default, er det apple tillater/krever. Innholdet i den står vi fritt til å løse sånn som vi vil. Og vi i Shortcut vil jo alltid det vi tror er best for brukeren. Men i denne saken tok det lang tid før vi kom til en enighet internt. Det er nemlig to retninger man kan gå, for å lage en optimal splash screen.

Det er enklest å forklare dette med bilder. To ganske like program er Twitter-klientene TwitterFon og Twitteriffic. De har valgt hver sin retning.

Twitteriffic: Den fine, fargerike velkomsthilsenen

Iconfactory har alltid vært overlegne på design, og spesielt gode, deilige ikoner (naturligvis). Så at de ønsker å vise sin fine twitrefugl stort, er kanskje ikke overraskende. Denne fuglen er jo mer kjent som Twitter-ikon, enn Twitters eget. På denne måten får de også tydelig profilert seg selv, med navnet nederst.

Vår kunne da se slik ut:

TwitterFon: Den som later som om den er selve programmet

Kazuho Okuis oppstartsbilde ser helt annerledes ut. Her er det ingen logo, ingen fine bilder, ikke noe produsentnavn. Ingenting. Bare et bilde av slik applikasjonen ser ut, tom for innhold. Dette er den løsningen Apple selv anbefaler, og bruker på mange av sine preinstallerte applikasjoner.

Slik ble vår versjon:

Merk: I henhold til Apples anbefaling, har vi ikke tatt med menynavnene nederst, i motsetning til Kazuho Okuis.

Hva er best?
Hva får brukeren ut av Twitteriffic-fuglen? Ingenting, annet enn en bekreftelse på at programmet åpnes. Det gir faktisk en ganske god følelse å klikke på det lille applikasjonsikonet med en fugl, også kommer fuglen stort. Nesten animert.

Hva med TwitterFons løsning? Gir den en god opplevelse? Her var det vi, brukerekspertene i Shortcut, var uenige. To sterke meninger duellerte i dagevis for og imot denne måten å gjøre det på. Argumentet for: Funksjonaliteten til programmet, med knapper og faner, blir presentert så tidlig som mulig. Slik at brukeren kan forberede seg på hva hun/han ønsker å gjøre. Argumentet mot: Å vise knapper, faner etc. som man ikke kan trykke på er i seg selv dårlig brukervennlighet. Det gir rett og slett en broken følelse av å klikke på noe som ikke responderer.

En interessant artikkel det ble referert mye til under debatten var John Grubers Apple’s Private ‘Default.png’ Cheat. Den ligger litt ned på siden, og er verdt å lese. (Den tar opp bl.a. en tredje splash screen-løsning som Apple selv kan benytte seg av. Men som er utilgjengelig for oss andre. Heldigvis, for det er ikke en særlig god løsning.)

Og vinneren ble…

Jeg var den hos oss som sterkest ønsket TwitterFons eksempel, med en tom applikasjon. Jeg så ikke noe problem med inaktive knapper i to sekunder og jeg mente at The Apple Way is The Best Way. Anbefaler Apple én ting, på en helt ny plattform ingen av oss har særlig erfaring med, er nok dét det beste. Og det er jo sånn deres egne applikasjoner fungerer, så da vil opplevelsen være konsistent på brukerens iPhone.

Vi ble enige om å lage og teste begge deler, i håp om kanskje komme til en enighet når vi opplevde dette i praksis. Og det gjorde vi. Etter at jeg så hvordan overgangen fra den fargerike reklamevelkomstskjermen til ferdig installert applikasjon, opp mot den alternative overgangen, kastet jeg inn håndkle. Det fungerte rett og slett mye bedre og virket mer stabilt å ha et rent bilde, uten noe som indikerer funksjonalitet, som oppstart.

På denne måten fikk vi også vist frem Trafikantens logo med larven også. For det var det ikke plass til noe annet sted, noe jeg skal fortelle mer om i en kommende artikkel om hvordan iPhone-ikonet bør se ut?.

Så Apple tok feil?
Jeg tror ikke det. Jeg tror de har jobbet masse med måten å gjøre dette på, og kommet til en riktig konklusjon. For dem, og deres applikasjoner. I vår Trafikanten-app. ønsket vi å gjøre listen over sist besøkte stoppesteder (som er siden du kommer inn på i programmet) litt tøff, og litt designet. Så det jeg opplevde i vår interne test, var at en tom liste til en full grafisk liste, ble en like stor forandring som fra den blå Trafikanten-larven. Og da mistet den sitt hovedargument om en myk oppstart.

Slik ser den siden ut:

Hvis noen har andre meninger og/eller erfaringer, kommenter gjerne under. Dette er jo fortsatt ganske upløyd mark. Er det ikke?

PS: Registrer deg på produktsiden vår, så får du gratis SMS rett til din iPhone når Trafikanten ligger tilgjengelig i App Store.

Trikk møter iPhone! Det beste fra to mobile verdener!

2008-11-26T11:41:06Z

Vi i Shortcut lager gode webløsninger. Og det er vi stolte av. Men vi lager mer enn det. I det siste har vi jobbet med et produkt som vil gjøre Trafikantens sanntids ruteinformasjon tilgjengelig for enda flere reisende. Vi har laget vår første iPhone-applikasjon.

Som vi nylig skrev om intensiverer vi vår mobilsatsing med Apparats mobilplatform. I tillegg til uante SMS- og MMS-muligheter, ønsker vi også å kunne tilby den gode brukeropplevelsen direkte på brukernes mobil/håndholdte. Og først ut er vi med en applikasjon skreddersydd for iPhone. Noe som også har fått litt mediedekning.

Trafikantens iPhone-applikasjon henter informasjon om hvor brukeren befinner seg (GPS er jo som kjent innebygd i iPhone), og kombinerer det med sanntidsinformasjonen til hver enkelt avgang. På den måten kan man kjapt og enkelt finne ut når neste avgang går.

Avhengig
Selv har jeg allerede rukket å bli avhengig av Trafikanten på iPhone. Hver morgen, når jeg sitter på kaffebar og prøver å våkne, kan jeg se hvor lenge det er til neste avgang. Selv om holdeplassen er bortgjemt, rundt et hjørne.

Ennå er ikke Trafikanten på iPhone tilgjengelig i App Store. Men vi er i siste testfase nå, og regner med å kunne lansere dette produktet innen kort tid. Og gleder oss til å komme med flere smarte, enkle løsninger for iPhone og andre mobile enheter.

Les mer på produktets egen side.

Shortcut kjøper mobilselskap

2008-11-25T10:48:15Z

Shortcut intensiverer satsingen på mobil ved å kjøpe selskapet bak Norges smidigste mobilplattform.

Shortcut har akkurat kjøpt mobilplattformselskapet Apparat AS. Apparat ble startet i 2006, med ambisjon om å utvikle markedets smidigste mobilplattform i Ruby on Rails. Shortcut har som visjon å bli ledende på utvikling innen både web og mobil, og dermed var synergiene tilstede.

Vi ser nå frem til å kunne tilby kundene våre komplette løsninger både for web og mobil. Vår erfaring med mobile tjenester er at man oppnår best resultater når man har tette relasjoner med mobiloperatørene, og dette får vi gjennom vårt eierskap i Apparat, da Apparat eier kortnummer 2210 og har direkteavtaler med alle norske mobiloperatører.

Hva betyr dette for Shortcut sine kunder i dag?

Det betyr at vi kan integrere både innkommende og utgående SMS og MMS i våre løsninger. Videre har vi mulighet til å lage betalingsløsninger hvor sluttbrukere kan betale for tjenester via mobilregningen. Dette gjør at vi kan pleie kunderelasjoner og ta betalt for tjenester med samme teknologi.

Nye muligheter

Utstrakt bruk av mobil var et av Obamas fortrinn under valgkampen i USA. Obama benyttet mobilteknologi både for å skaffe til veie penger via mobile donasjoner, og for å spre bevissthet om valget til yngre velgere via “Bring out the vote”-kampanjer på SMS. Shortcut eier nå tilsvarende teknologi, og vi hjelper gjerne våre kunder med en ny Obama-kampanje!

Har smidig utvikling (endelig) blitt stuerent?

2008-11-20T12:30:07Z

Smidig utvikling (eller Agile Development) har en stadig økende tilhengerskare. Det har blitt så normalisert at selv de som hevder å følge prinsippene, omtaler hverandre som buzzordryttere. Men hva er det egentlig?

«Hva det betyr er: Slutt på planlegging. Slutt på dokumentasjon. Bare begynn rett på kodeskrivingen og klagingen.»

På Smidig 2008-konferansen tidligere i høst, møtte det opp over 400 deltagere. Nesten en fordobling fra året før. Men det var først nå på tirsdag, en måned etter konferansen, jeg forstod hvor normalt det har blitt å snakke om smidig utvikling.

Jeg leste om det i VG, i tegneserieseksjonen. Det var Dilberts overordnede som innførte agile programvareutvikling. Så nå kan Dilbert og hans kolleger glede seg over å slippe fossefall og spesifikasjoner. Og jeg fikk et påskudd for å vise en tegneserie i bloggen vår:

Hvor mange triks kan man egentlig lære en gammel hund?

2008-10-28T09:04:25Z

Det er ingen tvil om at iPhone har sørget for at horder av utviklere har lært seg teknologiene som ble utviklet i NeXT – Cocoa og Objective-C rundt 1990. For å kunne lage programmer som kjører på iPhone må man lære seg programmeringsspråket Objective-C, og rammeverkene som finnes på iPhone ligner såpass mye på Cocoa, som Mac-programmer er laget i, at antallet utviklere av rene Mac-applikasjoner nok har økt stort det siste året.

Det er ingen tvil om at Cocoa er imponerende. Det er sjelden man ser abstraksjoner som fungerer så godt, ved at de hjelper utvikleren å lage avanserte og brukervennlige applikasjoner. Det at man kan bruke dette også på iPhone gir iPhone et forsprang konkurrerende mobilplattformer vil bruke lang tid på å ta igjen. I tillegg til Ruby on Rails er det få rammeverk jeg har sett gi abstraksjoner på riktig nivå i like stor grad som Cocoa.

Mitt problem er språket.

For å utvikle programmer på iPhone bruker man altså Objective-C. Objective-C er sterkt inspirert av Smalltalk, og slik sett et rendyrket objektorientert språk. Og dette er kanskje interessant: Smalltalk var det Steve Jobs så da han besøkte Xeroc PARC på syttitallet; da han oppdaget grafiske brukergrensesnitt, mus og vinduer – det vi alle bruker idag. Smalltalk var også det Apples Lisa kjørte. Smalltalk hadde imidlertid et stort problem på den tida, nemlig at det var gudsjammerlig treigt på datidens maskinvare.

Objective-C, derimot, er basert på C; Objective-C er faktisk et supersett av C. Samtidig er Objective-C (i den det er mulig i C) tro mot objektorienteringen i Smalltalk. Men altså mye, mye raskere og på sett og vis mer pragmatisk ved at man kan bruke C og C++-kode i Objective C-prosjektet sitt. Objective-C har noen åpenbare språklige vorter; firkantklammer og peker-asterikser reduserer lesbarheten, men dette føles på sett og vis bare herlig pragmatisk og er noe man slutter å irritere seg over etterhvert. Så også muligens med disse .h-filene man er nødt til å lage.

Nå har åpenbart tiden kommet for å legge til støtte for blokker i Objective-C. Og her begynner man å se mer av fundamentene Objective-C er bygget på enn jeg liker. Apple foreslår å bruke caret (^) for å definere blokker i C, og her snakker vi om en språklig mutant av dimensjoner:

void EvalFuncOnGrid( float(^block)(float) ) {
    int i;
    for ( i = 0; i < 5 ; ++i ) {
        float x = i * 0.1;
        printf("%f %f", x, block(x));
    }
}

void Caller(void) {
    float forceConst = 3.445;
    EvalFuncOnGrid(^(float x){ return 0.5 * forceConst * x * x; });
}

void main(void) {
   Caller();
}

Blokker, eller block closures, er et kraftig verktøy som kan være vanskelig å forstå. Den beste beskrivelsen jeg har hørt er at det er som å gi metodene dine en ekstra lunge. Ruby bruker kodeblokker til en rekke ting, ofte for å gi en eller annen form for transaksjonsstøtte rundt en operasjon. I funksjonelle språk er konstrukter som tilsvarer kodeblokker de mest grunnleggende byggeklossene i et hvilket som helst program. Smalltalk bruker dem i mye større grad, blant annet fordi Smalltalk mangler nøkkelord som if, else og while:

(theEconomy isInRecession) 
   whileTrue: ['Strange' printString]
   whileFalse: ['Not so strange' printString]

I Smalltalk, som altså er den største inspirasjonen til Objective-C, er altså blokker helt grunnleggende; det er helt umulig å lage et Smalltalkprogram uten dem. Når Objective-C nå har klart seg i tjue år uten er det i en merkelig forkledning Apple ser ut til å introdusere dem i språket, og jeg tror det vil ta lang tid før utviklere føler seg bekvem med å bruke dem i programmene sine.

Kanskje denne hunden har lært de triksene den kan?

Overrumplet av et iPhone-bokmerkeikon

2008-09-19T14:49:02Z

Ikonene på iPhone-skrivebordet mitt graderer jeg til tre nivåer. De viktigste får plass i docken nederst, andreplassen går til den første skrivebordsskjermen og resten ligger tilfeldig på de neste skrivebordene. Og nå nylig dukket det opp et ikon som klarte å presse seg lenger opp enn først planlagt: 37 Signals’ Campfire-ikon.

Etter å ha hatt iPhone i snart to måneder, har det dukket opp stadige flere ikoner på de tre-fire skrivebordene jeg har: de opprinnelige (hvorav flere jeg ønsker å fjerne), alle programmene fra AppStore og bokmerker jeg har lastet ned fra Safari.

Nylig lagret jeg enda et bokmerke på skrivebordet. Det var den smarte webapplikasjonen Campfire som jeg tenkte kunne være greit å ha rask tilgang til. Og jeg ble veldig overrasket da ikonet dukket opp på skjermen. Slik så det nemlig ut:

37 Signals hadde laget et eget ikon for løsningen sin, noe som er både vanlig og fint. Det gir en god iPhone-opplevelse. Men det som hadde skjedd her var enda smartere enn som så. Ikonet deres hadde samme utforming som Apples egne kommunikasjonsprogrammer, Tekstmelding og Telefon: hvitt på grønt, uten andre effekter eller detaljer enn det iPhone-en legger til selv (refleksjon, runde hjørner etc.).

Slik ser Campfire-ikonet ut opprinnelig:

Og denne utformingen (himmelhvelving med grønt gress og ett objektet) har alle de andre 37 Signals-produktene. Så hvorfor gjøre det annerledes på iPhone? Jeg tror de helt bevisst har kopiert utformingen til Apple av to årsaker:

Årsak én: Campfire er et chatteprogram, designet for flere brukere samtidig. f.eks. en arbeidsgruppe. (Tidligere har jeg sitert en samtale vi hadde i Campfire .) Og siden Campfire handler om kommunikasjon, er det vel smart å ligne på andre programmer som handler om det samme? Og for de som ikke ser likheten (bl.a. noen av våre utviklere) kan det jo hende at det kommuniseres underbevisst.

Årsak to: Hvordan unngå at et slikt snarveisikon ikke blir sortert lengst bak i køen? Én løsning kan være å gjøre det så fint og kult, at man ønsker å ha det fremme. En annen kan være å gjøre fristelsen til å plassere det nede i docken, altfor stor. Og for meg ble det for fristende. Kalenderen min røyk og Campfire fikk toppnivåplass.

Så nå skulle jeg nesten ønske at mailprogrammet også var grønt, men da ville jeg kanskje gått lei?

Gratulerer Yr!

2008-09-17T09:27:24Z

Før snakket alle om været. Men det siste året har vi sendt hverandre linker til yr.no i stedet. Ett år har gått siden yr.no ble lansert, uten brask og bram. La oss håpe at feiringen i hvert fall vil ha litt brask og litt bram. Det hadde vært velfortjent.

19. september 2007 ble yr.no lansert (etter noe betatid). Og sommeren 2008 passerte nettstedet en million ukentlige brukere. At alle snakket om været, visste vi. Men at alle også ville surfe etter det, dét visste vi ikke.

Men med en så god løsning som yr.no har blitt, er ikke det rart. Det er gøy å se været de nærmeste dagene i animert form, styrt med musa. Det er praktisk å kunne sjekke været før du drar på ferie, uansett hvor i verden du drar. Egen personlig forside, mulighet til å hjelpe til med oppdateringer, polleninfo, relevante nyheter og fin grafikk, alt man kan tenke seg finnes der. Topp for vanlige brukere!

Lage selv?
Meteorologisk institutt og NRK (som står bak yr.no) har i tillegg gjort en kjempegod jobb med å tilgjengeliggjøre dataene for alle som tør ta utfordringen om å lage en bedre løsning selv. De som har lyst til å lage en værtjeneste skreddersydd for sin hjemmeside, en widget, et program til sin mobiltelefon eller hva det skulle være, ønskes hjertelig velkommen. Les mer på yr.no/verdata.

«Fra og med 1. september 2007 er alle norske meteorologiske data gratis for alle. Null-prispolitikken gjør at kommersielle værleverandører kan bruke ressursene på annet enn datakjøp. For ’Hvermansen’ betyr frislippet bedre værtjenester på Internett.» skriver de på sine sider. Det morsomme er jo at de selv har den beste tjenesten.

Men utfordringen ligger jo der, klar til å bli plukket opp av oss alle… Vi gleder oss til å se hva folk kan komme opp med, og vi er spente på hvordan Yr vil utvikle seg fremover. Men mest av alt er vi bare feststemte og ønsker Yr en super bursdagsfeiring!

Grattis igjen!

Produktplassert sammen med Apple

2008-09-12T14:11:20Z

Den fantastiske Pixar-filmen Wall·E har fått endel pepper på grunn av produktplassering. (Selv synes jeg reklamene før filmen, direkte rettet mot barn, var mye verre.) Men da jeg fikk se Shortcuts tøffe og originale logoplassering på storskjerm på Colosseum, glemte jeg alt og bare nøt robotromansen.

«Er denne nusselige roboten egentlig en iPod? Produktplassering på et nytt nivå.» skriver Dagbladet, både før- og etterfulgt av hele verdens presse. Det er kanskje kritikkverdig at Apple-designeren Jonathan Ives har vært med å tegne Pixar-roboten Eve. (Begge selskap har som kjent felles eiere og interesser.) Eve ser ut som en iPhone, samtidig som Wall·E ser VHS-film på sin iPod. Men Shortcuts lille produktplassering har fått stå helt uoppdaget og ukritisert. På godt og vondt.

Tøff tatovering
Tidligere har vi vært med å sponse konferanser som omhandler vår favoritteknologi for tiden: Ruby og Ruby on Rails, uten å høste altfor mye oppmerksomhet. Men vi trodde virkelig det skulle bli litt blest rundt vår sponsing av Pixar-blockbusteren. Men nei. Det kan virke som om ingen har lagt merke til vår lille annonsering. Så derfor kryper vi til korset, er ærlige og innrømmer at det er vi som tatoverte Wall·E.

På begge armene kan man tydelig se våre karakteristiske Shortcut-striper. Noe både vi, Pixar-teamet og Jonathan Ives syntes kledde Wall·E godt. Og vi skal ikke se bort ifra at Eve også synes det er tøft med litt tatoveringer.

For de som ikke husker hvordan tatoveringene ser ut, her er noen eksempler:

Wall·E flexer og viser stolt frem tatoveringen.

Slik han ser ut på kontoret vårt om dagen, like tøff.

Men Wall·E er og blir en drømmer og en romantiker. Og godt er det.

La oss skryte av korrekte ordsammensetninger

2008-09-11T09:46:35Z

Stort sett klager folk over feil bruk av ordeling og –sammensetning. Og det med rette. Men i dag, hvor bruken av sammensatte ord oftere er gal enn korrekt, er det blitt rom for å vise frem de få som gjør det riktig, og som gjør det godt.

Astronomer mot orddeling heter en gruppe som har gjort seg bemerket med å finne slike orddelingsfeil. På siden deres kan man finne mange gode og morsomme eksempler. Og den er verdt å ta en titt på. For det gjøres mye feil. Overalt, hele tiden.

Kanskje er det mest på grunn av altfor enkle skriveprogram med altfor dårlig ordretting eller dårlige tegnsettere i dagspressen eller at det ikke finnes sekretærer lenger eller rett og slett fordi det slurves for mye. Uansett hva grunnen er, ser vi altfor mange tegnsettingsfeil overalt.

Gode eksempler?
Men hvis målet er at alle skal lære seg (de svært enkle) reglene og slutte å gjøre feil, er det kanskje mer effektivt å vise eksempler på korrekt bruk? Dette tenker jeg, hver dag til og fra jobb, når jeg går jeg forbi Servicesenter for utenlandske arbeidstakere som ligger på Tøyen i Oslo. Navnet er jo et eldorado for feil. Hva med f.eks. Service Senter For Utenlandske Arbeids Takere? Noe slikt ville ikke overasket mange. Men neida, de gjør det helt perfekt:

Selvfølgelig er noe av årsaken til at vi ikke lenger klarer å sette sammen ord på norsk, all den engelsken vi leser og skriver hver dag. For vi har ikke sammensatte ord på engelsk. Men det er vel bare en forklaring, ikke en unnskyldning ?

Stor eller liten bokstav
En annen ting er de store bokstavene. Hvor skal det være store bokstaver i overskrifter? På norsk er det bare første bokstaven i en overskrift eller tittel (og egennavn, selvfølgelig). På engelsk er det første bokstav i hvert ord (med noen unntak, artikler ol.). Men i tillegg til orddelingene gjøres det mange, mange feil her òg.

Så hva da med dette senteret jeg går forbi? De må jo forholde seg til engelsk, siden de er for utlendinger. Og det gjør de, like feilfritt som på norsk. Man blir glad av slikt. Se bare:

Lurer du noengang på hvordan det skal gjøres, se på disse to eksemplene. De er som tatt ut av en lærebok. Og husk: Disse reglene er minst like viktig for oss som jobber med web. Våre tekster vises ikke bare ett sted, én gang. De blir liggende i arkiver, sendes ut som RSS, XML-es til PDF-er, cuttes og pastes inn i årsrapporter osv. osv. (Så les gjerne gjennom før du publiserer.)

Og for all del, prøv å legge merke til de som gjør det korrekt, i stedet for å irritere deg over alle skrivefeil.

Vil du lese mer:
Ikkepedia om orddeling
Korrekturavdelingen om stor forbokstav

Kommuniser med HTTP

2008-09-11T08:40:41Z

Rails har nå endelig fått støtte for bruk av ETags for å avgjøre om innhold har endret seg eller ikke. ETags er eldgammel teknologi; som så mange ting er det først nå vi begynner å forstå hvor nyttig HTTP-standarden faktisk er.

ETags er en ganske enkel måte en HTTP-klient og HTTP-server kan gi hverandre hint om en ressurs har endret seg siden sist man brukte den eller ikke. Rent skjematisk er prosessen slik:

HTTP-klienten, for eksempel nettleseren din, ber om en ressurs – for eksempel http://host.example/people
HTTP-serveren henter ut denne ressursen, for eksempel fra en database eller filsystemet. Den bruker deretter en mekanisme den velger selv til å unikt identifisere dette innholdet, som regel en sjekksum. Sammen med dataene den sender tilbake til klienten sender den denne sjekksummen som HTTP-headeren ETag
HTTP-klienten “husker” denne sjekksummen, og sender den med tilbake til serveren neste gang den spør om samme ressurs, denne gangen som HTTP-headeren If-None-Match. På denne måten forteller klienten serveren at den bare er interessert i innholdet dersom det har endret seg siden denne sjekksummen ble laget
HTTP-serveren henter ut ressursen på samme måte som før, og genererer samme sjekksum. Deretter sjekker den om sjekksummen klienten sendte er den samme som sjekksummen innholdet har nå. Hvis innholdet har endret seg sender serveren innholdet på samme måte som før, og sender med den nye sjekksummen som ETag-headeren
Hvis innholdet derimot ikke har endret seg siden sist sender HTTP-serveren en 304 Not Modified-header og ingen data i responsen. HTTP-klienten vet da at innholdet den fikk sist, som den typisk har lagret i cache, fortsatt gjelder.

Denne prosessen gjør ikke alltid lasten på serveren mindre. I noen tilfeller, for eksempel når man har en HTTP-server som henter filer fra filsystemet, vil serveren kunne beregne sjekksummen med relativt lav kostnad. I eksempelet med filer kan man bruke tidspunktet fila sist ble endret, og dermed slippe å lese inn fila. I andre tilfeller må serveren faktisk hente innholdet og beregne sjekksummen på nytt, noe som gir omtrent samme belastning på serveren som før.

Imidlertid er det to andre faktorer som spiller inn: tiden det tar å transportere selve dataene tilbake over nettet og tiden det tar for klienten å tolke innholdet. Det tar tid å parse HTML, det tar tid å parse CSS, det tar tid å parse XML og javascript.

En slektning: If-modified-since

En lignende situasjon som der man bruker ETags er der klienten selv kan angi overfor serveren kriterier som skal tilfredsstilles for å avgjøre om innholdet har endret seg eller ikke. Til dette kan man bruke headeren If-modified-since. Om du for eksempel lager et mailsystem der klienten kan hente nye meldinger over HTTP kan man tenke seg at klienten sjekker etter nye meldinger hvert femte minutt. Vi kan da tenke oss dette scenariet:

Første gang klienten spør etter nye meldinger returnerer serveren alle meldinger som ligger i innboksen
Klienten “husker” så dette tidspunktet inntil den skal hente meldinger igjen
Når klienten fem minutter seinere sjekker etter nye meldinger sender den HTTP-headeren If-modified-since med tidspunkt for siste sjekk som verdi
Serveren kan da sjekke om det er kommet nye meldinger til denne brukeren siden sist. Hvis det ikke finnes nye meldinger svarer så serveren med en 304 Not Modified, og vi sparer igjen nettverkstrafikken og parsing av responsdataene

For en vanlig webapplikasjon, der klientene er vanlige nettlesere, er antakelig ETags den enkleste løsningen. En nettleser skal nemlig sende med informasjon om siste ETag den fikk, og man legger dermed ansvaret for å avgjøre om innholdet er endret til serveren. For en applikasjon der man kan styre betingelsene fra klienten, for eksempel der klientene er et API, gir imidlertid If-Modified-Since-headeren mer finkornet kontroll. Om vi skjematisk sammenligner de to modellene kan det se slik ut:

ETags

Klienten: jeg er interessert i innholdet /people, sist jeg hørte fra deg var sjekksummen for dette innholdet “abscder90”
Serveren: OK, innholdet du har er fortsatt gyldig

If-Modified-Since

Klienten: gi meg innholdet /people bare hvis det har endret seg siden klokka sju imorges
Serveren: OK, innholdet har ikke endret seg

Hvis vi for eksempel tenker oss at Twitter hadde støttet If-Modified-Since-headeren kunne en API-klient spurt etter nye meldinger siden et gitt tidspunkt. Serveren kunne så hatt en kolonne i sitt User-objekt som holder rede på sist en ny melding ble mottatt. Ved hjelp at en enkelt SQL-spørring kunne serveren så avgjort om den kan sende en 304 Not Modified eller om den må inn og hente nye meldinger fra databasen. Om man i tillegg tar denne litt lenger kunne vi tenke oss at dersom innholdet har endret seg sender serveren bare det nye innholdet tilbake. HTTP-spesifikasjonen har en egen header til dette formålet: If-Range. Med If-Range kan man angi både en ETag og en dato. På denne måten angir klienten at den har en delvis representasjon av innholdet, og at den bare er interessert i det som er nytt siden sist. Serveren skal da svare med 206 Partial content header, sammen med endringene.

Det er bra at Rails har fått støtte for ETags, men dette er bare begynnelsen. HTTP-spesifikasjonen ble plutselig langt mer interessant lesning enn jeg hadde tenkt meg.

Rails-tips: virtuelle attributter

2008-07-30T12:34:25Z

Noen ganger ønsker du å vise felter i et skjema som ikke direkte korresponderer med felter i databasen. Her er et tips på hvordan du kan gjøre dette på en mer elegant måte.

La oss si at du har en modell User som har et for- og etternavn, slik at du kan sortere brukerlistene dine etter for- eller etternavn. Når du viser kunden websida for brukerregistrering protesterer de imidlertid på at det er to felter; det blir for mye tabbing etter deres smak. Du vurderer å migrere dataene dine til å ha et felt for name istedet for de to feltene du har, men det finnes en enklere løsning.

Først lager du to metoder i User-klassen din: en getter og en setter for navn:

class User
  def name
    [first_name, last_name].join(" ")
  end

  def name=(a_name)
    first, last = a_name.split(' ')
    self.first_name = first
    self.last_name  = last
  end
end

Ved å lage disse to metodene ser det ut som users-tabellen din har et name-felt, men det har den ikke – den har to metoder som henholdsvis setter og leser to andre felter i modellen. En ting du kanskje ikke visste er at disse metodene kan brukes i en rekke Rails-metoder, for eksempel slik:

john = User.new(:name => "John Doe")
jane.update_attributes(:name => "Jane Doe")

Grunnen til at dette fungerer er måten Rails fungerer på. For hvert nøkkel/verdi-par som sendes inn til disse metodene (new build, update_attributes) kalles metoden som ligger i symbolet med verdien som ligger i verdien. For eksempel a_user.update_attributes(:name => "John Doe") vil metoden name= kalles med parameteret "John Doe". Dette kan du benytte deg av. La oss si at du har en UsersController med en create-action som ser slik ut:

def create
  @user = User.new(params[:user])
  if @user.save
    redirect_to "/" 
  else
    render :action => "new" 
  end
end

Hvis du har et form som ser slik ut:

<% form_for(@user) do |form| %>
<%= form.label :name %>
<%= form.text\_field :name %>
<%= submit_tag %>
<% end %>

og du fyller inn “Jon Hansen” i name-feltet, vil disse parametrene sendes inn til create-action’en din:

  user => {:name => "Jon Hansen"}

Dermed vil dette hashet sendes inn som parameter til User.new-action’en i controlleren, og first_name og last_name-feltene vil bli satt slik du ønsker.

Et mer konstruert eksempel kan være om du har en User-klasse og en Mood-klasse. Hver User har et humør (Mood), som representerer et humør denne brukeren har nå; la oss si at du ønsker å kunne finne et humør (Mood.find_by_name 'Tired') og finne alle brukere som har dette humøret. Om du skriver noe som:

class User
  belongs_to :mood
end
class Mood
  has_many :users
end

har du en enkel datamodell som støtter dette. Men selv om du nå har en egen modell for alle humørene ønsker du ikke at brukeren må gå inn på en egen side for å lage nye humører, du ønsker bare at brukeren skal kunne skrive inn en tekst i et tekstfelt, og så blir det riktige humøret funnet eller opprettet:

class User
  belongs_to :mood
  def current_mood
    mood.name
  end

  def current_mood=(a_mood_name)
    a_mood = Mood.find_or_create_by_name(a_mood_name)
    self.mood = a_mood
  end

Du kan nå lage eller hente et Mood-objekt basert på en tekstverdi. Og for å la brukeren skrive inn en tekst på profilsida si for å angi humør kan du bare bruke:

<% form_for(@user) do |form| %>
<%= form.label :current_mood %>
<%= form.text_field :current_mood %>
<% end %>

og du trenger ikke endre en linje i modellen din.

All teknologi trenger en katalysator. Og litt guldfeber

2008-07-29T11:33:21Z

Med seneste iPhone oppdateringen ga Apple oss entligen muligheten til å laste ner tredjeparts applikasjoner via iTunes.

Desverre virker det være litt for mye guld-feber syndrom over mange av de applikasjoner som er til salgs; de tilbyr egentligen ikke noe som er værdt så veldig mye.

For Ruby var katalysatorn uten tvivel Rails. Vi så muligheterne Ruby gav oss, i begynnelsen på en mer indirekte måte gjennom at det hjalp oss til å bli mer produktive. Men efter en stund inser vi styrken i Ruby og det er da vi virkelig får til kule ting.

Det samme gjelder Erlang (om enn ikke i like stor grad), web 2.0 illusjonen om at alle bare må kunne skalere inn i himmelen har fått folk til å få opp øynene for Erlang med sine lettvekts-prosseser og lovord om nesten oendelig skalering.

Men den virkelige katalysatorn ligger nok i kombinasjonen teknologi som er nyttig hos forbrukeren og utvikleren som blir imponert av muligheterne selve teknologin (eller implementasjonen) gir. Men ikke minst åpenbaringen om at denne teknologin faktiskt kan hjelpe oss utvikle et produkt vi har haft i tankene en lengre tid. Og den endelige konsekvensen av en sådan katalysator er muligheten for folk at tjene penger på den.

Akkurat nå virker det som at Cocoa på iPhonen er akkurat den teknologin, Objective-C sammen med Cocoa er virkelig fine ting:

Kul teknologi, med mange år på nakken som gir et komplett oppsett med løsninger på domene-spesifike problemer (Cocoa)
Kul dings som gir forbrukeren “vil ha” følelse (iPhone)
Muligheten at tjene penger fra “soverommet” (iTunes app store)

Kul teknologi

Cocoa er et rammeverk med otrolig mange fine løsninger på problem som er relativt spesifike for GUI applikasjoner og sammen med språket Objective-C gir det samme følelsen av produktivitet som Rails gir oss. For en teknolog som mig er det nok dette som gjør mig mest glad.

Kul dings

Det er ikke mange andre produkter en en iPhone som får folk til å stå tidligt opp om morgonen for at stille sig i kø utenfor butikken i håpet om at få kjøpt sig en iPhone idag, eller dele tvivelen (og rykten) med andre om hvorvitt butikken faktiskt har fått inn de på lager denne dagen eller ikke.

Muligheten for vinst

Visserligen finnes det alltid en mulighet at ta betalt for produkter og tjenester, hele samfunnet bygger trots allt på dette. Men med iTunes App Store åpner det faktiskt enda mer for den lille utvikleren med en bra ide som jobber fra soverommet sitt at tjene penger gjennom App Store. Vilke pris-modeller som kommer fram er derimot ganske ovisst enn så lenge, det krever ikke mye matematikk for at inse at man ska selge en del for tjene inn det som faktiskt koster at utvilke applikasjonen.

Akkurat det siste er vel ganske tydeligt i App Storen akkurat nå. Ser man i “productivity” seksjonen ser man ikke helt uventet minst 35 forskjellige todo-liste eller GTD applikasjoner. Grunnen til det er nok at todo-list-applikasjonen er på samme linje som at skrive sin egen blogg-programvare; det er den avanserte varianten av “hello world”.

Utvalg er flotte saker, men en liste er en liste og det er begrennset hvor mye innovasjon det får plass der. For at ikke snakke om kjedelige twitter-klienter, dåligt lagde pusselspil, poker eller kanskje den beste av de alle: Dice, 6 kroner vel brukt—let the ~~dice~~ $$$ roll!

Poenget her er vel egentligen at om du sitter med en iPhone applikasjon i ermet, så håper jeg virkelig at den ikke er av den typen jeg har nevnt. Ikke lag en iPhone versjon av siten din som i bunn og grunn ikke er mere enn en glorifisert RSS lesere. En sån har jeg allerede. Jeg ser spesiellt på dere alle norges aviser, ikke begynn med det mest åpenbare dere kan komme på. Dra den litt lengre så at applikasjonen faktiskt drar nytte av muligheterne som gis. Jeg har all respekt for den tiden det tar å lage noe, for den er alltid større enn man tror og selvsagt skal der være plass til den lille utvikleren med den lille idéen (for de kan være like mye vært som de store), men tenk iaf efter en gang for du lager noe (og ikke minst prøver å ta betalt) for noe som allerede finnes i App Storen.

En ting er iaf sikkert, iPhone gir nye muligheter presentert i finere pakke enn vi har sett førr, men likevel: lag noe som faktiskt bruker de muligheter iPhonen gir dig som utvikler; GPS, trykkfølsom skjerm og nett. Noe som binder iPhonen sammen med omverdenen, ikke bare noe som kopierer den.

37Signals, Colorpicker, Getting Real og... Shortcut

2008-07-25T11:25:54Z

37Signals har kommet med ny color picker i Basecamp nylig. Spennende for dem, og grunnlag nok for en sunn diskusjon hos oss.

Vi i Shortcut har alle sterke meninger om mye. Deriblant 37Signals og deres metoder og produkter. Og selv om vi er plassert forskjellige steder (Råduhsgaten, ute hos kunder og én i Buenos Aires), går dialogen fritt… takket være 37Signals’ program Campfire.

Så, i kjent 37Signals-stil er det gøy å dele vår synsing og dialog med dere. Kom gjerne med kommentarer nederst på siden.

Johan: Er jeg virkelig den eneste som ser “getting real” som et stort markedsførings-materiale for 37s?
August Lilleaas: er vel det også, ja ser ikke for meg at det var markedsføring som var hovedmotivasjonen til boka, men
Johan: Nei. Jeg syns bare det blir så åpenbart, som en salgs unnskyldning for den typen apper de lager syns det er fint de tar et “standpunkt” med at “dette gjør vi”, men jeg irriterer mig på preikendet
August Lilleaas: synes ikke appene deres trenger noen unnskyldning unnskyldning for hva, egentlig?
Marius: For at det ikke er flere features antar jeg. Tradisjonelt har man jo vurdert software etter antall features (innkjøpere setter opp digre matriser der de sammenligner hva X, Y og Z kan gjøre) – og antar at den med flest features er best.
Johan: appene deres trenger kanskje ikke noen unnskylding iom at det er det de står for men jeg mener at gettingreal blir som en slags unnskylding når folk kommer med forslag til appene ders “no way, hallo. vi driver med getting real her, ikke noe sånt tull som at du kommer med forslag. ikke lov.” noe men folk svelger det med hud og hår som om det vore en salgs ultimat sanning blir så lett “The Church of Getting Real” over det
August Lilleaas: synes det er greit å ikke høre på forslag, opp til dem. De er ikke monopolister, man kan jo velge noe annet™. Er det forresten sånn at de konsekvent ikke hører på forslag fra folk?
Johan: er iaf en del som klager på den customer service de får fra de har jeg sett de gjør små fine apper uten tvivel men de er så ensidige kanskje er ingenjören i mig, men http://www.37signals.com/svn/posts/1154-ne… is that it? er det virkelig allt som ska til for at 32 ska kommentere med “wow that’s amazing”
Marius: Noen som har hørt noen rykter om det er noe nytt på gang fra 37s?
August Lilleaas: synes den er kjempefin jeg =) kan ikke huske å ha sett en så sexy colorpicker før
Johan: de ser jo sån ut alle sammen?
August Lilleaas: selve colorpickeren ser vel ut som alle andre colorpickere, ja
August Flatby: Greia med 37signals er at de greier å polarisere brukerne: enten elsker man det de lager, eller så hater man det. I begge tilfeller greier man å skape debatt og dermed god PR.
Johan: da tror jeg hater dem ;)
August Flatby: Det viktigste er at folk ikke er likegyldige. Ref Zunes
Marius: Kan det ikke være sånn at en måte å lykkes på er å polarisere brukerne sine – og at dette passer bra hvis man er cocky av type. En annen måte er å lage noe som er så jævlig bra at folk ikke føler det er noe alternativ – la oss kalle det Google-metoden.
Johan: ja ikke sant det er jo mye mer intressant og prøve å lage simplicitet ut fra kompleksitet enn å lage en simpel wiki+todoliste der en liten colorpicker er det heteste på tre måneder
August Lilleaas: nåh har hørt folk si at de kunne laget basecamp på en helg men det er nettopp silke ting som at de bruker 3 måneder på å få småting perfekt som gjør basecamp til det det er
Johan: det er ikke tiden det tar å lage noe jeg mindregjør, det er resultatet
Marius: Jeg forsøkte å bruke Basecamp på mange prosjekter i ett år, og du vil ikke tro hvor mange ting man savner så snart man slutter å la seg sjarmere av kubjeller og forsøker å få gjort noe
Johan: jeg har all respekt for selve prosessen å lage appen, mitt poeng er at jeg synes det er ganske ointressant resultat
August Lilleaas: @marius: ja, det er vel det 37s vil også. De har mange brukere av basecamp som synes basecamp har alt de trenger s/har alt de trenger/har alt som trengs/
Marius: Mitt poeng var at jeg var fullstendig solgt på alt de sa om Basecamp og mente det passet fantastisk til våre behov (=Fatguy m/partnere og kundene våre). Så markedsføringa fikk meg helt hekta. Men så skulle det vise seg at det var ubrukelig i praksis. Man kan ikke kommentere items i todolista, det er ikke mulig å linke en melding til fx et writeboard eller omvendt, det funka rett og slett ikke. Resultatet vat at jeg ble sittende med en tekstliste i Textmate og vi samarbeidet ved å dele et dokument i Google Docs.
John Eivind: Wow, så morsom samtale dere har hatt… Jeg har gått fra å bare mislike 37s da jeg begynte i Fatguy med Marius & co. og alle digget disse appene som jeg ikke klarte å skille fra hverandre. Fortsatt synes jeg det de lager ikke er stort nok til å være så store i kjeften som de er. Og fullstendig enig med Johan; wtf en colorpicker? Javel… (Dessuten var den gml bedre for der kunne jeg legge inn fargeprofil-hex’en. Skal man detalj-style individuelt, er det gjerne for matche noe som finnes, og som har hex’er.)
John Eivind: Men likevel, nå er jeg veldig fascinert av tankene til 37s. Jeg ble utrolig inspirert av GettingReal i ferien, og synes de sier mye smart som vi bør tenke på. Alle ut-på-tur-ryggsekk-allegori-appene interesserer meg ikke, men de er kloke mennesker.
Og de er jo enig med Johan, under markedsføringskap. nevner de å skrive bøker (nudge nudge) for å markedsføre seg selv… Der ér det de gjør!
John Eivind: Skal vi gjøre hva de gjør? Poste hele denne dialogen som en blogg? :-D
Marius: +1

Ironin i at dette diskuteres via Campfire borde være tydelig…

MVC kan være så mangt

2008-07-04T07:29:19Z

Som Rails-utvikler har man god erfaring med en måte å gjøre MVC-programmering på. Cocoa viser oss en helt annen.

Cocoa, rammeverket for Mac-applikasjoner, er på samme måte som Rails basert på MVC – Model View Controller. Begrepet ble lansert av Trygve Reenskaug da han besøkte Xerox PARC (du vet, der Steve Jobs fikk alle de gode ideene) i 1978, Reenskaug beskriver det slik:

I created the Model-View-Controller pattern as an obvious solution to the general problem of giving users control over their information as seen from multiple perspectives.

MVC er ikke så mye en fasit for hvordan man bygger noe som et ideal eller prinsipp. Rails gjør det på sin måte, primært ved å gi oss tre mapper i Railsprosjektene vi lager: controllers, views og models. Ettersom webben er tilstandsløs (webserveren “husker” ingenting fra forespørsel til forespørsel) har controlleren typisk et tungt lass å dra på webben; den skal håndtere HTTP-headere, request-parametre, routing, styring av innholdstyper osv. I Rails er mange av disse oppgavene håndtert av selve rammeverket, men idet Rails overlater kontrollen til en controller-action du har skrevet har det allerede foregått mye i kulissene.

Hvis man sammenligner med en vanlig GUI-applikasjon er ting ganske annerledes. Her har programmet gjerne all tilstand selv, og svarer umiddelbart idet brukeren klikker på en knapp eller velger noe fra en meny. I motsetning til en webapplikasjon, der nettleseren først skal koble seg til serveren, sende over parametre, vente på svar og gjøre noe med responsen, foregår alt dette i samme prosess i en GUI-applikasjon.

I Cocoa er det en mye tettere integrasjon mellom viewene og controllerne enn på web, noe som har gitt meg ny innsikt i det egentlige forholdet mellom disse to. Veldig mye av controller-koden i en typisk Rails-applikasjon er ca 50% initialisering av tilstand og objekter, innlesing av parametre osv. I Cocoa er controlleren mer som en lydig slave for viewet. Et bra eksempel er når du skal bruke en tabell som skal inneholde en liste med data i en Cocoa-applikasjon. Du kan da bruke en NSTableView-kontroll i GUI-et ditt. Denne kontrollen kan du gi en datakilde (data source), som er ansvarlig for å levere data til tabellen og håndtere innlegging av nye rader, sletting osv. Og her er det Cocoa virkelig skiller seg fra webutvikling. Istedet for at man så forteller datakilden (eller viewet) at den skal legge inn en rad med kolonner x, y og z i tabellen er det helt omvendt i Cocoa. Tabellen vil istedet sende hovedsaklig to meldinger til viewet:

tableView:numberOfRowsInSection:
tableView:objectValueForTableColumn:row:

Ikke la deg skremme av at dette er Objective C, dette er bare to meldinger som et objekt som er satt til å være datakilde for en tabell vil motta. Den første meldingen spør datakilden om hvor mange rader tabellen skal inneholde, den andre spør om hvilken verdi som skal vises i en gitt kolonne i en gitt rad. Cocoa vil altså først spørre hvor mange rader tabellen skal ha, og så vise det antall rader som er synlig i grensesnittet ved å spørre etter verdier for hver kolonne i hver rad. Idet brukeren scroller nedover i tabellen vil datakilden igjen spørre etter nye rader og kolonner – viewet sørger altså selv for å hente de dataene som er relevante for grensesnittet.

Det har de siste månedene blitt ganske populært å erstatte paginerte sider (med Google-lignende linker for hver side i resultatsettet) med lister som scroller uendelig – der nye data hentes idet brukeren scroller siden. Jeg har ikke sett nøye på hvordan dette løses, men en god kandidat kunne vært å bruke Cocoas tilnærming.

Igår satt jeg og fiklet litt med hvordan man lager iPhone webapplikasjoner med Dashcode, da jeg oppdaget at Apple bruker akkurat samme tilnærming når man skal lage en dynamisk liste i HTML/javascript for iPhone. Jeg la inn en liste-widget i GUIet og sa at denne skulle bruke en datakilde for å hente data, hvorpå Dashcode laget et javascript-objekt som så slik ut:

// This object implements the dataSource methods for the list.
var listDataSource = {

    // Sample data for the content of the list. 
    // Your application may also fetch this data remotely via XMLHttpRequest.
    _rowData: ["Item 1", "Item 2", "Item 3"],

    // The List calls this method to find out how many rows should be in the list.
    numberOfRows: function() {
        return this._rowData.length;
    },

    // The List calls this method once for every row.
    prepareRow: function(rowElement, rowIndex, templateElements) {
        // templateElements contains references to all elements that have an id in the template row.
        // Ex: set the value of an element with id="label".
        if (templateElements.label) {
            templateElements.label.innerText = this._rowData[rowIndex];
        }

        // Assign a click event handler for the row.
        rowElement.onclick = function(event) {
            // Do something interesting
            alert("Row "+rowIndex);
        };
    }
};

Her har man altså et javascript-objekt med to funksjoner der den ene skal returnere antall rader i lista og den andre skal returnere data for en rad i lista. Man har altså en widget for websida som bruker en slags protokoll for å snakke med datakilden sin. Det er jo – som eksempelkoden antyder – trivielt å bruke datakilder på nettet til å drive listene, for eksempel med Ajax/XmlHttpRequest. Det virkelig interessante er å introdusere et slags controller-lag i javascript, ettersom dette er tilgjengelig mens siden kjører. Om man ønsker å oppdatere dataene i en slik liste trenger man ikke løpe gjennom alle radene på nytt, man sender istedet en melding til objektet:

document.getElementById("list").object.reloadData();

Her har vi et HTML-element som heter list, der vi forteller datakilden (object) å laste dataene på nytt. Det som da skjer er at datakilden vår vil bli sendt meldingene numberOfRows() og prepareRow() på samme måte som før.

Jeg tror vi ser omrisset av en ny generasjon webapplikasjoner der ute nå.

Save webpage as Web Application

2008-06-12T13:00:41Z

I sammenheng med utviklerkonferansen WWDC 2008 som pågår i disse dager, har Apple sluppet en utviklingsutgave av favorittnettleseren sin: Safari 4, som har ihvertfall én ny funksjon jeg digger.

Det er ikke lenge siden jeg ble henrykt over Fluid og hva det kunne gjøre med tjenester jeg (altfor) ofte bruker på nettet. Nå ser det ut til at Apple har stjålet ideen deres. (Eller kjøpt den? Noen som vet?).

Et nytt punkt har dukket opp i menyen deres, under File: Save webpage as Web Application. Og når man velger det, lager Safari det nye «programmet» automatisk. HTML-tittelen foreslås som programnavn, og det plasseres i en ny mappe ‘Safari Web Applications’ under applications.

Ikonet (som jeg er litt for opptatt av) er en autogenerert thumb av websiden, med et lite safarikompass oppå. Ganske fint. Og skulle du ønske et annet ikon, bare bytt ut med vanlig copy-paste.

Så hva har egentlig denne nye Safari-funksjonen som Fluid ikke har? Fint lite. Mye lettere tilgjengelighet, og litt finere ikon.

Så hva skjer nå?
En ting som er mer interessant enn genererte ikoner, er hvordan web- og desktopapplikasjoner nå smelter mer og mer sammen. Hva vil egentlig skje med nettleseren nå som funksjonene vi bruker blir egne program og nyhetene vi leser kommer i egne RSS-lesere?

Hva med mail? Mange har gått tilbake til nettmail, ikke bare Gmail, men også supre nye løsninger som f.eks. nydelige Zenbe.

YouTube-filmene er vel bedre å se i Miro enn på YouTube?

Office-pakka? Trenger vi den når vi har Google Docs?

Ikke rart Microsoft er skuffa over å ikke få kloa i Yahoo. exe-fil-produsentene går kanskje en tøffere tid i møte?

Jeg gleder meg til alle har laget egen desktop-versjon av Facebook. Etter en stund kommer noen til å bli dagens helt for å ha laget egen nettleser bare for Facebook. Skikkelig meta, eller hva? «Endelig kan jeg surfe rundt på nettet, uten å lukke Facebook»

:-D

Standardoppsett på Rails

2008-06-06T08:43:42Z

Ikke bruk Rails-kommandoen når du starter en ny Rails-app. Lag ditt eget standardoppsett og versjonskontroller det, slik at du kan hente ned denne Rails-appen når du starter et nytt prosjekt. Det sparer deg for mye tid og repetisjon i forhold til å skrive rails [prosjektnavn] hver gang.

Jeg har laget mitt eget standardoppsett som jeg bruker når jeg starter et nytt Rails-prosjekt. Personlig får jeg omtrent 1x fantastisk, revolusjonerende web 2.0-idé i uken, og da er det praktisk å slippe å skrive autentisering, hente ned jQuery, lage en settings.yml, mailer for «glemt passord», profilredigering, form builders etc. hver eneste gang.

Det finnes riktignok plugins for mesteparten av dette, men selv disse må lastes ned, settes opp og konfigureres. Dermed er det like greit med et standardoppsett, selv om et slikt oppsett ikke er mer enn en blank Rails-app med 3 plugins installert.

Her er et forslag til hvordan et slikt standardoppsett kan se ut.

Uløselige problemer?

2008-05-27T20:06:08Z

Stilt overfor noen oppgaver og problemstillinger (og datamodeller og algoritmer) kan man nesten fysisk føle sin egen hjernes begrensninger. Så snart man begynner å få tak på den ene enden av problemet, har man mistet grepet på den andre enden.

Jeg jobber for tiden på et prosjekt med datamodeller av hinsides kompleksitet. Stilt overfor oppgavene i prosjektet alene, er kompleksiteten på grensen av hva jeg greier å få mental oversikt over. Følgene av denne manglende oversikten er lav produktivitet, og motvillighet mot å gjøre dyptgripende endringer i koden.

Heldigvis har jeg hatt muligheten til å jobbe med parprogrammering på prosjektet sammen med arkitekten bak systemet. Dette gjør at kompleksiteten smyger seg ned på et forståelig nivå. På dette nivået blir problemene lettere å angripe, og vi får løst oppgavene (og refaktorert datamodellen!) i raskt tempo. Parprogrammering er i dette tilfelle effektivt fordi kompleksiteten er for stor til å passe inn i én persons hode, men passer fint i hodene til to personer.

Kunsten er altså å dra kompleksiteten ned til ett overkommelig nivå, hvilket øker både arbeidsgleden og produktiviteten. Da begynner det å nærme seg kollektiv intelligens, hvor man vil være i stand til å kollektivt forstå og løse problemer som er for komplekse til å løses av én eller 100 personer, men plutselig blir overkommelig når 101 personer blir satt på oppgaven.

Noen eksempler på bruk av kollektiv intelligens til å løse oppgaver – selv om skillet mellom kollektiv intelligens og god gammeldags dugnad kan være litt uklart:

Dell bruker en form for kollektiv brainstorming og rangering av ideer til å komme opp med nye produktideer på Dell Ideastorm

Google Translate lar brukere forbedre kvaliteten på oversettelsene: Suggest a better translation for ”we do not have a slurvete job”

reCAPTCHA er et prosjekt som bruker ord som ikke er lesbare med dagens OCR-programvare som tradisjonell CAPTCHA-input på websider. Dermed bidrar man som sluttbruker til å kvalitetssikre digitalisering av bøker uten at man nødvendigvis trenger å være klar over nytten i det man gjør.

World Without Oil Et ARG (alternative reality game) som forsøker å benytte spillernes kollektive intelligens til å løse en tenkt miljøkrise.

Hvis man kan kombinerer kollektiv intelligens med flashmob-aktig teknologi (broadcast SMS, for eksempel) burde det kunne oppstå interessante muligheter. Rask og intelligens respons i krisesituasjoner, for eksempel?

Nettverk

2008-05-08T18:00:11Z

Vi i Shortcut har en hang mot alternativer til relasjonsdatabaser.

Det er mange gode grunner til å være glad i relasjonsdatabaser, men disse er ikke blant dem:

Iterativ utvikling. Relasjonsdatabasene er veldig gode på å håndheve struktur på dataene sine. Dette betyr at man må fortelle databasen nøyaktig hvilke felter en tabell skal innehold og hva slags data som kan lagres i disse feltene. Innenfor iterativ/smidig utvikling har man gjerne en tendens til å ønske å dyrke datamodellen min mer som en kjøkkehage enn en romferge. Den rigide strukturen i relasjonsdatabasen kan derfor bli et irritasjonsmoment i et smidig prosjekt.
Kompatibilitet med objektorientert utvikling. Relasjonsdatabasens hovedkonsepter er databaser, tabeller og rader. I tillegg har de fleste databasemotorer støtte for innebygd logikk (views, triggere, lagrete prosedyrer), og språket man snakker med mot relasjonsdatabasen heter SQL. Innenfor objektorientert utvikling har man objekter, klasser og metoder. Når man de seinere årene har fått ganske gode verktøy for å representere objekter i en relasjonsdatabase har dette mindre å gjøre med relasjonsdatabasens fortreffelighet enn dens utbredelse.
Støtte for delvis strukturerte data. Som nevnt ovenfor er en av relasjonsdatabasens styrker at den har et strengt regime for hva slags type data den aksepterer. Skal en rad i en people-tabell kunne ha en first_name-kolonne må den kolonnen ligge i databaseskjemaet, punktum. Om man tar en kikk på en gjennomsnittlig databasedump fra et noen år gammelt system vil man oppdage at hver tabell plutselig har fått mange flere kolonner enn man opprinnelig tenkte. Dette er fordi skiftende behov har ført til at man må holde følge. Kanskje var det en kundegruppe som måtte ha et ekstra felt i databasen, så dukket det plutselig opp i databaseskjemaet uten at noen av de andre kundene trenger det. Dermed vil man se at det blir vanskeligere å vanskeligere å lese noen slags logikk ut fra databaseskjemaet, særlig når bare en av hundre rader har en verdi i en gitt kolonne.
Støtte for nettverksorienterte data. Om du har jobbet med en relasjonsdatbase noen gang: tenk deg følgende scenario. Du har laget et sosialt nettsted (gjesp), der brukerne angir andre brukere som sine venner. Tenk så at kunden din kommer og vil vite hvordan en bruker X er koblet sammen med en bruker Y. Sett deg gjerne ned med penn og papir; jeg er villig til å vedde på at du kommer opp med en SQL-setning som får deg til å føle deg skikkelig macho.

Tenk deg så at databasen du brukte var orientert rundt relasjoner mellom objektene i systemet. At de to typen objekter som finnes i systemet var objekter og relasjoner mellom objekter. Tenk deg videre at denne databasen var skikkelig god på å følge disse relasjonene mellom objektene og ga deg et språk for å uttrykke hvordan X og Y er forbundet.

Våre venner i Java-verden har laget en slik database, som er orientert rundt en nettverksfilosofi. Og etter å ha dummet meg skikkelig ut har jeg fått det til å spille sånn noenlunde i JRuby.

class FriendshipTest < Test::Unit::TestCase
  def test_basic_friendships
    Person.transaction do
      neo = Person.new(:first_name => "Neo")
      assert_equal("Neo", neo.first_name)
      morpheus = Person.new(:first_name => "Morpheus")
      assert !neo.knows?(morpheus)
      neo.meets(morpheus)
      assert neo.knows?(morpheus)
    end
  end
end

Testene kjører, og dataene lagres i Neo4j-databasen. Grunnen til at jeg bare viser fram testkoden her er at jeg skrev den først, og implementasjonen derfor neppe vil imponere noen ennå. Det som er ganske kult er at Jruby er blitt modent nok til at man kan plukke fram et nytt og lovende javabibliotek og regne med at det kommer til å fungere i Jruby. Nå har jeg aldri vært spesielt glad i Java, men jeg merker at allerede etter en liten time med hacking i Ruby begynner et API å ta form som jeg kan like.

Der java-APIet for en transaksjon ser slik ut:

Transaction tx = Transaction.begin();
try
{
   // all Neo operations that work with the node space, for example:
   // Node firstNode = neo.createNode();
   // ... etc ...
   tx.success();
}
finally
{
   tx.finish();
   neo.shutdown();
}

... føles det mer Ruby-aktig å gjøre noe mer ActiveRecord-lignende i Ruby:

class Person
  def self.transaction
    @@neo = EmbeddedNeo.new("test")
    tx = Transaction.begin
    begin
      yield
      tx.success
    rescue Exception => e
      raise e
    ensure
      tx.finish
      @@neo.shutdown
    end    
  end
end

Dermed får man noe som ser ut som en transaksjon inn i Ruby-klassen sin:

Person.transaction do
  me = Person.new
end

Har en sterk følelse av at dette ikke er siste gang vi skriver om Neo4j her…

Diskuter NRKs måldokument på nett

2008-04-15T09:56:44Z

NRK ser ut til å seile opp som et av de mest interessante offentlig eide virksomhetene i dagens Norge.

For ikke lenge siden la NRKBeta ut samtlige episoder av Lars Monsen-serien på Bittorrent, deretter annonserte de NRKBeta-doktrinen

I hereby coin the NRKbeta Doctrine: The only way to control your content is to be the best provider of it.

Nå har de åpnet for diskusjon om NRKs måldokument på nett, der de blant annet spør om det bør stå i måldokumentet at alt NRKs innhold skal distribueres ukryptert og i åpne formater. Det er forfriskende og utfordrende å se denne formen for demokrati, der man involverer kundene sine (som i NRKs tilfelle også er eierne) i målformulering og utforming av kringkastingspolitikken. Demokrati og medvirkning har kanskje virket gammeldags og irrelevant i en tid der alt handler om lønnsomhet, NRK tar her en helt ny vri.

'Getting Things Done' og selve livet...

2008-04-08T11:04:59Z

Overalt oppstår det situasjoner hvor ting ikke blir gjort fordi noen har lovet å gjøre det. Dette har jeg erfart både på jobb, i organisasjoner og blandt venner. Og så fant jeg plutselig den teksten som pushet meg til handling som ung…

Jeg tror vi ønsker altfor godt, og overvurderer oss selv. Jeg vet ihvertfall at dette gjelder meg: Jeg svarer alltid ja når noen trenger hjelp til noe jeg tenker tar kort tid. Og oppgaven i seg selv tar gjerne kort tid, men å få satt av den tiden, det tar lang tid. Og blir ofte aldri gjort.

David Allens (snart så altfor kjente) bok ‘Getting Things Done’ handler om hvordan man kan effektivisere selve utførelsen av det man skal ha gjort. Målet er å ikke bruke opp tiden på planlegging, men de faktiske oppgavene. Og den boka har hjulpet mange langt på vei, og blitt en velfortjent Must Read. (Selv om jeg har erfart at boka har ført til mye prat og lite handling mange steder.)

Men jeg har også brukt en annen tekst for å få ting gjort…

Her om dagen leste jeg gjennom noen gamle papirer fra ungdommen, og der fant jeg igjen et dikt av Rolf Jacobsen, om selve livet: ‘Dine tanker, det du gjorde’. Og da husket jeg at dette var min store pådriver for å få gjort ting på den tiden. For meg handler diktet om at det er handling som teller, ikke alle gode intensjoner: Man blir husket for det man får gjennomført. Og fortsatt, den dag idag, opplever jeg den teksten som en større pådriver, enn et smart og gjennomtenkt prosjektstyreverktøy.

Prøv det! Les diktet til morgenkaffen, og se hva som skjer:

Dine tanker, det du gjorde…
av Rolf Jacobsen

Dine tanker, det du gjorde
skal ikke dø
men dine håp
skal dø, din glede
dine behov
skal dø, dine ønsker, krav
dø men ikke
det du fikk gjort,
det du fikk gjort,
tross alt fikk
gjort, skammelig
det er lite
men det lever,
skulde vært mer,
det lever
men
det du ønsker
skal dø, dine håp skal dø
snart, men
det du tenkte, hva
tenkte du, skal leve og
hva gjorde du,
fordømt, ja hva
gjorde du
... du

Kilde: Jacobsen, Rolf, «Samlede dikt», Gyldendal norsk forlag

Gratulerer, Tinde!

2008-04-07T14:11:24Z

Tinde.no ble lansert i ny drakt og med helt ny teknologi forrige uke.

Tinde har på 3 måneder blitt skrevet helt om til å bruke Ruby on Rails og søkemotoren til Fast. Shortcut har jobbet med prosjektet siden like etter jul, og er stolt for å ha vært med på å bygge landets største nettsted skrevet i Rails på knappe nitti dager. Med sine circa 100.000 unike brukere i uka peker Tinde nese til de som påstår at Rails ikke skalerer.

Når nå den eksisterende løsningen er flyttet over på ny teknologisk plattform står lanseringen av nye tjenester for døra. I de kommende månedene vil Tinde lansere nye tjenester, og sikter spesielt på å koble redaksjonelt innhold fra Edda-konsernets medier med rubrikkannonser på Tinde. Vi gleder oss til å jobbe videre med Tinde, og gratulerer med vellykket lansering!

Husker du den første RubyFools?

2008-03-29T12:34:10Z

I det internasjonale Rubymiljøet er det noen ganske få som stadig vekk trekker fram den første RubyConf, som ble arrangert i 2002. Ifølge Dave Thomas blir skrytet fra disse få utvalgte verre og verre jo større Rubymiljøet blir. Ifølge Dave, som var der, var det fire deltakere og en hund til stede, så ekslusivt var det.

Nåtidens Rubyconf selges ut på noen få timer, og RailsConf trekker tusenvis av deltakere hvert år. Der kan oldtimerne høste ære og berømmelse for at de var så tidlig ute. Om noen få dager går historiens første RubyFools av stabelen i Oslo, og store navn som nettopp Dave Thomas og Yukihiro “Matz” Matsumoto er blant talerne. Her har du muligheten til å investere i framtidig ære og berømmelse; antakelig vil neste års konferanse trekke minst dobbelt så mange deltakere.

Konferansen går av stabelen på Chateau Neuf torsdag og fredag neste uke, og det er fortsatt ledige plasser. Om du ikke har meldt deg på ennå er det ingen grunn til å vente; hvis du er student kan du tilogmed få gratis adgang.

Ses neste uke!

Hvor lenge skal webben lide av dårlige nettlesere?

2008-03-19T09:58:03Z

Med Firefox 3 like rundt hjørnet og Safari 3.1 ute idag kan man lure på hvor relevant Internet Explorer er. Noen kalde fakta og en aldri så liten oppfordring følger….

Apple slapp Safari 3.1 idag; Safari 3.1 har støtte for en god del av det som er foreslått i HTML 5, en innebygget database og mye annet snacks. Firefox 3 er nå i beta, og ser ut til å være en kjapp og sexy nettleser.

Vi som lager nettsider legger imidlertid strenge føringer på oss selv som gjør at vi ikke bruker disse fete nyhetene fra nettleserne; hovedgrunnen er Internet Explorer. Internet Explorer 8 kan kanskje komme til å bli riktig bra, IE7 er ikke så aller verst, men i en slags masochistisk selvdisiplin tilpasser vi fortsatt nettsidene våre til Internet Explorer 6, som kom ut sånn circa i juratida. Denne velmente selvdisiplinen gjør at de fleste nettsider på innsiden ser ut som ukegammel spaghetti, et sammensurium av Araldit og duct-tape – hacks på dataspråket – for å fungere i programmer vi alle skulle ønske ikke lenger fantes. For alle som faktisk bruker en moderne nettleser må dette føles omtrent som å kjøre en Lamborghini på norske veier, det er rett og slett liten vits.

Bloggen du leser nå har en utypisk lesergruppe:

57% av leserne bruker Safari
31% av leserne bruker Firefox
9% av leserne bruker Internet Explorer

Et annet nettsted vi kjenner ganske godt til – Vålerenga-sjappa på nett – har en mer typisk målgruppe:

81% bruker Internet Explorer
14% bruker Firefox
2.7% bruker Safari
2.5% bruker Opera

En relativt ny trend i nettlesermarkedet er at det begynner å flokke seg rundt en håndfull nettleser-motorer:

Gecko brukes i Firefox, Mozilla og en haug smale nettlesere
Webkit brukes i Safari, Konqueror, iPhone/iPod touch, ~~iTunes~~, Adobe AIR og etterhver også Epiphany

For oss som utvikler nettsider er dette relevant; vi ser at “innmaten” i nettlesere og nettleser-lignende programmer i større og større grad er basert på kvalitetskode, samtidig som vi fortsatt har et innslag av konkurranse i og med at det finnes flere aktører. Microsoft og Opera er idag de store unntakene i at de vedlikeholder sine egne, proprietære (i betydningen lukket kildekode) nettlesermotorer. Opera har en rimelig god track record på å følge standarder, mens Microsoft – uansett hvor mye de prøver det motsatte – ender opp med spesialtilfeller. Og her står vi overfor et høna-eller-egget-dilemma: så lenge vi fortsetter å lage nettsider som fungerer i IE trenger ikke brukerne våre å oppgradere til en skikkelig nettleser, og dermed er vi med på å forlenge problemet.

Jeg tror løsningen ligger i å lage løsninger som funker i Internet Explorer, men skinner i andre nettlesere. Jeg satte opp et kjapt eksempel på en de nye CSS-egenskapene i Webkit/Safari for etpar dager siden – en slik løsning vil være leselig i Internet Explorer, men brukeropplevelsen vil være langt rikere med en moderne nettleser. Om vi omfavner slike praksiser er min påstand at brukerne vil kappes om å laste ned en ny nettleser så snart de ser hvor kul webben er for “alle de andre”. Om elementene på en nettside i din nettleser har harde, firkantete hjørner uten skygge og visuelle effekter; og du så ser at kollegaen får pene, runde hjørner med skygger, glasseffekter og diskrete animasjoner vil de tidsnok laste ned en annen nettleser. Der man tidligere ble møtt med “Denne nettsiden fungerer best i xxx”, som oppfordret brukerne til å laste ned en annen nettleser, bør vi heller satse på sex appeal; la brukerne selv finne ut av hva de går glipp av.

Hvordan tror du nettlesermarkedet ser ut om et år?

Oppdatering

TechCrunch ser ut til å ha plukket opp denne artikkelen – :-) – og oppfordrer nettbrukere til å slutte å støtte Internet Explorer 6. De linker til Save the developers og peker på etpar fine knapper man kan bruke på nettsidene sine:

A bit verbose, are we?

2008-03-13T10:42:16Z

While “debugging” a Rails application, developers tend to use the puts method to print debug information while developing. Although perhaps useful for the developer in mind, it makes it a lot harder for colleagues to use testing in their work as the console is cluttered with debug information.

Without going into whether using puts for debugging is a good practice or not, I wrote some Ruby code today that silences all this information while I’m running my tests. A very simple analysis of the problem tells me that:

I only want the output silenced when running my tests. I found it tempting to force my policy of not using puts on my peers, but strictly spoken all I wanted was my tests to run less verbosely
The reason for all this turning up in the console is the use of the method puts

The first point tells me that testhelper.rb is the natural place to put this functionality. This file is always loaded when you run your tests. The second point tells me that the method I should target is the puts method – and the puts calls are made in ActiveRecord::Base subclasses. So my first try was to put the following into testhelper.rb:

module ActiveRecord
  class Base
    def puts(something)
      # let's eat it
    end
  end
end

Running my tests, I was pleased to see about 50% of the output silently eaten by this hack. However, there was still some output sent from classes not extending ActiveRecord::Base, so I needed to be a bit more greedy. Let’s put it all into a module:

module SilentOutput
  def puts(something)
    #
  end
end
module ActiveRecord
  class Base
    include SilentOutput
  end
end
class SomeOtherClass;include SilentOutput;end

There! Now I can get back to work. One last issue before I let you get back to work: How do you discover which classes called the puts method, so you know which ones to include? A small trick is to put the following into your test helper file, and it will reveal other classes calling the method:

Kernel.module_eval do
  alias_method :old_puts, :puts
  def puts(something)
    raise "WARNING: #{self.class.to_s} tried to call puts with the message #{something}" 
  end
end

These lines mix into Kernel and creates an alias to the (old) puts method – in case you need it actually puts-ing, and then raises an error revealing which class tried to use puts to print its output. This gives you a hint of which further classes may be candidates for including your SilentOutput module.

Tick icon for your Fluid app

2008-03-07T13:15:42Z

I’ve just started using Fluid, a great app for making my favorite web applications work like real applications. But I couldn’t find a proper icon for Tick. So I made one…

Hope that’s OK for you guys at Mohill. If it doesn’t look exactly perfect, I’m sorry. I’d love to re-do it, with an original logo-file.

Anyways. The icon I made, you can find here:
Tick Icon

Enjoy!

15 push ups, for å få registrere et selskap

2008-03-06T15:48:42Z

For en uke siden skulle jeg starte et nytt plateselskap og ble helt begeistret over opplevelsen. Jeg visste hvor jeg skulle gå, nemlig Brønnøysundregisterene (brreg). Og jeg visste hva jeg skulle der.

Dette tenkte jeg var et veldig godt utgangspunkt for en enkel og hyggelig opplevelse, med en av statens største og beste nettjenester. Men nei, det var så overraskende vanskelig at det bare ble moro, nesten.

Som interaksjonsdesigner tenker jeg at det er en drøm og lage en løsning hvor brukeren vet akkurat hva som skal gjøres og hvor. Det viste seg at det bare var ett skjema som skulle fylles ut og sendes inn. Det var det hele. Så oppgaven til Brønnøysundregistrene var å gi meg det skjemaet. Lettere sagt enn gjort. Om dere orker kan dere lese min brukeropplevelse av det her:

Steg 1
På www.brreg.no er det en godt synlig og forståelig meny med tittelen ‘Tjenester for’, hvor jeg finner linken for ‘Etablerere’, med underpunktet ‘Registrering’. Enkelt!

Steg 2
På registreringssiden står linken ‘Registrering av ny enhet/foretak’ øverst. Perfekt!

Steg 3
På denne siden ser jeg med en gang ‘Elektronisk registrering’. Topp, elektronisk er bra. Akkurat hva jeg vil!

Steg 4
Oj! Her kom det en lang tekst som jeg skumleser. Et stykke ned finner jeg ‘Begynn registrering’. Ikke dumt!

Steg 5
Plutselig er jeg ikke lenger på Br.Reg. men på en side som heter ‘Altinn’. Den har jeg jo hørt om. Den skal være bra. Men her begynner moroa for meg. Jeg blir servert en stor meny (‘Aktuelle skjema og tjenester’) med elleve lange tekstpunkter, som jeg ikke skjønner stort av. I tillegg ser jeg to små menyer i høyremargen: ‘Snarveier’ og ‘Starte og drive bedrift’. Den siste med menypunktet ‘Registrering’. Topp, back on track!

Steg 6
Oj og dobbelt oj! En side med mange, mange tekstlinker, alle med lang tekst. De er delt opp i fem grupper og jeg skjønner med en gang at ‘Registrere foretaket’ er gruppen for meg. Under den gruppen blir linken ‘Hva gjør jeg for å bli registrert i Foretaksregisteret?’ det beste valget. Tror jeg. Ikke lenger trygg på dette her.

Steg 7
Her er det bare en kort liten artikkel som forteller meg at «Registreringen i Foretaksregisteret gjøres på Samordnet registermelding». Og etter kort leting finner jeg to linker i en høyremeny: ‘Samordnet registermelding (i Altinn)’ og ‘Samordnet registermelding (Varianter for nedlasting)’. Jeg velger Altinn, selvfølgelig, det skal jo være bra og effektivt og elektronisk. Spent nå!

Steg 8
Jaja, en lang artikkelside med tittelen ‘Samordnet registermelding (BR-1010)’. Jeg trenger ikke å skumme, for den øverste linken er ‘Her finner du skjemaet’. Yes! Endelig!

Steg 9
Ok, det var et anchor point. Jeg ble flyttet ned til et skjemaikon med tittelen ‘Samordnet registermelding’. Endelig, igjen.

Steg 10
På dette tiende steget kommer jeg til endel valg for å få logget inn i Altinn. De spør om jeg har smartkort, PIN-koder, engangskoder, registrerte passord og en haug med andre ting. Hvis jeg ikke har, kan jeg bestille. Jeg vil ikke bestille noe. Var det ikke et sted jeg kunne laste ned skjema? Jeg begynner å gå bakover i nettleseren. Hmm, får jeg til dette mon tro?

Steg 11
Tilbake til steg syv. Denne gangen velger jeg ‘Samordnet registermelding (Varianter for nedlasting)’. Nå er jeg spent, og etterhvert litt utålmodig.

Steg 12
Oj, vekk fra Altinn og tilbake til Br.Reg. Ti tekstlinker ønsker meg velkommen. Jeg styrer vekk fra alt uaktuelt: Mva, D-nummer, styreendringer osv. To valg står igjen: ‘Samordnet registermelding del 1 – hovedblankett’ og ‘Elektronisk registrering gjennom Altinn’. Det siste valgte jeg jo bort på forrige side, så jeg går inn på hovedblanketten. Nå sitter jeg og smiler og gleder meg til å skrive denne lange bloggposten.

Steg 13
En haug med linker igjen. Den øverste er ‘Last ned blankett’. Bra! Er jeg på sporet igjen?

Steg 14
Jeg lastet ikke ned noen blankett, men kom inn på en side som forteller at dette er i PDF-format… eller MS Word-format lenger ned. Jeg velger PDF hovedblankett på bokmål. Ikke verst!

Steg 15
BINGO! Jeg fant den! Et flott PDF-skjema som lar seg fylle ut og printe direkte fra nettleseren min. Det har også hjelpetekster der jeg trenger det. Kjempebra!

Tja, hva skal jeg si nå? Takk for tålmodigheten dere har hatt som har lest dette. For meg var det godt å få skrevet det. En konklusjon må vel være at brukertesting er viktig for alle nettsteder, også de som ikke har direkte, kommersielle konkurrenter. Jeg tør tippe på at de mottar mange telefoner der oppe i Brønnøysund som en følge av disse sidene.

Så mitt enkle, velmenende råd til Br.Reg.: Putt en link til den PDF-en allerede på steg 2, der jeg valgte at jeg skulle registrere et foretak. Og ring oss om dere ønsker flere forbedringer.

PS: Plateselskapet jeg startet heter forresten «Fin jobb», og det er noe jeg synes jeg har som kan bruke tid på å skrive alt dette. Ha en god dag!

Your browser is not supported

2008-03-01T13:51:38Z

Google Documents har noe så sjelden som en humoristisk vri på feilmeldinger om at nettleseren din ikke støttes i tjenestene deres.

Om du for eksempel skulle driste deg til å bruke Google Documents med Webkit får du opp en humoristisk melding:

Hvis du holder på å fikse problemer med en bestemt nettleser og kunne tenke deg å omgå denne kontrollen, er det bare å legge til &webleserok=true på slutten av nettadressen Google Dokumenter. Merk at det er et brudd på intergalaktisk lov å bruke denne parameteren under falske forutsetninger, så ikke la oss ta deg på fersk gjerning. Og det kommer faktisk ikke til å fungere særlig bra.

Det var noe annet enn å forsøke påtvinge brukerne en nettleser de ikke er interessert i.

(Selv om det ser ut til å funke aldeles utmerket å bruke Google Docs med Webkit).

Jo flere feil, jo bedre løsning

2008-02-18T15:58:19Z

I Shortcut er vi ikke redde for å gjøre feil, selv om vi gir råd, skriver kode og alt skal fungere. Vi er redde for å ikke gjøre feil. Og heldigvis er vi ikke alene om å ha det slik…

Etter å ha sett flere TED-foredrag i tilfeldig, tilsendt pr. mail, rekkefølge, har jeg begynt å gå systematisk gjennom dem. De er utrolig inspirerende og bra. Og jeg merker at jeg blir hekta på samme måte som da jeg pløyet meg gjennom samtlige Sopranos-episoder. Etter én, var det alltid tid til en til. Jeg anbefaler virkelig alle å ta turen innom TED for litt faglig (uansett fag) og menneskelig inspirasjon.

Min favoritt nå er kreativitetseksperten Ken Robbins’ «Do schools kill creativity?». Og ett av hans flere gode poeng, er tanken om hvordan strukturert skolegang bryter ned kreativitet. Men før jeg gjentar hans forklaring på hvordan dette skjer, en liten intro:

Jeg jobbet i reklamebransjen i en kort periode og ble veldig imponert over den kreative metoden deres. (Selvfølgelig har ikke hele bransjen kun én metode, men for meg som kom utenifra kunne det virke sånn.) Metoden var som følger. De uttalte sine ikke-gjennomtenke tanker, ustanselig og uten hemninger. De snakket uten å filtrere vekk det de syntes var dumt. Uten en gang å vurdere om det var dumt. Slik kom de med alle assosiasjoner de hadde, til det gitte tema. Som igjen ble plukket opp av andre i idémyldringen. Tilslutt hadde man så mange ideer, at noen måtte nødvendigvis være gode. Da var det bare å plukke.

Det er vår redsel for å si noe feil, for å dumme oss ut, som hindrer oss i å komme med alle ideene, før vi kan plukke ut de gode. Vi vil tenke gjennom først, forsikre oss om at det er smart, før vi tør delta i en samtale. Vi tør ikke si noe feil. Noe som ender med at man deltar altfor sjeldent. Og hvorfor er vi sånn? Ken Robbins’ svar er skolesystemet. Gjennom en lang skolegang blir feil slått ned på, gang på gang. Hele skolesystemet hyller det ene riktige svaret, selv om alle som jobber med kreativitet vet man må feile for å være kreativ. Og feile igjen.

Vi ønsker å være kreative i Shortcut. Vi ønsker å lage løsninger folk ikke har tenkt på. Vi ønsker å løse ting på en ny måte, en stadig bedre måte. Så da må man også ønske å feile, på veien dit. Men hvordan kan en teknologibedrift ønske å feile? Hvordan kan utviklere ønske å feile? Må ikke kode til enhver tid være feilfri? Skal ikke våre rådgivere gi gode råd, ikke gale råd? (Bare legg til de retoriske spørsmålene du måtte ha.)

Ved å innse at produktene vi lager til stadighet er under utvikling, kan vi få til å feile oss frem til gode løsninger. Vi lager ikke kode, for aldri å endre på den. Vi lager ikke design, for aldri å endre på den. Vi jobber systematisk mot den ideen vi har om hva vår løsning skal kunne gjøre. Vi fikser de viktigste oppgavene først. Så prøver vi ut andre ting, alternative ting. Forandrer litt her og forandrer litt der. Noen ting beholder vi, andre ting var nyttige feil på veien. De kaster vi.

Men tar ikke dette ekstra lang tid? Blir ikke dette svært dyrt? Nei, takket være den moderne teknologien og arbeidsmetodene vi bruker, blir ”feilene” bare endel av prosessen, uten å forlenge den. Med Ruby on Rails kan vi fort og enkelt lage all funksjonaliteten, og sette opp automatiske tester av alle oppgaver, til en løsning. Da har vi et nyttig verktøy hvor vi kan prøve og feile, og jobbe oss stadig nærmere det resultatet vi ønsker. Og ved å hele tiden å gjøre små oppdateringer, kan vi sømløst rette opp feil og fjerne ting, eller beholde ting og komme et steg videre. På den måten maner vi frem produktet slik vi vil ha det, med alle gode ideer ivaretatt.

Men før vi gjør noen fler feil, ikke glem å høre og se Ken Robbins’ «Do schools kill creativity?». Han har også andre gode poeng.

REST, hvilken vakker ting

2008-01-18T12:54:19Z

Jeg jobber for tida på mitt så langt største Railsprosjekt. Her har jeg merket noe som ser ut til å være en trend: når etablerte aktører vurderer Rails faller ofte ActiveRecord bort som alternativ i første omgang. Mange tror dette betyr at Rails ikke gir nok til at det er noen vits, der tror jeg de tar feil.

Rails består, ut av boksen av to hovedelementer: ActiveRecord, som håndterer forretningsobjektene dine slik de er representert i en relasjonsdatabase, og et rammeverk for det å lage webapplikasjoner. De fleste eksemplene på bruk av Rails er så enkle og tiltalende nettopp fordi de lener seg så hardt på grunnfunksjonaliteten i Rails: ActiveRecord og ActionPack.

Et av de nyere tilskuddene til Rails-familien er ActiveResource, et bibliotek som lar deg bruke ressurser fra et annet system omtrent som om de fantes i din egen database. Om det andre systemet også er en Rails-applikasjon er dette “plug’n’play”, hvis ikke må det gjøres litt jobb. Jeg mistenker at mange som vurderer Rails resonnerer omtrent sånn:

Kan vi bruke ActiveRecord? Nei
Kan vi bruke ActiveResource? Kanskje, men da må vi gjøre masse om på det eksterne systemet, slik at ActiveResource kan fungere uten tilpasninger

Om det så skulle vise seg at datastrukturen (eller noe annet) i det eksterne systemet ikke er tilsvarende Rails henfaller mange enten til å avskrive Rails eller å glemme alle prinsipper om bra håndverk og parse XML-strukturer i controllere og whatnot. Det er det ingen grunn til!

På prosjektet jeg jobber nå ligger foreløpig alle modellene våre “utenfor vår kontroll”, det vil si at eneste grensesnittet vi har mot dem er en REST-basert webservice. Disse ligner ikke på ActiveResource i det hele tatt, og det gjør ingenting. Vi bare begynte å skrive klientkode som om disse eksterne modellene var førsteklasses ActiveRecord-lignende objekter.

me = Person.find("marius")
all_people = Person.find(:limit => 22)

Jeg tenkte ikke på hvordan jeg skulle implementere dette i det hele tatt på dette stadiet, jeg bare skrev den klientkoden (som en enhetstest, såklart) som jeg ønsket å bruke om verden var et perfekt sted. Etter min erfaring er dette den eneste måten å få et API/DSL man orker å leve med i lengen: man er nødt til å skille det å designe seg et domenespråk fra det å implementere det. I dette tilfellet valgte jeg å få noe som lignet veldig på ActiveRecord/ActiveResource; først og fremst fordi noen her har tenkt på masse problemstillinger for meg, dernest fordi de andre elementene i Rails-applikasjonen min (Controllere og Views) blir mest mulig lik Rails og jeg slipper å tenke.

Deretter, når jeg hadde bygget meg et språk gjennom de testene jeg hadde laget satt jeg lykkelig og utslitt med et titalls tester som feiler. Da er det på tide å gå hjem, sove ut, og begynne implementasjonen neste dag.

Vi hadde en diskusjon med de som utvikler REST-tjenesten vi skal forholde oss til, og de fortalte blant annet om XML-formatet de brukte når man prøvde å aksessere en ressurs som ikke fantes. Igjen var det noen som hadde tenkt for oss, måten Rails’ REST-tjenester forteller at en ressurs ikke finnes på er å returnere HTTP statuskode 404 (not found). Det gir ingen mening å skulle parse XML for en ressurs som ikke finnes.

Dette er en oppfordring til å være litt ambisiøs når du ikke kan lene deg på Rails. Som Railsutvikler har vi et fantastisk verktøy tilgjengelig: det samme verktøyet som Rails-teamet bruker når de lager Rails – Ruby. Ruby er kraftige greier, bruk det!

Nå kan du følge bloggen vår på Twitter

2008-01-17T11:11:40Z

har fått både oppmerksomhet og pepper i det siste, sist etter at de gikk ned under Macworld her om dagen. Vi har nå laget oss en bot som du kan følge for å få oppdateringer fra bloggen vår inn i Twitteren din.

I første omgang har vi lagt inn funksjonalitet for at Twitter-boten vår sier fra hver gang noen poster kommentarer på blogginnlegg. Det kan neppe være lenge til også nye artikler annonseres.

For å motta oppdateringer fra boten vår går du inn på profilen hennes og trykker på “Follow”-knappen. Du må selvsagt ha en Twitter-konto for at dette skal fungere.

Så lover vi å si fra – via Twitter såklart – så snart noe nytt er på plass.

Penere adresser

2008-01-08T14:17:37Z

Selv om navlebeskuelse ikke er det mest tiltalende man kan gjøre på web er jo dette tross alt en teknologiblogg. Vi har idag gjort litt om på URLene her på nettstedet.

For å score sånn noenlunde på søkbarhet er ett av kriteriene at URLen gjenspeiler innholdet i artikkelen. Når man bygger en blogg i Rails fra grunnen av, slik vi har gjort med denne bloggen, er minste motstands vei å bruke den unike ID’en til en artikkel som basis for URLen til den. Fram til nå nettopp var adressene til artikler på denne bloggen nettopp slik:

http://shortcut.no/posts/1

Nå er det antakelig mindre interessant for deg som leser denne bloggen hvilken ID databasen vår tildeler artiklene i bloggen. Det som kanskje er av betydning er tittelen på artikkelen og når artikkelen ble skrevet. En veldig vanlig måte å gjøre dette på er å bruke Permalinker, der både dato og tittelen til artikkelen vises i URLen.

Vi har implementert permalinker i denne bloggen ved hjelp av et filter i Post-klassen i bloggen, slik:

class Post < ActiveRecord::Base
  before_create :create_permalink
end

Dette filteret gjør noen helt enkle operasjoner:

Først erstattes alle norske tegn (æ, Æ, ø, Ø, å, Å) med tilsvarende internasjonale tegn (a, o og a)
Deretter gjøres permalinken til små bokstaver
Deretter byttes alt som ikke er internasjonale bokstaver eller tall ut med en understrek

Resultatet av denne operasjonen lagres i kolonnen permalink i databasen. Enhetstesten for permalinker ser slik ut:

class PostTest < ActiveSupport::TestCase
  def test_permalinks
    post = @user.posts.new(
      :title => "Godt nyttår fra Østerdalen 123")
    assert post.save
    assert_equal(
      "godt_nyttar_fra_osterdalen_123", 
      post.permalink)
  end
end

Vi har valgt å ikke kreve at permalinkene skal være unike, dette ville hindret oss fra å skrive to artikler med samme tittel. Istedet bruker vi routingen i Rails til å sørge for at vi henter riktig artikkel. Linkene til artikler genereres i en helper, slik:

def permalink_to(post, label)
  link_to(label, permalink_url(post))
end

def permalink_url(post)
  url_for(
    :controller => "/posts", 
    :action => "show_permalink", 
    :year => post.created_at.year, 
    :month => post.created_at.month, 
    :day => post.created_at.day, 
    :permalink => post.permalink)
end

Ved å skille dette ut i to metoder kan vi både bruke helperen til å generere en permalink-link som kan brukes for seg selv og en link_to-lignende syntaks. Helperen sørger for å sende med parametre for år, måned og dag artikkelen ble skrevet. For at adressene skal bli formatert riktig lager vi en linje i routes.rb som formaterer dette slik vi er vant med:

  map.permalink '/posts/:year/:month/:day/:permalink', :controller => "posts", :action => "show_permalink"

Datoen havner nå som henholdsvis params[:year], params[:month], params[:day] og params[:permalink] i PostsController-klassen vår.

Magi i Rails med composed_of

2008-01-04T16:15:29Z

Rails lar deg lagre sammensatte dataobjekter i en modell med metoden composed_of. Denne artikkelen gir noen eksempler på hvordan du kan bruke dette til å få til ganske avanserte ting i Rails-programmet ditt.

I dokumentasjonen for composed_of står det

Adds reader and writer methods for manipulating a value object

Det helt grunnleggende tilfellet er der du har en Person-klasse som har et adresseobjekt tilknyttet seg. Man kan selvsagt ha en egen addresses-tabell der man lagrer adressen og så bruker has_one :address for å koble personen med adressen.

En annen løsning er å ha et Address-objekt som er en helt vanlig klasse, men som (tilfeldigvis) lagrer dataene sine i people-tabellen. La oss si at en adresse består av en gateadresse og et postnummer. Dette kan man kode slik i Rails:

class Person < ActiveRecord::Base
  composed_of :address, :class_name => "Address", 
    :mapping => [
      [:address_street, :street],
      [:address_postal_code, :postal_code]]
end

class Address
  attr_reader :postal_code, :address
  def initialize(street, postal_code)
    @street = street
    @postal_code = postal_code
  end
end

Det som her skjer er at to kolonner i people-tabellen din, address_street og address_postal_code settes sammen til et Address-objekt som du bruker i Ruby-koden din istedet for å manipulere disse feltene direkte:

me = Person.find_by_name("marius")
me.address = Address.new("Nonnegata 21","0656")
me.save

Okay, dette virker kanskje som pirkete objektorientert idealisme, men du kan faktisk bruke dette til noe nyttig også. La oss si at du ønsker å også kunne hente ut poststed til en norsk adresse. La oss sette opp følgende krav:

Address-klassen din skal ikke lagre poststedet, men hente dette fra en egen tabell i databasen
Person-objekter skal ikke være gyldige med mindre de har et gyldig postnummer (eller riktigere: et Address-objekt med et gyldig postnummer)

For å få dette til lager vi en egen ActiveRecord-klasse (med en tilhørende tabell) for poststeder (Zip). Vi kan laste ned en fil som inneholder alle norske postnummer og -steder fra Posten og så lage en Rake-task som bruker denne fila til å oppdatere zips-tabellen. Du har da en Zip-klasse som kan se omtrent sånn ut:

class Zip < ActiveRecord::Base
  validates_uniqueness_of :number
end

Om du så kobler sammen Address og Zip-modellene dine for eksempel slik:

class Address < ActiveRecord::Base
  def postal_place 
    z = Zip.find_by_number(postal_code)
    return z.place.chars
  end
end

vil du kunne hente ut poststed for en adresse slik:

me = Person.find_by_name("marius")
me.address = Address.new("Nonnegata 21","0656")
me.address.postal_place  => # OSLO

Vi sukrer pillen litt til ved å la deg få en snasen måte å representere adresser på i viewet ditt:

class Address < ActiveRecord::Base
  def to_s
    "#{street}, #{postal_code} #{postal_place}" 
  end
end

Så vil du kunne skrive ut en adresse i viewet ditt på den mest naturlige måten:

me = Person.find_by_name("marius")
me.address = Address.new("Nonnegata 21","0656")
puts me.address => # Nonnegata 21, 0656 Oslo

Men vi lovet mer: nemlig at en Person måtte ha en gyldig adresse for å kunne lagres. Her skal vi rett og slett basere oss på duck-typingen som ligger i Ruby. Vi skal først bruke validates_associated metoden for å si at en Person skal validere sin tilhørende Address:

class Person < ActiveRecord::Base
  validates_associated :address
end

Det har ikke noe å si om Address-klassen ikke er en ActiveRecord-klasse, det som skjer er at metoden valid? blir kalt på det tilhørende Address-objektet. Dette kan vi implementere slik:

class Address
  def valid?
    return !Zip.find_by_number(postal_code).nil?
  end
end

Og dermed har vi sørget for at en Person bare er gyldig dersom dens tilhørende Address er gyldig også.

Neste gang vil jeg skrive om hvordan du kan bruke composed_of til å lagre penger i databasen på en fornuftig måte ved å bruke et eget Money-objekt.

Ny blogg

2008-01-04T11:17:32Z

Den vanskelige første posten, hva skal man skrive om?

Vi, altså John Eivind Hallén og Marius Mårnes Mathiesen, sluttet i Fatguy i begynnelsen av desember, og er nå midt oppe i prosessen med å starte med ganske blanke ark.

Denne bloggen vil inneholde små og store drypp om de tingene vi er opptatt av, kort oppsummert som design og utvikling. Og for at det ikke skal være helt tomt: dette er aller første post her på bloggen vår.

Om det er noe som ikke funker (RSS-feed, kommentarer), noe du misliker eller du bare vil ønske oss velkommen: legg gjerne igjen en kommentar nedenfor!