...om Interaktion i Relationer på Nätet

Relationsproblem

noreply@blogger.com (Björn) — Tue, 24 Jun 2008 16:14:00 +0000

Jag har läst Umair Haques olika bloginlägg och essäer senaste halvåret. Han är ganska kompakt i sitt sätt att skriva så det har tagit ett tag att komma till det stadium då jag kan reflektera över kunskapen han delar med sig.

Nyligen har jag iaf reflekterat över en av hans idéer, nämligen att IT-sfären inte löser riktiga problem längre. De problem han diskuterar är svält, vattenbrist, miljöförstöring etc. Problem på den skalan löser inte jag (än), men problem-perspektivet är intressant att applicera även på mina projekt.

För vissa av projekten kan jag inte komma på vilka problem som egentligen löses. Det kan vara en orsak till att de projekten ej lyuckas så bra.

OrkidéPrat löser dock tre problem. Problemen är, som sagt var, inte grandiosa, men att lösa dem förbättrar livet en aning för en del av Sveriges befolkning.

3 problem i OrkidéSverige
1. Sveriges orkidéodlare är ganska få och utspridda över en geografiskt stor yta. Det är därför svårt att hitta, träffa och skapa en relation med andra intresserade.
Lösning: OrkidéPrat är ett geeografiskt och tidsmässigt oberoende forum där orkidéintresserade kan träffas och prata publikt likväl som privat.

2. Svårt att hitta råd om specifika arter och ovanligare släkten.
Lösning: Pratoteket samlar OrkidéPrats kunskap. Om infon man söker inte finns i Pratoteket kan man såklart be medlemmarna om råd. Ett framtida wiki-liknande projekt kommer göra Pratoteket än bättre då wikin kommer innehålla artiklar, snarare än enstaka frågor med svar, om en mängd aspekter av orkidéodlandet.

3. Svårt att hitta ovanliga sorter att köpa i Sverige.
Lösning: Auktioner och KöpOchSälj-möljligheter där medlemmarna kan köpa sorter av varandra. Sambeställningar för att minska kostnaderna som det innebär att importera.

Utifrån de identifierade problem ovan kommer jag fortsätta utveckla OrkidéPrat. Lösningar ska bli kraftfullare, enklare och tydligare.

Värdet av problem
Att se på de specifika problem en tjänst skall lösa känns nu, tack vare Haque, som en självklarhet. Det är dock ett problem att vissa projekt jag just nu arbetar på inte löser tydliga problem...

Ibland behöver världen anpassas till individen

noreply@blogger.com (Björn) — Wed, 04 Jun 2008 09:39:00 +0000

Vi lever inte alla i samma värld. Med det som utgångspunkt kan fantastiska möjligheter skapas för specifika personer och grupper. Ett exempel är ZacBrowser vilken fundamentalt ökar interaktionsmöjligheterna för unga personer med autism.

Artikel på boston.com.

Interaktion

noreply@blogger.com (Björn) — Sat, 26 May 2007 17:33:00 +0000

Vad är det som utgör de där relationerna?

Vad jag är intresserad av, och vill arbeta med, syns ovan. Jag kallar det TPI, PPI och MPI. Och PPI är kung.

PPI = person-person-interaktion.
Det är PPI som är hela anledningen. Kanske kan jag till och med säga att PPI är meningen med livet. Dalai Lama säger att Lycka är meningen med livet. PPI kan medverka till lycka.

Jag vill möjliggöra person-person-interaktion genom att:
- bygga person- och interaktion-centrerade tjänster
- aktivt initiera interaktion genom att exempelvis delta i gemenskapen
- aktivt underhålla gemenskapen genom att exempelvis moderera och ge support samt lägga till nya utvecklande tjänster
- aktivt hjälpa gemenskapen definiera sig själv och sina interaktionspreferenser genom att exempelvis föreslå regler och interaktionsformer samt diskutera hur konflikter kan undvikas och hanteras
- avsluta gemenskapen på gott sätt när så behövs genom att exempelvis möjliggöra export av eget prat samt hänvisa till alternativa forum för fortsatt gemenskap

PTI = person-tjänst-interaktion
Var person behöver interagera med tjänsten för att kunna kommunicera och skapa gemenskap. Interaktionen behöver vara ... god.

Jag vill möjliggöra god person-tjänst-interaktion genom:
- tjänstedesign (definition av delar i tjänsten)
- interaktionsdesign (prototyper, tester, implementationsdefinitioner)
- informationsarkitektur (innehållskategorisering, navigation, sök och findability)

MPI = möjliggörare-person-interaktion
De som bygger tjänsten behöver bygga sitt arbete runt kommunikation med de kommande användarna.

Jag vill möjliggöra produktiv kommunikation genom:
- användartester (som del av Interaktionsdeign ovan)
- support (struktur kring support-arbetet)
- moderering

Sammanfattningsvis vill jag hjälpa personer hitta varandra under goda förhållanden. Jag vill möjliggöra goda virtuella samhällen.

Jag är inte statistik!

noreply@blogger.com (Björn) — Tue, 10 Apr 2007 15:12:00 +0000

Relationer går inte att beskriva med statistik.

Det slog mig alldeles nyss att statistik är meningslöst som designgrund. Jag utvecklade en del besöksstatistik utifrån en mycket detaljerad databas med besöksstatistik. Man kan skapa hur många tabeller och grafer som helst utifrån datan. Jag började dock ställa frågan:

"Men, vad kan vi förändra utifrån den här grafen?"

Svaret var oftast:

"Ingenting"

Problemet är att den typ av data vi har, vanlig besöksstatistik, inte säger något om vad som kan förändras för att förbättra saker. Exempelvis kan vi veta att X% av de som ser sida A går vidare till sida B. Jaha. Det säger vanligen inget. Vi har ett flöde där det kan tänkas vara vettig statistik: Hur många av de som tittat på villkoren väljer att bli medlemmar. Utifrån den procenten kan vi experimentera med villkorstexten och dess layout. Vilka specifika problem villkoren har vet vi dock inget om...

En "lösning på problemet" är multivariat testning. Det har vi dock inte gjort, men kanske kommer göra, vem vet.

Det uppenbara är dock att avstå från att formge för statistiken och istället designa för individer.

Genom att göra användartester och använda personas kan vi ha en mer solid grund att designa utifrån.

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

noreply@blogger.com (Björn) — Mon, 26 Mar 2007 09:45:00 +0000

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:

status-uppdateringar ("Hur e läget?" "Fint.")
pladder och info ("Vad gjorde ni på gympan idag då?" "Samma gamla vanliga, hinderbana.")
försäkranden ("Du klarar det!")
fel-meddelanden ("Nej, ha inte i timjan i pajen.")
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?")
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?

status-uppdateringar "Du är på steg 2 av 5"
info och instruktioner: "Fyll i fälten och klicka på 'skicka'"
försäkranden: "Det går snabbt och är gratis att bli medlem"
fel-meddelanden: "du glömde fylla i din e-postadress"
diskussioner och inspiration: utförliga artiklar om intressanta ämnen och trevliga diskussioner mellan personer
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

noreply@blogger.com (Björn) — Wed, 07 Mar 2007 12:05:00 +0000

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...

noreply@blogger.com (Björn) — Thu, 01 Mar 2007 18:40:00 +0000

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

It's the social, stupid!

noreply@blogger.com (Björn) — Thu, 01 Mar 2007 07:38:00 +0000

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:

En person gillar nåt.
Han gör/stjäl en video om det han gillar och slänger upp den på YouTube.
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.

Vilka älskar jag?

noreply@blogger.com (Björn) — Wed, 28 Feb 2007 21:16:00 +0000

Grupper bygger på relationer. Om relationerna är positiva är gruppen stark. Ännu starkare är kanske den, eller det, som är gruppens infrastuktur.

Gruppen: Jag, min moster, tre av mina orkidépolare och söstra mi.
Ämnet/Syftet: Kakbakning.
Möjliggöraren: En tjänst i form av en gemenskapwebbplats med (kak-)bakning som tema.

Gruppen + Ämnet + Möjliggöraren = ett möjligt Personligt virtuellt nätverk.

Ett personligt virtuellt nätverk är helt enkelt människor som delar ett intresse och gemensamt agerar på det intresset online. Aktionen är oftast att man pratar med varandra och delar media såsom bilder (och kakrecept). Ibland tar gemenskapen en tur ut i verkligheten -- man träffas helt enkelt och umgås.

Namn
Jag tror att det är vanligt att nätverken, för var person eller gemensamt, har en benämning. det kan vara 'Orkidétokarna' eller 'Fikapolarna i Gospelkören'. Jag har sett diskussioner om personer som betecknar sina vänner som 'grodMagnus' och 'orkidéHanna'.

Omfattning
Termen 'privat nätverk' tar utgångspunkt i en individ som är medlem i nätverket. Det är troligt att hans personliga nätverk har andra medlemmar än valfri annan medlem i hans nätverk. Hur det går ihop? Nätverkens sammansättning är subjektiva! PersonA har PersonB och PersonC i sitt 'Cumbidium-älskare-nätverk'. PersonC kanske har PersonB och PersonD i "samma" nätverk. Så småningom kan det hända att PersonA träffar och inflikar PersonD i sitt nätverk. Eller kanske inte...

Antal nätverk
Jag tror inte att var person är med i fler än kanske 3 eller 5 personliga nätverk (virtuella eller ej) samtidigt. Det kan vara 1 eller 2 kompisgrupper (från gymnasiet exempelvis). Släktingar är kanske 1 grupp. Sedan kanske 1 eller 2 grupper per intresse man har. Det finns ju ett visst behov av underhåll för att hålla nätverken levande...

Utveckling
Medlemmarna i nätverket kan vara mer eller mindre nära bundis. Över tiden kommer också medlemmarna i nätverket förändras -- dels att var medlem utvecklas inom ämnet/syftet och att medlemmar byts ut. Båda sakerna leder till att nätverket utvecklas. Till slut försvinner troligen många nätverk.

Möjliggörarens möjlighet
En cool grej är att möjliggöraren inte är speciellt viktig när man beskriver gemenskapen. Gemenskapen är ju relationerna mellan personerna. Men samtidigt skapades och underhålls gemenskapen genom den möjliggörande tjänsten. Beroende perspektivet kan man allts[ anse att tjänsten är, eller inte är en del av nätverket.

Jag tror att så länge tjänsten ej förändras i för breda svep så kommer nätverket vara tjänsten trogen. Tjänsten var ju trots allt del av nätverkets födelse. Den troheten är såklart bra för tjänsten.

Vilka egenskaper har då en tjänst som är en möjliggörare?
Först ett exempel som jag tycker inte är en bra möjliggörare. QXs Qruiser har 'Grupper'. En 'grupp' skapas av en person som ger 'gruppen' ett namn. 'Gruppen' har ett diskussionsforum. Qruiser-medlemmar kan sedan bli medlemmar i 'gruppen'. Visst låter det som ett bra scenario för att skapa gemenskap och personliga nätverk?
Problemet är att så ej är fallet.

Qruiser har 25 000 grupper. Den siffran talar för sig själv -- det kan inte vara så många personliga nätverk bland Qruisers 100 000 medlemmar.
Jag har fått känslan av att få grupper har några riktiga diskussioner. Nu är visserligen Qruiser en crusing-site, menmen...
Medlemmar skriver i sina profiler "se vilka intressen jag har genom att kolla på vilka grupper jag är medlem i".

Qruisers 'grupper' är alltså, enligt min mening, ett sätt att visa vilka intressen man har. 'Grupperna' handlar inte om gemenskap och nätverksbyggande.

Vilka fel gör då QX? Jag tror att grundtänkandet (eller genomförandet) är fel. 'Grupperna' utgår från att en person skapar en grupp och äger densamma (skaparen är moderator). Men så funkar inte personliga nätverk.

Ett personliga nätverk är en dynamiskt skapad grupp individer -- en grupp som, enade av ett ämne och i en tjänst, har funnit varandra. Nätverket kommer alltså efter ganska stora mängder interaktion. Det är den avslappnade (casual) vanligen publika konversationen som ger gnistan till nätverket.

När gnistan tänts behöver den möjligheter att flamma upp till en gemenskap. Det är här verktyg såsom de QX tillhandahåller är värdefulla. Om en 'QX-grupp' skapas efter det att nätverket flammat upp så kan 'gruppen' stödja nätverket.
Apaches 2-stegsprocess för projekt är också ett exempel. Ett projekt kan bli ett 'Incubator project' hos Apache. Om projektet visar sig ha nog med utvecklare och ett gott syfte (med andra ord: om nätverket har skapats) får projektet status som officiellt Apache-projekt.
I OrkidéPrat har jag inte några formella sätt att stödja personliga nätverk. Medlemmarna har dock själva kommit på att de kan göra andra medlemmar till 'FavoritMedlemmar' och sedan skapa Privata inlägg. I dessa privata inlägg kan sedan favoritnätverket diskutera, ostörda. (Om en medlem skapar ett privat inlägg kan bara medlemmens favoriter se och svara på inlägget.) Dessa privata diskussioner har fördjupat flera personliga nätverk. 'FavoritMedlemmar'-funktionen i OrkidéPrat är också ett exempel på att de personliga nätverken är subjektiva. Var medlem har sin egen lista med FavoritMedlemmar. Den listan kan representera ett personligt nätverk.

Det handlar om relationer.

Varför älskar du oss inte längre?

noreply@blogger.com (Björn) — Wed, 28 Feb 2007 20:06:00 +0000

Ibland kommer man till ett stadium i en relation där en av parterna inte uppmärksammar den andra så mycket längre...

Om man verkligen menar det så kan man skicka denna typ av meddelanden till de medlemmar/kunder som inte längre besöker en:

Hej Tommy!
Vi på TjänstX har sett att du inte varit inloggad hos oss på ett par veckor. Vi är nyfikna på varför.

Om du helt enkelt glömt bort oss så klicka på länken och logga in:
Till TjänstX

Om det finns en eller flera andra anledningar till att du inte hälsat på oss på ett tag så svara gärna på detta brev och berätta. Vi uppskattar dina åsikter och ingen anledning är för trivial.

Vi ser fram emot ditt svar eller att se dig på tjänstx.com igen.

Vänliga hälsningar,
Björn på TjänstX

Dock: Om man inte menar det som står så får man inte skicka sådana här brev. Och breven får aldrig innehålla reklam. Brevet är en del av en relation.

Inspirationen kommer såklart från Disambiguity.