...about relations and interactions

Web development in 4 simple steps (kinda')

noreply@blogger.com (Björn) — Thu, 03 Dec 2009 12:51:00 +0000

All web sites have a purpose and goals. Based on those, an Interaction design (IxD) can be created to specify how the site should work. Graphical design build on the IxD to define how the site feel and look. Implementation then actually make it work.

My IxD method, as outlined elsewhere, is based on the problems and issues that the site owner and visitors encounter. Together with pattern languages and user testing, a prototype (often on paper) is created.

In graphical design, color and shape are used to further the goals of the IxD. Relative importance of elements, relationships between elements etc are communicated via graphics. The grahpical designer is also in charge of creating a visual identity for the site. That the identity is suitable and polished is important–studies have shown that the visual design of sites greatly impact visitor's confidence. While designing, IxD issues will likely come to the surface and will need to be addressed. Delivery is often in the form of user tested digital prototypes.

Implementation is of cause the stage where the site is built, both on the front- and back end. During the build phase several IxD and visual issues will surely be discovered and will need to be addressed. Since the IxD has been done thoroughly the issues will likely be small and easy to overcome. After user testing the site is ready to go like and the circle starts again.

Am I reeeally needed, and if so, how much?

noreply@blogger.com (Björn) — Wed, 02 Dec 2009 15:01:00 +0000

Which design tasks need Interaction Design knowledge to be properly solved?

If the task has been solved successfully before by the project group, they should solve it again. I.E. already done == do it again.
If the number of possible interaction related misfits in the task is small, or the possible misfits are almost irrelevant, the project group can probably handle them themselves. I.E. simple problem == simple solution.
If the task at hand has interactive elements that are difficult to get a grasp of (I.E. has a large number of possible misfits) and thus the solution is not obvious, specific knowledge of Interaction Design has great value. I.E. complex problem == IxD useful.
If previous attempts at solving the problem has failed, IxD might help. I.E. repeat failures == IxD to the rescue.

Once the need for IxD has been established, the question turns to: how much resources will be needed? The answer, of cause, depends on project scope (I.E. the number of possible misfits to take into account) but it also depends on how well the design should fit – sometimes even a large project can manage with a rather skimpy design.

Possible steps in my work include 1. interviews with the client, 2. interviews with their customers, 3. discussions with the project group, 4. own contemplation, 5. analysis and hierarchy-creation, 6. pattern reuse, 7. pattern creation and 8. pattern synthesis (to create the final form for task). Steps 1, 2 & 3 can be skipped, steps 4 & 5 can be rushed, step 6 cam be maximized at the cost of step 7. But some contemplation, analysis, pattern creation has to be done and pattern reuse and the synthesis has to be allowed to take it's time.

Prototypes of Design Patterns

noreply@blogger.com (Björn) — Thu, 19 Nov 2009 08:56:00 +0000

I am reading Todd Zaki Warfels excellent book about prototyping and realized early on that I need to use prototypes as a compliment to functional diagrams for documenting design patterns in the misfits method.

When the method has produced a tree of misfit groups, the task is to find design patterns that neutralize the misfits, I.E. that solve the design issues. Starting from the lowest level (the single misfit) I create (or reuse) patterns. Once the low level patterns are found, they are combined to form higher level solutions, eventually creating a solution to the full design problem. A visualization (only one level of misfit groups and thus also only one level of solutions are display, but there is often several such):

In interactive applications, the full solution should often be a prototype. My new realization is that some low level design patterns also benefit from being prototyped.

In Alexander's book, functional diagrams play the role of communicating the contents of the design pattern. The following is an example of a beautiful functional diagram:

This diagram depicts an abstracted summary of data about traffic flow in an intersection. The arrows indicate direction of the driving vehicles, the width of the line indicate the amount of traffic flowing in each direction. Therefore the diagram indicates which form the new intersection should take, I.E. the diagram can function as a guide when designing the intersection.

Abstract diagrams can often be used in software design, but I feel that prototypes can add communicative abilities to a pattern. Prototypes are made to be played with – experienced – whereas diagrams are static. I imagine using prototypes for patterns that are highly interactive and thus difficult to create diagrams for.

Below I have embedded a demo of a full design solution prototype. Could not find videos of prototypes for smaller design problems, but it is easy to imagine the below solution being made up of a multitude of patterns that could benefit from a prototype...

10/GUI from C. Miller on Vimeo.

The misfits method might create innovative patterns, but that's not important

noreply@blogger.com (Björn) — Wed, 14 Oct 2009 20:14:00 +0000

Language divides reality and can never present the whole, real X (with X being any man made or natural object or system). Language also categorize and, together with culture, formalize the categories, thus making it difficult to discovery new ways of categorizing the world.

A design problem, as stated previously, is the gap that exists between a object/system and it's context. The gap exists because a number of problems, misfits, exist. Eliminating the misfits will close the gap and thus produce an artefact that fits it's context.

Design problems, when presented to me, are in some more or less significant way not already solved. If a good solution to a problem existed, I would not be needed. This means that my solution needs to be innovative and thus the formalized categories created by language will be a hindrance. I need a method that actively opposes categorization.

In my method, as described in an other blog post and heavily influenced by C. Alexander, I work hard to avoid labeling the groups of misfits during the analysis phase. The problem, of cause, is that any label I apply will be the name of a preexisting category and, since the category name is an abstract simplification of the object/system it represents, associating the name with my group of misfits will, almost unconsciously, limit my imagination both when reevaluating and reorganizing the groups and when finding patterns that solve each group's misfits.

So, once the tree of misfit groups has been laid out, the pattern work begin. Each group, starting at the level with the smallest groups, is matched with one or more patterns that solve the misfits in the group. The patterns are often illustrated with a functional diagram and might also be accompanied by a label and a description, but the most important part is to clearly show which misfits the diagram solve. This means that the pattern and the misfits are the key deliverables from the process, rather then labels/categories.

When working with the method my goal is to find suitable patterns that, when combined, solve the misfits between a design problem and it's context. The patterns can be new or previously described (for example the book Designing Web Interfaces contain fantastic IxD patterns). A newfound pattern, I.E. an original solution to a group of misfits, can be said to be an invention. However, whether the pattern is new or "old" does not matter as long as the pattern is a good fit. I.E. on the pattern level there is no value in innovation itself, any inventions that happen to be created are a mere byproduct.

When the groups on the lowest level each have one or more patterns associated with them, the patterns are combined, from the bottom up, to create the complete solution to the design problem. Since I strive to avoid formalized, preexisting categories in my analysis, the solution will most likely both fit the context of use and be innovative.

Misfits are my new best friends

noreply@blogger.com (Björn) — Thu, 24 Sep 2009 12:53:00 +0000

Current Process Overview
In my post "Thoughts on IxD process" I outlined the following as a good base for creating interaction design deliverables:

Understand the client — products, goals, market as well as the problem they want solved
Understand the client's customers and users
Clearly articulate the client's central process(-es) from a user perspective
Create concepts
Prototype and create reusable deliverables – material and immaterial – together with the client

The wonderful world of design patterns
I have recently finished C. Alexander's seminal book "Thoughts on the synthesis of form" in which he outlines the base of what was to later become "design patterns". (I also have Alexander's book "A Pattern Language" but have not started it yet.)

A quick note: Alexander speaks of the design of a new tea kettle as being a "design problem". I will use "design task" from time to time to refer to the assignment itself.

In the book Alexander highlights that creating a form based on a design task is actually the same thing as and understanding the context of the design task. Only when we start to understand the context can we create a form that fit the context. Also, when designing we gain new knowledge of the context – questions that arise during the design work will need to be answered and thus make us understand the problem's context better.

Alexander discuss misfits as being more appropriate to use in the design process then requirements. Misfits between a form and it's context are often easy to spot, easy to articulate and often even part of the initial design task: "Our web site does not sell enough gadgets", i.e. there is a misfit between the form (the site) and it's context (what customers want and act).

The start of the process for Alexander is to find all possible misfits that can occur between the form and it's context (including the ones already solved by existing products). Misfits should be analyzed to see if they actually are a unit of several smaller misfits. For example "Can not find items in the shop" can be divided into "Items lack meta data", "Search facility is missing", "Navigation items are not labeled according to the user's mental picture of the domain" etc, many of them then subdivided themselves. The misfits that are found often interact. In a sales site the possible misfits A: "Check out takes a long time" and B: "We can not ship without knowing the address of the customer" interact in a negative way – making one better can negatively influence the other. However, other misfits, such as C: "Available color options for items are not displayed" does not interact with A and B.

The misfits can be divided into groups based on which ones interact. The groups can be paced in a hierarchy – a tree – with the full design task ("Our web site does not sell enough gadgets") on the top and branching from that are the different groups of misfits all the way down to the misfits that can not be divided further. Only actual problems that can occur are included in the tree – if intuition tells us that a problem would not really occur, then it shouldn't be in the tree.

Starting from the bottom of the tree one then create a design pattern that, as far as possible, neutralize all the misfits in a specific group. The pattern can often be illustrated as a functional diagram – an illustration that includes both basic form and interaction. The lowest patterns are combined to create the upwards patterns all the way up to the full design diagram which solve the full design problem.

By modularizing design like this:

the interaction between the created form and it's context is made clear during the process
thus, it becomes easy to share ones reasons for design decisions (since there really are reasons for the decisions — not so common in web design)
each design task becomes small enough to be grasped fully by the designer
future upgrades to the form becomes easy as new problems can be introduced and only the patterns that interact with that problem should be changed
creating a better version of a design pattern does not influence other parts of the system
created design patterns can be reused if the same (or a very similar) combination of problems occur in an other project

Synthesis
When incorporating C. Alexander's wonderful work into my process, the following new process appear:

Understand the misfits that can occur in the design task. Tactics: discuss with client about their market, position, products etc, discuss with the client's customers about which misfits they find between their needs and the client's and the client's competitors products, have the designer and the development team think about possible misfits. (Step 1 & 2 in my previous process.)
Subdivide the misfits, find their relations and create the hierarchy. (Step 3 in my previous process.)
Create or reuse design patterns / diagrams that solve all misfits in each group, to create the final solution to the design task. (Step 4 & 5 in my previous process.)

Well designed sites

noreply@blogger.com (Björn) — Tue, 08 Sep 2009 10:58:00 +0000

I was recently asked, by a recruiter, to name a few sites that I think are well designed. This is my answer:

To me there are lots of ways of defining design. Purpose, Content, Interaction and Decoration are a few of many design aspects.

http://www.etsy.com/ — Etsy has accepted the noble quest of creating a global market place for handicraft. They thereby work to increase the interest in unique, handmade products (which is usually good for the environment) and also work to make it possible for more people to live off their creative enterprise (which is good for the individual and society). They have created a number of ways to explore the thousands of products on the site and they engage sellers to take ownership of their shop within Etsy. The site's decorative elements are also well crafted—they set the focus on the products. Over $20 million has so far been invested in Etsy by Union Square Ventures, Accel Partners and others.

http://wave.google.com/ — I have one of the preview screen shot from Wave pinned to my wall at the office. I have not been able to use the service myself yet, but from what I have seen the wave team seem to be working hard with all the details that create good interaction. Both large aspects such as real time updates in conversations and personalization of the interface and details such as panel scrolling seem meticulously crafted.

http://www.gourmet.com/ & http://www.wired.com/ — Both of these Condé Nast sites are beautiful, useful and valuable but above all else they manage to engage my interest thanks to the use of different types of articles and (restrained) variation in layout and presentation.

http://www.drudgereport.com/ — Perhaps the worlds most poorly styled web site. But the fact that the Drudge Report has two to three million unique visitors per month and over a million dollars of profit per year despite having only two employees make the site excellently designed.

All points in a flow where not created equal

noreply@blogger.com (Björn) — Tue, 18 Aug 2009 08:34:00 +0000

Jesse James Garrett's Visual Vocabulary is an excellent resource for creating flow charts. There are of cause also other diagramming conventions such as UML and Entity Relation diagrams, but I often use JJG's for my flow charts.

One thing that many vocabularies lack is a way to specify that some parts of a flow are more important then other parts. We need to focus our design efforts on the parts that add most value and we therefore need to be able to communicate the relative importance of different flows and even of different points in each flow.

The need to represent different importance in flows became apparent to me after a recent discussion with a client. The client is creating a system where customers of physical retail stores can go online to get access to services that enhance the shopping experience. I.E. they are enhancing physical retail by creating valuable online services.

The client of cause have a lot of flows that need to be outlined — for example finding and choosing which services to use, setting up services and daily use flows — but one of the most important ones is the flow that starts in the store with the customer getting info about the service. That flow, the discovery and sign up flow, will be the single most important one for the customer's first year.

When I lay out the different flows I do of cause only add as much detail as is necessary to the charts, which is something JJG clearly states as a necessity in his vocabulary description. So, already in the vocabulary there is a provision about only including what is important. However, the flows also need to be complete — that point A of a flow is less important then point B might not mean that point A does not need to be included in the graph.

My solution to the issue is to use color to depict differences in importance. Color after all has an innate ability to communicate importance — orange is generally more visible then light blue. In order to capture the power of color without over loading the graph, i often use hues. darker hues mean higher importance. Which color I use depends on my mood as well as the client's graphical identity.

Some examples:
The flow on the right is a standard Visual Vocabulary flow, on the left I have indicated that point B is the most important one in the flow, with C being slightly less important and A & D least important.

Here I have indicated that the choice of B or C is the most important part, with B being the preferred choice (preferred by a combination of the customer and my client). The graph could for example represent the decision of whether to pay by Credit Card or via PayPal, with Credit Card being the preferred choice.

The careful addition of color to flow charts to depict importance can enhance the communicative ability of the chart.

Thoughts on IxD process

noreply@blogger.com (Björn) — Fri, 07 Aug 2009 12:55:00 +0000

The Goal
In a video that introduce the acquisition of Zappos by Amazon, Jeff Bezos outlines his view of what is important. First on his three point list is "Obsess over customers" and thereafter "Invent on behalf of your customners" and "Think long term".

In "You Can't Innovate Like Apple" Alain Breillatt discusses the focus Apple puts on knowing their market and having leaders who obsess over all fasetts of design.

Epic
In the excellent HFI white paper "The Evolving Institutionalization of Usability: User Experience as Strategy" Eric Schaffer outline a process for making usability equally important to a companys operations as HR, manufacturing and similar business areas. The process involves having a CXO (Chief eXperience Officer) who is in charge of creating, implementing and maintaining a user experience strategy for the company in question. The strategy outlines such things as staffing, training and knowledge sharing. The process is truly epic.

Lean
Most of my clients come to me asking for usability work leadership. However, they are not of the size needed for Schaffer's process to be practical. I need a process that:

Is small and efficient (resources are never abundant)
Is modular (some pieces may already have been done by he client, others may not be prioritized at the moment)
Can solve a large range of problems (since all my clients have different kinds of problems)
Will create reusable design artifacts (so the client can do some future work themselves)

Adaptive Path are my experience / interaction design idols. The guys and gals there create wonderful experiences for a wide range of clients. Their solutions always seem simple, but are of cause very "designed". Also their process, as examplified in a recent article about a bike shop design, is deceivingly simple. However, to me it is close to perfection:

Understand the client — products, goals, market as well as the problem they want solved
Understand the client's customers and users
Clearly articulate the client's central process(-es) from a user perspective
Create concepts
Prototype and create reusable deliverables — material and immaterial — together with the client
Don't be afraid to iterate within, and jump between, stages of the process (for example by testing prototypes on customers)

Variations
The process outlined above is the one I currently base my work on. Each project has it's own characteristics and goals, but with these five activities I can help my clients obsess over customers and create products and services that both delight and help customers reach their goals.

My job is to influence behaviour

noreply@blogger.com (Björn) — Fri, 03 Jul 2009 14:08:00 +0000

To me, Interaction design is all about influencing behavior.

- Each user's behavior leads to (or from) fulfillment of their own goals as well as fulfillment of those of the service's owner.
- The service's behavior (feedback, flows, categorizations etc) influence how efficient and usable the user feel that the service is. People often experience that systems have a"personality" and it is, to large parts, built by the system's behavior in combination with it's graphical design.
- Behavior by the owner of the service, often represented by employees, affect how users experience the service. Personnel in editorial, support, sales, and other customer facing roles therefore need to be encouraged to reflect over how their behavior influence users. The behavior of executives also influence the service.

To enable users and service owners to reach their goals I, the Interaction Designer, need to influence behavior on all three levels: The user's behavior, the system's behavior and the owner's behavior.

The Interaktion Equation

noreply@blogger.com (Björn) — Sun, 12 Oct 2008 00:33:00 +0000

+Value = Entity X + Entity Y

(+ = interaction) (value = relationship) (= [equals to] needs to be)

Interaction is all about entities and the relationship they have in common. The entities may be two people or one person and a machine (or two machine, but currently I am not all that interested in the agent phenomenon).

The small formula above has a plus on the left side. That is of cause redundant, but it is there to signify the importance that positivity has in interactions.

When two entities interact, there can be a number of outcomes, value wise. If entity x bring along +1.0 value and entity y contribute -2.0, then the relationship that they have will be negative. However, it both entities contribute 1.0 or more, the interaction will be positive. Simple, huh? :)

But, really, what does this mean?

In reality, we all all, always, part of interactions. Me and my boyfriend, me and my boss, me and you, we are interacting. In each interaction I (and the other entity in the interaction) can choose to contribute or take. (I.E. add or substract.)

Contribution (and subtraction) can take a lot of forms. Tone of voice, ratio of questions to answers, accuracy of interpretation etc are all forms of contributions/subtractions.

The big, glaring secret is that interactions need to be positive. The equation need to add up. If one entity take more then the other give, or if both entities are set on taking, well, then you will create no interaction. There will be no value.

And creating value is what interacting is all about.

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.