The art of engagement design (previously known as gamification)

What’s the difference between a boring tool or game, and an engaging one? For something to be engaging, it needs to be easily understandable, and appealing; it needs to provide various different mechanics that appeal to different people, without forcing all of them on anyone. In a word, it needs engagement design, the concious act of designing something to be engaging. Some of you may have heard of this approach by its old name, gamification.

[Read more…]

Ratkaisuni koulujen uudistamiseksi: Edukata

Edukata-fasilitaattorin opaskirja

Edukata-fasilitaattorin opaskirja

Olin johtavana muotoilijana 4-vuotisessa iTEC-hankkeessa, jossa meidän tutkimusryhmämme muotoilemia oppimisaktiviteetteja pilotoitiin yli 2600 oppilasryhmässä pitkin Eurooppaa. Nämä oppimisaktiviteetit toimivat niin hyvin, että meidän piti tuotteistaa design-prosessimme paketiksi, jota opettajat voisivat itsenäisesti käyttää. Tulos: Edukata, opas oppimisaktiviteettien osallistavaan muotoiluun. Väitän, että tässä on erittäin hyvä työkalu koulujen uusiutumisen avuksi. [Read more…]

Web 2.0 ohjelmistotuotannossa

Pidin asiantuntijapuheenvuoron 14.4.2010 Digitaalinen Suomi -seminaarissa Jyväskylässä otsikon mukaisesta aiheesta. Tässä 45 minuutin pituinen slidecast-tallenne puheestani. Käsittelen teemoja sekä web 2.0 -ohjelmien tekemisen näkökulmasta että web 2.0 -palveluiden hyödyntämisestä ohjelmistotuotannossa yleensä. Joitain teknisiäkin asioita mukana on, kuten pilviarkkitehtuuri ja NoSQL-tietokannat. Oli ihan hauska välillä puhua ihan teknisestä aiheesta – sisäistä nörttiä pitää silloin tällöin ruokkia. Niin ja minut voi tilata puhumaan muihinkin tilaisuuksiin. [Read more…]

Visuaalisuus ja nimet oppimisympäristössä

Anne Rongas pohtii visuaalisuutta kirjoituksessaan Väliäkö visuaalisella? ja sanoo mm.

Miksi visuaalinen on niin tärkeää (ainakin minulle)? Se on kuin arkkitehtuuri ja sisustus ja puutarhasuunnitelma ja liikennejärjestelyt. Jos verkossa visuaalisuus ei tue liikkujaa, ympäristö ei avaudu. Harva uskoo, mikä vaiva on luoda mahdollisimman havainnollista verkkoympäristöä. En todellakaan ole taitava tässä. Muut pankoot nyt paremmaksi.

Ympäristön nimeksi tuli Penaali. Visuaaliseen ilmeeseen liittyy erilaista normipenaalista löytyvää: kyniä, terotin, klemmari yms. Penaalilla on myös vertauskuvallinen merkitys, kuten testihenkilö totesi: Sieltä löytyy kaikki apu visaisiinkin pulmiin, kunhan vain muistaa ajatella!!

Lähtökohtahan kaikkien tilojen rakentamiselle on se todellinen tarve. Opetuksessa perimmäinen tarve on oppimistulosten parantaminen. Niitä voi tukea uusilla menetelmillä, pedagogialla ja toimintatavoilla. Toimintatapoja taas voi tukea uusilla välineillä, kuten tällä Annen perustamalla Penaalilla.

Kukin väline tarjoaa affordansseja ja rajoitteita, eli tarjoaa joitain mahdollisuuksia ja toisaalta rajoittaa toimintoja jollain tavalla. Nämä eivät kuitenkaan ole jokaiselle välineen käyttäjälle itsestäänselviä. Ne pitää tuoda esiin.

Nimi on tärkeä elementti, sillä se ohjaa välineen käyttäjien ajattelua (frame of mind). “Penaali” nimenä johtaa palveluun tulijan suhtautumaan siihen eri tavalla kuin vaikkapa “Koulutuskeskus” tai “Kahvihuone” tai “Liitutaulu” tai “Kateederi”.

Palvelun nimen lisäksi myös muut käytetyt termit vaikuttavat toimintaan. Kutsutaanko blogia blogiksi, vai kurssipäiväkirjaksi, vai kurssin kotisivuksi? Onko foorumi foorumi, vai keskustelualue, vai ideointipaikka, vai hengailumesta?

Myös visuaalinen ilme vaikuttaa. Käytetyllä kuvakielellä saadaan katsojassa aikaan tunnetason reaktioita. Onko kuvitus innostavaa, viileän asiallista, omituista, kunnioitusta herättävää vai ahdistavaa? Tyhjän tilan käytöllä, typografiaa vaihtelemalla, värimaailmaa säätämällä ja kuvia valikoimalla voi samasta palvelusta tehdä tyystin erilaisen. Ja tämä erilaisuus tulee myös vaikuttamaan sen käyttötapaan.

Kokeilkaapa joskus vaikka katsoa jännityselokuvaa tai toimintaelokuvaa mutta mykistäkää ääni ja soittakaa ihan mitä tahansa muuta musiikkia tilalla. Musiikki on tietysti oma aistimodaliteettinsa, mutta vastaavalla tavalla visuaalinenkin vaikuttaa kokonaisuuteen.

Itselläni on itse asiassa sama homma kuin Annellakin edessä, kun täytyy rakentaa verkkosivusto tukemaan tammikuussa ilmestyvää Sosiaalinen media opetuksessa -kirjaa. Eli pitää miettiä visuaalista esillepanoa.

Tags: , , visuaalisuus, sometu, design, kuvat, värit

NetPosti on ihan web2.0

Olen käyttänyt Postin (vai Itellan?) netposti-palvelua jo vuosia. Sinne tulee luottokortin lasku kerran kuussa, noin pääasiassa. Ja palvelu on näyttänyt sellaiselta tavalliselta webmailin inboxilta. Okei, laskuja katsoessa voi klikata itsensä suoraan verkkopankkiin, mutta kuitenkin.

Pitkän tauon jälkeen menin taas netpostiin, kun sinne oli taas muutakin kuin suoraveloitettavia laskuja tullut, ja yllätys oli melkoinen, kun havaitsin koko järjestelmän ilmeen muuttuneen varsin värikkääksi. Poissa on se vanha asiallinen virkamiesleiska ja tilalla värikäs, isoilla kuvakkeilla varustettu web2.0-tyylinen näkymä. Raikas ja kiva. Mutta tärkeämpää olivat uudet ominaisuudet.

Vanhan webmail-tyylisen kansioajattelun sijaan netposti on nyt tyylikkäästi tagipohjainen. Jokaisella uudella kirjeellä on tagi “Saapuneet” sekä saapumiskuukauden mukainen tagi, tyyliin “Huhtikuu 2008”. Jos kirje tiedetään laskuksi, on sillä vastaava tagi. Voin itse valita kirjeille lisätageja valmiista listasta ja lisätä listaan omia tageja, jos niin haluan. Ja kirjeet tietysti voivat sitten näkyä useammassa paikassa kun niillä on useampi tagi. Erittäin kätevää, vaan kuinkakohan hyvin muutos menee läpi perinteisemmille asiakkaille? Postilta kyllä tuli parikin kirjettä, joissa annettiin vinkkejä uuden tagijärjestelmän käytöstä (eikä tagi-sanaa käytetty).

Mutta ehkäpä se syy, jonka vuoksi herryin oikein blogiin kirjoittamaan ylistyksen, oli yllättävän pitkälle viety käytettävyys, joka näkyi pienissä asioissa. Esim. kun katson kirjettä, on ylälaidassa oletusarvoisena valittu toiminto “Poista saapuneista”. Ja kun kirje on poistettu saapuneista, on oletustoiminto “Siirrä roskakoriin”.
 Ja roskakorissa taas oletustoiminto on palautus, vaihtoehtonaan tuhoaminen.

Okei, jotain pientä säädettävää on, esim. jos vaihdan kirjeen otsikkoa, pitää painaa ok:ta sille erikseen. Jos erehdyn vaihtamaan otsikon ja tekemään jonkin arkistointitoimenpiteen, otsikon muutos unohtuu. No, täydellistä ei voi saada. Mutta erittäin hyvä suoritus postilta.

Tags: ,

Sähköyhtiön kilpailuttaminen ja web-designin merkitys

Kilpailutimme eilen sähköyhtiömme käyttämällä Energiamarkkinaviraston erinomaista sahkonhinta.fi-palvelua. Palvelu osaa laittaa kaikki sähköyhtiöt hinnan mukaiseen järjestykseen sekä graafisesti näyttää uusiutuvat, fossiilisen sekä ydinenergian osuuden kunkin yhtiön energiantuotannossa. Listan voi (joskin vähän hankalasti) järjestää hinnan sijaan myös ekologisuuden mukaan. Nyt entinen yhtiömme Helsingin Energia kyllä tarjoaa ympäristöpennin (joka meillä olikin), mutta se takaa vain 1000kWh ekologista energiaa lopun tullessa pääasiassa fosiillisten polttoaineiden polttamisesta.

Suomesta löytyy jopa 15 sähkölaitosta, jotka voivat tarjota 100% uusiutuvista luonnonvaroista tuotettua sähköä. Kävimme läpi näistä 8 edullisinta. Neljä putosi kisasta koska heidän uusiutuviin energianlähteisiinsä kuului esim. puuhakkeen poltto. Vaikka puu onkin hiilidioksidipäästöiltään 0 (koska poltossa vapautuu vain sama määrä, minkä puu on ottanut kasvunsa aikana sisäänsä), tulee siitä kuitenkin muita päästöjä ja voisi se puumateriaali toimia esim. lahomateriaalina metsässäkin. Rajoitimme siis tarjonnan vain niihin, jotka tarjoavat tuotantoaikana täysin puhdasta energiaa, siis käytännössä tuuli- ja vesivoimaa – aurinkovoimaa ei näyttänyt olevan tarjolla. Tietysti nämäkin muodot saastuttavat tarvittavien laitteiden valmistusprosessin yhteydessä, mutta ovat kuitenkin siitä puhtaammasta päästä. (Vai ovatko? Kiinnostaisi tietää, saastuttaako high-tech-tuulivoimalan valmistusprosessi enemmän kuin esim. vastaavankokoisen puuhakevoimalan rakentaminen ja sen päästöt 20 vuoden ajalta.)

Lopuista neljästä vaihtoehdosta (jotka energian tuotantomuodon ja hinnan ja muiden ehtojen osalta olivat varsin tasapäisiä) kolme putosi pois huonon web-designin vuoksi – ihme flash-kikkareilla tehdyt tarjouslomakkeet, ihan vaan jotta näyttää kivalta, tai väärin suunnitellut lomakkeet, joissa heti alkuun kysellään yhteystietoja tusinalla kentällä ennen kuin päästään itse asiaan.

Lopulta voittajaksi karsiutui Kuopion Energia, joka tarjosi siististi puhdasta tuulisähköä järkevään hintaan. Web-sivut ovat asialliset ja hyvin suunnitellut, lomaketta on juuri sopivasti ajaxoitu jotta valinnat sujuvat sutjakkaasti ja yleensä käyttökokemus oli varsin kivuton. Hyvän designin tunnistaakin siitä, että tuotteen avulla tehdään se, mitä halutaan tehdä, eikä mietitä miten se pitäisi tehdä.

Thinking about the users

Kathy Sierra is one of the bloggers at Creating Passionate Users, which I already had on my Bloglines subscription, but ran into again in an IT-Conversations podcast, where she had some good insight on thinking about users. Here I’ll summarize those insights and combine them with other ideas I’ve gleaned from other places.

Her main argument was that in order to have users that are passionate about your site, they need to get past the “suck” phase. If you suck at something, then you won’t be passionate about it. OK, I can conceed that having some level of competence on a theme is a, but not the only requirement. So the first step is to analyze why people would want to use your service in the first place – what kind of new skills they will need to gain to use it fully? And why would they do that learning (5 why’s)? An example she uses is a Nikon photography guide site, that made her buy a better camera in order to take better shots.

The road to mastery of a skill is a long one, so most people need intermediate milestones. So it’s a good idea to show the vision of what mastery will give to them, but also make it clear that there are smaller steps to be taken, and each step does also produce some added value to the user. These visions could be communicated via images, or verbally (“wouldn’t it be cool if you could…”).

To get people to learn something voluntarily, you should aim for the flow experience. This means providing a challenge that is interesting enough, but not too hard for their current skills. Boredom and frustration are the alternatives to a flow experience if the situation is not balanced correctly.

For keeping up the motivation that users have initially gained, Kathy Sierra mentions levels in games. Gaining new levels of expertise give you new “superpowers”, that should be visibly demonstrated to the users. This is one very good idea, and more ideas about keeping users addicted to your service are in my previous blog post.

One important factor often neglected (or just done poorly) is user documentation. A technical, logically structured doument may be understandable to the designers of the system, but hardly so for the newbie user. The documentation should use conversational style (because the brain is more interested in conversations than monologues), and provide a story or stories (because the episodic memory of the brain is otherwise unused). Fun stuff should also be included (because fun equals play equals learning opportunity for the brain). And showing pictures of puppies and kittens (or snakes and spiders) also lights up additional areas of the brain. Leaving some things obscure or unclear or mysterious is also a good way to keep users interested.

Finally, featuritis is a good way to kill user enthusiasm and make them feel guilty for not understanding the whole system. Having good documentation, a user community for peer support, and of course, KISS (keep it simple, stupid!) are good ways of avoiding this.

Getting people addicted to your web site

I listened to an IT-Coversations podcast from SuperNova 2006 a few days ago about games and education. The most interesting part of the podcast were the notes by Amy Jo Kim describing how games get their players addicted to them, and how those techniques could be applied to learning environments or any systems. In the social web the largest challenge usually is starting a new community. Adding the “game appeal” of the site may help.

The main appeal-increasing features seen in games and many social software applications as well are:

  1. Collecting stuff: Items in WoW, links in del.icio.us, connections in LinkedId, furniture in Habbo Hotel… Allowing users to collect various things into their virtual environment will appeal to many collector-minded people, and will increase their tendency to continue using the system.
  2. Earning points: The old wisdom is that any visible meter becomes a goal to people, so it is important to carefully design those meters. Earning points can be based on some rules in the system (WoW experience levels), or they can be social in nature (LinkedIn recommendations, Ebay ratings).
  3. Feedback: Feedback on the progress on any meter should be provided multimodally (visual, auditive, tactile?), often, and in interesting ways. This keeps people going with the system.
  4. Social exchanges: The visibility of the community and people is important. It is also important to allow the community members to communicate. Exchanging any kind of communications or tokens (blog comments, eBay ratings, Habbo Hotel presents, WoW chats) is essential for a community to flourish.
  5. Customization: Making the environment look like you want is an important way to add a feeling of ownership to the user. Customization of the user interface is an easy way of doing that. Also customizing your character (WoW avatar, community profile) and tailoring how things work and optimizing the things you see are also important affordances.
  6. Allow for emergence: Do not overdesign the system and force people to work in a certain way. Most communities will surprise the original designers of the system. So make the system open enough to allow emerging behaviour, and be ready to modify your system to better support these emerging patterns.

Corrections to the Joel test of software development quality

I just listened to an interview of Joel Spolsky on It Conversations, and checked out his Joel Test. While Joel has good argumentation for his opinions, I think a different perspective is needed for a few of the steps in his test, especially concerning testing and user involvement.

Here’s my version of the Joel test. It starts with the same 12 steps (although modified more or less), but continues with a few additional steps that I consider important.

  1. Do you use source control?
    This is too obvious to go into detail – even a one man team needs source control. It gives you history traceability, undo, coordination of simultaneous work, and backups. I personally use it even for all of the documents that I write.
  2. Do you have automatic builds? (was: Can you make a build in one step?)
    The one step build that Joel wants is a good start, but I’d rather see an automatic build done every night, and a big fat red warning on the frontpage of the development site whenever something breaks.
  3. Do you make daily builds?
    If you can’t build the software every day, you won’t build it until you need to. That means a convergence period before releasing, which is in fact just fixing technical bugs that could have been fixed when you wrote the code. So build automatically, and daily. And make each developer build and verify his code before he commits to source control.
  4. Do you use a ticket system? (was: Do you have a bug database?)
    Again, an obvious necessity. In addition to bugs, tracking all enhancement and auxiliary tasks should be carried out in the same ticket system, especially if you’re doing distributed and/or dispersed development.
  5. Do you prioritize bugs? (was: Do you fix bugs before writing new code?)
    As Joel says, bugs shouldn’t be left lying around, since they’re getting more expensive to fix as time goes by. But a black-and-white rule of “fix all bugs before doing features” won’t work – most bugs can be tracked to one developer, who should be the one to fix it (since he’s most likely the most efficient on that bug). Others shouldn’t wait, but continue with other tasks. Related to this, if you do frequent releases, then you usually have a one day convergence period, where all the remaining bugs are squashed.
  6. Do you have an up-to-date schedule?
    No disagreement here. Having limits on what is done are needed. They discourage feature creep, for one. So timebox everything – two weeks between releases, for example.
  7. Do you have a plan that you can change? (was: Do you have a spec?)
    Joel wants a spec. I don’t. In the majority of development projects, the customer cannot exactly specify what he wants. Thus instead of a spec, use a format that the customer also understands, like user stories. The collection of accepted user stories is the spec. But it’s a spec that can be changed by the customer, and that is refined as needed. Of course, you need development practices that support a changing spec, like automated unit testing.
  8. Do you provide developers with conductive working conditions? (was: Do programmers have quiet working conditions?)
    Here I completely disagree with Joel. Most of the problems are best solved by more than one mind. The flow that Joel talks about isn’t necessarily an individual experience, but can even more easily be experienced by a pair or team of developers. Therefore: have all developers in a single room, preferrably facing the walls, with an open area in the center, so they can at any time turn around and talk to whomever. Of course, there are those people who will need 15 minutes to get their focus back on what they’re doing after being interrupted, as Joel says, but I wouldn’t want those people on my team.
  9. Do you use appropriate tools? (was: Do you use the best tools money can buy?)
    Not the best money can buy, as Joel says, but appropriate. There is no added value in getting the compile done in 5 seconds instead of a couple of minutes. Having time to relax your mind and getting some distance to the code generally improves the result. Plus it’s critical to have time to reflect on the work you’ve done. Waiting a few minutes for the compilation or the unit test suite to run is a good time for all this. Plus it makes the code that much better, since the developers actually need to think their code through instead of just trying quick fixes and seeing if the compiler likes it or not.
  10. Do you do quality assurance? (was: Do you have testers?)
    Not dedicated testers, as Joel says, but quality assurance. This can come in many forms, including dedicated testers, or by doing automated unit tests by the programmers themselves. Even Joel admits that good testers are hard to find and harder to keep, since testing is not good work. He argues that it’s still cheaper to use testers than have developers do testing, since testers have lower wages. I on the other hand argue that having developers write unit tests is cost-effective. Automated unit tests have several advantages: they make sure that any defect can only be created once (since once found, a test is written for it), they improve the quality of the code (not allowing laziness to cause bugs), and they allow you to respond to a changing spec by changing your architecture as needed. After the initial phase (after you have the first 50-100 tests done) the unit tests actually save developer time, instead of consuming it. Plus you don’t need as many testers as you otherwise would.
  11. Do you only hire competent team members? (was: Do new candidates write code during their interview?)
    Instead of just making the potential new recruits write code, as Joel suggests (which is an excellent idea), it’s also important to let the development team meet the candidates and see how the chemistry works. Since development is a team effort, it’s best to let the team have their say in who should be hired.
  12. Do you do usability testing? (was: Do you do hallway usability testing?)
    Joel’s suggestion of hallway testing is not enough, if the company is filled by developers. What you need are representatives of the focus group. No developer can say if a primary school teacher can understand a certain functionality, and few developers actually know the general usability guidelines that do exist. So using usability experts to iron out general usability issues, followed by a focus group test, where the vocabulary, approach, and priorities of the software can be tuned to the focus group, are necessary.
  13. Do you do user-centric design?
    One reason Joel doesn’t like XP is the need for an on-site customer. In Joel’s opinion customers can’t provide you with good specs – they either say the obvious, or ask for features that they really don’t need. This is where user-centric design comes to play. Instead of asking the customer what he wants, find out what the customer needs. This is not an easy task, and involves a number of practices, one of which is a representative of the customer, who has the authority to make decisions, and the expertise to find out things. This representative is not enough alone, of course. You need to do participatory design, for example.
  14. Do you have a heterogonous team?
    Unlike Joel claims, I don’t believe that a software developer can learn to understand the customer’s field in just a few hours. You need the customer’s expertise in some form. But you also need the expertise on the theoretical backgrounds and advanced technologies that are to be applied in development. It’s not enough to just have developers. You need user interface logic specialists, you need graphic designers, you need usability professionals, and most importantly instead of separate code drones and architects you need people who are excelled programmers, great architects, and that have some expertise in the field being worked on, all wrapped into a single human. Most of the failures in software development are due to miscommunication between the customer and the programmer. Misunderstandings are cut radically when you have more roles packed into a single mind. Not all of your developers need to have problem domain expertise, mind – it’s usually enough to have just one, because he can translate between customer-lingo and programmer-jargon.

In summary: This is just my experience of how people and code work. Joel’s test is an excellent resource for job seekers and managers, but in some aspects I disagreed so much that I had to write this response – Joel test as it is is biased away from some very good new practices that I consider a comptetitive advantage. Comments are welcome. And thanks to Joel for sharing his thoughts with us all.

Distributed design and development using agile methods and Trac (XP2006 presentation)

I’m hosting a session at the XP2006 conference and here’s the material for that session.

Also, the title should probably talk about Dispersed, not distributed, since that’s what we’re doing (not just having teams in separate locations, but having team members in separate locations).