Käyttöliittymistä taisi täällä olla jo useampi merkintä. Aihe kolahti minuun paremmin kuin nuo muut. (mitä kiinnostavaa voi edes sanoa String-luokasta, pakkauksista, tai API:sta) Käyttöliittymien kanssa olen sentään tekemisissä koko ajan tätäkin kirjoittaessani.
Suoraan asiaan. Yksi ärsyttävimmistä käyttöliittymistä on mikroaaltouunissani. Lämmitysajan säätö tapahtuu isosta pyöreästä säätöruuvista kääntämällä – tai niin ainakin luulisi. Todellisuudessa säädin ei tee mitään, ennen kuin on”aktivoinut” sen painamalla MW-nimistä painiketta. TIME-nappula on kutsuvasti säätöruuvin vieressä, mutta se säätää mikron kelloaikaa, ja tarpeeksi remppaamalla se ajastaa mikron. Näytön teksti 3:00 saattaa tarkoittaa joko pieleen asetettua kelloaikaa, 3 min lämmitystä tai sitä, että mikro käynnistyy itsekseen aamulla klo 3. START/STOP nappula ei tee mitään ennen kuin aika on asetettu, AUTO-nappula käynnistää mitään varoittamatta mikron oletusajaksi, antamatta kuitenkaan itse asettaa aikaa. Kun lopulta nyt esimerkiksi tuo 3 min on kulunut, pillastuu mikron palohälytintä muistuttava äänimerkki, jonka piipitys jatkuu ja jatkuu ja jatkuu… siitäkin huolimatta, että lämmitys on tässä vaiheessa jo loppunut, mikron ovi avattu, ja suljettu ja ruoka nostettu ulos uunista.
Hyvä esimerkki on myös eräs työssäni käyttämä piirustusohjelma, jossa fontin vaihtamiseen tarvitaan alueen aktivoimisen ja tekstin valitsemisen lisäksi sekä vasenta että oikeaa hiirinäppäintä, yhteensä kahdeksan klikkausta.
Käyttöliittymäsuunnittelussa puhutaan usein heuristiikoista, nyrkkisäännöistä. Tässä mielestäni parhaat ideat, joita voi soveltaa vaikkapa omiin javasovelmiin: Käyttöliittymän tulisi olla mahdollisimman yksinkertainen, ei mahdollisimman hieno. Käyttöliittymä tulisi suunnitella paperilla eikä antaa sen muodostua itsekseen. Dialogien ja painikkeiden ulkonäössä, asettelussa, ikoneissa, teksteissä jne. tulisi mukailla surutta jo yleisesti käytössä olevia ratkaisuja (jotain rajaa tietysti 
, esim. Windows ja Mac sovelluksiin löytyy tyylioppaat ja valmiit käyttöliittymäkomponentit. Jos työ menee laajempaan levitykseen, se pitäisi testauttaa käyttäjillä ja iteroida palautteen pohjalta. Ohjelman rakenteen pitää luonnollisesti pitää käyttöliittymä erillään, jolloin käyttöliittymän muuttaminen aiheuttaa vain triviaaleja muutoksia koodissa.
Käyttöliittymässä pitäisi lisäksi tavoitella yhdenmukaisuutta, antaa informatiivista palautetta toiminnoista, estää virheitä (esim. valikot komentojen sijaan) tarjota opastavat virheilmoitukset, tarjota mahdollisuus perua komentoja (undo, cancel) ja huolehtia ohjelman käyttäjän lyhytaikaisesta muistista eksyttämättä tätä dialogien viidakkoon.
Mikroaaltouuniani voisi parantaa seuraavilla piirteillä: samanlaiset toiminnot ryhmitellään yhteen, ja rajataan toisistaan kehyksillä. Tärkein nappula (ajan asetus, ja käynnistys) näkyvimmälle paikalle ja vierekkäin. Älyttömät ruokatyyppinappulat (höyryävä kuppi, vihannes, kalkkuna..?) pois ja tilalle tavallinen tehonsäätö. kellonajan asetus syrjään lähelle kellonäyttöä ja ajastustoiminta kokonaan pois. Mutta ehkä tämä olisi valmistajan mielestä vähentänyt mikron esteettistä arvoa. Huoh…
Hauska nähdä myös muiden kirjoituksia tästä aiheesta. Aika lailla samanlaisia tuntemuksia…