Inga status-uppdateringar tack, men gärna Inspiration!

Kommunikation i relationer kan vara av ett flertal typer. Kommunikation som inte löser ett primärt mål filtrerar nog de flesta bort, snabbt.

Ett par exempel på typer av innehåll i kommunikation:

1. status-uppdateringar ("Hur e läget?" "Fint.")
2. pladder och info ("Vad gjorde ni på gympan idag då?" "Samma gamla vanliga, hinderbana.")
3. försäkranden ("Du klarar det!")
   
4. fel-meddelanden ("Nej, ha inte i timjan i pajen.")
   
5. diskussion och inspiration ("Jag ser pappersprototyper som vårt främsta utvecklingsverktyg." "Jaha. Vilka fördelar och nackdelar har den typen av prototyper jämfört med html-prototyper?")
6. slagsmål ("Sluta skriva på din blog att jag är fet!" "Men du är ju det ju!")
   

De sex typerna ovan tycker jag är listade i ökande viktighets-ordning. Diskussioner är alltså viktigare än pladder.

Innehållet i status-uppdateringar oss människor emellan är nog riktigt oviktigt. Vi fortsätter endå med dem, för de är en mycket viktig del i att underhålla relationer oss människor emellan. Interaktion handlar ju primärt om att underhålla relationer.

I webbapplikationer finns det många tillfällen då inte personer pratar. Istället pratar 'systemet'/'webbplatsen'/'applikationen'. 'Applikationen' har inget ansikte, ingen röst.

Användarna har ingen personlig relation till 'applikationen'. Därmed har användaren väldigt liten anledning att delta i interaktion med 'applikationen'.

Vilka motsvarigheter till de 'riktiga' interaktionstyperna ovan finns det då i webbapplikationer?

1. status-uppdateringar "Du är på steg 2 av 5"
2. info och instruktioner: "Fyll i fälten och klicka på 'skicka'"
3. försäkranden: "Det går snabbt och är gratis att bli medlem"
   
4. fel-meddelanden: "du glömde fylla i din e-postadress"
5. diskussioner och inspiration: utförliga artiklar om intressanta ämnen och trevliga diskussioner mellan personer
6. slagsmål: flame wars

Jag vill säga att webbanvändare generellt inte läser någonting före punkt 5 och 6 ovan. Diskussioner och slagsmål däremot kanske man ögnar igenom, eller till och med läser.

Generellt kan man alltså säga att den text som webbproducenterna skriver inte läses, medan användargenererad text kanske läses.

För webbskapare betyder detta att extremt fokus behöver lägas på att inte behöva felmeddelande, instruktioner och sånt blaj. Användartester är självklart en av lösningarna på problemet.

Ett intressant undantag tror jag är Inspiration. I applikationer där användaren ska skapa något (skriva en text, bygga en frågesport, publicera ett fotogalleri) kan rent inspirations-skapande innehåll hjälpa användaren. Jag tänker mig att 'inspirationen' visas i eller nära flödet som användaren går genom för skapa artefakten. Inspirationen är därmed en del av 'systemet'.

Anledningen att inspiration kan vara värdefullt är att inspirationsmaterialet löser ett av användarens primära problem: "Jaha, jag ska skapa ett fotogalleri. Hur vill jag att det ska se ut då?" Felmeddelanden och statusinfo löser inga primära problem för användaren.

/ Björn

ps. Självklart ska vi tillse att status-meddelanden och hjälp-texter finns tillgängliga på de ställen där se behövs. Så gäller även text och andra element vars syfte är att försäkra användaren om att han kommer klara av skapandeprocessen. Grejjen är dock att de ska vara lagom osynliga och att man aldrig får se dem som något primärt i applikationen man skapar. ds.

Hubs

Grupprelationer. Inte bara för människor -- för prylar på webbplatser också!

I "Structure and Flows" diskuterar Hagan Rivers konceptet hubbar. En hubb är en samling funktioner och/eller (länkar till) material. En hubb är Royal Quiz turneringslista. I hubben har vi samlat ett antal nuvarande och ett antal gamla turneringar. Dessutom finns en länk till alla gamla turneringar. (Navigationen etc är inte del av hubben.) När man genomfört en turnering är det naturligt att man återkommer till hubben för att prova en annan. Det är den cirkeln (hubb -> funktion -> hubb) som visar på att det är en hubb.

Hagan diskuterar ett flöde enligt ungefär följande:
1. Få en kravspec på funktioner (eller innehåll).
2. Identifiera hubbar, alltså funktioner som verkar vettiga ihop.
3. Användartesta.
4. Skapa design som stödjer hubbarnas funktion. Designfasen kan innebära att innehållet i hubbarna ändras.
...iterera 3 & 4 till dess att det är klart...

Jag tänker att hubbens ursprungliga innehåll kan ges större fokus än vad Hagans ger det.

En hubb är ju en samlign funktioner som ska lösa ett problem för användaren. Som ett exempel kan vi ta frågan "Vad är nytt på OrkidéPrat?" vilket är naturligt att fråga sig när man loggar in.

Svaret hittar man genom olika metoder -- fältstudier, användningsanalys etc -- och jag tycker just nu att 4 underfrågor är viktiga att besvara:
- Har jag fått några nya brev?
- Är några av mina favvo-medlemmar inloggade?
- Finns det några nya svar på mina favoritdiskussioner?
- Vilket nytt prat finns det?

Utifrån de 4 frågorna byggde jag om sidan OrkidéPrat-medlemmarna hamnar på när de loggar in.

Min process var alltså:
1. Hitta problemet.
2. Hitta funktioner som löser problemet.
3. Identifiera hubbar, alltså funktioner som verkar vettiga ihop. (Kan hända att man ska skapa flera hubbar utifrån problemet.)
4. Användartesta.
5. Skapa design som stödjer hubbarnas funktion. Designfasen kan innebära att innehållet i hubbarna ändras. (Ändringar känns dock mindre aktuella då problemet gyuidat processen från början).
...iterera 4 & 5 till dess att det är klart...

För mig är alltså en hubb:
Hubb: Problemet / Huvudfrågan
Funktion: Lösningen / Underfrågan / Svaret

Hubb-konceptet kan alltså användas inte bara för att skapa en arkitektur som funkar för innehållet utan även för att definiera innehållet självt.

Ingen hjälp här...

Jag vet inte om nätet kan hjälpa unga Vincent...

It's the social, stupid!

Relationer byggs i grupp. Men man har ju en relation till sig själv också. Funkar webben bäst som en ego-booster eller som gemenskapsbyggare?



Professorn anser att det innehåll (i detta fall YouTubes widgets) som funkar är det som har en grupp av personer som identifierar sig med innehållet. Låter la vettigt. Men individen och gruppen samspelar trots allt:

1. En person gillar nåt.
2. Han gör/stjäl en video om det han gillar och slänger upp den på YouTube.
3. Gruppen som gillar samma sak som han kollar kanske och sprider kanske vidare varvid gemenskapen i gruppen troligen förbättras.

1an och 3an handlar om gruppen, 2an om individen. Både individen och gruppen behöver ha verktyg för att få innehållsspridningen/gemenskapsbyggandet att fungera.