Mitől jó egy program?

Érdekes kérdés, és ha így valaki hozzámszegezi, hát akkor nagyon nagy a valószínűsége, hogy nagyot fogok nézni, és miután túljutottam a legelső megrökönyödésen, hát (mivel még mindig nem jutok szóhoz a csodálkozástól) legfeljebb megkérdem milyen programra gondolt. A kérdés annyira tág fogalomkört ölel fel, hogy szinte lehetetlen egy általánost választ adni rá.

Miért van, hogy egyes programok sikerkarriert futnak be, míg mások, melyek (szinte) ugyanazt a szolgáltatást nyújtják, eltűnnek a süllyesztőben. És itt nem feltétlenül gondolok arra, hogy az egyes programok szolgáltatásai jobban vannak leprogramozva, míg másoknál a szolgáltatás színvonala nincs annyira kidolgozva. Miért ragaszkodnak a felhasználók mégis körömszakadtukig egyes programokhoz, annak ellenére, hogy más programok is nyújtják ugyanazokat a szolgáltatásokat, sőt talán többet is.

Ez a cikksorozat a felhasználók szemszögéből fogja szemügyre venni, hogy „mitől is jó egy program”. Remélhetőleg hasznos útmutató lesz a programozó kollégáknak, hogy ne kövessenek el egyes hibákat, melyek az évek során súlyos következményeket vontak maguk után egyes programok piacra dobása esetén. A cikk tűzdelve lesz példákkal is, természetesen programnevet nem fogok említeni, hogy cikkem senkit ne sértsen meg.

A három futtatás szabálya és más érdekességek

Nagyon kevés programozó ír programot, melyet más programozók fognak használni, ezért ha valaki igazán sikeres programot szándékszik készíteni, akkor meg kell tanulnia egy felhasználó nézőpontjából tekinteni a világra. A felhasználók más szemekkel tekintenek a programunkra mint ahogy mi tesszük, hisz mi fejlesztjük, tudjuk, hogy mit miért raktunk oda, ahová raktunk, előre tudjuk, hogy mi fog történni, ha megnyomunk egy bizonyos gombot, hogy melyik rutinra fog ugrani. A felhasználónak meg kell tanulnia használni a programunkat, és (ez már saját tapasztalat is) ha általában a harmadik elindításkor még mindig gondjaim vannak egy programnak a kezelésével, akkor harag ne legyen, de mást keresek, és nagy valószínűség szerint találok is. Lehet, hogy szolgáltatásaiba nem lesz olyan mélyre menő, mint előző programom, de ha a kezelhetőségben veri azt, akkor nekem, mint felhasználónak megérte a váltást.

Alkalmam nyílt kipróbálni két Offline Browser programot (amelyek teljesen letöltenek bizonyos honlapokat), és érdekességképen említem meg a következő esetet: Mind a kettő úgynevezett projektet készített, amely általában a honlap nevét tartalmazta, természetesen ez változtatható volt, de ez nem lényeg. Az a program, amelyet először kipróbáltam rögtön az ismerős [Finish] gomb megnyomása után kezdte el letölteni az oldalt. És én ezt nagyon természetesnek vettem, hisz ezt is akartam: letölteni egy oldalt. A programnak nem voltak szuper szolgáltatásai, egyszerűen letöltötte az oldalt, és lementette egy könyvtárba.

A második program miután végigvezetett egy sor kérdésen, amelyeknek az én szempontomból nem voltak jelentőségei (hogy miket töltsön le, link mélység, satöbbi) azt mondta, hogy a projekt kész, és bezárta a Varázsló ablakot. Én meg csak néztem, hogy mikor kezdi már el a letöltögetést, hisz nem volt időm a végtelenségig várni, és nagyon kellet volna már az oldal. Majd lezártam a programot, gondolván, hogy majd amikor indul, akkor fogja elindítani a letöltéseket. Hát csalódtam. Végül nagy nehezen megtaláltam a rengeteg kezelőszerv közt a letöltést elindító gombot. Mondanom se kell, hogy első csalódottságomba messze hajítottam a második programot, és maradtam az elsővel, amelynek szinte semmi szolgáltatása sincs pluszban, csak egyszerű oldalletöltő.

A felhasználók azt várják el egy programtól, hogy azt csinálja, amit a neve ígér. Ha egy program neve azt mondja a felhasználónak, hogy erre írtak akkor fő szolgáltatásként ezt kell nyújtania, és a felhasználónak ezt nem a szolgáltatások tömkelegében kell megtalálnia, hanem rögtön az első lépéseknél kell tudatni vele, hogy igenis, ezt így és itt lehet megtenni. Egy programot lehessen könnyen kezelni.

Néha van, hogy egy programot nem használunk többet, mert a harmadik futtatás után még mindig nem világos számunkra, hogy milyen funkciói vannak, részletes segítséget nem adtak mellé, hisz a programozónak nyilvánvaló volt, hogy mit fog tenni, ezért csak sündisznófarknyi magyarázatot fűzött egyes kezelőszervek működéséhez.

Találkoztam egy sakk programmal, amelynél a menüjébe ott volt a sokat sejtető „Delete Tree” menüpont. Mivel az adatott meg, hogy ezt a programot nekem kellett tovább fejlesztenem, hát írtam a régi fejlesztőnek, írja már meg postafordultával, hogy mit jelent az ő szemszögéből ez. A válasz valahogy így hangzott: a pRoot-ból kitörli a pCurItem utáni alfát. Ez neki teljesen nyilvánvaló volt hogy a program ezt fogja csinálni, hisz ő írta, viszont bennem csak sorakoztak a kérdőjelek. Miután mélyebbre ástam a forrásba, megtaláltam, hogy a pRoot illetve pCurItem egy TMoveTree osztályra mutató pointer.

Miután ezzel se lettem sokkal okosabb, hát elkezdtem tesztelgetni, hogy valójában mi is fog történni a programmal, ha a játszma különböző fázisaiban kattintgatok erre a menüpontra. És rájöttem, hogy n visszalépés (Undo) esetén törli az aktuális lépés utáni lépéseket (vagyis a Redo lehetőséget), úgy, hogy a játékos többé nem tud előre ugrálni a lépéssorozatban.

A programozónak teljesen nyilvánvaló volt, hogy mi fog történni, viszont egy felhasználónak bizony gondjai akadtak a helyes értelmezésével. Egy felhasználónak nem kötelessége ismernie adatstrukturáinkat, őt csak az érdekli, hogy tudja, hogy a program működik, és lehetőleg minél kevesebb energiaráfordítással a lehető legjobb eredményeket hozza ki a lehető legrövidebb idő alatt. Egy program legyen érthető. Mindenki számára.

Megint visszatérek az első példámhoz. Mindkét program Threadeket hozott létre a letöltést felgyorsítandó, és mindkét programban volt egy mechanizmus, mely kiírta, hogy az aktuális Thread éppen hol tart. Az egyik programban egymás alatt, aránylag nagy képernyőterületet elfoglalva ott volt a nyolc darab Thread, és látam, hogy az egyes Thread épen hozza az index.htm fájlt és ennyi töltődött le ennyiből, ez meg ennyi százaléknak felel meg, a kettes a background.gif-el küszködik, és így sorban.

A másik program az ablak Status Linejaba írta ki a letöltésről szóló információkat, ott viszont csak egy sor van, és ezért aránylag gyorsan cserélődtek a nyolc Thread fent említett adatai, és én egy idő múlva kezdtem elveszteni a fonalat, és teljesen belezavarodtam, hogy hol is tart a letöltésem. A felhasználók szeretnek egy összképet látni arról, hogy a program amit használnak hol is tart, főleg ha időigényes munkával bízták meg a programot.

Viszont vannak esetek, hogy a programot könnyen is lehet kezelni, világos is minden funkciója, és mégsem sikeres. Hiába vonogatja a programozó a vállát: hisz szerintem nyilvánvaló. Ott van minden funkció a ToolBaron, mindig látja az összes funkciót, ha meg akar nyitni valamit kattint az első gombra, ha menteni akar a másodikra, ha be akarja állítani hogy a lementendő kép színmélysége 24 vagy 32 bit legyen, akkor a tizenhetedik gombra, én igazán nem tudom miért nem sikeres a program, hisz látjátok én mindent megtettem, hogy tudják használni.

A következő részben a kezelőfelületeket vesszük szemügyre.

Deák Ferenc