Projektiranje korisnikih suelja - programski jezik Delphi

Fakultet elektrotehnike i raunarstva Ergonomija raunalne i programske opreme

Duko Murk 10.Svibnja, 2006

UVOD

VIZUALNI IDENTITET BOJA VELIINA I POLOAJ FONT INTUITIVNOST FUNKCIONALNOST ISPRAVLJANJE KORISNKIH POGREAKA ISPRAVLJANJE OSTALIH GREAKA UBRZANJE RADA LINKOVI

5 5 7 10 11 13 13 15 17 18

Uvod
Prvo to korisnik bilo kojeg raunalnog programa vidi jest njegovo suelje. Sam izgled suelja je jako bitan kod manjih programa koji se najee distribuiraju internetom, a koriste se da bi korisniku olakali koritenje raunala ili obavljanje neki svakodnevnij ranji. Naime, kod tih programa skoro uvijek postoje probne verzije koje su ujedno i besplatne. Ako se potencijalnom korisniku ne svi a izgled programa, isti nee program kupiti ve e potraiti neki ljepi. Kod testne verzije programa do izraaja dolazi i lakoa koritenja, tj. intuitivnost. Ako se program pokae neintuitivan, tj. korisnik bez detaljnog itanja dokumentacije ne zna to i kako napraviti, vjerojatno ni tada nee kupiti program. Stvari se malo mjenjaju kod poslovnih programskih rjeenja. Istina, i u tim se programima preporuuje da budu to inuitivniji pa i to ljepi, ali i u nedostatku tih osobina jo uvijek moemo imati aplikaciju kojom e korisnik biti zadovoljan. Iz osobnog iskustva mogu rei da sam sretao programe koji izgledaju poprilino komplicirano, ali su korisnici istih rekli da su oni tim program jako zadovoljni. Naime, oni su dobro radili posao za koji su bili namijenjeni i nakon to se korisnik naviknuo na program, sve je bilo u redu. Funkcionalnost. Kad kaemo da program dobro radi ono za to je namijenjen, znai da je funkcionalan. I to je jedna od najvanijih karakteristika bilo kojeg raunalnog programa (a i bilo kojeg proizvoda uope). Funkcionalnost raunalnog programa ne proizlazi samo iz injenice da je program napravio to to smo mi htjeli. Relevatno je i trajanje te radnje. Tako e program koji radi bre uvijek biti popularniji kod korisnika. Brzina programa nije odre ena samo vremenom za koje raunalo neto napravi, nego i vremenom koje korisnik utroi da bi se neka radnja zapoela. I na kraju, program ne moe biti (potpuno) funkcionalan ako ima puno greaka. Ako korisnik unosi iole veu
3

koliinu podataka pri emu se desi greka u programu te on mora taj posao ponoviti, nikako ga to nee uiniti zadovoljnim bez obzira to e nakon toga moda i ostatak posla protei bez ijedne greke. Dakle, ako imamo program koji svojim izgledom ne ulijeva povjerenje, ili pak program kojim se teko sluiti (neituitivan), imat emo problema sa prodajom istih. Ako pak te stvari uspijemo rijeiti na zadovoljavajui nain, a program nije (dovoljno) funkcionalan imat emo probleme tek nakon prodaje. Stvorit emo si bazu nezadovoljnih korisnika, a kako se dobar glas daleko uje, a lo jo i dalje, krenuli smo putem sigurne financijske propasti. Programski jezik Delphi je jedan od najboljih alata za razvijanje poslovnih aplikacija u okruenju Windows-a. Iako su njegove mogunosti velike, ovdje nee biti opisane kao pregled, ve samo preko primjera koji slijede ope odrednice koje su ovdje opisane, a u vezi sa projektiranjem korisnikih suelja.

Vizualni identitet

Vizualni identitet je ono to korisnik vidi prilikom koritenja neke aplikacije. To se prvenstveno odnosi na veliinu, boju i poloaj kontrola na ekranu. Napravimo li samo jednu od tih osobina loe, cijeli e proram na oigled izgledati neozbiljno, a u nekim sluajevima i neupotrebljivo. Boja Kod kreiranja aplikacije mnogi programeri ne posveuju dovoljno panje bojama. Najee se koriste standardne postavke kontrola koje se koriste. Pa se onda radi uljepavanja (ili naglaavanja neega) programa promijeni poneko svojstvo (boja fonta, pozadinska boja). Najea greka koja se tad javlja je koritenje ne sistemskih boja. Iako program na programerovom raunalu izgleda u redu, kod korisnika to moda nee biti sluaj. Ako korisnik ne koristi standardne boje u windowsima moe se desiti da nam neke kontrole imaju istu boju teksta i pozadine te tako postaju nevidljive. Ako postoji potreba za koritenjem ne sistemskih boja tada je vano postaviti boju fonta, boju pozadine te rub kontrole kako bi ona bila vidljiva bez obzira na okolne boje. Delphi nudi vie mogunosti kod koritenja boja. Jedna od njih je svojstvo Color i Font.Color. Pomou njih je lako mijenjati boju kontrola i boju fonta. Ali nemaju sve kontrole mogunost promjene boje, a osim toga ponekad nam sam promjena boje nije dovoljna. U tom sluaju se koristi Canvas kojim moemo nacrtati praktiki bilo to. Kako nemaju sve predefinirane kontrole svojstvo Canvas tad nam ostaje da sami kreiramo kontrolu koja naslje uje Canvas te implementiramo ono to nam treba. Zapravo, velika je vjerojatnost da je to ve netko i napravio pa e esto biti dovoljno da to potraimo na internetu.

Primjer: Upotreba sistemskih i korisniih boja

Izgled prozora istog programa na predpostavljenoj (lijevo) i na promjenjenoj (desno) shemi Windows-a. Primjetimo da je kontrola koja ne koristi sistemske boje zadrala isti izgled ali je i dalje upotrebljiva (Edit3), za razliku od one koja koristi kombinaciju sistemskih i korisnikih boja (Edit2). Kontrola koja koristi sistemske boje uvijek e biti upotrebljiva (Edit1), a izgled e joj se mijenjati ovisno o vizualnoj shemi Windows-a. Dio koda koji odre uje boje kontrola: object Edit1: TEdit Text = 'Sistemske boje' Color = clWindow Font.Color = clWindowText end object Edit2: TEdit Text = 'Ne sistemske boje' Color = clWindow Font.Color = clBlack end object Edit3: TEdit Text = 'Ne sistemske boje' Color = clWhite Font.Color = clBlack End

Veliina i poloaj Kao to smo vidjeli promjena sistemskih boja moe program uiniti neupotrebljivim. Ali osim o bojama, programer mora voditi rauna o rezoluciji i veliini korisnikovog monitora. To zapravo moemo objediniti u veliinu prozora u kojem se program izvrava i njegovu proizvoljnu promjenu od strane korisnika. Ako su nae kontrole u prozoru postavljene na tono odre enu lokaciju, promjenom veliline prozora moe se desiti da se dio njih ne vidi (pa se pojavljuje scroll bar koji oteava koritenje programa) ili da imamo prazan prostor. Do rjeenja dolazimo koritenjem doga aja TForm.OnResize. Prilikom svake promjene veliine prozora promijenimo veliinu i/ili poziciju kontrola koje se u njemu nalaze. Daljnje poboljanje dobijemo koritenjem kontrola TPanel. Na prozor postavimo nekoliko TPanela. Sada grupiramo kontrole po panelima te prilikom promjene veliine prozora dovoljno je da promijenimo veliine tih panela. Kako i panel ima doga aj OnResize njega moemo koristiti za promjene na kontrolama u tom panelu. Na taj nain dobijemo puno pregeledniji kod jer tono znamo gdje se to radi. Ujedno i izgled suelja postaje pregledniji jer moemo odvojiti kotrole po grupama posla. Dodatno poboljanje dobijemo koritenjem kontrole TSplitter. Prilikom koritenja TSplittera potrebno je koristiti i svojstvo Align koje nam omoguuje da se panel "zalijepi" na odre eni dio radne povrine. Ako postavimo splitter izme u dva panela (kojima su postavljena svojstva Align), omoguujemo korisniku da sam promjeni granicu izme u njih (tako da jednog poveava a drugog smanjuje). Ako iskoristimo i mogunost doga aja OnStartDrag mogue je implementirati i promjenu lokacije tih panela. Kako ve imamo rijeeno kako e se kontrole ponaati prilikom promjene veliine svakog od panela, time je korisnik praktiki dobio mogunost potpunog prilago avanja cijele radne povrine prema svojim eljama.

Primjer: Upotreba panela i splitera

Na gornjoj slici nije implementirano nita u vezi sa promjenom veliine prozora te smo smanjivanjem dobili scroll barove, dok bi poveanjem istog dobili prazan prostor. Donja slika prikazuje isti program sa minimalnim programskim zahvatima. Da bi smo to postigli bilo je potrebno staviti na formu dva TSplitter-a te postaviti svojstva Align na 'alCustom'. Tako er je dodan kod koji mijenja visinu i irinu panela:

type private vertScr : double; horScr : double; procedure TForm1.FormCreate(Sender: TObject); begin Self.vertScr := 0.3; Self.horScr := 0.5; end; procedure TForm1.FormResize(Sender: TObject); begin panelDolje.Height := Round(self.Height * vertScr); panelLijevo.Width := Round(self.Width * horScr); end; procedure TForm1.SplitterDoljeMoved(Sender: TObject); begin vertScr := panelDolje.Height / self.Height; end; procedure TForm1.SplitterLijevoMoved(Sender: TObject); begin horScr := panelLijevo.Width / self.Width; end;

Font Osim same veliine kontrola poeljno je da se moe mijenjati i veliina slova. Prilikom promjene veliine slova potrebno je voditi rauna i o veliini svih kontrola koje sadre tekst. Za rjeenje tog problema potrebno je dosta truda. Iako neke od kontrola imaju svojstvo AutoSize pa samom promjenom slova automatski prilago avaju veliinu, potrebno je osigurati da kod promjene veliine kontrole ne dolazi do preklapanja istih. Tako er je potrebno za kontrole koje nemaju AutoSize implementirati promjenu njihove veliine to nije lak zadatak. Upravo zbog tih razloga se rijetko koristi mogunost da korisnik sam moe mijenjati veliinu slova. Iznimka su neke od kontola koje promjeni veliine slova pristupaju na drugaiji nain. To su npr. Memo, ListBox, ComboBox, StringGrid, DBGrid i sline kontrole koje sadre razne liste elemenata ili jednostavno imaju mogunost da tekst bude u vie redaka. Naime, te kontole se iscrtavaju na taj nain da se pojavljuju ScrollBar-ovi kada bi sadraj trebao premaiti granice kontrole. Upravo zbog toga e u veini programa biti mogua promjena veliine fonta samo kod tih kontrola.

10

Intuitivnost

Cilj svakog programera je da koritenje programa bude to jednostavnije. Kako su neki programi zbog veliine i obima posla koji obavljaju sve samo ne jednostavni, tako ni njihovo koritenje ne moe biti jednostavno. Unato tome, koritenje nekih programa je lako od samoga poetka. To znai da su oni intuitivni. Ako pretpostavimo da korisnik programa poznaje osnove rada sa raunalom te da ima potrebno teorijsko znanje o onome to program treba raditi, tada bi morao moi koristiti program bez pomoi ili evenutalno uz minimalnu pomo. Dakle, intuitivnost moemo mjeriti po tome koliko esto korisnik mora posizati u pomo (bilo u vidu Help-a ili korisnike podrke). Da bi program bio to laki za koritenje potrebno je slijediti nekoliko smjernica: 1. Tekst kontrola. Ako sam tekst kontrole ukratko opisuje ono to ista radi, korisniku je nee biti teko pronai. Kod teksta na kontroli, tako er je potrebno voditi rauna o programima na lokalnom jeziku. Kako je veina korisnika ipak nauena raditi na engleskom, prijevod na hrvatski zna biti zbunjujui. Kako s vremenom ima sve vie programa na hrvatskom, taj je problem sve manji, ali nije na odmet dobro promisliti koji emo izraz koristiti jer doslovni prijevod sa engleskog esto ne opisuje nabolje to neka kontrola radi. 2. Hijerarhija glavnog menija. Prilikom kreiranja glavnog menija potrebno je grupirati zadatke jer bi inae meni imao previe objekata te bi bio nepregledan. Grupe je potrebno paljivo kreirati tako korisnik slijedei logiki slijed lako prona e ono to mu treba.

11

Primjer: Pokazuje kako tekst kontrola i hijerarhija menija pridonose intuitivnosti

3. Slike na ikonama. Ikone nisu nita drugo do gumbi sa slikama. U Delphi-u postoji kontrola TSpeedButton koja (za razliku od TButtona) ima sliku na sebi a ne tekst. I tu vrijedi slino pravilo kao kod naziva. Slika bi sama po sebi trebala ukazivati koju akciju e pokrenuti. Osim toga potrebno je voditi rauna da ikone nisu previe sline jedna drugoj jer to samo uvodi zbrku kod korisnika. Primjer: Ovaj primjer sadri i kontraprimjer kako ikone ne bi trebale izgledati (prvi redak) i dobar primjer (drugi redak). Primjetimo da su u prvom retku ikone sline te nije jasno ta koja predstavlja

4. Opis kontrola. Neke kontrole ne mogu imati tekst za njihov opis jer se one koriste za unos podataka. Npr.: TEdit. Tada koristimo TLabel koji stavimo pokraj te kontrole sa opisom to se u TEdit upisuje. Za opis kontrola moemo koristiti i svojstvo Hint. To je oblai koji se pojavi kad korisnik do e miem na kontrolu i malo prieka i postoji kod svih kontrola. U taj se oblai upie kratak opis to ta

12

kontrola predstavlja. Primjer se moe vidjeti na prethodnoj slici tako da je nedostatak zbog slinih ikona ublaen. Slijedei ove smjernice, uvelike olakavamo rad na programu te ujedno ubrzavamo rad na njemu.

13

Funkcionalnost

Da bi program bio funkcionalan, mora ono za to je namijenjen raditi tono i to je prije mogue. I mora imati im manje greaka zbog kojih bi program zablokirao ili se ak ugasio. Ispravljanje korisnikih pogreaka Kako raste koliina podataka koje korisnik mora unijeti ili radnji koje mora obaviti za pojedini zadatak, tako raste vjerojatnost da e neto krivo napraviti. Stoga je vano provjeravati podatke koje korisnik unaa. Ili jo bolje ograniiti ga da unese samo ono to se od njega trai. Tako kontrola TMaskEdit ima svojstvo EditMask gdje moemo postaviti to tono korisnik moe upisati. Primjer: Dozvoljava se unos telefonskog broja (u Hrvatskoj). EditTelBroj.EditMask := (000)_9000-000;0 Prvi dio je izraz za unos, a nula na kraju pokazuje da e svojstvo Text prikazivati samo one znakove koje korisnik unese (dakle bez '(', ')', '_', '-') '0' - obavezni brojani znak '9' - neobavezni brojani znak '(', ')', '_', '-' - znakovi koji se automatski pojavljuju na tim pozicijama Osim toga, ostavimo li korisniku da mora neke radnje obaviti tono odre enim redoslijedom, velika je vjerojatnost da on to nee napraviti. Stoga je potrebno onemoguiti kontrole koje se koriste tek nakon neke akcije te ih naknadno omoguiti, nakon to je korisnik istu ve izvrio. Za to nam slui svojstvo koje ima svaka kontrola, a to je

14

Enabled. Na taj nain smo prisilili korisnika da ne napravi pogreku. Me utim, potrebno je voditi rauna o tome da korisnik moda nije svjestan zato on ne moe npr. "pritisnuti gumb izraunaj". Tako da je u nekim sluajevima bolje ostaviti mogunost da korisnik radi to hoe, ali tada moramo provjeravati da li su obavljene sve radnje koje trebaju biti. Ako neto nije obavljeno potrebno je u poruci korisniku dati do znanja to jo treba napraviti da bi mogao nastaviti rad. Npr. "Niste unijeli podatak za koliinu". Takav nain prekida kontinuitet rada, ali koritenje dobija na jasnoi. Ispravljanje ostalih pogreaka Za razliku od greaka koje moe uzrokovati korisnik neispravnim unosom podataka ili neispravnim redoslijedom radnji, postoje greke za koje je odgovoran programer. To su npr. diljenje s nulom, broj premauje maksimalnu vrijednost, datoteka koju elimo otvoriti je zauzeta od nekog drugog procesa itd. Neke od tih greaka moemo sprijiti klasinim if - then sistemom. A za sve ostale Delphi nam nudi na koritenje try - except i try - finally naredbe. U try bloku napiemo dio koda za koji je postoji mogunost da bi mogao dovesti do pogreke. U sluaju da se pogreka zaista desi, program nastavlja izvo enje u catch bloku. Tu je potrebno napraviti oporavak od pogreke. Oporavak moemo obraditi ovisno o tipu pogreke. Najee se nije mogue u potpunosti oporaviti od pogreke na nain da se izvri zadatak koji je doveo do pogreke, ve je potrebno vratiti stanje programa u kojem je bio prije nego li se greka dogodila. Usto je potrebno korisnika obavijestiti da eljeni zadatak nije izvren to je jo uvijek bolje nego da se program jednostavno prekinuo. Ako imamo mogunost da pokupimo povratnu informaciju od korisnika, nije loa ideja svaku pogreku koja se javila negdje zapisati kako bi se otklonila u sljedeoj verziji programa.

15

Primjer: Ako se dogodila greka prilikom itanja iz datoteke poziva se procedura ObradiDatotekaNePostoji za obradu iste. Na taj nain je mogue definirati neogranieni broj pogreaka te svaku obraditi ovisno o vrsti. To se koristi kad oekujemo neke greke. U ostalim sluajevima "uhvatimo" nepoznatu greku te moemo proitati podatke o greci i obraditi je. procedure TForm1.FileOpen1Accept(Sender: TObject); begin try RichEdit1.Lines.LoadFromFile(FileOpen1.Dialog.FileName); except on EFOpenError do ObradiDatotekaNePostoji; on E : Exception od ObradiNepoznataGreska(E); end; end; Procedure ObradiNepoznataGreska(E: Exception) begin ErrorDialog(E.Message, E.HelpContext); end;

16

Ubrzanje rada sa programom Funkcionalnost programa ovisi i o koliini vremena koje korisnik mora utroiti da bi neto napravio. Smanjenje koliine posla za korisnika nije lak zadatak. Ali ni nemogu. Ako korisnik esto popunjava nekakve obrasce na kojima se ponavaljaju iste vrijednosti, moemo koristiti automatsko popunjavanje tih podataka. U sluaju da je korisnik zadovoljan onim to smo pretpostavili da on treba unijeti, bit e dovoljno ako samo pritisne Enter, a ako nije moe samo poeti pisati. U tom sluaju najbolje je promijeniti pozadinu kontrole tako da korisnik bude svjestan da je podatak promijenjen. Bitan je i poredak kontrola tj. TabOrder. Nako to korisnik pritisne Enter (ili Tab i sl.), fokus mora biti na kontroli koja logiki slijedi tekuu. Na taj nain mogue je bitno ubrzati unos podataka. Kao to sam mnogo stvari kad okruenje u kojem njemu snalazi i na obavi zadatak. rekao u uvodu, zadovoljstvo korisnika ovisi o se radi o raunalnom programu. Od toga da radi izgleda "lijepo" pa preko toga da se lako u kraju, a moda i najbitnije, da lako, brzo i tono

17

Linkovi

Ergonomija na FER-u http://web.zpr.fer.hr/ergonomija/ Delphi32.com http://www.delphi32.com/ Delphi pages http://www.delphipages.com/ Torry's Delphi pages http://www.torry.net/ Delphi basics http://www.delphibasics.co.uk/ Delphi source http://www.delphisource.com/ VCL Components - Delphi http://www.vclcomponents.com/Delphi/ Richey's DELPHI-BOX http://www.inner-smile.com/delphi5.phtm The Delphi Super Page http://delphi.icm.edu.pl/ The Dephi Corner http://www.delphicorner.f9.co.uk/

18