Itse ohjelmointi alkaa aina ongelman hahmottamisella. Tämän jälkeen suunnitellaan ohjelman toiminnot. Nämä vaiheet eivät välttämättä vielä riipu siitä, millä työkalulla ja mihin ympäristöön ohjelma halutaan tehdä. Kuitenkin käyttöympäristö saattaa antaa mahdollisuudet monipuolisemman käyttöliittymän toteuttamisen ohjelmaan.
Linnun nokka on kaareva:Vastaavassa kohti graafisella käyttöliittymällä varustetussa ohjelmassa voisi olla kuva erilaisista nokan muodoista ja haluttua muotoa osoitettaisiin hiirellä:
a)laspäin
y)löspäin
e)i ole
:_
Valitse linnun nokan muoto:Tässä tapauksessa graafinen liittymä antaa käyttäjälle havainnollisemman kuvan eri vaihtoehdoista. Itse kysymys on kuitenkin edelleen sama. Nokan pituutta kysyttäessä graafisessa versiossa vaihtoehdoissa voisi olla jo mukana edellä valittu kaarevuus ja näin lintua voitaisiin "muokata" jatkuvasti kyselyn edistyessä.
Alaspäin Ylöspäin Ei kaareva
Valitse nokan pituus:Merkkipohjaisessa versiossa ainoa mahdollisuus olisi tulostaa jo tehtyjä valintoja näyttöön:
Lyhyt Pitkä Normaali
Linnun koko 10-15 cm.
Nokka ei ole kaareva.
Onko nokka
L)yhyt
P)itkä
N)ormaali
:_
Edelleen
itse toiminnot ja kysymykset pysyisivät oleellisesti samoina
käyttöliittymästä riippumatta. Toinen mahdollisuus
merkkipohjaisessa ohjelmassa olisi täyttää lomaketta, jossa
olisi tarpeelliset tunnistamiseen tarvittavat kohdat. Lomaketta voitaisiin
täyttää missä järjestyksessä tahansa;
käyttäjä voisi tällöin paremmin miettiä mitä
on nähnyt. Lomake voisi (ja ehkä jopa täytyisi) muuttua
vastausten mukaan.
Vastaava "graafinen" versio antaisi muutella valmiista linnun kuvasta ominaisuuksia missä järjestyksessä tahansa.
Edellä on esitetty ajatuksia "asiantuntijajärjestelmän" mahdollisesta käyttöliittymästä. Mitä kummastakin versiosta kuitenkin puuttuu? Epämääräisyys! Entä jos mikään valinnoista ei ole käyttäjän mieleen tai hän ei pysty sanomaan mistä yksityiskohdasta oli kyse? Valikoissa pitäisi olla "En tiedä" -vaihtoehto tai jopa mahdollisuus ilmasta että 40% todennäköisyydellä näin. Ongelma ei kuitenkaan ole käyttöliittymäkohtainen vaan itse ohjelman toimintojen suunnitteluun liittyvä.
Siis toimintojen suunnittelu voidaan erottaa aika pitkälle käyttöliittymän suunnittelusta.
Tietenkin ohjelman "myyvyys" riippuu paljolti sen ulkoasusta ja tällöin käyttöliittymän suunnittelu nousee ratkaisevaan osaan. Graafisen käyttöliittymän suunnittelu on huomattavasti hankalampaa kuin perinteisen tekstipohjaisen käyttöliittymän suunnittelu. Siis ohjelmoinnin (ja varsinkin sen koodausosan) viemän ajan painopisteet saattavat helposti vääristyä ja tuotteesta saattaa tulla liian kallis. Uusilla ohjelmointityökaluilla ohjelmaan voidaan kuitenkin joskus (toivottavasti) liittää "näyttävyyttä" uhraamatta siihen kohtuuttomasti aikaa.
Alasvetovalikot, päällekkäiset ikkunat ja lomakepohjat yhdistetään graafiseen käyttöliittymään. Näinhän ei välttämättä tarvitse olla. Kaikki mainitut ominaisuudet voidaan esittää tavallisella tekstinäytölläkin. Esimerkkinä voitaisiin pitää vaikkapa Borlandin C -ympäristöä, joka on tekstipohjaisena aivan samanlainen käyttää kuin vastaava Windows-versiokin.
Jatkossa graafinen käyttöliittymä tarkoittaa kaikkea missä hiirellä tai vastaavalla syöttölaitteella voi olla osuutta ohjelman käytön kanssa.
Miten niin voi? Koska aina pitäisi olla mahdollisuus käyttää ohjelmaa myös ilman hiirtä (tai vastaavaa). Tietenkin piirto-ohjelma ilman hiirtä tai muuta vastaavaa syöttölaitetta on aika vaikea käytettäväksi, mutta jopa tässä tapauksessa joskus näppäimistö on tehokkaampi. Esimerkiksi halutaan piirtää tasan tietynkokoinen ympyrä tiettyyn paikkaan. Näppäimistöltä on nopea antaa ympyrän keskipiste ja säde.
Erityisesti ero tulee kuitenkin alasvetovalikoiden ja muiden menujen kanssa. Nopea näppäimistön käyttäjä on valinnut jonkin toiminnon jo ennenkuin hiiren käyttäjä edes ehtii siirtää kättään hiirelle, saati siten suorittaa valintaa. Esimerkiksi useissa Windows ohjelmissa tiedosto talletetaan File Save, mikä voidaan tietysti valita hiirellä menusta tai painaa näppäimistöltä ALT-F S. Windows Wordissä lisäksi Shift-F12 suorittaa talletuksen.
Käyttäjälle pitää siis antaa mahdollisuus myös ohjelman nopeaan käyttämiseen helppokäyttöisyyden lisäksi. Missään tapauksessa graafinen käyttöliittymä ei saisi laskea käyttäjän tuottavuutta. Valitettavasti graafisen käyttöliittymän "helppous" ja suuremmat koneresurssien vaatimukset saattavat kuitenkin tehdä näin:
vaikka käyttäjälle olisi järjestetty oikotie-mahdollisuuksia, ei hän niitä viitsi koskaan opetella.
näytön päivityksen takia joidenkin toimintojen saaminen saattaa kestää luvattoman kauan
Käyttöliittymää suunniteltaessa kannattaa pysyttäytyä muiden ohjelmien "raameissa". Siis jos talletus on jossain tunnetussa ohjelmassa laitettu tiettyyn kohtaan valikoita ja tiettyyn näppäimeen, kannattaa sama tehdä omassakin ohjelmassa. Tämä on ehdottomasti eräs "graafisten" käyttöliittymien parhaita puolia; kurinalaisuus ohjelmoitaessa. Kurinalaisuus on tietenkin aluksi johtunut työkaluista, jotka käyttöjärjestelmän ohjelmointiin on annettu.
Nimenomaan tämä kurinalaisuus ohjelmoinnissa on se, joka on nostanut Apple MacIntoshin helppokäyttöisen koneen maineeseen. Kurinalaisuutta olisi voitu noudattaa myös muissa ohjelmointiympäristöissä, mutta harvapa itseään kunnioittava ohjelmatalo laittaa ohjelmaansa samoja toimintoja kuin pahimman kilpailijan ohjelmissa.
Tähän oliomaiseen ohjelmointiin ei välttämättä tarvita olio-pohjaista ohjelmointikieltä, vaan oikea ajattelutapa. Jos aikaisempi ohjelmointitapa on ollut aliohjelman kirjoittaminen kutakin pientäkin omaa tehtäväänsä varten ja tietueiden käyttö samaan yhteyteen kuuluvien asioiden säilyttämiseen, ei ajattelutapaa tarvitse paljon muuttaa. Jos lisäksi esimerkiksi suoraan linkitetyn listan tiettyyn alkioon viittaamisen sijasta on käytetty funktioita jotka palauttavat kyseisen alkion, on ohjelmointitapa varmasti terveellä pohjalla.
Olio-ohjelmoinnin tärkeimpiä ominaisuuksia ovat
* tiedon piilottaminen (encapsulation, information hiding)
* koodin uudelleen käytettävyys
* periytyvyys
Kaksi ensimmäistä saadaan aikaan varsin hyvin esimerkiksi tavallisella C-kielellä ja sopivalla suunnittelulla. Periytyvyyden järjestäminen vaatii työlästä "liimaa ja leikkaa" -metodia.
Edellä on sanottu vain osa graafisten käyttöliittymien ohjelmointiin liittyvistä ongelmista. Itse käyttöliittymän suunnittelu, toiminnat, ulkoasu, värit, kuvat jne. vaativat huomattavasti graafista silmää, mielikuvitusta ja mallien ottamista muista ohjelmista.
Jatkossa emme puutu graafisen liittymän ohjelmoinnin taiteellisiin näkökohtiin, vaan keskitymme vain tekniikkaan; miten ohjelmoidaan ja millä työkaluilla. Myöskään työkalun valinta ei ole itsestään selvää. C-kielellä graafisen liittymän ohjelmointi voi olla hyvinkin raskas valmiista kirjastosta huolimatta. Ohjelmaan tulevat muutokset saattavat tuottaa valtavasti ylimääristä työtä. C++ auttaa tässä asiassa hieman, mutta aliohjelmakirjastot (luokkakirjastot, Application FrameWork) eivät ole vielä mitenkään standardoituneet, joten työn alussa valittu aliohjelmakirjasto saattaa olla vanhentunut ennen työn loppua.
Työkaluna voi olla myöskin tietokantaohjelmisto, sovelluskehitin, taulukkolaskenta ja jopa tekstinkäsittelyohjelma. Myös "oikeiden" ohjelmoijien karttama Basic Microsoftin VisualBasicin muodossa saattaa tulla, ja nykyisin usein tuleekin, kyseeseen. Tietenkin C-kieli (tai C++) tarjoaa suurimmat vapaudet. Borlandin Delphi on VisualBasicin tapainen olio Pascal-kieleen perustuva visuaalinen kehitin, jolle voi povata myös hyvää tulevaisuutta. Projektissa voi olla mahdollista myös vaiheittainen eteneminen; prototyyppi taulukkolaskennalla ja lopullinen tuote C-kielellä.
Lisäksi esimerkiksi Windowsin DDE- ja OLE-linkit (Dynamic Data Exchange, Object Linking and Embedding) antavat mahdollisuuden rakentaa monimutkaisiakin sovelluksia, joissa tietoa vaihdetaan kunkin parhaiten eri tehtävään pystyvän ohjelman kesken. Näin esimerkiksi pylväs- yms. kuvioiden piirtäminen voitaisiin jättää taulukkolaskennan tehtäväksi, raporttien tekeminen tekstinkäsittelyohjelman tehtäväksi, monimutkaiset piirrokset CAD-ohjelman tehtäväksi ja hankalat numeeriset laskut voitaisiin hoitaa omalla C-kielisellä ohjelmalla, joka DDE- tai OLE-linkkien avulla välittää tiedon sovelluksen muihin osiin.
Jatkossa käytämme esimerkkiympäristönä MS-DOSin päälle rakennettua Microsoftin Windows 3.1:stä ja C-kieltä. Samat ongelmat ja näkökohdat kuin Windows-ohjelmoinnissakin on otettava huomioon myös muissa graafisissa käyttöliittymissä, joten vaikka keskitymmekin yhteen järjestelmään, saamme pohjan muidenkin järjestelmien ohjelmointiin. Eräät asiat ovat jopa yksinkertaisempia kehittyneemmissä ympäristöissä, kuten X11 (X-Window).