Web-sovellukset toimivat paremmin ilman selainta

Webin toisella kultakaudella kokonaan uusia sovellustyyppejä ilmaantuu verkkoon kuin sieniä sateella. Vähänkin aktiivisempi webin käyttäjä on pian pulassa selaimen välilehtiviidakossa.

Minulla kesti pitkään tajuta, miksi työpöytäsovellus on lopulta parempi vaihtoehto kuin 15 avointa välilehteä. Satunnaiseen käyttöön web-liittymä vielä menee, mutta kun sovelluksia alkaa olla enemmän, ei selaimen käyttöliittymä enää veny.

Sivujen selailu ja sovellusten käyttö ovat kaksi eri käyttötapausta, vaikka protokollat ovatkin samat. Käyttöjärjestelmien käyttöliittymät on suunniteltu usean yhtäaikaisen sovelluksen käyttöön. Selaimen välilehdet ovat äärimmäisen alkeellinen käyttöliittymä sovelluksesta toiseen vaihtamiseen. Havainnollinen alt-tab-yhdistelmä, Exposé, tiedostojen raahaaminen ikkunoihin, kaikki nämä ja monta muuta ovat mahdottomia selainsovelluksille.

Selaimen välilehtien käyttö muuttuu hyvin hankalaksi kun avoimien välilehtien määrä lähentelee kymmentä ja painajaiseksi tämän jälkeen. Jatkuvasti avoinna olevat sovellukset syövät näitä arvokkaita paikkoja tehosurffaukselta.

Vielä pahempi ongelma ovat käyttäjät, jotka eivät osaa hyödyntää välilehtiä. Kymmenen avointa selainikkunaa ja “mikäs se Facebook näistä olikaan, en löydä, avaanpa uuden ikkunan” -syndrooma on tuttu näky, kun vierailen monien työpisteillä. Heille erillissovellukset eivät ole ratkaisu, koska ne vaativat perehtyneisyyttä ja kokeiluhalua. Ehkä ongelman ratkaisisi jos www-sovellus voisi kommunikoida selaimelle olevansa sovellus. Selain voisi tällöin ehdottaa sivuston rekisteröintiä omaksi sovelluksekseen, joka toimisi yhdessä, kenties sovellukselle kevyesti mukautetussa, selainikkunassa.

Jo nyt Fluid tarjoaa JavaScript-rajapinnan www-sovelluksen ja Fluid-sovelluksen väliseen kommunikointiin. Laajentamalla ideaa yhden klikkauksen sovelluksen generointi olisi mahdollinen. Jo tällaisenaan vielä buginen ja muutenkin keskeneräinen Fluid on silti jo varsin käyttökelpoinen. Olen käyttänyt Gmailia muutaman viikon sen kautta menestyksekkäästi. Fluidin suurin hyöty on sovelluksissa jotka eivät tarjoa rajapintaa tai joille ei ole kunnollista työpöytäsovellusta olemassa.

Bloggaaminen onnistuu OS X:ssä Marseditillä ja Windowsissa Windows Live Writerillä. Marsedit on tätä kirjoittaessa kokeilussa ja todennäköisesti tulee hankittua.

Sähköpostia voi tietenkin lukea millä vain sähköpostiohjelmalla. IMAP-tuki on tässä palveluntarjoajalta aika ehdoton vaatimus.

Syötteiden lukemiseen aivan ehdottoman loistavaksi olen havainnut NewsGatorin NetNewsWiren. Nykyään ilmaisena sitä ei kannata jättää kokeilematta. Windowsissa saman firman asiakasohjelma on FeedDemon, joka sekin on erinomainen sovellus. Google Readeria, Bloglinesia ja kumppaneita voi tietysti käyttää selaimessa, mutta varsinkin vähän isommalla syötemäärällä en vaivautuisi.

Twitter, Jaiku ja vastaavat eivät ole saaneet minua vielä innostumaan, mutta näille löytyy myös omat sovelluksensa. Deliciousiin ja muut sosiaalisiin kirjanmerkkipalveluihin samoin.

Unohdinko jonkin oleellisen www-sovellustyypin? Tiedätkö jonkun erityisen hyvän työpöytäkäyttöliittymän jollekin web-sovellukselle?

Käyttökokemuksia Macbook Pro:sta Santa Rosa -piirisarjalla

Muutaman viikon uutta Macbook Prota käyttäneenä olen yleisesti ottaen erittäin tyytyväinen. Mutta, negatiivinen ihminen kun olen, listaan tässä vain vastaan tulleita ongelmia tai henkilökohtaisia ärsytyksen aiheita:

  1. Trackpad toimii välillä miten sattuu, varsinkin raahaaminen tökkii. Tämä voi olla yksilövika, mutta ei niin iso ongelma (varsinkaan tällaiselle kaikki näppäinkomennot opettelevalle), että jaksaisin vaatia korjausta.
  2. Useasti olisi hyötyä siitä, että kansi avautuisi enemmän.
  3. Pimeässä huoneessa nukkumista ilmaiseva “hengittävä” valo häiritsee herkän unta. Kone on siis parempi muistaa sammuttaa yöksi, jos sen haluaa jättää samaan tilaan missä nukkuu. Lisäys 29.7.2007: command-option-eject nukuttaa koneen ilman sykkivää valoa. 30.7.2007: Se mitään toimi, normaali nukkumiskomento se vain on. Sammuttaa täytyy edelleen.
  4. Näytön taustavalo ei ole maailman tasaisin eikä värivirheetön katselukulma universumin laajin.
  5. Näppäimistö on muuten aika hyvin oman makuni mukainen, mutta return on liian kapea ja virhepainalluksia tulee jonkin verran. Fn:n sijoittaminen näppäimistön aivan vasempaan alakulmaan on perusvirhe kannettavien näppäimistössä. Onneksi OS X:ssä ei käytetä control-näppäintä yhtä paljon kuin Windowsissa, muuten tämäkin olisi ongelma.
  6. Näytön taustavalon automaattisesti säätyvä taso viehättää aluksi, mutta häiritsee käytännössä enemmän kuin hyödyttää. Jos se ei olisi niin nopea säätämään tasoa pienestäkin valon vaihtelusta, voisi se olla käyttökelpoinen. Näppäimistön taustavalon vastaava ominaisuus toimii paremmin.

Osuuspankin e-lasku: ikävä käyttökokemus

Päätin testata Osuuspankin e-laskupalvelua Visa-laskun kanssa. E-laskun idea on kannatettava: paperisia laskuja ei tarvitse lähetellä — lasku tulee suoraan verkkopankkiin. Saapuneesta laskusta saa halutessaan ilmoituksen sähköpostilla.

Visa-laskun voi maksaa haluamallaan summalla, olettaen että maksaa luottorajan mukaan määräytyvän minimisumman kuussa. Paperisen laskun kanssa olen tottunut siihen, että maksun määrä -kohdassa seisoo minimisumma eikä todellinen kuukauden Visa-käyttö. Koska luotto on korotonta kuukauden verran, maksan tyypillisesti koko laskun aina sen saapuessa. Todellinen summa löytyi paperisesta laskusta helposti, joten virheitä ei ole sattunut.

Sähköisen laskun kanssa onnistuin tekemään virheen ensimmäisellä kerralla viime kuussa: maksoin minimisumman todellisen kulutuksen sijaa. Virheen seurauksena jouduin maksamaan korkoa ylijääneeltä summalta. Summa ei toki ole iso, mutta se että vika on huonon käyttöliittymän on raivostuttavaa.

Tässä kuussa olin terävämpi ja osasin ihmetellä kummallisen pyöreää summaa:

Erääntyvät maksut

Tuolta sivulta siirrytään linkistä E-laskun hyväksyminen -sivulle, jossa ei myöskään ole mitään mainintaa mahdollisesta vaihtoehtoisesta summasta:

E-laskun hyväksyminen

Tässä vaiheessa pitää tajuta klikata erittäin heikosti esillä olevaa laskun erittelytiedot -linkkiä. Sitä ei ole tarjolla millään muulla näytöllä. Seuraavat valinnat avautuvat:

Laskun erittelytiedot

Ensimmäisestä vaihtoehdosta voi avata laskun HTML-muotoisena ja siitä löytyy todellinen maksettava määrä. Tämä tieto on sitten kopioitava ja liitettävä laskun hyväksyminen -lomakkeelle.

Ei kauhean kätevää, mutta silti siedettävä määrä klikkauksia.

Ikävintä on kuitenkin, että virheen mahdollisuus on aivan liian suuri. Pitää osata ennakoida, että e-laskun summa ei välttämättä ole se summa minkä haluaa maksaa. Lisäksi laskun avaaminen on tehty insinöörimäiseksi (käytetään teknisiä termejä DTD ja XSL ja tarjotaan näennäisesti samanlaisia valintoja) ja se on piilotettu huomaamattoman linkin ja liian monen klikkauksen taakse.

Ymmärrän sen, että laskulla voi olla monta summaa ja niiden tuominen käyttöliittymään on hyvin vaikeaa. En silti halua joutua maksamaan ylimääräistä sen takia, että käyttöliittymä on kehno. Osuuspankin käyttöliittymä on erittäin kehno muutenkin, mutta aiemmin en ole rahaa sen takia menettänyt.

Tämä ongelma olisi ratkaistavissa esimerkiksi siten, että linkkiä laskuun tarjottaisiin aktiivisemmin tai jopa että lasku olisi yksi pakollinen näyttö hyväksymisprosessissa.

Itse en todennäköisesti tätä virhettä tule toiste tekemään, mutta aivan varmasti lukuisat muut oppivat saman asian kantapään kautta.

Linkit eivät sovellu komennoiksi

Jakob Nielsenin Alertbox pureutuu tänään alati yleistyvään linkkien väärinkäyttöön toimintoihin. Mikä pahinta, Nielsen sortuu hyväksymään linkit, joilla on lieviä sivuvaikutuksia. Perusteluna käytetään vähän yllättäen Vistaa:

Windows Vista introduced a new GUI widget for commands: the command link. Once something is in the system that people use on a daily basis, it becomes a de facto standard. Because they’ll encounter them frequently in Vista, users will come to know and expect command links.

En muista moisiin epälinkkeihin turhasta karkista riisutussa Vistassani törmänneeni, mutta tämä osoittaa ettei Microsoftin käyttöjärjestelmäpuolellakaan (ASP.NET on toinen) ymmärretä linkin semantiikkaa. Microsoftilla on valta-asema, mutta kaikkea ei tarvitse kopioida. Linkillä on aina osoite, mutta käyttöjärjestelmä ei toimi URLien varassa. Vistassa ei siis ole linkkejä vaan sinisiä alleviivattuja sanoja, jotka käynnistävät toimintoja.

Toinen perustelu nojaa siihen, että komentolinkit mahdollistavat kuvaavamman komentonimen:

— — command links have their place because they introduce some benefits. Most notably, with a link, you can write a longer command name and thus make it more descriptive, whereas button labels have to be short (4 words or less) or the button will look weird.

Yli neljäsanaiset linkit eivät ole kovin luettavia nekään. Linkin saa ehkä hiukan pienempään tilaan, mutta painikkeenkin voi muotoilla — varsinkin kuvana — erittäin vapaasti. Edut alleviivatun tekstin käyttämisestä ovat marginaaliset. Toisen, vielä huonomman Nielsenin perustelunkin voi käydä lukemassa.

Epälinkkien kanssa toimiminen vaikeutuu ja syntyy ilmeisiä käytettävyysongelmia. Kaikki klikkausta edistyneempi toiminta tulee mahdottomaksi.

Jos unohdetaan käytettävyys, niin kuten olen kirjoittanut, GET ja sivuvaikutukset eivät sovi yhteen tietoturvasyistä. Tätä Nielsen ei tietenkään osaa huomioida, ja siksi pidänkin kirjoitusta erittäin vaarallisena.

Esimerkiksi, jos blogin kommentointi sallii kuvien liittämisen ja kommenttien poistaminen tapahtuu GET-pyynnöllä, voi kommentoimalla sopivasti saada ylläpitäjän tahtomattaan (ja huomaamattaan) poistamaan ilkeämielisen kommentoijan haluamat viestit. Google Web Accelerator tekee samaa, mutta yli-innokkaan “kiihdytyksen” harmillisena sivuvaikutuksena.

Turvallisinta on olla käyttämättä GETiä minkään toiminnon yhteydessä mitä ei voi huoletta toistaa.

Positiivista on, ettei Nielsen kovin varauksetta komentolinkkejä suosittele. Joissain asioissa on kuitenkin parempi olla ehdoton, ettei synny tuhoisia väärinymmärryksiä. Kunnioittakaamme linkkiä.