Soha ne figyelmeztess, ha a visszavonás is elegendő!

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Soha ne figyelmeztess, ha a visszavonás is elegendő!
Miért? Mert a szoftvernek tudnia kellene, hogy szokásokat veszünk fel. Tudnia kellene, hogy azután, hogy számtalanszor válaszolunk OK-val a kérdésre, feltehetőleg akkor is az OK-t választjuk, ha nem arra gondoltunk. És azt is tudnia kellene, hogy nem lesz lehetőségünk gondolkodni, mielőtt véletlenül eldobjuk az egész munkánkat.

Miért kellene tudnia a szoftvernek ezeket a dolgokat? Mert a szoftvertervezőknek is tudniuk kellene, hogy szokásokat veszünk fel, akár akarjuk, akár nem.

A szokások felvétele tulajdonképpen egy jó dolog: segít megkímélni minket annak a gondjától, hogy gondolkodni kelljen, amikor az interfész bosszantó apróságaival találkozunk és csökkenti a valószínűségét, hogy a gondolatmenetünk eltérül. A „Biztosan ki akar lépni?” kérdésre a kezünkben van egy memorizált kattints-és-zárd-be folytonos folyamat. Ez jó, mert a legtöbb esetben nem akarunk gondolkodni a kérdésről – csak a jó dolgot csináljuk. Szerencsétlen módon, a szokásaink időnként félrevezetnek: nem lesz időnk rájönni a hibánkra, amíg meg nem csináltuk.

Így a tervezők számára egyenes út vezet az általános felhasználói felülettervezési elvhez: Ahhoz, hogy egy felhasználói felület emberi legyen, figyelembe kell vennie a szokások kialakulását.

Lehetséges megoldások

Mi lenne, ha a figyelmeztetést nehezebb lenne figyelmen kívül hagyni? Egy diszkrét figyelmeztetés felett könnyű átugrani, így vegyük elő a teljes eszköztárat: villogtatjuk a képernyőt és egy hangos, idegesítő zajt játszunk le annak érdekében, hogy biztosítsuk a felhasználói figyelmet. Próbálkozhatunk, ahogy tetszik, továbbra sem fog működni. Minél tolakodóbb a figyelmeztetés, annál gyorsabban meg akarunk szabadulni tőle (az OK-ra kattintva) és annál többször fogunk hibázni. A gond az, nem számít, mennyire tolja a képünk elé a figyelmeztetést a szmítógép, mi ugyanazt a hibát fogjuk elkövetni: akkor is az OK-ra kattintunk, ha nem azt akartuk. De ez még mindig nem a mi hibánk: addig, amíg szokások felvételével figyelmen kívül lehet hagyni a hibaüzenetet, felvesszük a szokásokat, azután pedig hibázni fogunk.

Mi lenne, ha a figyelmeztetést lehetetlen lenne figyelmen kívül hagyni? Ha a szokások okozzák a problémát, miért nem tervezzük úgy meg a felületet, hogy ne lehessen szokásokat felvenni? Így mindig rá leszünk kényszerítve, hogy gondolkodjunk a válaszadás előtt, és így mindig azt válaszoljuk, ami választ mi szeretnénk. Ez megoldja a problémát, nem?

Ez a fajta gondolkodás nem új: ez az írd-be-az-n-edik-szót-ebből-a-mondatból-a-folytatáshoz megközelítés. Például a Guild Wars játékban ahhoz, hogy egy karaktert töröljünk, először a „Törlés” gombra kell kattintani, majd a karakter nevét be kell írni megerősítésként. Sajnálatos módon ez nem mindig működik. Pontosabban:

  1. Arra kényszerít minket, hogy koncentráljunk a szokatlan feladatra és nem arra, hogy tényleg el akarjuk-e dobni a munkánkat. Így a nem figyelmen kívül hagyható figyelmeztetés se sokkal jobb, mint a teljesen átlagos: mindkét esetben végeredményben elveszik a munkánk. Ez (a munka elvesztése) az elképzelhető legnagyobb bűn a szoftver világában.
  2. Figyelemre méltóan idegesítő, és mert mindig szükséges a figyelem, szükségszerűen elterel minket a munkánkról (ami a második legnagyobb szoftver-bűn).
  3. Mindig lassabb és több munkát igényel, mint egy egyszerű figyelmeztetés. Ezzel elköveti a harmadik legnagyobb bűnt – azzal, hogy több munkát igényel tőlünk, mint az szükséges.

A Guild Wars-os példánkban a második és harmadik pont nem túl lényeges, mert a karakterek törlése elég ritka esemény. De ha be kellene írni a dokumentum nevét, mielőtt mentés nélkül kiléphetnénk, nagyon megterhelőnek éreznénk.

Mit tanultunk? Azok a felületek, amik nem veszik figyelembe a megszokást, nagyon rosszak. A figyelmeztetés nagyobbá, hangosabbá és nem-figyelmen-kívül-hagyhatóvá tétele nem működik; akárhogy is nézzük, a figyelmeztetések egy nagy, sötét csapdát jelentenek az interfészben. Inkább szabaduljunk meg a figyelmeztetésektől.

A mentőöv: visszavonás

Ha csak simán eltávolítjuk a figyelmeztetéseket, nem mentjük meg a munkánkat a végzettől, de ha egy „visszavonási” lehetőséget beteszünk, akkor már igen. Hadd ismételjem meg: a figyelmeztetéses nyomorúságunkra a visszavonás a megoldás. Egy kellően robosztus visszavonással akár nemtörődöm módon is bezárhatjuk a munkánkat tudva, hogy mindig visszanyerhetjük. A visszavonással ezt a szörnyű „Hoppá!” érzést eltüntethetjük a munka visszaszerzésévelA „Hoppá!”-tényező egy Laura Creighton-nal folytatott megbeszélés alapján született meg..

Mivel szokásokat veszünk fel, soha nem fogjuk tudni garantálni, hogy nem lesz ilyen „Hoppá!” pillanatunk. Ezzel szemben a tervezőknek tudomásul kell venniük, hogy meg fog történni, és ennek megfelelően tervezni. Ahányszor csak megvan a lehetősége, hogy eldobjuk a munkánkat, a számítógépnek lehetővé kell tennie, hogy visszacsináljuk a dolgokat.

Ez elvezet minket az egyik legalapvetőbb és legfontosabb felülettervezési mantrához: Soha ne figyelmeztess, ha a visszavonás is elegendő!

A Google Mail egy jó példája ennek a mantrának. Ha törölsz egy e-mailt, azonnal ad lehetőséget arra, hogy visszavond ezt a lépést. Milyen felhasználóbarát! Ezzel ügyesen kikerüli a figyelmeztetések kérdését (csakúgy, mint a visszavonás láthatóságát). Ha hibázunk (ami elő fog fordulni), nem kerül túl sokba, mert egyszerűen visszavonhatjuk. A visszavonással kevesebbet aggódunk és több időt dolgozunk.

Gmail visszavonás: Ezt a beszélgetést áthelyeztem a kukába. Link a Visszavonás opcióra.
1. ábra: Még nincs túl késő. A Gmail lehetővé teszi, hogy visszavonjuk a törlést.

Természetesen ez csak egy rétege a visszavonhatóságnak – és Gmail ennél tovább megy. Ha törölsz egy levelet, az nem veszik el örökre… ott van a kukában, hogy visszaállíthasd, ha később úgy döntesz, mégsem akartad törölni.

Sajnos, ezt a leckét a Google Calendar még nem tanulta meg. És, ahogy megjósolható volt, töröltem már olyan eseményeket, amit nem akartam. Sokszor a rossz eseményt töröltem, ami különösen rossz, mert ekkor abban sem vagyok biztos, hogy mit töröltem. Visszavonás nélkül nincs is rá mód, hogy kitaláljam.

Google Calendar figyelmeztetőablaka: Biztos, hogy törölni akarod az
2. ábra: Légy óvatos! A Google Calendar nem engedi a téves törlések visszavonását.

Tulajdonképpen még Google Mail sem mindig használja ezt a módszert. Ha egy címkét törölsz, már jön is egy ilyen figyelmeztetés. Miért van az, hogy Google ilyen jól megcsinálja egy helyen, és alig néhány kattintással arrébb meg ilyen rosszul? Talán mert ez a figyelmeztetés alapú gondolkodás annyira beágyazódott, hogy hősies erőfeszítéseket igényel a meghaladása. Még olyan cégek is, amelyek egyébként a jó tervezés védőbástyái (ilyen a 37Signals), ezt nagyon rosszul csinálják.

Highrise figyelmeztetés: Biztos, hogy törölni akarod ezt a feladatot?
3. ábra: A Highrise, a 37Signals alkalmazása is figyelmeztet visszavonási lehetőség nélkül

Figyelmeztetések használata a visszavonás helyett a legkisebb ellenállás felé mozdulás útja a programozó szemszögéből, és nem igényel különösebben újító gondolkozást a tervező nézőpontjából. De ez nem mentség a számítógépeink számára, hogy nem emberi módon gondolkodnak.

Következtetés

A figyelmeztetések miatt elveszíthetjük a munkánkat, bizalmatlanok leszünk a számítógépekkel szemben és magunkat hibáztatjuk. Egy egyszerű, de bolondbiztos tervezési módszertan megoldja a problémát: „Soha ne figyelmeztess, ha a visszavonás is elegendő!” És ha a felhasználó törli a munkáját, mindig elegendő.

Ó, és a következő alkalommal, amikor azt látod, hogy figyelmeztetnek a visszavonás helyett, küldj az alkalmazás/weboldal tervezőjének egy kedves e-mailt, amiben javaslod, hogy inkább implementáljanak egy „visszavonás” funkciót. Küldj nekik egy linket erről a cikkről. Nézzük meg, meg tudjuk-e változtatni annak a módját, ahogy az emberek a webre terveznek – és ebben a folyamatban mindenki számítógépes életét egy kissé emberközelibbé és kevésbé frusztrálóvá tegyük. Kezdődjön a háború a figyelmeztetések ellen!

Illusztráció: Kevin Cornell

A szerzőről

Aza először 10 éves korában a SIGCHI helyi, san franciscoi székházában beszélt a felhasználói felületekről, és a rabjukká lett. 17 évesen nemzetközi megbeszéléseken és konzultációkon vett rész; 19 évesen egy fizikakönyv társszerzője lett, mert túl fiatal volt, hogy alkoholt vegyen; 21 évesen elkezdett inni, és társalapítója a Humanized-nek. Aza szeret játszani a kürtjén és a laborjában tenni-venni, ha az ideje engedi.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Programok összehangolása OSX alatt

Megvan már egy ideje, hogy Mac-et használok. A múltkor is, amikor ismét próbálkoztam a Windows-zal (lásd a cikket a Macre telepítéséről), már erőteljesen érzékelhető volt a különbség. Az, hogy a Mac működik, a Windows meg nem.

A helyzet még durvább, ha azt is figyelembe vesszük, hogy az Apple segített azoknak, akiknek egy egyszerű szolgáltatás hiányzik egy programból. Nekem például az iTunesszal volt egy-két problémám.

Több rendszer még több programját kipróbáltam korábban, és mivel az a szokásom, hogy szinte állandóan zenét hallgatok, szeretem időnként megnézni, hogy áll a zenelejátszás. Ugyanakkor az ellen sincs kifogásom, ha ehhez nem kell túl sokat kattintgatnom, stb.

Megvan már egy ideje, hogy Mac-et használok. A múltkor is, amikor ismét próbálkoztam a Windows-zal (lásd a cikket a Macre telepítéséről), már erőteljesen érzékelhető volt a különbség. Az, hogy a Mac működik, a Windows meg nem.

A helyzet még durvább, ha azt is figyelembe vesszük, hogy az Apple segített azoknak, akiknek egy egyszerű szolgáltatás hiányzik egy programból. Nekem például az iTunesszal volt egy-két problémám.

Több rendszer még több programját kipróbáltam korábban, és mivel az a szokásom, hogy szinte állandóan zenét hallgatok, szeretem időnként megnézni, hogy áll a zenelejátszás. Ugyanakkor az ellen sincs kifogásom, ha ehhez nem kell túl sokat kattintgatnom, stb.

Windows-on a Winampnál, Linuxon az Amaroknál elég volt a kis ikonjára ráhúzni az egeret, és rögtön kaptam egy feliratot arról, hogy mit játszik éppen, esetleg még arról is kaptam információt, hogy mennyi ideig játssza még az aktuális számot. Nem is beszélve arról, hogy mindkét program képes rá, hogy számváltáskor dobjon egy üzenetet, és ez rövid ideig jelenjen meg, majd automatikusan tűnjön el.

Na, az iTunes ezekre önmagában nem képes. Nincs egységes notification interfész az OSX-be integrálva, más kérdés, hogy helyette van a kvázi-szabványos, nyílt forrású notification-program, a Growl. Amennyire látom, egyre több OSX-es alkalmazásfejlesztő foglalkozik azzal, hogy Growl értesítéseket használjon, köztük kereskedelmi termékek is. Nem lepődnék meg, ha idővel az Apple saját szoftverei is elkezdenék használni.

De addig is, amíg ez nem következik be, a Growl fejlesztői elkészítettéka saját Growl-pluginjeiket a legtöbb alkalmazáshoz: az iChathez, az iTuneshoz és több máshoz is. Az iTunes-plugin pontosan arra képes, hogy üzenjen, ha új szám kezdődik.

Ezzel félig megvagyunk, a másik problémára csak trükkösebb megoldás képzelhető el. Ugyanis ezt még nem igazán csinálták meg korábban. De azért egy magamfajta kockafejnek ez azért nem jelentett igazi kihívást – pláne, hogy a megoldás nagyjából már megvolt a weben is. Sajnos egy jó ideje, hogy megtaláltam, akkor is nehezen, így nem tudom megmondani a forrását a megoldásnak, de ha megtalálom, utólag is be fogom illeszteni. Addig is névtelenül tisztelem meg azzal, hogy felhívom a közönség figyelmét, hogy a megoldás elve nem az enyém.

Tehát, a megoldás lényege az volt, hogy írni kell egy Applescript scriptet (szóismétlés ruley 🙂 ), ami értesíti a Growlt az aktuális szám adatairól, majd ehhez be kell állítani egy gyorsbillentyűt globális triggerként.

A globális trigger relatíve egyszerű eset volt nekem, aki már korábban úgyis használt Quicksilvert. A Quicksilver egy productivity app OSX-re (bár valahol olvastam, hogy már van Windows-os változata is), ami többek között alkalmazásgyorsindító (OSX-en szükség is van rá, ugyanis a Dock-on korlátozott számú ikon fér el, az Applications foldert megnyitni, és abban keresni körülményes, a Spotlight kereső pedig erre a célra lassú), és mellesleg egyéb lehetőségeket is kínál, például gyors levélírás a címjegyzék és a levezelőprogram felhasználásával vagy, amit most ki fogok használni, gyorsbillentyű hozzárendelése szinte bármihez (többek között Applescriptekhez is). A program egyébként tartalmaz iTunes modult is, amivel mellesleg az iTunes vezérlése is könnyedén megoldható.

Az Applescript pedig egy nagyon egyszerű, magas szintű nyelv, majdhogynem angol szöveget kell leírni csak ahhoz, hogy a kívánt funkcionalitást elérjem. Például az iTunes alkalmazás megcímzése a következőképpen történik: tell application "iTunes".

Ezután szerepelt mintakód is, de nekem nem tetszett az eredmény, ugyanis az eredeti Growl-pluginhez hasonló megjelenítést ért el, míg én Last.fm felhasználóként kicsit másfajtát vártam. Ezután kis testreszabás következett, meg persze Applescript dokumentáció böngészés (igen, ilyen is van és használható) után a következő végső kódot produkáltam (megosztom, mondván talán másnak is hasznos lesz.

tell application “System Events” to
if (application processes whose name is “iTunes”) is not {} then
log
tell application “iTunes”
if player state is playing then
set trk to current track
set trk_arts to the artist of trk
set trk_name to the name of trk
set trk_albm to the album of trk
set trk_dur to the time of trk
–Artwork
if (count of artwork of trk) ≥ 1 then
set trk_artwk to data of artwork 1 of trk
tell application “GrowlHelperApp”
set the allNotificationsList to ¬
{“Show Status”}
set the enabledNotificationsList to ¬
{“Show Status”}
(register as application ¬
“iTunesScript” all notifications allNotificationsList ¬
default notifications enabledNotificationsList ¬
) notify with name “Show Status” title trk_name description trk_arts & ”
” & trk_albm & ”
” & trk_dur application name “iTunesScript” pictImage trk_artwk
end tell
else
tell application “GrowlHelperApp”
set the allNotificationsList to ¬
{“Show Status”}
set the enabledNotificationsList to ¬
{“Show Status”}
register as application ¬
“iTunesScript” all notifications allNotificationsList ¬
default notifications enabledNotificationsList ¬
icon of application “iTunes”
notify with name “Show Status” title trk_name description trk_arts & ”
” & trk_albm & ”
” & trk_dur application name “iTunesScript”
end tell

end if
end if
end tell
end if
Az OSX rendszer egy nagy előnye, hogy viszonylag sokféle library-t kifejlesztett az Apple, ezek után a programozók elkezdhetnek a hozzáadott értékekkel foglalkozni, mint amilyen az alkalmazások közötti kommunikáció. Ez a rendszeren látszik. Természetesen az én megoldásom, mivel nem a háttérben, hanem a felhasználó segítségével történik, nem a legelegánsabb megoldás, de ez nem von le semmit az értékéből. A módszer használható, pár óra alatt össze lehetett hozni a dolgot minta alapján, és ha az embernek extra igényei vannak, elég részletes dokumentáció, és ügyes Applescript-készítő program áll a rendelkezésére.

Végeredmény: egy újabb jól használható pont azok számára, akik szeretik a végletekig testre szabni a rendszerüket, de nem kívánnak túl mélyen belefolyni a részletekbe, forrásba (tudom, Linux alatt is el lehet érni frontend megoldásokkal ugyanezt a hatást, mielőtt valaki kötözködne, de sokkal több munkát igényel). Nem véletlen használnak egyre többen OSX-et desktop operációs rendszernek.

Suckerfish menük

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2003. november 7. óta elérhető itt.

A „DHTML” legördülő menük maguk után vonták az otromba, böngészőspecifikus hackelésekkel teletömött Javascript kódokat, amik az egyébként elegáns, szemantikus HTML kódot meglehetősen hozzáférhetetlenné A hozzáférhető/hozzáférhetetlen fogalmakon a webtervezői szókincsben megfelelő accessibility kifejezést értem. teszik. Ó, azok a pehelykönnyű, hozzáférhető, szabványos, böngészőfüggetlen módszerek! Tekintsd meg a Suckerfish Suckerfish: Brehm és Wikipedia alapján rövidszárnyú bojtorjánhal. Ez a hal a Gályatartóhal-félék családjába tartozik. Ezek a halak már az ókorban is ismertek voltak a Földközi-tenger vidékén, a halak különlegessége, hogy más halakhoz, esetenként hajókhoz kapcsolódtak, velük vitették magukat. Konkrétan a bojtorjánhalról Brehm ezt írja: „Elterjedésének határa valószínűen egybeesik a kardoshalakéval, mivel többedmagával ezekre tapadva viteti magát. (Brehm: Az állatok világa) menüket!

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2003. november 7. óta elérhető itt.

A „DHTML” legördülő menük maguk után vonták az otromba, böngészőspecifikus hackelésekkel teletömött Javascript kódokat, amik az egyébként elegáns, szemantikus HTML kódot meglehetősen hozzáférhetetlenné A hozzáférhető/hozzáférhetetlen fogalmakon a webtervezői szókincsben megfelelő accessibility kifejezést értem. teszik. Ó, azok a pehelykönnyű, hozzáférhető, szabványos, böngészőfüggetlen módszerek! Tekintsd meg a Suckerfish Suckerfish: Brehm és Wikipedia alapján rövidszárnyú bojtorjánhal. Ez a hal a Gályatartóhal-félék családjába tartozik. Ezek a halak már az ókorban is ismertek voltak a Földközi-tenger vidékén, a halak különlegessége, hogy más halakhoz, esetenként hajókhoz kapcsolódtak, velük vitették magukat. Konkrétan a bojtorjánhalról Brehm ezt írja: „Elterjedésének határa valószínűen egybeesik a kardoshalakéval, mivel többedmagával ezekre tapadva viteti magát. (Brehm: Az állatok világa) menüket!

Először a HTML

Először is, válasszuk a legjobb módszert a menü leírásához — egy listát. Példánkban egy egyszerű HTML sorszámozás nélküli listát használunk.

<ul>
  <li>Sunfishes

    <ul>
      <li><a href="">Blackbanded sunfish</a></li>
      <li><a href="">Shadow bass</a></li>
      <li><a href="">Ozark bass</a></li>
      <li><a href="">White crappie</a></li>
    </ul>

  </li>

  <li>Grunts

    <ul>
      <li><a href="">Smallmouth grunt</a></li>
      <li><a href="">Burrito</a></li>
      <li><a href="">Pigfish</a></li>
    </ul>

  </li>

  <li>Remoras

    <ul>
      <li><a href="">Whalesucker</a></li>
      <li><a href="">Marlinsucker</a></li>
      <li><a href="">Ceylonese remora</a></li>
      <li><a href="">Spearfish remora</a></li>
      <li><a href="">Slender suckerfish</a></li>
    </ul>

  </li>
</ul>

Tényleg eléggé magától értetődő — tiszta és elegáns HTML, ami a hozzáférhetőséget biztosítja. De ezt most átalakítjuk egy dinamikus listává — a listaelemek első szintje egy vízszintes menüsávot fog alkotni, ebből fognak legördülni a második szintű listák.

Formázzuk meg!

Kezdésként minden listaelemet piszkáljunk meg egy kicsit — nevezetesen a margót és kitöltést nullára állítjuk, a listaelemek jelzését pedig kikapcsoljuk:

ul {
  padding: 0;
  margin: 0;
  list-style: none;
  }

A következő lépésben a lista első szintjét átalakítjuk egy vízszintes menüsávvá. Többféle technika van erre, amiket máshol részletesebben kifejtenek. Megjelölhetnénk az elemeket a display: inline; jellemzővel, de ebben a példában inkább balra lebegtetjük őket.

li {
  float: left;
  position: relative;
  width: 10em;
  }

Az elemek helye position: relative;-ra lett állítva, mivel a beágyazott listákat az első szinthez képest relatívan helyezzük majd el, a fix (!) szélességmegadás meg azért szükséges, hogy elérjünk bizonyos méreteket. A legördülő menü lassan összeáll.

Ezek után nézzük a lista második szintjét, ami a tényleges legördülő menü lesz:

li ul {
  display: none;
  position: absolute;
  top: 1em;
  left: 0;
  }

Ez a listák második szintjét abszolút módon helyezi el (kiemeli a HTML folyamból, és külön kezeli őket), és alapértelmezetten meg nem jelenítettekké állítja. Abban az esetben, ha a display: none; részt display: block;-ra cserélnénk, akkor látjuk szükségét a top és a left értékek beállításának az Internet Explorerben, mert ezek nélkül az IE a második szintű listákat az ősük jobb felső sarkába helyezi a bal alsó helyett. Sajnos ez az IE megoldás elkavarja a dolgokat az Opera-hoz hasonló böngészőkben, így ezekben a következő CSS kódra van szükség a top és left paraméterek beállításához:

li > ul {
  top: auto;
  left: auto;
  }
Angolul: And now, making the sucker work. Lefordíthatatlan szójáték, az angol suckerfish névvel játszik.

És most rakjuk hozzá az összekapcsolást! Ahhoz, hogy a második listaszintet megjelenítsük, amikor az első szinten a pontok „kiválasztódnak”, egyszerűen a következő kódot kell hozzáadni:

li:hover ul { display: block; }

Ami annyit jelent, hogy bármely elem, ami egy olyan pont alatti listában szerepel, amire az egérkurzor rámutat, megjelenítendő.

Végül, mert a listaelemek balra vannak lebegtetve, a tartalmat alattuk függetleníteni kell a lebegtetéstől a clear: left formázás kijelölésével.

Várjunk egy pillanatot!

”Ez a legördülő halandzsa nem működik!” – hallom az olvasók 102,6 százalékát (vagy a legfrissebb, éppen csökkenő hányadukat) kiabálni. Igen, mint kitalálható, az Internet Explorer felhasználóiról beszélek. Minél többet használod egyszerű szörfözőként, vagy webfejlesztőként a Mozillához hasonló böngészőket, annál feltűnőbb, hogy mennyire nevetséges az Internet Explorer, ha a webes szabványokról esik szó. A :hover pszeudoosztálynak elvben minden elemre működnie kellene, de az Internet Explorerben csak a linkekre működik. Pont. Mi a haszna a legördülő menünek, ha csak a böngészők -2,6 százalékán működik? Hogy őszinték legyünk, nem sok. Egy kicsit többet kell még varázsolnunk.

A mentőöv: DOM-szkriptelés

Ugyan megállapítottuk, hogy az IE ugyan nem támogatja a :hover pszeudo-osztályt, de a Document Object Model használatával egyszerűen kapcsolhatunk egéreseményeket (mouseover, mouseout) bármilyen elemhez. Ez jó hír számunkra, mert azt jelenti, hogy egy rövid JavaScript kódocskával hatékonyan orvosolhatjuk az IE :hover gondjait.

Mivel az IE vak, ahhoz, hogy azonosítsuk a :hover pszeudoosztály tulajdonságait, más módszert kell találni. A JavaScript segítségével manipulálhatuk a className tulajdonságát egy elemnek, így először egy kicsit a CSS-t kell megváltoztatnunk:

li:hover ul{ display: block; }

helyett a következő kód használható:

li:hover ul, li.over ul{ display: block; }

Ezután meghívhatjuk a :hover CSS szabályokat a kívánt elemre, ha hozzáadjuk az over osztályt a kívánt elemhez. Szükségünk lehet továbbá arra, hogy megmondjuk az IE-nek, hogy mely UL elemek szolgálnak az oldalon legördülő menüként. Ez egy id hozzáadásával tesszük meg a listánk gyökér ul elemére:

Ezáltal a

<ul>

kódból a következő lesz:

<ul id="nav">

Most, hogy tudjuk azonosítani a gyökér ul elemét a legördülő listánknak, kiemelhetjük ezt az elemet, és végigmehetünk az összes gyerekelemén, hozzáadva a mouseover és mouseout eseményeket az összes li elemhez a belsejében. Ezt így tehetjük meg:

startList = function() {
if (document.all&&document.getElementById) {
navRoot = document.getElementById("nav");
for (i=0; i<navRoot.childNodes.length; i++) {
node = navRoot.childNodes[i];
if (node.nodeName=="LI") {
node.onmouseover=function() {
this.className+=" over";
  }
  node.onmouseout=function() {
  this.className=this.className.replace(" over", "");
   }
   }
  }
 }
}
window.onload=startList;

A lap betöltésekor a startList függvény meghívódik. Ez meghatározza, hogy a böngésző IE 5 vagy újabb a document.all objektum és a document.getElementById függvény létezésének vizsgálatával. Ez egy picit nyers megoldás, de rövid és egyszerű, és mivel mi egy kompakt megoldást szeretnénk, ez is megteszi. Ezután végiglépked a listákon, engedélyezve a mouseover és a mouseout eseményeket, amik hozzáadják/eltávolítják a over osztályt a className tulajdonságához az elemnek.

Így már működik. Probléma esetén érdemes megnézni a megjegyzésekkel ellátott példa vázat működés közben.

Kopoltyúk, uszonyok, pikkelyek…

Eddig amit csináltunk, egy kicsit meztelennek tűnik. Ez a cikk csak az ötlet alapjait mutatja be, de CSS segítségével sokkal szebben meg lehet valósítani. Egy nyilvánvaló kiindulópont lehet háttérszín hozzárendelése a második listaszinthez.

Miután visszaállítottuk a top és left tulajdonságokat, ahogy korábban leírtuk, a legördölő menük a szép példában közvetlenül a feliratok alatt jelennek meg a legtöbb modern böngészőben, de sajnos nem mindben. A Safari 1.0-ban még mindig a képernyő bal felső sarkából gördülnek le.

További használhatósági és hozzáférhetőségi gondolatok

Ha az első listaszint elemeiből hivatkozásokat csinálunk, megengedjük a tabstop használatát azon olvasók számára, akik nem használnak mutatóeszközöket. Ha sikerül olyan oldalakra mutatnunk, amik magasabb szinten vannak, mint az almenü elemei, az még jobb eredményt ad.

A szerzőkről

Patrick Griffiths egy szabadúszó londoni webtervező, aki kedveli, tiszteli a soul-t, az evolúciót és a kedves weboldalát (megjegyzés: az eredeti pet kedvencet és háziállatot egyaránt jelent), a HTML Dog-ot. Időnként becézgeti a PTG-t a hangulatától függően.

Dan Webb egy webtervező és DJ-nek is tanul. A korábbi munkái között szerepel szabványkövető, hozzáférhető oldalak és webalkalmazások megvalósítása az Egyesült Királyság kormányzati hivatalainak és emberek táncra penderítése London homályos szórakozóhelyein.


Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk elérhető itt.

Firefox – Take back the field

Az amerikai Oregon állambeli Amity környékén egy gabonaföldön különleges jel került elő. A jel nagyjából kör alakú, ~67 méter (220 láb) átmérőjű, ugyanakkor egy ismerős jelet formáz: a Mozilla Firefox böngésző logóját.

Az amerikai Oregon állambeli Amity környékén egy gabonaföldön különleges jel került elő. A jel nagyjából kör alakú, ~67 méter (220 láb) átmérőjű, ugyanakkor egy ismerős jelet formáz: a Mozilla Firefox böngésző logóját.

Firefox gabonakörA tettesek ugyanakkor nem az UFO-k voltak, hanem az Oregon Állami Egyetem (Oregon State University) Linux-felhasználók csoportja nevű szervezete (Linux Users Group), ami főleg hallgatókból áll.

További részletes leírás, képek a itt található.

Az alkotóknak ezúton is gratulálok, és remélve, még sokan átváltanak erre a nagyszerű böngészőre (vagy ha esetleg jobban tetszik valakinek, akkor Operára).

Elkockázott pecsétgyűrű és túlcsordult kocka

Fegyvermérgekről
JK1: Van egy kontaktméreg, amit fegyverméregként használok, extra óvatossággal.
JK2: Gumikesztyű…

Elf ruházatról
JK1: Nem feltűnő útiruha.
JK2: Zöld köpeny, à la Gyűrűk Ura.
JK1: Mondom, hogy nem feltűnő útiruha.

Kockadobások
KM: 10x1k10, háromszor dobhatod.
JK (dob): 30, 60, 90.
KM: Ha most dobsz még egyet, és 120 lesz, akkor bevonom a kockát.
JK (dob még egyet): 100… túlcsordult.

Fegyvermérgekről
JK1: Van egy kontaktméreg, amit fegyverméregként használok, extra óvatossággal.
JK2: Gumikesztyű…

Elf ruházatról
JK1: Nem feltűnő útiruha.
JK2: Zöld köpeny, à la Gyűrűk Ura.
JK1: Mondom, hogy nem feltűnő útiruha.

Kockadobások
KM: 10x1k10, háromszor dobhatod.
JK (dob): 30, 60, 90.
KM: Ha most dobsz még egyet, és 120 lesz, akkor bevonom a kockát.
JK (dob még egyet): 100… túlcsordult.

KM a csapat bárdjának (JK1) ismert álruháinak listáját böngészi
KM: Mit értesz azon, hogy ficsúr?
JK2 (bajvívó): Olyan, mint én!

KM: Elfek között vagytok? Akkor ők is felfigyelnek…
JK: Ők csak a természetben, tehát nem…
KM: Jó, akkor nem figyelnek fel…

Csapat egyik bajvívója (JK1) levelet kap a régóta nem használt nevére, de nem akarja a többiekkel megosztani az információt
JK1: Régi magánéleti problémák… nem itt kéne megbeszélni.
Többieknek nyilvánvaló, hogy mellébeszél.
JK2 (bárd): Jó, de ezért holnap el fogom happolni az összes nődet.
JK1: Sebaj, lesz másik.
JK3 (másik bajvívó): Pedig arról volt szó, hogy bedobjátok közösbe.

Bárdmágiáról
JK1: Egy nagyon tápos városőr képét öltöd magadra?
JK2: Nem, egy nagyon tápos (erioni) városőrhöz hasonló kalandozóét.

Megtörténik JK1 (bárd) alakváltása
KM JK2-nek: Azt veszed észre, hogy a bárdnak megnőnek az izmai.
JK2: Belenyúlok a bicepszébe, hogy nagy illuzionistának tűnjek.

A titkolózó bajvívó egy késdobálóba ment a levéllel, kezd bajba kerülni, a bárd (JK1) és a másik bajvívó (JK2) kintről figyeli.
JK1 Kocsmai verekedés, vagy előbb kimentjük?
JK2 Várjunk, most varrattam meg az ingemet, nem akarok verekedni.

JK: Megbízhatok indiszkréciótokban?

Utazásról
JK: Nem tudom, hogy szárazföldön menjünk, vagy gyalog.

JK: Itt csak én mutatkozom be eredeti nevemen?

JK1: A tengeribetegségnek okai voltak (utal arra, hogy korábban a karakter elkerülte a Gályák tengerét, most viszont arra menne), mit tettél a kajájába?
JK2: Le ne buktass!

JK1: Pincér, még egy kört!
JK2: Ne csajozz, holnap utazunk!

JK: Isturnában, mint látjátok, forrong a hangulat.

JK1 (bajvívó) családi pecsétgyűrűjének országos jelentősége van.
JK1: A gyűrű jelenleg nincs a birtokomban…
JK2: Elkockáztad?