Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

80/20 s.14

Luettu 80/20 säännöstä. 20% voi vaihdella 10-30% välillä.

Tarkoittaa periaatteessa sitä että suurin osa elämässä tapahtuvista jutuista/designistä menee tolla säännöllä.

Eli:
80 % tuotteen käytöstä tehdään 20% ominaisuuksista
80% liikenteestä tapahtuu 20% teistä
80% edistymisestä tapahtuu 20% panoksesta(smile)

Kiinnitä huomiota eniten käytettyihin ominaisuuksiin!!!! Lisää tuotteen helppokäyttöisyyttä!!!

En nyt ehkä ihan kaikkeen lähtis tätä soveltaa, mut alin rivi pitää muistaa.

Pari pointtia vielä:

Rajoittuu järjestelmiin, joita suuri määrä ihmisiä käyttää. Suuntaa antava
sääntö, jonka mukaan 80% toiminnallisuuksista muodostuu 20% muuttujia.
Tavoitteena olisi tunnistaa tuo 20%, keskittyä sen kehittämiseen ja arvioda
tämän ulkopuolella olevien ominaisuuksien tuoma lisäarvo.

Verkkopeleissä voisi tuo pitää paikkaansa ainakin mutu-tuntumalla.
Suurin osa pelaajista tuntuu keskittyvän hyvin pieneen osa-alueseen koko sisällöstä.
Muu kenties jää "tosifanien" ja vaihtelua etsivien temmellyskentäksi.
Tähän esimerkkiin voisi ehkä soveltaa myös performance vs. preference-sivun pointtia.

MAYA s.162

...

Most advanced yet accebtable

...

Ihan ok artikkeli, poimittu satunnaisesti kirjasta. Ei kyllä sytytelly mitenkään erikoisesti!

esteettisyys
käytettävyys
toiminallisuus
Huomioi palvelua suunniteltaessa tai presentoidessa.

Performance vs. preference s.180

Tehokkaampi tai helppokäyttöisempi tuote ei välttämättä menesty,
koska se ei ole yleisten mieltymysten mukainen (sisältää myös tuotteen ulkoasun).
Esimerkiksi on jo opittu toimimaan tietyllä tavalla, eikä haluta investoida aikaa uuden,
ehkä tehokkaamman tavan oppimiseen.

Minulle on haastavaa pakottaa itseni suunnittelemaan asioita etukäteen.
Suunnitelmallisuudella esim. ohjelmoinnissa kykenisin nopeammin ratkaisemaan ongelman,
kirjoittaamaan tehokkaampaa koodia ja pääsisin pienemmällä turhautumisella.
Suunnittelu tuntuu kuitenkin turhan työläältä prosessilta, vaikka ymmärränkin sen merkityksen.

Flexibility-usability tradeoff - sivu 102

  • Kun järjestelmän monipuolisuus kasvaa, sen käytettävyys laskee.
  • Esimerkkinä yhteen perusasiaan keskittyvä Pinterest vs Google+, jossa on iso kasa vaikka mitä, tai kaukosäätimet joissa eri määrä nappeja
    • Sata nappia kaukosäätimessä tuo monipuolisuutta, mutta samalla laskee sen käytettävyyttä, koska selkeys vähenee

s.124 Hierarchy of Needs

  • Jos haluaa suunnitella jotain menestyksekästä pitää täyttää ihmisten perustarpeet ennen kun voi täyttää korkeammat tarpeet.
  • Functionality needs -- toiminnallisuus**  esim. videonauhuri vaatii tilaa nauhoittaa ja mahdollistaa uudelleenkatselun (Alin taso)
  • Reliability needs – vakaus**  videonauhurin pitäisi toimia jatkuvasti ja näyttää nauhoitteet suht hyvälaatuisesti (Toisiksi alin taso)
  • Usability needs – käytettävyys ** taltioinnin ajastaminen pitäisi olla helppoa ja tapahtua ilman suurempia ongelmia (Keskimmäinen taso)
  • Proficiency needs – pätevyys** videonauhuri, joka etsii tallenteita ja osaa tallentaa ohjelmia keywordien avulla on edistyksellistä (Toiseksi ylin taso)
  • Creativity – luovuus** tällä tasolla kaikki tarpeet on täytetty ja ihmiset alkavat kommunikoida “tuotteen” kanssa innovatiivisesti. Tältä tasolta syntyvät yleensä ns. kulttituotteet. (Ylin taso)

s.52. Comparison.

Näytetään vertailtavat asiat samalla tavalla Ihmiset ymmärtävät maailmaan asioiden välisillä suhteilla. Jos halutaan vertailla jotain asiat pitäisi esittää samoissa yksiköissä ja samalla tavalla.

Redundancy

  • Riittävää määrää useamman elementin käyttäminen siltä varalta, että yksi tai useampi elementti järjestelmässä pettää.
  • Diverse redundancy: esimerkiksi tekstin, videon, kuvan ja äänen käyttäminen saman informaation välittämiseksi.** Minkään yhden asian kaatuminen ei sulje järjestelmää, mutta ylläpito hankalaa
  • Homogenous redundancy: monta samankaltaista tai samanlaista elementtiä muodostaa kokonaisuuden / järjestelmän.** Helppo ottaa käyttöön, mutta on altis jonkin tietyn ongelman aiheuttamille ongelmille, jotka voivat vaikuttaa kaikkiin elementteihin yhtäaikaisesti*** Esimerkkinä erillisistä säikeistä koostuva köysi, joka kuitenkin voi katketa yhden terävän reunan vuoksi
  • Active redundancy: ylimääräisten elementtien hyödyntäminen kaiken aikaa** Esimerkiksi monta pilaria, jotka tukevat rakennuksen kattoa*** Yhden pilarin (elementin) katkeaminen ei johda katon sortumiseen, ja kaikenlaisiin muutos- ja kunnostustöihin on mahdollista ryhtyä ilman että rakennusta (järjestelmää) tarvitsee sulkea pois käytöstä
  • Passive redundancy: ylimääräisten elementtien käyttöä vain silloin, kun jokin aktiivinen elementti pettää.** Esimerkiksi auton vararenkaan käyttöönotto kun jokin renkaista puhkeaa, tai hissien turvajärjestelmät pääasiallisten kaapelien katketessa
    • Toimii ei-kriittisten elementtien kanssa, mutta kriittisten elementtien kohdalla voi koitua ongelmaksi
    • CSS graceful degradation*** Jos jokin drop-down ei näy niin päätason linkkien kautta voi mennä alasivuille

s.74 design by committee

Suunniteluprosessi, missä on useampia henkilöitä ja asiaa tutkitaan usealta eri suunnalta ja tehdään kompromisseja. Uskotaan että yksinvaltiaat yrityksissä saavat aina hyviä tuloksia, mutta näin ei ole aina. Diktaattorimaisissa suunnitelmissa on hyötyä silloin jos aika on hyvin rajallinen, mutta silloin päätökset eivät välttämättä ole hyviä kaikkien kannalta.