Her er linkene til noen av demoene jeg viste på foredraget “Teknologi for rike webanvendelser” på Software 2008 den 13. februar 2008.

• Ajax: Telenor produktveiviser. Klikk på “Bestill”-knappen for å starte produktveiviseren.
• Ajax rammeverk: Rico
• Ajax rammeverk: Yahoo User Interface Library. Eksempel på faner der back-knappen virker.
• Flash: Jøtul
• Flex Component Explorer
• Flex: Picnik bildebehandler
• Flex: Buzzword tekstbehandler
• Air runtime og eksempelapplikasjoner
• Silverlight runtime og eksempelapplikasjoner
• Silverlight: Golden Globe
• Java applet: Boids
• Google Web Toolkit: Kitchen Sink
• Google Web Toolkit: Mail

Mule ESB er et rammeverk for integrasjon som har fått ganske så mye oppmerksomhet i IT-miljøer og på konferanser som Java Zone 07. Årsaken til dette er nok at Mule sees som et open source alternativ til svært dyre integrasjonsteknologier, samt dens nære knytning til populære open source teknologier som Spring, Maven og JBoss.

Så hva kan Mule brukes til og hvordan funger det? Mule er en Enterprise Service Bus i forstand at den består av komponenter som kan motta data, transformere data, eksekvere kode, og sende data videre. Disse komponentene konfigureres via XML filer hvor prosessflyten og protokoller spesifiseres. Her er en figur som illustrerer et tenkt scenario hvor den første komponenten mottar data via en Web Service og legger dataene på en kø via JMS, og er ferdig. En annen komponent lytter på køen, transformerer dataene og splitter den til en komponent som lagrer dataene til en database og en annen komponent som sender dataene til et annet system via en Web Service.

Dette er et enkelt men veldig typisk scenario for integrasjon. Siden flyten og protokollene konfigureres via en XML fil er det en smal sak å endre det slik at dataen sendes til en tredje komponent, samt å legge på transaksjonsstøtte for garantert levering fra kø til destinasjon.

Mens flyten, protokoller, destinasjoner og transaksjons konfigureres via en XML fil, så består selve innholdet i hver komponent av en enkel java klasse. Å lage en web service kan være så enkelt som å lage en klasse med en metode String getName() og så spesifisere XML filen at det skal være en Web Service.

It’s free. There must be a catch? Vel, ja. Hovedproblemet med Mule er den teknologiske terskelen for å komme i gang. Mule består av så mange forskjellige teknologier, hvor mange av dem, blant annet Mule selv, er nokså dårlig dokumentert. Så foruten at man trenger en god forståelse av integrasjonsteori som synkron/asynkron kommunikasjon, normalisering, korrelasjoner, transaksjoner, xml og database, så er det underliggende teknologiene som er en utfordring. Teknologier som man bør kunne for å få gjort noe i Mule vil generelt være: Java, Spring, Maven, Web Services (Xfire,CXF, JAX-WS), JMS, XML, JDBC, JMX og J2EE applikasjons tjener.

Det er mange måter deployere Mule på, men måten jeg har funnet ut fungerer mest tilfredsstillende er pakke hver instans som en ear fil, og hot-deploy til JBoss. Når man deployer flere instanser så vil hver instans ha sin egen classloader og være fullstendig separat. Problemet med dette, i forhold til andre ESB produkter, er at Mule ikke kan dele såkalte konnektorer mellom ulike instanser. Konsekvensen av dette er at dersom man har to instanser som eksponerer Web Services så må hver instans ha sin egen port. Dette kan fort bli en utfordring dersom man har mange instanser.

Så for å summere opp. Fordeler med Mule er

• Fleksibelt og veldig pragmatisk rammeverk for integrasjon og prosessflyt
• Skalerer sannsynlig veldig bra teknologisk på komponentnivå
• God støtte for protokoller
• Open source, noe som gjør det lettere å debugge
• God støtte for unit- og funksjonell testing (noe som de aller fleste andre ESB mangler)
• Ingen lisenskostnader
• God online hjelp via deres mailingliste
• Relativ god støtte for innsyn/monitorering under kjøring via JMX

Svakheter

• Skalerer dårlig når det gjelder deployering
• Høy terskel for å komme i gang
• Fortsatt en del ting som ikke fungerer som det skal
• Mangler grafisk grensesnitt for konfigurering
• Mangler grafisk grensesnitt for XML mapping

Så alt i alt så er Mule et veldig interessant rammeverk som i mange tilfeller vil være tilfredsstillende for å gjøre integrasjon.

Source and tutorial (in english)

De fleste Java utviklere kjenner til Eclipse som en utviklingsplattform med mange verktøy og hjelpemidler. Eclipse IDE har faktisk blitt så omfattende at de færreste har full oversikt over alle de muligheter man har tilgjenngelig. Mye av årsaken til dette mangfoldet i funksjonalitet i Eclipse er den plug-in baserte arkitekturen. I prinsippet kan en hver utvikler utvide/endre hvilken som helst funksjonalitet i Eclipse, ved å skrive en ny plug-in. Men først må man over en liten kneik for å komme inn i Eclipse plug-in tankegang.

Jeg har skrevet en enkel liten refactoring plug-in som gir utvikleren mulighet til å endre typen på en klassevariabel og tilhørende getter/setter ved en liten wizard. Kilde koden for denne plug-in’en sammen med en liten tutorial for hvordan man kan lage egne refactoring plug-ins kan du finne her.

Tutorialen er skrevet med tanke på utviklere som ikke har utviklet plug-ins for Eclipse og går dermed ikke dypt ned i materien. For mer om plug-in utvikling så er det en god start med JDT Plug-in Developer Guide og PDE Does Plug-in. For grundigere og mer utfyllende om eclipse refactoring rammeverket så finner man forklaring og eksempler i Unleashing the Power of Refactoring og Automated Refactorings in Eclipse-based IDEs. Sistnevnte bruker eksempel fra renaming i properties filer. Og for de som er interessert i å lære mer om det mektige AST (AbstractSyntaxTree) så er dette en fin plass å begynne.

Mandag 3. desember var en aldri så liten merkedag i norsk internettbransje, da Bransjerådet for søkemotormarkedsføring hadde sitt stiftelsesmøte. Nå skal det nemlig bli mulig å handle konsulenttjenester for å optimalisere sine nettjenester i trygg forvissning om at man ikke risikerer sanksjoner fra Google eller andre søkemotorer.

Bransjerådet skal ikke bare fremme kunnskap om fagområdet, men skal sikre at brukere og kunder i søkemotormarkedet ikke skal utsettes for feil type rådgivning. Medlemmer av rådet forplikter seg til å følge rådets regler for søkemotormarkedsføring, og annerkjenne vurderinger fra en egen klagenemd som skal vurdere eventuelle konflikter.

Det kan kanskje virke rart at man ser behovet for å etablere et bransjeråd for søkemotormarkedsføring, herunder søkemotoroptimalisering (SEO). Det er jo ikke akkurat Norges lover som brytes om man skulle forsøke seg på et kreativt grep for å få en høyere plassering i søkemotorene. Og i søkemotorenes tidlige barndom kunne man langt på vei si at dette ikke var verre enn å gå på epleslang. Regelbruddene var uskyldige, og langt på vei ufarlige.

Men i dag kontrollerer søkemotorene, med Google i spissen, nær sagt all trafikk som er basert på at brukere skal finne frem på internett. Søk er i følge Forrester og Georgia tech. GVU center kun overgått av e-post når det gjelder folks bruk av internett. Ikke minst har omfanget av innhold på nett blitt så formidabelt at vi er helt avhengige av at søkemotorer kan gi oss relevante treff på våre søk. Søkemotorene er med andre ord nødt til å slå hardt ned på forsøk på å manipulere regelsettet deres, hvis ikke vil deres produkt levere dårlig. Bedrifter er på sin side blitt helt avhengig av søkemotorene, og en utestengelse fra resultatlisten fordi man bryter regelsettet kan få fatale følger.

Det er med dette som utgangspunkt man må se på bransjerådets begrunnelse. Når arbeidet som skal utføres er av så kritisk art, både ovenfor søkemotorene og for bedriftene, er det en klar trygghetsfaktor at det nå finnes en tiltrodd tredjepart som man kan henvende seg til for å finne frem til seriøse leverandører og ikke minst grunnleggende informasjon om søkemotormarkedsføring.

Dynamisk er fint. Dynamisk betyr bevegelig, effektivt og hensiktsmessig. Dynamisk er et plussord, og udynamisk er et tilsvarende minusord. Dersom man kaller en person udynamisk er det ikke for å rose, skryte og framheve positive egenskaper. Udynamisk er det når ting er helt fast definert, og man (nærmest vrangvillig) ikke ønsker å bevege på dem. Udynamisk gjør det vanskelig å gjøre annet enn det som er faktisk planlagt og avtalt - og gode idéer skal man helst ikke presentere underveis. For å sikre gode vilkår for innovasjon og kreativitet er det derfor viktig å være dynamisk.

I Tarantell leverer vi prosjekter. Prosjekter er (av andre enn oss) definert som å være “ikke-repeterende” arbeidsoppgaver. En form for dugnad, der man setter ned en arbeidsgruppe eller prosjektgruppe på tvers av linjeorganisasjonen; på tvers av ordinære ansvar og oppgaver. En prosjektgruppe har mandat til å løse én bestemt oppgave, innenfor gitte tidsrammer og budsjettrammer.

Et prosjekt kan i sin natur ikke gjentas. Om det kunne, ville det vært en prosess, en produksjonsprosess - som gjerne kunne inngå i en industribedrift. Måten man lager hamburgere på hos McDonalds er en slik prosess: man følger de samme stegene og kommer til det samme resultatet. Gang på gang, i et repeterende mønster.
I et prosjekt kan man gjenbruke erfaringen og kunnskapen som ligger igjen hos prosjektdeltakerne, men prosjektet i seg selv er for unikt til å gjentas steg for steg.

Gjennom denne ganske raske argumentasjonsrekken kan man trekke den slutningen prosjekter (som er unike) har behov for dynamikk (for å sikre nødvendig innovasjon og kreativitet). Dynamiske prosjekter burde derfor være et plussord som var mye brukt. Men det er det ikke. Istedet hører man mye om agile prosjektmetoder, smidighet, fleksibilitet og effektivitet. Dette er verktøy for å nå prosjektets målsetning - ikke for å påvirke prosjektets målsetninger. Den kreativiteten og innovasjonen man gir rom for er for å levere det beste resultatet - ikke for å omdefinere behovet.

Det er viktig å se denne forskjellen, slik at man legger til rette for den rette bruken av alle kreative krefter (og de er mange!). Prosjekt som arbeidsform er i de fleste tilfeller lagt opp som en relativt rigid og udynamisk gjennomføring. Man har fastsatte budsjettmidler, en fast tidsramme og et fast team av mennesker til å løse oppgaven. At teamet eller arbeidsgruppen har behov for en smidighet i sin gjennomføring er lett å se: Når alt annet er fastlagt, er det kun den mennesklige tilpasningsevne som kan dekke opp for uforutsette forhold (og de er det OGSÅ mange av!).

Finnes det da ikke dynamiske prosjekter der ute? Prosjekter der målsetningene defineres basert på en kontinuerlig læringsprosess?
De finnes. Men jeg er ikke sikker på om det gjør prosjektgruppens arbeid noe enklere. I dynamiske prosjekter vil man arbeide på et høyt abstraksjonsnivå; og man er nært koblet til forretningsstrategi og bevilgning av midler. Dette gir helt andre leveransetyper enn de man er vant til i mer rendyrkede utviklingsprosjekter. Man vil f.eks. levere en idé, et mandat, en beslutningsunderlag - kort sagt et premiss for å gjøre den endelige leveransen. Og det er noe ganske annet enn en å komme til en sluttført løsningsleveranse.

For å reparere myten om at alle IT-prosjekter leverer a) For Sent, b) Over Budsjett og c) Med Irrelevant Funksjonalitet er den gjengse oppfatning at svaret har ankommet. Enter Scrum.

Med hurtige iterasjoner, fokus på burn down og team som ikke konstant forstyrres av endrede krav er framtiden allerede ankommet. Veien blir målet, vi reiser sammen og alle ender på samme sted, på samme side i boken, funksjonaliteten er som avtalt, kvaliteten er i henhold til planlagt nivå - og tid og kostnader er under kontroll.

Andre, gammeldagse metodeverk konsentrerer seg om å planlegge før man går til aksjon - også kalt fossefall. Noen helt klare ulemper med dette er at fossefallsprosjekter har en tendens til å vare lenge, og de kravene man hugde i steintavlene ved prosjektets start er kanskje ikke like viktige lenger. Kostnadsrammene er fastsatt, og rigid endringshåndtering sørger for at det er vanskelig å omprioritere kravene underveis. Dersom man allikevel velger å endre kravene blir tidsrammene forskøvet og man må tilføre mer budsjettmidler. Fordelen, vil mange hevde, er at det er langt lettere å knytte dette til standard kontrakter og juridiske avtaleverk.

I hverdagen oppleves det slik at fossefallsprosjekter betinger en god del støtteleveranser. Dokumentasjon. I utgangspunktet vil det være en god idé å dokumentere sine planer og veivalg, slik at partene er enige om hvilke prioriteringer prosjektet har gjort. Men ofte er det slik at: a) leverandøren må sette av produksjonskapasitet (les: programmerere) for å dokumentere, og b) oppdragsgiver ikke har kompetanse eller tilgjengelig tid til å vurdere planene.

Dersom man i korte iterasjoner KODER i stedet for å dokumentere vil man være produktiv tidligere, og det blir enklere og mer oversiktlig for oppdragsgiver å ta stilling til resultatet, og å prioritere den viktigste funksjonaliteten. At standard kontraktsverk ikke ennå støtter denne partnerorienterte arbeidsformen skal jeg ikke komme nærmere inn på her.

Men: I prosjekter av strategisk natur vil ikke løsningsområdet være tydelig. Målsetningen kan være å øke inntekter; å redusere kostnader; å søke nye forretningsmuligheter. Å starte å kode noe på dag 1 vil i slike tilfeller være en relativt sikker måte å ødsle med tid og penger på. Man vil ikke kunne vite om man er på riktig plattform, med riktig personell, og man kan bare gjette på hva kravene til løsningen kan være.

Ingen fare, sier scrummerne. Scrum kan brukes til alt mulig, også strategiarbeid. Dette er selvsagt 100% korrekt, gitt at HELE prosjektet dreier seg om strategi. Men dersom første iterasjon dreier seg om strategisk fundament, andre iterasjon vil dreie seg om plattform- og leverandørvalg, tredje iterasjon om etablering av infrastruktur etc. har jeg følgende påstand: Dette er fossefall. Og det er fossefall med en uhensiktsmessig metode. Teamet vil måtte endres fra iterasjon til iterasjon, backlog kan ikke videreføres, koding må avvente anskaffelse og leverandørvalg etc. I slike tilfeller vil man være langt bedre tjent med å splitte opp i flere og mindre prosjekter. Eller å benytte en velprøvd fossefallsmodell med faseinndelinger, formaldokumenter og beslutningspunkter.

At Scrum inneholder samspillsregler og oppmuntrer til god internkommunikasjon i prosjektgjennomføring kan bare applauderes. At man har fokus på produktivitet og klare ansvarsforhold likeså. Men som verktøy må det være tilpasset oppgaven.

I dagens Digi skriver de om den nyeste satsningen til Mozilla, Prism. En ny browser som kan kjøre programmer uavhengig av det tradisjonelle grensesnittet. I utgangspunktet en gammel idé i ny innpakning, men det ligger mer i dette enn kun å endre måten vi browser nettapplikasjonstjenester på.

Mozilla er nemlig ikke alene. Adobe Labs har for eksempel lansert sin nye plattform “Air” som gjør det mulig å lage fullverdige desktopapplikasjoner som kan samhandle helt eller delvis med webappliaksjoner. Et eksempel på dette er eBay sin beta desktop applikasjon, hvor man kan betjene hele sitt engasjement på auksjonstjenesten - offline. Så snart man er online vil informasjon fra din desktop syndikeres med den sentrale nettjenesten. Du kan også “surfe” og bruke den ordinære webtjenesten til eBay fra desktop applikasjonen.

Dette er på mange måter en “stille revolusjon”. For forbrukere er dette kun en utøkt service fra tjenesteleverandører vi benytter oss mye av. Tenk deg for eksempel nettbanktjenester utført på denne måten. Men for virksomheter kan de faktiske implikasjonene langt overgå det som ligger i bedre service.

Bedre service er bra, og vil sannsynligvis gi økt inntjening, eller bedre måloppnåelse for de det gjelder. Men enda viktigere er sikkerhetsaspektet. Browsere er ikke laget for sikkerhet, noe alle sikkerhetseksperter er smertefullt klar over. Flytter man applikasjoner til desktopen vil man ha helt nye muligheter til å tilby tjenester hvor man tar i bruk brukernes egne maskiner for å ivareta sikkerheten. Sikkerhetsutfordningene på nettet blir ikke borte ved hjelp av den desktop webapplikasjoner, men vi får et helt nytt sett med muligheter som tradisjonell browserhåndtering aldri vil kunne gi oss.

Og om ikke dette var nok, vil man kunne utnytte lokal prosessorkraft i stedet for å prosessere alt over egne servere. Dette gir mulighet for store innsparinger for virksomheter som tilbyr tung funksjonalitet i sine webapplikasjoner.

Min spådom - og jeg er ikke alene om den - er at desktop webapplikasjoner vil bli utviklet av virksomheter som har en stor masse av brukere som hyppig benytter seg av webløsninger med høye sikkerhetskrav og prosessering av store datamengder. Eksempler på dette kan være meglertjenester, nettbanker, webbaserte effektiviseringsverktøy osv.

Så langt ligger mye av utviklingen på dette området i softwareselskapenes lab avdelinger. Men det vil ikke vare lenge.

Bloggsfæren og utnyttelse av egen blogg burde ha en naturlig plass i enhver kommunikasjonsstrategi. Likevel er det svært få selskaper og virksomheter som har det. Mye av årsaken tror jeg ligger i mangelen på kjennskap. Ikke det at kommunikatører ikke kjenner til fenomenets eksistens, men de færreste kan redegjøre for bloggsfærens egenskaper og struktur utover de helt grunnleggende funksjonene knyttet til selve publiseringen.

Ser man overflatisk på en blogg så fremstår den som en rørende enkel webside. Det er tilsynelatende ingen navigasjonsstruktur utover løpende utlisting av artikler, og at det er en blogg avsløres av mulighetene til å legge inn kommentarer på hver enkelt artikkel. Det er lett å avvise så enkle løsninger når man har en påkostet og avansert webløsning fra før. Likevel er en slik avvisning et strategisk feilskjær.

En blogg er mer.

Dens enkelhet er dens fortrinn. En bloggs natur er å være hyppig oppdatert, og bestå av korte artikler. Det at den også innbyr til korte kommentarer fra leserne gjør at en artikkel har evne til å leve et lengre liv.

Bloggen er dessuten ikke alene. Dersom man går inn i bloggsfæren vil man oppdage et utrykk som heter “TrackBack”. Dette kan virke som en uskyldig og artig liten feature, men her ligger mye av kraften i bloggens natur. Trackbacking er nemlig verktøyet man bruker for å fortelle en annen blogg at man omtaler deres artikkel. Man trenger altså ikke å kommentere på selve bloggen der noe er skrevet, man kan lage sin egen artikkel - på sin egen blogg - og sette opp en trackback som henviser til artikkelen man omtaler, og ikke minst forteller eieren av denne bloggen at jeg følger opp dere artikkel. Og trackbacken kan følges av andre, og det kan opprettes nye trackbacks i den nye artikkelen osv. En artikkel som har nyhetens interesse kan dermed spre seg som tema og raskt etablere et innholdsunivers i bloggsfæren. Men ikke på samme måte som en nyhet sprer seg i ordinære medier, men som stadig voksende menings- og innholdsproduksjon omkring temaet.

Kombinerer man dette med RSS, og tar inn over seg søkemotorene som “elsker” blogger, så har man en sterk oppskrift på hvordan et lite frø kan vokse til å bli en skog av meninger og postinger som dominerer internett i løpet av svært kort tid.

Og det er her en kommunikasjonsansvarlig bør stille seg spørsmålet; hvem dominerer mitt innholdsunivers? Hvem er det Google finner når de søker på mine produkter, mine tjenester, temaene vi er interessert i å være synlige på? En ensom pressemelding på selskapets hjemmeside vil kunne virke som en dråpe i havet i forhold til blogsfærens omtale av samme tema. Selv med en god SEO håndtering, vil man kunne risikere at bloggerne vil oppnå høyere relevansrangering i Google enn din virksomhet.

Mange selskaper i verden har allerede hatt smertefulle erfaringer med bloggens kraft i forbindelse med kriser de har møtt, men bloggstrategi behøver ikke å kun henvises til kriseskuffen. Tvert i mot. Virksomheter bør etablere seg i bloggsfæren og aktivt gjøre seg tilgjengelig. Man bør overvåke bloggsfæren på samme måte som man overvåker tradisjonelt media, og man bør delta i samtalene rundt de temaene man mener man har noe å si og som er viktig for ens virksomhet.

Du kan være sikker på at samtalen du er interessert i pågår - spørsmålet du skal stille deg er om du skal la andre dominere ditt innholdsunivers. Men ikke prøv på juks. Kreative PR byråer har forsøkt å manipulere bloggsfæren ved å kjøpe seg innlegg, og masseprodusere blogginnlegg og kommentarer. Dét har vist seg å være en sikker vei til selvmål.

Når tilgjengelighet nedprioriteres i webutviklingsprosjekter begrunnes det gjerne med at blinde ikke vil ha utbytte av løsningen uansett, eller at det er en så liten andel brukere som er blinde at det ikke er økonomisk viktig å ta hensyn til denne målgruppen. Det er lettvint å nedprioritere tilgjengelighet, for da slipper man å ta hensyn til retningslinjene fra WAI, som noen mener setter så strenge rammer at løsningen blir kjedelig.

Tilgjengelighet på nett har mange navn: ”Universell utforming”, ”design for alle”, ”inkluderende design” og ”tilgjengelighet for alle”. Men ”design for de blinde” er ikke så vanlig som synonym for tilgjengelighet. Tilgjengelighet har altså en større målgruppe enn bare de som er blinde.  For å forstå viktigheten av tilgjengelighet må vi vite hvem som trenger tilgjengelighet. Hvor stor kundemasse lukker vi egentlig døra for når vi bestemmer oss for en løsning som ikke er tilgjengelig?

Les hele artikkelen

Hvert eneste prosjekt jeg har vært involvert i som informasjonsarkitekt og brukervennlighetsekspert har på en eller annen måte handlet om å sørge for at brukerne får riktig informasjon til riktig tid. Menystrukturen på nettstedet (eller applikasjonen) er alltid et diskusjonstema i prosjektene.

Det finnes naturlig nok mye faglitteratur på temaet og trender kommer og går mht. hva som er “riktig”. De fleste har kanskje hørt om regelen som sier at man ikke skal ha mer enn 7 +-2 menypunkter? Opprinnelsen til denne regelen er fra en artikkel publisert i 1956 av George A. Miller som var en undersøkelse av korttidshukommelsen til ungdommer (se også en kort forklaring av teorien på Wikipedia). Jeg var senest på et U11 seminar i Boston i fjor hvor Gerry McGovern gjentok denne regelen og mente at den fremdeles gjelder for navigasjon. Det er bare en liten hake ved hele greia, man trenger aldri å huske/memorere en navigasjonsmeny - man skal bare kunne vite sånn cirka hvordan nettstedet er organisert og så scanne seg frem til riktig menypunkt! Derfor er det meningsløst å ha en regel som går på at man må begrense menyer til antall menypunkter som folk antas å kunne memorere selv. Lengden på hovedmenyen er stort sett aldri et problem i seg selv, men hvis du bryter en av mine sju regler for god menystruktur så vil du oppleve at brukerne dine får problemer. Garantert!

OK. Nok prat. Her er mine 7 regler for god menystruktur og navigasjon:

1. Lag et navigasjonskonsept som er lett å forstå for brukerne!
2. Finn en god balanse mellom bredde og dybde!
3. Menypunktene skal være på samme logiske nivå!
4. Det skal ikke være vanskelig for brukeren å velge menypunkt på toppnivå!
5. Ikke bruk fagutrykk i hovednavigasjonen!
6. Baser navigasjonen på nettstedet på ett hovedprinsipp for navigasjon, men tilby flere innganger til samme informasjon!
7. Vær konsistent!

Jeg vil gjerne ha kommentarer på disse reglene og hvis det er noe jeg har glemt så vil jeg gjerne vite om det også

Jeg vil prøve å uttdype disse reglene en etter en i blogginnlegg her på blogandtell.no og linke disse opp til denne artikkelen.