søndag 16. mars 2014

Leksikonsøk på TVen?

Hver søndag, starter jeg som regel dagen min med litt surfing fra sengekanten, før jeg drar meg ut av sengen, trer inn i dusjen og deretter lager egg og bacon til frokost.

Jeg er vel neppe alene om dette, å sitte på sengekanten for å lese litt nyheter eller andre artikler. I morges tenkte jeg over: Hvordan gjør JQuery Mobile seg på en SmartTV? Jeg har jo to SmartTVer og flere JQuery Mobile sider jeg har laget før - så det var jo en enkel sak å teste.

Ransake fant jeg ut var en god kandidat, her er det utstrakt bruk av CORS (Cross-Origin Resource Sharing), gjennom min egenutviklede API-PROXY, som mellomlagrer resulatene. Ransake benytter seg også av NSF (Norsk Scrabbleforbund) sin ordliste, for "tilfeldig"-funksjonen (søk etter tilfeldige emneord).

Testen min var ikke -om det virker-, dagens SmartTVer baserer seg nemmelig - som de fleste nettleserne på WebKit. At det virket, var nesten forventet - og det virket!

Universell utforming

Når det kommer til grad av universell utforming, vil jeg si at her er det TVen som ødelegger moroen.
Teksten, bilder og alt annet fungerer utmerket og som forventet, knapper er store og tydelige, illustrsajoner like så. Men tekst-inntasting gjennom en fjernkontroll er fremdeles en utfordring.

Nå kan jeg riktignok fjernstyre TV-en min gjennom en APP, slik at jeg kan bruke tastaturet jeg foretrekker på telefonen (eller nettbrettet). Eller, jeg kan velge å koble til et tastatur til TVen.

Hvor mange som kobler tastatur eller mobile enheter til TV-apparatene, vet jeg ikke. Hvis mange gjør dette, er kanskje ikke inndata et like stort problem som jeg personlig føler det er. 

Funksjonalitet

Som forventet, fungerte funksjonaliteten på lik måte som på mobil, nettbrett eller PC.
Jeg må egentlig si at jeg var overrasket over hvor raskt det gikk, særlig når jeg henter tilfeldige ord og så søker opp fra 8 API-tilbydere og laster dette inn asynkront i Ransake. Jeg fikk opp bilder fra Flickr, artikler fra Store Norske Leksikon, artikler fra Bergen byleksikon, Norsk Kunstnerleksikon, WikiPedia og flere andre kilder. Alt fungerte sømløst og kjapt, selv om SmartTVer har svakere prosessor enn dagens telefoner.

Her skinner selvsagt den asynkrone lastingen godt, man laster nemmelig inn data - uavhengig av grensesnittet. Grensesnittet lastes bare en gang og innholdet lastes uavhengig. I motsetning til synkrone webapplikasjoner, vil man ikke her måtte vente på svartider, domeneoppslag og annet. At jeg har laget en proxy for API-er, som både omgår CORS-problemet (same origin policy) og mellomlagrer JSON-treff, betyr at jeg får enda raskere søketreff.

Erfaringer fra bruk

Tilfeldig-knappen synes jeg er enda mer på sin plass på TV, enn på mobil. Jeg er glad i den på mobilen også, men på TV-en er inndata enda kjedeligere enn på mobilen. Jeg liker ikke å skrive på OSD (On-Screen Display) tastatur. At jeg kan ligge på sengekanten og trykke på "tilfeldig" og enten laste tilfeldige bilder, basert på ord fra NSF-listen (eller se artikler), er ganske kult. Jeg vil si det er minst 80% kult, en måte å snuble over innhold på.

Jeg tror ordskyen (som jeg ikke har utviklet) - der jeg skal visualisere brukerskapte spørringer og utbredelsen (relativ forekomst hos datatilbyderne) - vil være enda en god kilde for bruk. Særlig gjelder nok dette på TV, hvor man da kan lese seg gjennom en strøm av hva andre folk har søkt etter! Man har da en "trending", ved at brukerne skaper metadata om bruken.

Andre kule ting å gjøre på mobil/tv-APP

Jeg har tenkt på å implementere SSE (Server Sent Events), som betyr at jeg kan fra serverens side påtvinge oppdateringer av grensesnittet til brukeren. Eksempel på dette er et parkeringssystem jeg lagde i HTML5, med kartbobler, som viste kapasite på 3 parkeringshus i Bergen. Her brukt jeg AppCache, LocalStorage, SSE og selvsagt responsivt design. Jeg har tenkt litt tanker rundt dette i morges, når jeg lå på sengekanten.
Hva er egentlig vitsen med informasjonstavler, når man kan lage HTML5 APPS med SSE?
Man trenger ikke dyre infotavler med proprietær programvare, man kan like gjerne lage HTML5-baserte APPs som fungerer på alle plattformer.

Tanker om ransake

Jeg er usikker på hva jeg skal gjøre med ransake, den fungerer fint som en demo og jeg kan utvikle mer på den. Men jeg tenker at Ransake -navnet ikke er bra nok. Hva er det for noe? Enten må jeg finne på et "hipt navn" og skape assosiasjoner, eller jeg må prøve å få en bedre definisjon av hva ransake er for noe. Det er ikke utelukkende leksikon, samt jeg vil koble på mer.. Men hva er det egentlig (hvis man ser bort i fra at det er en slags proof of concept).

Hvis jeg for eksempel skal lansere Ransake som en APP, på TV og mobil, hva kaller man det? :-)
Den vil jo gi treff i alt fra WikiPedia til forskjellige nettleksikon, til flickr og enda flere kilder jeg kobler på.
Jeg er usikker på hvordan jeg skal definere ransake, hva er det, er det håndfast? Hvorfor skal folk bruke ransake? Må jeg snevre inn "scopet" til bare leksikale kilder, ellre bør jeg koble på populære tjenester som instagram, facebook og annet? Jo flere datakilder jeg kobler på, jo mer "ullent" føler jeg tjenesten blir.

Men samtidig blir en mer ullen tjeneste kanskje mer morsom å bruke, med NSF-ordlisten og tilfeldig-funksjonen, ser jeg jo lett at mange søkerod ikke får treff i flickr. De fleste ordene har artikler i en av de autoritative kildene, men bilder er en annen ting - her må jeg nok eventuelt koble meg på flere bildetjenester!

torsdag 6. mars 2014

NSF Ordlisten og GA Kampanjer innført i Ransake

Bidraget mitt til hackathon tidligere i år; Ransake, har jeg i kveld jobbet videre med. Nå har jeg implementert NSF-Ordlisten slik jeg ønsket å gjøre det. Jeg har også implementert funksjon for sporing av kampanjer (det vil si, ikke kampanjer i økonomisk forstand, men sosiale kampanjer i form av QR-koder og NFC).

Det som ikke kan måles, har ingen verdi!

Kanskje jeg overdrev litt med den overskriften, men overskrifter selger! Hvis QR-Koder og NFC skal kunne måles i en konkret verdi, må man se på tilsvarende til CTR (Click Through Rate). Hvis jeg hadde tenkt på dette, før jeg lagde mine proof of concept QR-koder, kunne jeg bakt det inn i URL-strengen. Men jeg har ikke nok parametre i QR-kodene jeg har skrevet ut, samt jeg eier ingen skriver.

NFC-brikkene kunne jeg bare reprogrammert, jeg tenker miljø, gjenbruk og lommebok. Derfor er de ikke låst for skriving. Selv om jeg kunne gjort dette, er det ulemper med en lenger nettaddresse.
  • NFC-brikkene mine tar 120 bytes. 
  • QR-kodene blir mer kompleks, jo mer data man fyller i
    • Dette fører til at de blir vanskeligere å skanne

Altså føler jeg at jeg egentlig er kanskje på en sweetspot, men jeg har tenkt mine tanker om hvilke parametre man bør bake inn i en QR-kode, for kampanjesporing i Google Analytics. Skal ikke utbrodere noe mer om det i denne omgang.

Hvordan bør man spore den sosiale kampanjen fra QRkode og NFC?

Man trenger ikke spore kampanjen helt fra den fysiske koden, man kan like gjerne sende en unik ID som identifiserer kampanjen, så kan systemet slå opp kampanjen i databasen og "oversette" til sporingsparametrene. Feks. Kampanje ID 99 sendes fra QRkoden gjennom adresselinjen, eller fra NFC-brikken. PHP slår opp mot MySQL og henter ut informasjon om Kampanje 99.

Systemet henter ut at det for eksempel er et a4 ark, at det er en QRkode, hvilke søkeord som er relatert (hvis noen), samt andre faktorer. Man kan da også ha mye annen informasjon, som når kampanjen ble laget, forventet levetid, samt man kan legge inn styringslogikk som fører brukerne ut fra kampanjen, hvis den har et absolutt stopp-punkt.

På denne måten kan man styre brukerne, man kan føre relativt omfattende statistikk på fysisk interaksjon med kampanjer, man får beholde korte URL-er, man sender bare kampanjeid. Søkeord og annet kan man bake inn i kampanjen.

Selv om jeg har nevnt veldig mange fordeler med denne løsningen, er kanskje den aller største fordelen fleksibilitet. Tenk om noen har laget 100.000 plakater som er sendt ut og hengt opp, så finner man ut at man burde endret litt på søkestrengen. Hvis QRkoden og NFCbrikken sender bare kampanjens ID og systemet slår opp resten, kan man påvirke prosessflyten fra fysisk interaksjon med plakat eller annet objekt, til hvor man blir ført. Ikke bare er det et enormt sikkerhetsnett, men i andre tilfeller kan man jo tenke gjenbruk.

Man kan lage generiske kampanjer, som for eksempel "Månedens artikkel" eller "dagens...", som endres innenfor gitte tidsintervaller. Det er jo som alltid fantasien som setter grenser, ikke teknologien.

Status på piloten Ransake

Saken er den at jeg fikk på plass det jeg tenkte på tidligere i dag, jeg fikk laget meg en overstyring av asynkrone søk, i de tilfeller det var et statisk søk (søkeparameter i addresselinjen). For å ikke forvirre brukerne, fjernes søkeboksen når det er søkestreng i adresselinjen.

Man får en knapp "fjern søk", når man kommer inn gjennom kampanjene NFC eller QRkode (som kan være på den samme fysiske plakaten, for den slags skyld).

Teksten på knappen blir muligens endret, samt ikoner. Ransake er en proof of concept løsning, som kanskje munner ut i noen praktiske løsninger i andre tilfeller. Når jeg ser Ransake tar til form etter hvert, føler jeg egentlig at det kanskje blir brukbart i seg selv, når løsningen er ferdig. Domenet ransake angrer jeg på, jeg føler at det kanskje er et ladet ord.

Når jeg kjøpte domenet, rett før hackathon, tenkte jeg på ordet ransake. Det kan jo være å gå etter noe i sømmene. Men i ettertid har jeg tenkt på domenenavnet, kanskje det er for ladet? 

Hva har jeg lært i dag?

  • Kampanjesporing på Google Analytics er ikke vanskelig
    • Men det kan være veldig nyttig!
  • Lag sporingssystemene før du lager QR-koder og skriver til NFC-brikkene
    • Hvis du gjør det i motsatt rekkefølge og glemmer en parameter, vil du måtte lage unntaksbehalding i bakende-koden.
NB! GA sin sporingskode for kampanjer, skiller på STORE og små bokstaver.

onsdag 5. mars 2014

Jeg hacket hos kulturrådet, i morgen skal jeg tilbake!

Artikkelsamlingene vises fra det
jeg definerer som autoritative kilder.
I anledning jobben min på Bergen Byarkiv, ved Avdeling for Moderne Arkiver, får jeg gjort veldig mye kjekt og interessant. Mye av det vi gjør på, er "research" og utviklingstjenester.

En av tingene jeg har gjort i det siste, er å delta på et Hackathon for åpne data. I morgen skal jeg reise på posthack, et slags nachspiel for hackathonet.

I motsetning til et vorspiel med alkohol, ble det gjort mye produktivt på hackathon (med potetgull, sjokolade, cola og ~~200 mennesker).

Klapp :)
"Det var altså ikke bare tannlegene som ble glad for dette arrangementet."



Min deltakelse

Jeg deltok med mitt prosjekt "Ransake", som er en løsning som søker i Store Norske leksikon, Bergen byleksikon, Norsk kunstnerleksikon, Wikipedia, Flickr, m.fl.

Søket går gjennom en egenutviklet proxy (mellomledd) som mellomlagrer treff fra API-grensesnittene.
Her er et typisk søk etter oslofjorden,
i den grad det kan bli typisk. Treffene
kommer her fra Flickr. Det vil komme
instagram og andre koblinger i fremiden.
Denne løsningen kaller jeg "Flux Capacitor", som er en intern vits med meg selv. Jeg er litt usikker på om man kan ha en intern vits med seg selv, men jeg jobbet alene med Ransake, så det ble nå en gang slik.

For de som ikke skjønner vitsen, så må jeg nesten legge til et sitat fra Wikipedia:

The flux capacitor, which consists of a rectangular-shaped compartment with three flashing Geissler-style tubes (arranged in a "Y" configuration), is described by Doc as "what makes time travel possible."

Altså er fluxcapacitoren det som gjorde tidsreise mulig - i "Tilbake til fremtiden"-filmene.

Dette er i "god skikk"-tråd, for å forhindre hamring av API-er, samt man sparer gjerne 0.1-0.2 sekunder per domeneoppslag. Ransake slår jo opp mot 8 kilder per dags dato og tallet skal øke! Ganger jeg 8 med 0.2 sekunder, blir det 1,6 sekunder sløst på domeneoppslag alene! Dette er før PHP-skriptet røsker til seg JSON-data gjennom http-protokollen. En annen viktig fordel med dette skriptet, er at jeg får komprimert JSON-dataen, fra Flux Capacitor proxyen til jquery skriptingen som kjører i nettleseren. På denne måten blir det mindre "overhead" (cpu-tid) og det blir en mer sømløs opplevelse.


Kjedelig å vente

Forskning viser til særlig tre tidspunkt for brukere av datasystemer, som også gjelder for web og da særlig Web 2.0, samt sosiale medier. Tallene er: 100 millisekunder, 1 sekund og 10 sekunder.

"Flux Capacitor, makes time travel
possible" Kilde: Doc, tilbake til fremtiden

Hvis en bruker venter 0,1 sekund, føles det umiddelbart ut. 1 sekund føles responsivt, 10 sekunder fører til at brukerens tanker har sklidd over i noe annet. Nå er brukeren på vei bort. Jeg forutså potensielle ytelses-problemer rundt dette og jobbet for å få ned tiden. Hackthon gikk over to dager, så jeg tok å la noen ting til JavaScript som jeg har tenkt å flytte til "serversiden". Ytelsen kommer sånn sett til å forbedres ytterligere.

Men Flux Capacitoren tar seg av mange problemstillinger, i form av svartid, domeneoppslag og trafikk.

Formålet med ransake

Hele tanken bak prosjektet mitt, var å forhindre metasøk, man skal ikke søke for å søke. Videre har det jo unektelig blitt slik at Google og andre søkemotorer leverer deg det du forventer å finne. Jo mer aktiv du er på sosiale medier, bruker Web 2.0 tjenester, jo mer vet Google og andre om deg. Dette fører til at du får et mer innsnevret verdensbilde, enn om du gikk rett til de autorative kildene.

Men problemet er at ingen husker alle kildene og du orker ikke å gå inn i alle kildene og søke direkte. Du vil søke en gang og finne det - der og da (det er i alle fall det jeg vil at du skal ville)!

Nå høres det kanskje ut som at jeg vil erstatte Google, men det er ikke det som er hensikten. Hensikten er å gi autorative kilder til lærere, studenter, skribenter eller andre. Vi er alle i vår generasjon påvirket av "google effekten" (Man glemmer informasjonen, men husker hvor man finner den).

Jeg ønsker sånn sett å gi en alternativ inngang, en autorativ kilde som kan knytte sammen relevante data. Det er i utgangspunktet leksikale data og Wikipedia jeg anser som relevant å koble i denne konteksten.
Prosjektet er mer en "proof of concept" greie, men jeg har lastet inn NSF (Norsk Scrabbleforbund) sin ordliste i databasen. Tanken er å utvide med "tilfeldig ord", slik at man kan bruke løsningen som tidsfordriv. Sitter du å kjeder deg, kan du søke etter tilfeldige ord i autorative kilder! Denne tjenesten er dog ikke utviklet enda, selv om jeg er ferdig med selve databasen.

Ordskyen er heller ei på plass, denne tenker jeg skal vise populære søkeord og vekte de etter relativ frekvens. Eksempelvis kan det være at mange søker etter et emneord, som muligens mangler i SNL eller Wikipedia. Dette vil jo ha en enorm verdi, å kunne målrette innholdsproduksjon etter brukernes aktivetet, i tro med hele Web 2.0 og Sosiale medier tankegangen. Man kan tenke forbi brukerskapt materiale og tenke skreddersydd materiale etter brukerne. Når artikkelen er på plass, kan denne "pushes" ut til brukerne som søkte etter artikkelen?

QR-koden som gir deg 1 million kr.
Neida, bare tuller, den fører deg
til www.ransake.no , men det er
jo nesten verdt like mye i
mine subjektive(?) øyne.
Enkelt sagt: Ekstrahere statistikk på hvilke artikler som mangler i hvilke artikkelsamlinger, som igjen kan brukes som en viktig kilde for faglig påfyll i innholdsmotorene.

Her kan man gjøre mye lurt - og det er data som skapes av bruk.
Det er data som er verdt mye mer enn en generisk spørreundersøkelse, som til gjengjeld koster mye å få utført og analysert! Hvorfor ikke la brukerne spørreundersøke deg, fremfor at du skal spørreundersøke brukerne? De spør etter ditt innhold - har du det ikke - så lager du det (hvis du vil, da!).

Jeg skal med tid og stund (jada, jeg vet det er farlig å love) - utvide ransake med både NFC-inngang og QR-koder. Jeg lager en liten "proof of concept", men jeg må bygge om siden for at den skal klare å ta i mot lagrede søk. Nettsiden bygger jo på utstrakt bruk av AJAX / Web 2.0, med asynkront innhold. Det er noen strategiske valg som må gjøres, for å forhindre at man overstyrer asynkrone søk, ved å sende brukeren til en statisk søkestreng.

Jeg har tenkt ut løsningen nå, et "vanlig søk", med paramtere:
  • NFC-Kilde
    • ?nfc=søkestreng
  • QRKode-Kilde
    • ?qr=søkestreng
NFC som inngang til www.ransake.no ,
langt fra en drøm - jeg har gjort det!
Jeg er jo fremdeles ikke kommet "rundt" problemet med asynkrone søk som overstyres av statisk nettadresse, men jeg har en tanke om å sjekke om $_GET[]-variabelen (som er den delen man ser synling i adresselinjen) er tom eller ei. Hvis den er NULL, viser jeg søkeboksen. Hvis den ikke er NULL, må jeg vise et eller annet "søketreff for <søkeord>", med en lenke eller knapp for å gå tilbake til søk. Det kan tenkes at jeg trikser det til med .htaccess for å lage litt finere URL (mod rewrite, for de som bryr seg(da skal du være en god nerd!)).

I praksis vil dette muliggjøre deling av søk, på sosiale medier. Jeg er litt usikker på verdien av å dele et dynamisk søk, da man aldri helt kan vite hva som kommer fra kildene, selv om de i stor grad er autoritative.

Det ble nå en digresjon, men en viktig ting å tenke over, særlig når det kommer til bildetjenester. Man jo risikere at noen laster opp bilder som er NSFW!.

I have a dream


Jeg har en drøm, eller, kanskje bare en fantasi.

Min tanke er igjen å jobbe videre med mitt proof of concept. Spørsmålet er selvsagt hvor mye man må bevise i et konsept, men jeg har en drøm (eller fantasi?) - om å videreutvikle ransake til å hente mer data, fra innholdsprodusentene. Til syvende å sist vil jeg fremdeles ha en "gå til ekstern kilde", men jeg har en drøm om at ransake kan være en base som også kan vise til spesifikke objekter, de kan være enten kartfestede eller være artikler eller annet. Fantasien setter grenser (samt selvsagt hvor mye tid jeg bruker), men saken er jo den at man kan plassere ut fysiske interaksjonsobjekter i form av QR-Koder og NFC-Tagger.

Gamification

Når man først har kommet så langt, hvorfor ikke tenke det neste steget med gamification?
Kan vi lage et fysisk spill av ransake? Nå sier jeg vi her, men vi er altså meg.
Jada, jeg er meg! For øvrig er jeg en mester i digresjoner, men poenget er: I hvilke andre kontekster kan man vise den samme dataen og lage nye "mashups", i Web 2.0 ånden.

Når det er sagt, er det posthack i morgen. Da blir det ikke en praktisk hackeaffære, men innlegg og viktige bekjentskaper og erfaringsutvekslinger, idèmyldringer, innlegg, og annet.

Relevante lenker

Smartere SmartTV, la oss lage gode APPer!

Utallige ganger har jeg hørt folk si ting som

  • "Jeg trenger ikke smartTV"
  • "Jeg bruker aldri funksjonene på smartTVen"
I en viss grad er det vel stort sett bare NetFlix og HBO som blir benyttet svært aktivt.

Hva er årsaken?
  • Kan det ha noe å gjøre med at fjernkontrollen ikke er egnet for interaksjon?


Hva kan vi gjøre?


Mange savner nok APPer på sine Smarte TV-er, smarte DVD-spillere og andre enheter i hjemmet. Men få vet vel at man kan faktisk gjøre noe med det selv (så fremt man er en utvikler). Mange smart-tver støtter HTML5 APPer og har API-er, SDK-er, samt dokumentasjon som er enkel å beherske.

Case for dette innlegget, er Samsung sine APIer for smartTV.
Jeg skal ikke i denne casen ta for meg alt man kan gjøre, bare noen ting jeg her og nå synes er fascinerende og en slags ièmyldring med meg selv på begge sidene av bordet.

Utviklingsguide

Samsung har en svært omfattende utviklingsguide, med gode skjermbilder. Her ser man alt fra hvordan man setter opp en emulator, til hvilke taster man kan bruke på et tastatur, som er tilkoblet. Alt i alt er det veldig lett å skumme seg gjennom manualen, jeg er svært positivit overrasket av hvor lettfattet dette er å sette seg inn i. Jeg liker særlig at de også viser hvordan man kan emulere en smarttv inne i Google Chrome, som betyr at man ikke nødvendigvis trenger å kjøpe en smarttv for å starte APPfabrikken sin.

Før man kommer så langt, bør man lese startguiden for å lage apps, samt UX-guide som tar for seg alt fra fontstørrelser til skalering fra 720P til 1080P, ytelsesprobelamtikk, vanlig visningsavstand, standardavvik i farger, fontstørrelser, linjelengde og mye annet som er relatert til UXD. Noen av eksemplene viser rèelle eksempler fra en demo APP man kan lese utviklerguiden av, nyhetsleseren.

Bilde i bilde

Hvis du ønsker å ha bilde i bilde (eller tvbilde inne i APPen din), kan man ganske enkelt finne eksempelkoden i dokumentasjonen til Samsung. Som man ser av eksempelet, er det svært få linjer kode, men dette forutsetter jo at man har bygget rammeverket rundt på forhånd.

Multi Screen SDK

Dette begrepet høres bedre og mer logisk ut på engelsk, det er i praksis en måte å muliggjøre APP på en telefon (IOS, Android, Windows eller hva som helst), som interagerer med SmartTV APPen gjennom en kanal man åpner for kommunikasjon. 

Jeg fikk umiddelbart her idèer som at man kunne utnyttet NFC-leseren  til å interagere med APPen man lager i SmartTVen. I tillegg kan man selvsagt bruke kamera med QR-koder, eller sosial deling gjennom SmartTVen. Jeg tenker at litt av akkilleshælen til dagens Smarte TVer, er at å taste inn tekst på en vanlig fjernkontroll er noe herk! Med Multi Screen SDK, kan man selvsagt sende tekst/data fra telefon, nettbrett eller PC. Inndatamulighet som ikke føles som sirup, endelig!

Men hvorfor stoppe der? 

Kontekstualiserte APPer i SmartTVen din

Hva med å bruke Android Tasker for å automatisere APPer du har på smarttven din, for eksempel kan du slå på TV-en, bytte til riktig kanal og så starte APP-en din og få bilde inn i APPen. Kanskje du vil aggregere nyhetsstrømmer inn i en ny flate, der du også kan se på din favorittkanal, i det du kommer inn døren :) 

Man må møte brukerne der brukerne ønsker å møtes - og hvem ønsker ikke å bli møtt i døren?

Det krever ikke all verden utvikling, men for å fjernstarte APPer, må du registrere APPen i DIAL-registeret

Hvis du flytter interaksjonen ut på din favoritt-telefon eller nettbrett, enten om den er IOS, Android eller Windows Phone, får du en flate som du selv har valgt. Du valgte selv din telefon, med mindre du var så heldig at du fikk den i jule- eller bursdags-gave, men det var nå egentlig en unødvendig digresjon.

Konseptet gjelder uansett, du kan bruke telefonen sine sensorer, alt fra temperatursensor, magnetsensor, digitalt kompass, gps, høydemåler, g-sensor og annet. Du kan høste informasjon fra fysiske objekter, for å utføre interaksjon i form av augmentert virkelighet, ved å bruke NFC-leser og kamera.

Mulighetene er uendelige og kanskje noen endelig lager en APP som alle vil ha.

Relaterte lenker

tirsdag 4. mars 2014

Forventninger ved foretningsmessig bruk av sosiale medier

For å lykkes med foretningsmessig bruk av sosiale medier, er det viktig at man er klar over forventninge man da havner i. I denne casen, vil jeg ta for meg bloggen til SNL (Store Norske Leksikon). Her vil jeg ta for meg de fem punktene og analysere hvordan bloggen jeg valgte - fyller hanskene.

Troverdighet (authenticity) 

Bloggen innehar en personlig tone, som ikke hadde egnet seg på selve leksikonet som ligger på www.snl.no . Dette er noe man forventer av en blogg, en kanal for interaksjon, med en noe mer personlig fremtreden i artikler. Tilllitten forsterkes videre gjennom facebook-boksen som viser at det ikke bare er jeg som liker SNL, det er også 1919 andre. Facebook-boksen gir meg den transistive tilliten, ved at jeg ser bilder av at mine venner også liker SNL på Facebook. Implisitt, gir dette en følelse av samhold og tillitt ovenfor SNL.
Det gir også en autentistetsfølelse, jeg føler at dette må være den ekte bloggen til SNL.

Gjennomsiktighet (transparency) 

En av de tingene som fort kommer til syne på bloggen, er hvordan livet er som en leksikonmedarbeider. Det ytres økonomiske utfordringer, det ytres bruk og man tar opp viktige problemstillinger, samt utfordringer knyttet til dette. Man kan på bloggen lese forretningsmodellen, man kan lese om tilskudd, politiske valg, løfter fra politikere og andre emner som -der og da- virker å være viktige for artikkelforfatterne.
Dette gir en følelse av gjennomsiktighet og viser samsunnsengasjement. Tjenesteinnholdet kommer også til syne, ved at man omtaler hendelser, innhold og artikkelforfattere.

Åpenhet (Medvirkning) (engagement) 

Forventninger om at meninger skal bli hørt og tatt hensyn til, blir aktualisert gjennom brukerskapte kommentarer. Det er ikke alle blogginnleggene som har kommentarer, men det virker ikke som at man "filtrerer vekk" kommentarer basert på en subjektiv verdifaktor. Dette er jo en viktig oppskrift på å skape engasjement, at brukerne kommer til syne, de føler de blir sett og verdsatt. De assosieres med noe større, med et kvalitetsstempel.

Bloggen oppfordrer til kommentarer, det samme gjør for øvrig også www.snl.no, hvor innholdet har en leksikalsk karakter. Brukerne blir ofte besvart, der det virker logisk å besvare de.

Rask respons (real-time response) 

På et utvalg innlegg jeg sjekker, var responstiden alt fra 10 minutter til 24 timer.
Det vil jo nødvendigvis være slik at en organisasjon eller bedrift, ikke er på jobb 24/7, slik en privatperson gjerne er på sosiale medier. 24 timer vil på en hverdag føles ut som en sosial evighet, men i helgen vil man gjerne forvente en lenger svartid.

SNL sin blogg er ikke av den karakter at de bør forvente misfornøyde kunder, som må behandles og besvares raskt, for å unngå viral spredning av misnøye. De drifter et elektronisk leksikon, med mange støttespillere. Men det er viktig å besvare innhold relativt kjapt, for å opprettholde forventningene om rask respons, som brukerne gjerne har vent seg til med nettbrett og smarttelefoner.

Langsiktighet (long-time view)

SNL evner å skape troverdighet og tillit til organisasjonen, som igjen kan ha stor betydning for
økonomisk støtte og bidrag. Merkevarebygging i sosiale medier tar tid, og forutsetter at man har en langsiktighet som overgår det tradisjonelle fokuset på tidsbegrensete markeds- og produktkampanjer.
Man ser klart i bloggen at de lykkes med nettop dette, de blogger på en smart måte, for å bygge opp sin egen merkevare.

Bloggen knytter tettere og mere permanente relasjoner med leserne, som nok består av både politikerne med pengesekken, så vel som organisasjoner som kan donere penger til et godt formål. Man kan også knytte til seg nye fagmedarbeidere og bidragsytere, skape et engasjement gjennom denne fremtoningen. Som nevnt innledningsvis, har de 1919 Facebook fans, som viser at de har gjort mer enn en ting riktig.

Bloggen kan høste meninger og erfaringer, analyseverktøyene kan brukes for å høste statistikk om trafikk, søkeord og annet. Dette har en potensiell verdi, ved at man kan målrette innhold etter brukerne. Hvis brukerne kommer inn og søker etter noe som ikke eksisterer i leksikonet, kan man prioritere dette for eksempel.

Analyse av en it-blogg

Jeg vil her ta for meg en analyse av http://blogg.itfag.hist.no.

Analyse av bloggens artikkelforfattere og formål

Ved å gå inn på "om oss", finner man fort ut hva bloggen har som formål - og hvem som skriver på bloggen. Det er en blogg som handler om IKT, teknologi, læring og forskningsarbeid. Innholdet er skrevet og publisert av ansatte ved HiST, som ligger til avdelingen for Informatikk og e-læring.

Dette gir bloggen en autensitet, da det implisitt er gitt at dette er skrevet av fagfolk.

Grensesnitt, innhold og målgrupper


Bloggen ser ved første øyekast relativt ryddig og oversiktlig ut, blogginnleggene er kategorisert innenfor campus, data og teknologi, diverse, FoU, intervju, itfag, læring, studier, samt tips og triks.
Alt i alt er det i skrivende stund 207 blogginnlegg, som er lett å finne frem til ved hjelp av kategorlisten i høyremargen eller ved hjelp av søkeboksen. Det er også på plass en ordsky (tagger), som viser den relative frekvensen av nøkkelord, som en alternativ inngang til innhold. Tagger gir en måte å søke på tvers av artikler, basert på nøkkelord. Det er litt jobb å "tagge" artikler, men det gir mye igjen i økt brukeropplevelse, søkemotorrangering og CTR (Click Through Rate), dvs. hvor mange som klikker seg gjennom, før de faller av lasset.

Forsiden på bloggen har til enhver tid det nyeste innholdet, slik man per definisjon egentlig skal ha på en blogg (kronologisk listing av innhold). I noen tilfeller regner jeg med at man bruker "sticky" / fastlimt blogginnlegg, hvis det er en spesiell hendelse (f.eks. streik, snøstorm eller andre ting som er svært viktig å formidle).

Leserne på gruppen, antar jeg at man primært kan dele inn i tre målgrupper.
Primærmålgruppen er nok studenter ved HiST, sekundærmålgruppen vil jeg anta er potensielle studenter.
Tertiærmålgruppen vil jeg si er den vanlige personen, med teknologisk interesse. I noen tilfeller vil nok tertiærmålgruppen omfavne medarbeidere hos HiST, men jeg antar at de fleste av dem kommer inn gjennom søkemotorer eller deling i sosiale medier.

En del av innleggene har brukerskapt innhold, i form av kommentarer på innlegg.
Dette fører i noen tilfeller til økt verdi av hovedinnholdet, som for eksempel blogginnlegget Wonderlop - det neste store?

Her ser man at bloggeren kommer med "it nytt", som er en fersk nyhet. Det skaper engasjement blant leserne, som tilfører bloggen merverdi gjennom brukerskapte tilbakemeldinger. Det forekommer erfaringsutvekslinger i kommentarfeltet, der det blant annet blir påpekt at man skulle ønske at det ikke bare var en APP, men også en nettside. Videre fører det til at man får formidlet at APPen var ustabil, samt at det ikke var mulig å få tak i invitasjoner.

Teknologisk plattform

Bloggens teknologiske plattform er WordPress, som er en åpen kildekode bloggplattform. Efaringer tilsier at WordPress er et av de bedre bloggverktøyene man kan installere på eget webhotell. Man kan utvide bloggplattformen med utallige innstikk, det er store forum og mye hjelp å få på sosiale erfaringsnettverk som for eksempel stackexchange. WordPress kjører også best på Linux, Apache MySQL og PHP (LAMP).

LAMP har en fordel at det er fritt for lisenser, samt krever ikke all verden av maskinvare for å gå rundt.
Man kan installere en LAMP-server på en liten rasberryPI pc, som har samme fotavtrykk som et (forvokst) kredittkort.

Bloggen har noen ting som er gode, som for eksempel ordskyen som ble nevnt tidligere, bruk av kategorier og en bredde i innholdet. Dette gjør at man har flere innganger, samt man har en faglig bredde i innholdet.
Det er også smart av bloggerne å bruke bloggen i fagsammenheng, som gir økt oppslutning på bloggen.

Det er noen ting på bloggen som bør gjøres noe med, blant annet står det "Search..." i søkefeltet, det er relativt lav grad av universell utforming på menyen (:hover). Til slutt vil jeg nevne at bloggens identitet har en klar sammenheng med nettsiden til HiST. Man ser med en gang at det er kjente HiST-elementer, som er med å skape tillitt (autensitet).

Hva gir bloggen?

De har som mål at bloggen skal være en viktig arena for erfaringsdeling og utveksling av kunnskap, dette er i tråd med forventningene om hva sosiale medier tilsier, dette med åpenhet og transparenthet. Bloggen gir også en personlig tilnærming til emner og det fremkommer en synergieffekt ved at man får delt erfaringene og på den måten samtidig produsert artikler. I motsetning til mange private bloggere som må finne på sine egne emner og må oppleve episoder, reiser eller hva enn de ønsker å promotere, vil IT-bloggen ha et tilnærmet uendelig påfyll av erfaringer og kunnskapsutveksling, samt ny teknologi og programvare.