Watch!

Itt van mindjárt a Delphi watch ablaka. Nem bonyolult dolog, lényegében egy lista. Lehet hozzáadni, és törölni belőle. Lehet módosítani az elemeit. Hány idegesítő hiba férhet egy ilyen egyszerű valamibe? Vegyük sorra.

Az első hiba talán nem is konkrétan a watch ablakkal van, hanem általában a dokkolási mechanizmussal. Ha megnyitom a watch ablakot, majd bedokkolom az editor alá. Ezután az ember dülledő szemmel nyomkodja az enter gombot, de új elemet ugyan felvenni nem tud, ugyanis a fókusz visszament az editorra, oda írtunk be pár új sort nagy lendülettel. Próbálkozunk az alt+ctrl+W kombinációval, de az semmit sem csinál, ha az ablak már látszik, és egy fókuszált ablakba van bedokkolva. Egérrel kell odakattintani, más módszer nincs. Az F7 vagy F8 gombot megnyomva a fókusz ismét az editorra megy át, visszaút nincs, csak az egér.

Az elemeket nem lehet átrendezni. Emiatt az ember hamarosan egy ilyen elrendezésnél köt ki:

SomeList[i]
SomeList[0]
i
SomeList.Count
SourceText
SomeList[5]
SomeList[4]
j

Nem mintha kitörölni olyan könnyű lenne. Ha a ctrl-A kombinációval szeretnénk kijelölni az összes elemet, rájövünk, hogy az nem arra való, hanem új elem felvitelére (Add). Mindent kijelölni egyszerűen nem lehet. Illetve lehet, egérrel.

De abban sincs sok köszönet, mert ha kijelöljük az összes lehetséges sort, azt tapasztaljuk, hogy a Delete gomb nem csinál semmit, és a jobbgombos menüben is szürke a törlés. Van ugyanis egy sor, ami üres, ám mégis kijelölhető. Ennek funkciója az, hogy ráállva és entert nyomva új elemet vihetünk fel. Ha ezt az üres sort is kijelöljük, törölni nem lehet.

Egyáltalán, vajon minek üres sor? Ha újat akarok felvenni, arra ott van az Ins gomb (vagy a némileg szokatlan ctrl-A, ami ugyanazt csinálja). Miért jó az nekem, hogy egy nemlétező elem módosításával hozok létre egy újat? Az lenne a logika, hogy ha egy nemlétező elemből létező lesz, az végülis módosítás? Ha a Borland (CodeGear? Embarcadero?) ilyen gondolkodásmódot vár el a programozóktól, annak nem lesz jó vége.

De a homokóra ...

Mondjuk az ember éppen csinál valami olyasmit, amire oda kell figyelni, emlékezni kell pár részletre, stb. Eközben ki kell menteni egy fájlt valamely programból. Két másodperc alatt megnyílik az Kimentés ablak, legördítjük a mappákat, ám az nem nyílik ki, és csak képzeljük hallani, ahogy a számítógépben zakatolnak a fogaskerekek. Tizenöt másodperc múlva megjelenik az áhított lista. De ha közben újra kattintottuk a legördítő gombot, gondolván, hogy az elsőt valahogy nem vette észre, rögtön el is tűnik. Ha végre elő tudtuk csalni, választunk, fájlnevet adunk, mentünk.A kimentés két másodperc. Mire az ember ennek a végére ér, tanakodhat, hogy hol tartott éppen a feladatával.

Fülesablakban átváltunk egy másik fülre, de eszünkbe jut, hogy még valamit nem töltöttünk ki. Ám a gép már dohogva dolgozik az ablak megjelenítésén, éppen az adatbázisból pakolja kifele az adatokat, és nem hajlandó félbehagyni. Ki kell várni elsőre is, majd a módosítás után megint, immár a helyes adatokkal. Az ember frusztrációszintje a piros vonal felé kúszik. A jövőben minden adatot háromszor átolvas, és akkor is szorongva nyomja meg a gombokat. Hogy ne csak panaszkodjunk, itt vannak a tanulságok mára:

• Aki készíti, annak sokkal kevésbé fontos, hogy a program gördülékenyen használható legyen. Onnan kisebbnek látszanak a kényelmetlenségek. Ha választani kell a bonyolultabb megvalósítás és egy másodpercnyi várakoztatás között, azonnal az utóbbit választjuk. Adott esetben ez lehet jó választás, de ezt tudatosan kell végiggondolni, ergonómiai szempontokat figyelembevéve. Tudjunk a felhasználó fejével gondolkodni.
• Ami pár másodpercnek tűnik, az nem biztos, hogy csak pár másodperc. A folyamatok gyakran egymás után történnek, így az idők könnyen összeadódhatnak. Előre nem látott körülmény lassíthatja feldolgozást. Erős hálózati forgalom mellett párszáz sor letöltése az adatbázisból pillanatszerűről kínosan lassúra változhat. Egy fájl beolvasása is eltarthat öt másodpercig is akár, ha a lemezt a rendszer energiatakarékosságból kikapcsolta.
• A felhasználótól ellopott időt nem óradíjban kell számolni. Tény, hogy egy másodperc késedelem nem nagy veszteség. A veszteség abban rejlik, hogy felhasználó munkakedve, figyelme, lelkesedése milyen mértékben degradálódik. Az ilyen lelkesedéselszívó módszerek a produktivitást aláássák.

Tessék ezért figyelmet fordítani arra, hogy a program maradjon folyamatosan készenlétben, a felhasználója instrukcióit azonnal kövesse. Amit lehet, a háttérben csináljon, és ha már nincs rá szükség, hagyja abba. A felhasználó érezze úgy, hogy egy hangszeren játszik, amit tetszése szerint szólaltathat meg, és amely idomul a kezéhez. Mint minden szabály, ez is értő fülnek való. Nem muszáj minden tizedmásodpercet lefaragni. De kötelező végiggondolni, és tudatosan dönteni.

Nem, nem és nem!

Nem, az ablak fejléce nem való üzenetek közlésére.

Nem, nem lehet üresen hagyni az üzenetrészt.

Nem, a Close nem helyes választás erre az esetre.

Ez így nem jó.

Gombsaláta

A K9 egy jó kis spam szűrő, ingyenes, kicsi, egyszerű. Egyáltalán nem áll szándékunkban rosszat mondani róla. De most mégis arra fogjuk használni, hogy bemutassuk, hogy kell zavaró felületet készíteni.

Elöljáróban, hogy mire való a K9. Beépülve a levelezőprogram és a mailboxunk közé, figyeli a leveleket, amiket kapunk, és megpróbálja kitalálni, hogy melyik kéretlen reklámszemét, és melyik valódi. A program tanítható, tehát ha átengedett egy szemetet, vagy elfogott egy jó levelet, a megfelelő ablakban ez a döntés korrigálható. A korrekciót megjegyzi, és legközelebb pontosabban ítél.

A program kritizálásra váró ablaka pedig az alábbi.

Az ábrán az a felület látható, amivel az elmúlt időszakban kapott emailjeinket tekinthetjük át, illetve igény szerint átsorolhatjuk szemétté vagy jó levéllé. Az ablak tetején egy toolbar-szerű kialakításban gombok sorakoznak. Funkciójuk változatos. Haladjunk balról jobbra.

Az első két gomb együtt értelmes, közülük mindig az egyik van lenyomva. Ha az első van lenyomva, akkor a jó leveleket, ha a második, a szemeteket látjuk a listában. Ez tehát egy szűrő funkció. A programbeli megvalósítás feleslegesen szigorú, hiszen semmi akadálya nem lenne, hogy egyszerre lássuk az összes levelet. Ha viszont kizárólagosra készítették, talán szerencsésebb lett volna fülesablakot választani, mint arról korábban írtunk.

A következő két gomb egymáshoz nem kapcsolódó funkciókat takar. Az elsővel megnézhetjük a levél tartalmát, a másodikkal törölhetjük a raktárból. Érdemes megfigyelni, hogy a törlés gomb képe azonos a spam szűrőgomb képén levő áthúzással, csak ott egy mappa is van. Szerencsétlen dolog két eltérő funkciót azonos szimbólummal jelölni. A raktárból törlés és a szemétté nyilvánítás egymástól nagyon különböző dolgok.

A következő két gomb a levél átminősítésére szolgál. A jóvá minősítő gomb ikonja azonos a jó leveleket mutató szűrőgombéval, ez rendben van. A szemétté minősítő gomb ikonja egy szokvány tiltó jel. Ez szerencsésebb jelölés az áthúzásnál, mivel semmi esetre sem keverhető a törléssel. Ám mindenképpen helytelen, hogy a szűrőgombbal nem illeszkedik. További zavaró tényező, hogy a gombok felirata megegyezik az első két gombéval, holott funkciójuk igencsak eltér. Van tehát egy két Spam gombunk, az egyik mappával, áthúzással, a másik mappa nélkül, titlójellel. Ember legyen a talpán, aki itt kiigazodik.

A következő gomb a lista frissítésére szolgál. Bár ez a funkció nem tűnik túl hasznosnak, nincs vele baj.

A következő gombot most diszkréten átugorjuk, őszintén szólva fogalmam sincs, mire szolgál, sose próbáltam.

Az utolsó gomb funkciója az, hogy az átminősített leveleket szortírozza a helyükre. Átminősítés után ugyanis nem tűnik el a levél a szemünk elől (nagyon helyesen), hanem csupán a "Spam" oszlopban látszik a változás. Az ablak legközelebbi megnyitásakor kerül a helyére. Illetve ezen gomb megnyomására azonnal. Ami feltűnik, hogy az ikon teljesen azonos a frissítéssel, csak más a szine. Vajon milyen módon jelenti a zöld szín a szortírozást, szemben a kék színnel, ami az újraolvasást jelöli? Nem sikerül ebben értelmet látnunk.

A gombsor nagyon egysíkú. Az összes gomb hasonló képi elemekből táplálkozik, amelyek nem segítenek a feladatokról a képekre asszociálni, és viszont. Zavaró az áthúzás és a tiltójel hasonlósága. Ráadásul a jelek használata sem konzekvens.

Mindezt tetézi az, hogy a gombok eltérő hatókörrel bírnak, és ebben sincs semmilyen rendszer. Az első két gomb a lista láthatóságát szabályozza. A következő négy gomb a kiválasztott levélről szól. Ebből az első kettő a levélről magáról szól, a második kettő viszont azok besorolásáról, ami inkább a szűrőkkel függ össze logikailag. A többi gomb listával kapcsolatos funkciókat takar.

Célszerű lett volna a különböző hatókörű gombokat vizuálisan elkülöníteni. Ezt lehet csinálni mérettel és/vagy elhelyezéssel, csoportosítással. Ha a levélre ható gombok jobbra igazítva vannak, vagy a lista oldalán helyezkednek el, egyszerűbb lenne a felhasználó dolga.

Ugyancsak átgondolandó, hogy miért kell a szűrőt ilyen furcsán megvalósítani. Nem lett volna praktikusabb egy "Show" feliratú combo három választással?

Both spam and good
Spam only
Good only

A levelekről szóló gombok hátterébe egy boríték elfért volna.

Meggondolandó lett volna a szemetet jelző áthúzott kör helyett egy behajtani tilos tábla, vagy bármi más, szemléletesebb jelzés. Akár egy bűzölgő kutyagumi képe is jobban kifejezte volna a felhasználó gondolatvilágát.

A szortírozás gomb talán felesleges. Egy szűrőváltással a dolgok kerüljenek a helyükre.

A konkrét megvalósításon és az egyes gombok hasznosságán lehet elmélkedni, de mindenképpen olyan irányban keresgéljünk, ami csökkenti a felület egyhangúságát, és jobban reflektál a különböző funkciók természetes csoportosítására, viszonyára egymással és a többi felületelemmel.

Ööö, igen ... nem?

Korábban már jeleztük, hogy a program által feltett kérdések legyenek világosak. Azt elfelejtettük mondani, hogy egyszerre egy kérdést kell feltenni.

A baj az, hogy túl kevés a gomb. Négy kellene: Yes/Yes, Yes/No, No/Yes és No/No.

Forrás: The Daily WTF

kimért stílus

A korábbiak alapján mindenki meg tudja ítélni, hogy jó-e az alábbi hibaüzenet, avagy pedig nem jó.

A helyes megfejtéshez legalább két alapelvet kell említeni, aminek az üzenetablak nem felel meg.

(Forrás: The Daily WTF)

Szürke hétköznapok

Az alábbi form fogad minket egy bizonyos CD/DVD író program indulásakor.

Elsőre úgy tűnik, nem sok választásunk van, mert mindhárom felsorolt funkció ki van szürkítve, van továbbá egy Cancel gomb, ami az adott kontextusban elég hülyén fest, de a fő baj az vele, hogy mi előre mennénk, nem hátra. Az ablak ettől eltekintve se túl jól tervezett, mert nincs rajta semmi olyan elem (a Cancel és a fejlécbeli X gomb kivételével), ami bármiféle funkcióra engedne asszociálni, csak képek és szöveg van. Az még megérdemelné a kegyelemkettest, na de hogy lehet innen továbbmenni?

Azért még nem érdemes újrainstallálni a programot, mert a megoldás egyszerűbb. A három szöveg nem inaktív. Azok bizony működnek, csak valamiért a szerző úgy látta jónak, hogy az az opció, ami felett nem tartózkodik egérmutató, az lehetne például szép szürke. Ha fölé navigálunk az egérrel, akkor az alábbi csodálatos változás zajlik le.

Nahát! Működik ez, csak titkolja!

Ez a megoldás rossz. Nem kényelmetlen vagy furcsa, de még csak nem is pocsék, hanem rossz. Hosszú út vezet idáig a kényelmetlentől a pocsékon át.

Kezdetben voltak a gombok, a radio button, és a többi "oldschool" megoldás. Aztán valaki úgy vélte, hogy túl csicsásak az ablakok, és az nem jó, talán azért, mert fárasztó a szemnek, talán azért, mert nem volt kellően jól dizájnolható. Mindenesetre a gomb helyett jöttek a sima ikonok, vagy a modern toolbar, aminek a gombjai nem emelkednek ki, csak ha felettük jár az egér. Ettől az ablakok valóban simábbak lettek, de hogy ez mitől előny, nekem nem egészen világos. Az így tervezett ablakokról azok a kattingatós játékok jutnak az eszembe, amiknél az ember tűvé tette a képernyőt a használható tárgyakért (toll, kulcs, levél, stb), hogy aztán segítségükkel továbbjusson a következő helyre.

Az ablak eltérő funkciójú részeinek eltérő módon való jelölése nagyban megkönnyíti a használatot. Azért néz ki másképp a gomb és a kép, mert mást jelent. A gombot meg lehet nyomni, hogy valami történjen. A képet nem szoktuk nyomkodni, mert csak dekoráció, vagy információ. Mondhatjuk persze, hogy ez megszokás kérdése, mivel valóban az. A rossz szerszámot is meg lehet szokni, ügyes mester lötyögő kalapáccsal és életlen gyaluval is jobban dolgozik, mint én az újjal. De a mester mégis a jó szerszámot ajánlja, és nem véletlenül! Mert tudja, hogy a rossz szerszám, nos, rossz. Azt meg kell javítani, vagy jóra kell cserélni, mert növeljük a használhatóságukat, és ezzel a saját termelékenységünket. Bizonyított tény, hogy a bonyolított szoftverfelületek akkor is fárasztanak minket, ha már rutinszerűen használjuk, mert megszoktuk. Attól, hogy tudatosan nem okoz problémát, továbbra is jobban terheli az agyat, ami feszültséghez és fáradtsághoz vezet. Hasonlóan ahhoz, amikor valaki furcsa alakú, torz betűkből álló szöveget olvas. Azt is meg lehet szokni, de a fejfájás borítékolható.

Legújabban azt is kitalálta valaki, hogy a toolbar gombjai szintelenek, tompák, jellegtelenek, és csak az egér közelségére szinesednek ki, élénkülnek fel. Ez a megoldás teljesen ellentétes azzal, amit a józan ész diktál. A toolbaron az ember úgy keres valamit, hogy előbb a szemével végigfut rajta, meglátja, amit keres, aztán odaviszi az egeret kattintás céljából. Tehát a gombok akkor tompák és rosszul láthatók, amikor néznénk őket, és akkor szinesek, amikor már amúgy is megtaláltuk. Van ennél feleslegesebb?

Ezt az utóbbi megoldást fokozta tovább pocsékból hibássá a fenti ablak tervezője, amikor az alapállapot kissé tompa színvilágának az inaktív színt választotta, ami teljesen mást jelent. Ez már nemcsak nem olvasható rendesen, hanem el sem olvassuk, hisz úgyse lehet használni.

It's a Long Way to Tipperary

Mondjuk az ember megnyit delphiben egy projectet, aminek desktop fájlja (.dsk) is van. Így sok form megnyílna. De csak megnyílna, mert nincs feltelepítve egy komponens, ezért a delphi hibaüzenettel jutalmaz, majd megkérdezi, hogy mit tegyen (Cancel, Ignore). Ha negyven form van nyitva, akkor negyvenszer. Ha Cancel a választásunk, rögtön azt is közli, hogy akkor nem lehetett megnyitni a formot. Ezt is negyvenszer, és nincs menekvés, végig kell nyomkodni.

Ha Excelben hat új munkafüzetet nyitottunk, lezáráskor egyesével rákérdez, kimentsük-e. Ha ezek csak próbálkozások voltak, vagy csak megnézni nyitottuk meg, és lapozgattunk benne, akkor most hatszor kell nemet nyomni, hogy végre békén hagyjon.

A kapcsolódó alapelvek:

1. Minden kérdés egyben megszakítási pont is kell legyen. Az egész folyamat legyen leállítható.

   Ez az elv vonatkozik minden olyan folyamatra, ami alkalmat ad a felhasználónak, hogy közben meggondolja magát. Alapvetően két ilyen eset van: a hosszú ideig tartó műveletek, és a felhasználói interakcióra váró folyamatok. Nem szép dolog, ha a program 1-2 másodpercnél hosszabb ideig úgy dolgozik, hogy nem lehet leállítani. Az sem szép, ha becsal egy olyan helyzetbe, ahonnan csak előre lehet kijönni, nem lehet abbahagyni az egészet. Ha a felhasználó véletlenül indította el a folyamatot, vagy később jött rá, hogy mégsem kell ez most, nem szabad azzal büntetni, hogy nem szállhat ki. Ez az egyik legaljasabb mód a felhasználó magabiztosságának aláásására.

   Mi a teendő akkor, ha olyan folyamatot terveztünk, aminek megszakítása végzetes? Akkor rosszul terveztünk! Ugyanis a folyamatokat mindig meg lehet szakítani félúton, hiszen ott a Task Manager, amivel bármikor kilőhető a program. Illetve ott a reset gomb a számítógépen. És még csak azt sem mondhatjuk, hogy jó, de akkor magára vessen. Nem mondhatjuk azért sem, mert mindezeken túl ott van az áramszünet vagy gépelromlás lehetősége, amiről igazán nem a felhasználó tehet. A folyamatokat megszakíthatóra kell tervezni.

2. Minden ismétlődő kérdésnél megfontolandó, hogy Yes to All, No to All lehetőségeket adjunk.

   Na de mi van, ha ez túl fontos döntés, hogy csak úgy egyszerre megválaszolja az összeset. Először is, azt a felhasználó jobban tudja. Ami nekünk oly fontos adatnak tűnik, a felhasználó számára csak egy megkezdett játszós fájl. Másodszor erre nem az a megoldás, hogy negyven ablakot tolunk az orra alá, mert a gomb géppuskaszerű nyomkodása közben éppen nem fogja elolvasni a nagyon fontos kérdéseinket, sőt, ha egyszercsak egy teljesen más kérdés csusszan közéjük, azt is lendületből továbblöki. Ezt vagy észreveszi, de akkor már késő, vagy nem, és akkor ki tudja, milyen kárt okoz. Vajon melyik a rosszabb? Ha pedig mindenképpen minden egyes fájlra/formra fel akarjuk hívni a felhasználó figyelmét, marad a következő pont.

3. Meggondolandó, hogy több azonos kérdést egy ablakban is fel lehet tenni. Ekkor a dokumentumok/formok egy listában szerepelnek.

   Ez nem szokás sajnos, ezért lehet, hogy meg is bukna a felhasználók értetlenkedésén. De ha valamiért mégis muszáj látni az összes dolgot név szerint, próbálkozzunk meg vele. A kialakítás sokféle lehet. Nyilván lesz egy lista a nevekkel. Esetleg mellettük checkbox, hogy melyiket kell kimenteni. Vagy csak gombok: Save, és Discard. Persze akkor is kell Save All és Discard All gomb, illetve checkbox esetén Check All, Uncheck All. És persze az elengedhetetlen Cancel! (Ld 1. pont.)

Pintér Krisztián

csapda

Az egyik legbosszantóbb dolog, ami az emberrel egy számítógép közelségében történhet, ha fáradságos munkával kitöltött adatlapját nem tudja elmenteni, érvényesíteni, mert a program valamilyen külső eredetű hibát jelez, ami tehát nem a beírt adatokból fakad. Így sajátkezűleg kell a Mégsem gombbal az egész eddigi munkáját kidobnia.

Nyilván vannak esetek, amikor nem lehet előre tudni, hogy az adatkitöltés után a kért funkció elvégezhető. Példa erre egy internetes regisztrációs adatlap. Az ember kitölti az adatlapot, majd a Rendben gomb megnyomásakor a program kapcsolódik a regisztrációs szerverhez, és elküldi az adatokat. Ám mi legyen, ha nem érhető el a szerver? Az igazán pocsék program megköszörüli a torkát, és elnézést kér. A kicsit jobb program ezentúl még nyitva is hagyja az ablakot, hátha másodszor sikerül, vagy esetleg a felhasználó tud segíteni a problémán például a tűzfala konfigurálásával. De ha nem megy, nincs mese, elkerülhetetlen a harakiri a Mégsem gombbal.

Az ilyen eseteket ha csak egy mód van rá, el kell kerülni.

A fenti esetben például rögtön az elején ellenőrizhető a szerver elérhetősége, és egy figyelmeztető ablak jeleníthető meg, hogy nem fog menni a regisztráció. Ez nem véd az ellen, ha később romlik el, de legalább valami. Még jobb, ha az adatokat lokálisan is tároljuk, és ezzel logikailag szétválasztjuk az adatok bepötyögését az elküldéstől. Ha nem megy a regisztrálás most, majd megy legközelebb, de az adatok legalább már be vannak írva.

A fenti példa egy igazán nehéz eset volt. Számos olyan helyzet van, amikor kizárólag a programozó gondosságán múlik, hogy csapdába csalja-e a felhasználót, vagy nem. Az ilyen csapdákra nincs mentség! Egy módosító dialógust nem mutatunk meg, ha az objektum szerkesztéséhez a felhasználónak nincsen joga. Ha az ablak egyben megnéző ablak is, nem csak módosító, akkor pedig gondoskodunk a csak olvasható módú megjelenítéséről. Ami lehetőleg látszon is rajta, mert az sem jó, ha a felhasználó elkeseredetten veri a klaviatúrát dülledő szemmel, és nem érti, hogy miért nem tud bele írni. (Ilyen esetben igen hasznos tud továbbá lenni egy felugró képregénybuborék, ami az ablak alján levő lakat indikátorra mutat, és részletesen elmagyarázza annak jelentését.) Új adatot felvevő dialógust nem mutatunk meg, ha nem lehet új adatot felvenni. Ha az adat fevevése vagy módosítása azért nem lehetséges, mert egy másik adattal ütközik, nem szabad a felhasználót javításra kényszeríteni, mert lehet, hogy a másik adat a hibás, és amig a modális szerkszetődialógus látszik, a másik adatot nem lehet javítani.

Az alábbi képen látható esemény valószínűleg minden delphi programozóval megtörtént már. Datasetbe új mezőt veszünk fel, majd kitöltés után ez a kedves hibaüzenet jelzi erőfeszítéseink hiábavalóságát. Mivel a mezőfelvivő ablak modális, az egyetlen kérdés csak az, hogy mennyi ideig gondolkodunk kétségbeesetten, mielőtt megnyomjuk a Harakiri gombot.

LoseAmp

A múltkor már ekéztem a winamp páratlanul barátságos kezelőfelületét. Most újabb fantasztikus tulajdonságait fedeztem fel. Mivel a számlista nem rendes ListView, sem pedig ListBox, ezért számos funkcó nem működik:

• nincs olyan billentyű, amivel a kiválasztott elemet ki lehetne jelölni
• shift+nyilak nem csinálnak semmit
• ctrl+nyilak nem csinálnak semmit
• page down/page down nem csinál semmit
• home/end nem csinál semmit

Találós kérdés: hogy lehet kijelölni több sort billentyűzettel? Nekem még nem sikerült. Biztos van rá valami szuper billentyűkombináció, de feladványokban sose voltam erős.