ugrás a tartalomhoz

Weblapok ergonómiája

Nagy Gusztáv · 2005. Már. 29. (K), 22.00
Weblapok ergonómiája
A Web-ergonómia (vagyis a gyakorlati használhatóság), mint fogalom Jakob Nielsen: Web-design című könyvén keresztül jutott el hozzám. Sok olyan szempontot olvastam benne, amelyet magam is fontosnak tartottam, voltak azonban olyanok, amelyekre rádöbbentem az olvasás folyamán. De leginkább annak örültem a könyv áttekintése után, hogy az ott leírtakra építhetek a további munkáimban, és mint a téma egyik vezető szakemberét, hivatkozási alapként idézhetem érvként. A saját rossz tapasztalataim indítottak arra, hogy készítsek egy felmérést arról, milyen a mai magyar weboldalak minősége az ergonómiai szempontok alapján. A továbbiakban ezen kutatásom eredményeit fogom bemutatni.

Ahol a terjedelem ezt lehetővé teszi, szeretném azt is bemutatni, hogy hogyan lehetne használhatóbb oldalakat készíteni. Természetesen ezek is csak lehetőségek, és nem feltétlenül a legjobbak.

A felmérés módszerei

A kitűzött minta (a továbbiakban Minta) a következő kategóriákból áll (a részletes lista a cikk végén található):

TípusDarabszám
Általános portálok7
Népszerű oldalak12
Üzleti cégek8
Magánszemélyek5
Honlap-fejlesztéssel foglalkozó cégek oldalai11
Egyetemek7
Főiskolák4
Középiskolák6


E kategóriákból 60 oldalt „véletlenszerűen” választottam ki. Egy ilyen méretű minta már alkalmas arra, hogy következtetéseket vonjak le, de a kategóriánkénti eloszlások értékeit csak nagyon óvatosan szabad értelmezni. Nagyon sokféle konkrét mérést lehet (és lett volna érdemes) megvizsgálni, de a feladat nagysága miatt csak néhány alapvető, viszonylag könnyen mérhető jellemzőt vizsgáltam meg. A mérés 1024×768–as felbontású monitoron, Internet Explorer 6.0 és Firefox használatával történt. Az első böngésző elterjedtsége, a másik pedig a szabványoknak való megfelelés igénye miatt fontos. Az oldalak szövegének vizsgálatához a Context 0.97.3-as verzióját és a Word „szavak száma” szolgáltatást használtam fel.

A vizsgálat eredményei

Megéri kivárni a letöltődést?

Fontos, hogy egy oldal letöltési ideje egy bizonyos lélektani határ alatt legyen, ameddig az olvasó még „türelmesen vár”. Nem mindegy tehát, hogy mekkora egy oldal, aminek a letöltését végig kell várni. Természetesen vannak olyan oldalak, amelyek „információtartalma” alapvetően nem szöveges, hanem pl. kép alapú. Ilyenkor a látogató sokszor inkább kivár.

A közhiedelemmel ellentétben a hosszú letöltési időt sok esetben nem várják meg a látogatók – még egy tetszetős megjelenésű oldal kedvéért sem. Pedig egyszerű módszerekkel kis méretű, mégis mutatós oldalakat lehet készíteni. Megjegyzem, még nagyobb tévedés, hogy a jó megjelenés el tudja adni a gyenge tartalmat.
Letöltési méret
A Minta átlagos oldalmérete 185 KB, ami modemes elérés esetén körülbelül fél perc alatt töltődik le. Nagyon jó tartalom kell ahhoz, hogy ennyit várjunk érte, hiszen a szakirodalom általában 0,1 és 1 másodperc közötti letöltési időt javasol, e fölött a látogató joggal türelmetlen.
Miért ilyen nagy?
Többek között azért, mert az oldalak méretének 74%-a nem szöveges, hanem egyéb (döntően kép) állomány. Bár nem cél a képek (és egyéb multimédia elemek) teljes elhagyása, fontos, hogy az oldalak formázásához minimális számú és méretű képet használjunk. Ügyes trükkökkel egy képet több helyen is felhasználhatunk egy oldal kinézetének kialakításában. Ilyenkor a kép természetesen csak egyszer töltődik le.
Szöveges tartalom
További érdekes tapasztalat, hogy a HTML forrásokban rengeteg olyan formázó elem és tulajdonság található, amely praktikusan kiváltható lenne a CSS jobb használatával, és a táblázatos oldalkialakítás feladásával. Könnyen belátható, hogy a táblázatok leírására szolgáló sok elem jelentősen csökkenti a HTML tényleges szövegtartalmát.

1KB HTML kódra mindössze 102 ténylegesen megjelenő betű jut, vagyis a „hatékonyság” 10,2%. Természetesen nem a 100% a cél, de az ember talán joggal várna el magasabb értéket.

TípusOldalméretHTMLKülső
CSS
Betű/HTML KB
Általános portálok280 kb119 kb7,4 kb76,0
Népszerű oldalak232 kb51 kb3,5 kb61,3
Üzleti cégek135 kb35 kb3,1 kb68,5
Magánszemélyek479 kb79 kb5,8 kb100,4
Honlap-fejlesztéssel foglalkozó cégek127 kb26 kb2,8 kb51,7
Egyetemek106 kb18 kb2,9 kb110,7
Főiskolák164 kb24 kb1,3 kb125,9
Középiskolák88 kb5.8 kb0 kb385,6
Összesítve185 kb45 kb3,4 kb102,4

A felhasználó irányít?

Jóval a Web születése előtt, a grafikus képernyők megjelenésének idején „kicsúszott” a programozó kezéből a felhasználó irányítása. Az interaktivitás eszméje felhatalmazza a felhasználót arra, hogy azt tegyen, amit akar, és úgy tegye, ahogy akarja - természetesen bizonyos keretek között, de az ésszerűség határain belül mindenképp. Sajnos a Weben ezt sokan ismét elfelejtik, és webfejlesztőként nem adják meg az olvasónak azt a szabadságot, ami talán joggal elvárható lenne.
Rögzített oldalszélesség
Az olvasók a PC-től kezdve kéziszámítógépekig és mobiltelefonokig különböző hardvereken sokféle képernyőmérettel olvassák a honlapokat. PC-n ma 640 x 480-tól akár 1600 x 1200-ig terjedhetnek a használt felbontások. Ha ezt egy webfejlesztő nem veszi figyelembe, akkor sok felhasználót jó eséllyel kizárhat a látogatói közül. Tekintve, hogy általában pont a látogatók csalogatása és megtartása a cél, szerintem minden webfejlesztő számára megfontolandó a rugalmas oldalszélességre való tervezés. Nem nehéz elképzelni, hogy milyen könnyen továbbáll a felhasználó, ha problémái vannak az oldal megjelenésével.

Példaként nézzük meg, hogy hogyan használható a startlap.com 640 és 1024 pixeles szélességen (a tervezők 690 pixelre tervezték a megjelenítést).

Startlap 640 képpontos szélességen

Jól látható, hogy kisebb felbontásban megjelent a vízszintes görgetősáv, így sokszor szükség lehet a vízszintes görgetés használatára, ami a weben szokatlan.

Startlap 1024 képpontos szélességen

Nagyobb felbontás esetén kihasználatlan helyeink vannak a képernyőn. Én úgy gondolom, senki nem azért vesz nagyobb felbontású monitort, hogy egy weboldal látogatásakor üres, indokolatlanul kihasználatlan csíkok legyenek a képernyőjén. Hiszen pont azért nagy a felbontás, hogy több információ jelenhessen meg rajta egyszerre.

Nézzünk egy példát alkalmazkodó oldalszélességű oldalra 480 és 1024 pixelen megnézve:

Alkalmazkodó oldal 480 képpont szélességen

480 pixelen még kényelmesen olvasható, nincs szükség vízszintes görgetésre.

Alkalmazkodó oldal 1024 képpont szélességen

Nagy felbontáson problémaként esetleg azt lehetne ellenérvként felhozni, hogy a túl hosszú sorok nehezen olvashatók lehetnek. Véleményem szerint ez jóval kisebb probléma, mint az üres sávok kétoldalt fix szélesség esetén, ugyanis ha zavaró a hosszú sor, a látogatónak bármikor van lehetősége az ablakméretet csökkenteni, vagy esetleg eleve nagyobb betűmérettel szeret olvasni, amikor a hosszú sor ismét nem fog problémát jelenteni. De ha a kis méret miatt görgetnie kellene, nem tudja nagyítani a képernyőjét.

Természetesen bizonyos esetekben indokolt lehet a rögzített oldalszélesség, de ez véleményem szerint túl sokszor csak azért fix, hogy könnyebben megvalósítható legyen, illetve a webhely megjelenése ezt „követeli meg”. Itt még egy indokot szeretnék említeni, ami miatt szerintem ez legtöbbször nem célravezető. Jó néhány oldallal találkoztam, ahol a precízen belőtt oldalkialakítás teljesen szétesett, ahogy a nehezen olvasható betűméretet nagyobbra állítottam.

A Minta 70%-a rögzített szélességben jelenik meg. A fix szélességű oldalak nagy része 800x600-as képernyőfelbontásra tervez. Nézzünk egy diagramot a pontos adatokról (a teljes hosszúságú vonalak az alkalmazkodó felépítésű oldalakat jelentik):

Weboldal szélességek

Hosszú oldalak
A weben olvasó nem tolerálja a hosszú oldalakat, ennek ellenére az áltagos oldalmagasság (1024×768–as felbontáson és Mozilla 1.7-en mérve) 1555 képpont. Az olvasók többnyire nem olvasnak végig egy ilyen hosszú oldalt.

A teljesség kedvéért megjegyzem, hogy egy adott oldalméret mást-mást jelent különböző célú oldalaknál, pl. egy olyan tartalomjegyzék vagy fórum jellegű oldalnál, ahol az oldal tetején jelennek meg a legújabb információk, ennek a méretnek nem feltétlenül van hátránya. Ennek érdekében az egyes oldalakat témák szerint lenne érdemes kategorizálni, és így pontosítani az itteni eredményeket. Talán még annyit a számok érvényességéről, hogy a honlapoknál a kezdőlapot vizsgáltam, ahol fórumok egyáltalán nem szoktat előfordulni, a tartalomjegyzékek pedig általában csak az időben utolsó néhány információt jelenítik meg.
Rögzített méretű szöveg
A felhasználó sokféle környezetben olvashatja egy oldal tartalmát, és nem feltétlen felel meg számára az a betűméret, amelyet a fejlesztő határozott meg, hiszen a fejlesztő monitora, szeme érzékenysége, ízlése nem feltétlen fog megegyezni a látogatókéval. A böngészők adnak ugyan lehetőséget arra, hogy az oldalt kicsinyítve-nagyítva jelenítsük meg, de ha szövegeket (menüpontokat, címeket) képpel ábrázolunk, akkor ez a szabadság elveszett, illetve az Internet Explorer a rögzített betűmérettel megadott szövegek átméretezéséres sem képes.

A megoldás az, hogy lehetőleg ne képpontban megadott méretű, hanem relatív mértékeket adjunk meg a szövegek esetén. Másrészt a szöveges információt (a logó kivételével) lehetőleg sose képpel jelenítsünk meg. A CSS nagyon jó lehetőségeket nyújt arra, hogy kép-szerű feliratokat szövegesen valósítsunk meg. Nézzünk erre is példát az ilovejackdaniels.com webhelyről:

CSS segítségével formázott kép hatású menü

Eredeti beállításokkal vizsgálva nem is könnyű felismerni, hogy képpel, vagy szöveggel vannak-e megvalósítva a menüpontok. Firefox alatt két fokozattal nagyobb betűméreten megfigyelhető, hogy csak a jobboldali címek vannak képpel megvalósítva, az oldal többi részén minden szöveg mérete megváltozott. Ami ennek az oldalnak az egyik szépsége: a középső piros sor kivételével az oldalkialakítás ugyanúgy élvezhető, nem esett szét a betűméret változatásától.

CSS segítségével formázott kép hatású menü, nagyobb méretben

A Minta 68%-ában a tartalom, és 88%-ában a címek nem voltak átméretezhetőek Internet Explorerrel. A Mozilla és Firefox böngészők – épp a felhasználó érdekében – az ilyen szövegeket is átméretezik.
Keretek
A keretek csábítanak arra, hogy a reklámcsíkot vagy a menüsort az oldal valamelyik szélén rögzített pozícióban tartsuk. Van azonban jó néhány probléma ezzel:
  1. A menüt tartalmazó keret görgetősávját ki szokás kapcsolni esztétikai okokból. Ha egy adott méreten ez a szöveg kilóg a neki szánt helyből, nem lehet begörgetni a kilógó részt - illetve csak különböző, nem széles körben ismert trükkökkel.
  2. A webcím nem ír le egy állapotot, nem tud leírni kereteket, így nem lehet egyszerűen címezni egy oldalt. Ez például linkeknél vagy könyvjelzőknél okoz problémát.
  3. Nem lehet tudni a képernyőfelbontást, így lehet, hogy egy kézi számítógépen vagy mobilon csak egy rögzített méretűre tervezett keret részlete látszik, a tényleges tartalomból semmi, vagy szinte semmi.
  4. Keretes oldalak kinyomtatása is nagyon problémás.
Megjegyzendő, hogy CSS segítségével az adott hátrányok nélkül is el lehet érni ilyen rögzített formázásokat. Nézzünk egy példát elrettentésül. A slaveland.hu oldal baloldalt a logó miatt, felül pedig a menü miatt keretet használ. Átlagos felbontás esetén nincs is gond:

Keretek átlagos felbontások

350 képpont szélességnél az oldal teljesen használhatatlan: a bal és felső keret a felület háromnegyedét elfoglalja, a maradék negyed területen pedig még a görgetősávok is megjelentek:

Keretek kis felbontásban

A Minta oldalak negyede használ kereteket, bár a nagy portálok közül egy sem.
Sok olyan weboldal, amely megengedte a választást a keretes illetve a frame nélküli változat között, úgy találta, hogy a felhasználók jobban kedvelik a keret nélküli megjelenítést. (Jakob Nielsen: Web-design)

Következtetések

A vizsgált minta alapján kimutatható, hogy a mai magyar weboldalak fejlesztői alapvető ergonómiai szempontokat is mellőznek. Látszik, hogy a probléma szemléletbeli, amin átfogó „felvilágosító” munkával lehet csak változtatni. A mai magyar helyzetet tekintve szélmalomharcnak tűnhet az ergonómikus web kialakítás hirdetése, de vannak, akik komolyan felvállalják ezt a küzdelmet. Én is ezek közé tartozom.

Irodalomjegyzék

  1. Jakob Nielsen: Web-design Typotex Elektronikus Kiadó, 2002 (második kiadás)
  2. HTMLInfo v2.0 – online agytáp webmestereknek és műkedvelőknek
    http://htmlinfo.polyhistor.hu
  3. Sindelyes András:Webdesign alapok III.
    Használhatóság = le a képekkel!
    http://www.prszichologia.hu/cikk/cikk.phtml?id=40
  4. Web Style Guide
    http://www.webstyleguide.com
  5. George Murray, Tania Costanzo:
    Usability and the Web: An Overview
    http://www.collectionscanada.ca/9/1/p1-260-e.html
  6. Constance J. Peterson:
    Writing for a Web Audience
    http://www.smartisans.com/articles/web_writing.aspx
  7. Carole Goble:
    The Semantic Web: an evolution for a revolution
    http://www.elsevier.com/locale/comnet
  8. Yiyu Yao:
    Web Intelligence: exploring structures, semantics, and knowledge of the Web
    http://www.elsevier.com/locale/knosys
  9. World Wide Web Consortium (W3C)
    http://www.w3.org
  10. W3C Magyar Iroda
    http://w3c.hu

Melléklet

Általános portálok
Startlaphttp://www.startlap.com/
lap.huhttp://www.lap.hu/
Origohttp://origo.hu/
Indexhttp://index.hu/
Porthttp://port.hu/
Stophttp://www.stop.hu/
TÁRhttp://www.tar.hu/


Népszerű oldalak vegyesen (top100.hu alapján)
CoffeCuphttp://www.coffeecup.hu/
AdverSitehttp://www.adversite.hu/
Vicclaphttp://vicclap.hu/
Csajozáshttp://www.csajozas.hu/
Ingatlan.comhttp://www.ingatlan.com/
SlaveLandhttp://sl.e98.hu/
lol.huhttp://lol.hu/
duen.huhttp://www.duen.hu/
KarrierExpresszhttp://www.karrier.expressz.hu/
Gumicsizmahttp://www.gumicsizma.hu/
Térképcentrumhttp://www.terkepcentrum.hu/
Net-Cafehttp://www.net-cafe.hu/


Üzleti webhelyek
G-Neohttp://www.ngeo.hu/
Geomontanhttp://www.geomontan.axelero.net/
DigiTerra Informatikai Szolgáltató Kft.http://www.digiterra.hu/
Microsoft Fejlesztői Portálhttp://www.developer.hu/
Szoftverműhelyhttp://www.szoftvermuhely.hu/
MaxInfohttp://www.maxin.hu/
D-Bridgehttp://www.dbridge.hu/
HWSWhttp://www.hwsw.hu/


Magánszemélyek
Matizhttp://www.tar.hu/matiz/
Magyar Charmed Portálhttp://bubajosboszorkak.hu/
Loogoshttp://www.loogoos.hu/
lacyhttp://www.lacy.hu/
ErikaStúdióhttp://erikastudio.uw.hu/


Honlap-fejlesztéssel foglalkozó cégek oldalai
Xubionhttp://www.xubion.hu/
GFX Grafikahttp://www.gfx.hu/
Webdoktorhttp://webdoktor.hu/
Neosofthttp://neosoft.hu/
Webrahttp://www.webra.hu/
Thomashttp://www.thomas98.hu/
Siwwwahttp://www.siwwwa.hu/
LebroNethttp://www.lebronet.hu/
CraftCorehttp://www.craftcore.hu/
Calcunhttp://www.calcun.hu/
Kirowskihttp://cms.kirowski.com/


Egyetemek
SZEhttp://www.sze.hu/
SZOTEhttp://www.szote.u-szeged.hu/
PTEhttp://www.pte.hu/
MEhttp://www.uni-miskolc.hu/
SZIEhttp://www.szie.hu/
SOTEhttp://www.sote.hu/
ELTEhttp://www.elte.hu/


Főiskolák
Szegedi Hittudományi Főiskolahttp://www.theol.u-szeged.hu/
Pünkösdi Teológiahttp://www.ptf.hu/
Juhász Gyulahttp://www.jgytf.u-szeged.hu/
Dunaújvárosi Főiskolahttp://www.poliod.hu/


Középiskolák
Kodályhttp://www.netlap.hu/kodaly/
Premontreihttp://www.prem.hu/
KISKépzőhttp://www.kiskepzo.sulinet.hu/
Eötvös József Gimnáziumhttp://www.ejg.hu/
Széchenyi Gimnáziumhttp://www.szechenyi-szeged.sulinet.hu/
Ferenczihttp://www.ferenczi.hu/
 
1

Észrevételeim

Dualon · 2005. Már. 29. (K), 23.58
Elöljáróban annyit szeretnék leszögezni, hogy ez a cikk is remekül átmegy a Weblaboros cikkek hagyományosan magas színvonalt megkövetelő rostáján. Szemléletformáló, tartalmas, tényekkel alátámasztott, egyszóval jó. Csak egy picit rövid. :)

A 640x480-ra optimalizálással nem kifejezetten értek egyet. Például egy háromhasábos elrendezésben a középső tartalmi terület könnyen annyira beszűkülhet, hogy az már nem csak az esztétikum, de a kényelem és használhatóság rovására is megy. Engem zavar az 1 szó/sor arány. :)
Természetesen ahol lehet, ott érdemes az általad vázoltak szerint eljárni, de az alsó határt inkább 800x600-nál húznám meg (illetve egészen lazán kezelném a 640x480-ra való optimalizálást); alatta az a tényleg kis számú felhasználó legvégső esetben úgy állítja be a vízszintes görgetősávot, hogy a tartalom legyen középen (pl. az említett háromsávos kiosztásnál).

A cikk témáját ugyan a Minta vizsgálatából levont következtetések jelentik, ugyanakkor szerintem belefért volna még néhány, a webes ergonómiával kapcsolatos, amúgy sarkallatos kérdés. Betűméretek és -típusok esetében mire érdemes figyelni, a színválasztás hogyan befolyásolja a látogatói kört, van-e, és ha van, milyen egy "szerencsés" oldalelrendezés, milyen irányelvek jöhetnek szóba a kényelmes navigációnál, az áttekinthető tartalmi, szerkezeti felépítésnél, és így tovább.

Némi szőrszálhasogatás:
- ha pontos tényeket közölsz egy cikkben, szerintem érdemes mindenhol ezt tenni, ahol teheted; a "Firefox", mint böngészőtípus és -verzió picit kevés az IE 6.0 megnevezés után. Ez elsőre talán semmiségnek tűnik, de szerintem az ilyen apróságok megléte nem csupán nekem jelenti a körültekintés és igényesség bizonyítékát.
- az egyik cím így szerepel: "Rödgzített oldalszélesség"

Mindezektől függetlenül a cikk tényleg jó, köszönet érte!
50

Felbontás opt

Anonymous · 2006. Nov. 10. (P), 13.37
A cikk igen jó.
A képernyő követő oldalszélesség mától halott. Pár éve még a 800 pix széles képernyő szinte nyeremény volt. CSS esetén is célszerű lenne az 1024 mint max esetleges megadása. A nyomtatott sajtóból kiindulva az A4 álló, max fekvő formátum követhető optikailag. Üdv
2

Végre

airwalker · 2005. Már. 30. (Sze), 00.20
Én is olvastam az általad említett könyvet, és mindenkinek tudom ajánlani. Már épp itt volt az ideje, hogy valaki a web-ergonómiával is foglalkozzon.
Egyébként szerintem, ha több ember elolvasná Jakob Nielsen könyvét nem lennénk mi sem ilyen kevesen.
airwalker
airwalker##kukac##freemail.hu
3

Kérdések

docker · 2005. Már. 30. (Sze), 01.02
A cikket tényleg érdmes átolvasni mindenkinek!
Egyet értek azzal, hogy teljesen illeszkedik a Weblabor színvonalához.

-Ami most következik az nem tejesen idevág, de remélem nem nagy gond, hogy ide írom:
Igazából most kezdenék átállni css-re, és a cikkben leírtaknak megfelelően. Nem tudom, hogy egyedül vagyok-e ezzel, de az a gondom, hogy az alapokkal már megismerkedtem, de igazából itt már komolyabb dolgok hangzottak el: táblázat és frame-k nélküli oldalak. Nézegettem már idevágó dolgokat, de nem találkoztam jó cikkel, vagy segédlettelé ebben a témában.
A kérdésem az, hogy szakirodalom megvétele nélkül el tudnám-e sajátítani ezen dolgokat, vagy ha kell milyen könyvet javasoltok? (Nem css guru akarok én lenni csak szeretném ha az általam készített oldalak megfelelnének az elvárásoknak)
Remélem mások nevében is tudtam szólni...
Elöre is köszönöm a segítséget.
docker##kukac##mailbox.hu
4

CSS tanuláshoz

Nagy Gusztáv · 2005. Már. 30. (Sze), 08.52
Először is egy nagyon jó indulási oldal a http://css.lap.hu, nagyonsok a témával foglalkozó oldalt gyűjtöttek itt össze.
A teljesség igénye nélkül:

http://www.456bereastreet.com/lab/cssframes/
http://www.hotdesign.com/seybold/

Konkrét kérdés esetén talán konkrétabbat tudnék ajánlani. :)

Nagy Gusztáv
tanszéki mérnök
Kecskeméti Főiskola GAMF Kar
Informatika Tanszék
23

CSS szakirodalom és társai

Anonymous · 2005. Már. 31. (Cs), 21.59
http://www.w3schools.com/
Nagyon ajánlom az oldalt és nem csak CSS témában. Összeszedett, példákkal jól alátámasztott, tartalmaz minden szükséges információt.
5

És ki csinálja?

prezi · 2005. Már. 30. (Sze), 10.09
Tetszett a cikk, és valójában csak az lenne a kérdésem, h szerintetek kinek a feladata jól használhatóvát tenni az oldalt? A dizajneré? Ő csak egy képet ad át, h így kéne kinéznie az oldalnak. A programozónak? Ő elvileg csak a html kódrészletekbe illeszti a programjának a kimenetelét.

Létezik manapság olyan "szakma", hogy HTML szerkesztő?

ps: azért írtam a programozónál, h "elvileg" mert én azt látom, h valóságban ő csinálja, aztán lesz amilyen lesz. Az oldal dizájnjával a végén meg csak köszönö viszonyban van.
6

html szakma

Anonymous · 2005. Már. 30. (Sze), 10.44
Ergonómiával a site tervezője, a megrendelő és a designer foglalkozik.
Egy nagyobb (nem egyszemélyes) vállalkozás esetén a feladatokat az alábbiak szerint érdemes felosztani:
- designer (ő képeket készít)
- sitebuilder (html templatek-et, css-t készít, majd a kódba vágja ezeket)
- fejlesztő mérnök (a func. specifikáció alapján kialakítja a működést)
A fenti felsorolásban nem szerepel a tervező, illetve a tesztelő.

A "HTML szakma" szerintem a sitebuilderi feladatkör.
A funkcionalitás kialakítása akkor kezdődik meg, amikor a funkcionális specifikáció, illetve a designtervek elkészültek és az ügyfél elfogadta. Ez biztosítja azt, hogy a design-nal összhangban marad a működő site.
Balázs
7

Köszi, de a kérdés

prezi · 2005. Már. 30. (Sze), 12.19
Köszi, de a kérdés valójában arra vonatkozott, h valaki látott-e már olyan embert, akinek ez volt a feladata...
9

látott

Anonymous · 2005. Már. 30. (Sze), 13.11
Kicsit eltértünk a cikk témájától, de én nap mint nap látok ilyen lényeket. :)
Azt hittem ez érződik a válaszomban.

B
11

Ergonómia

Bártházi András · 2005. Már. 30. (Sze), 13.32
Az ergonómia kialakítása egy külön szerep. A HTML szerkesztőnek egyáltalán nem feladata az ergonómiával foglalkoznia, "csak" a megkapott tervek alapján elkészítenie az oldalt. Az ergonómikus weboldalt a megrendelő cégének megismerésével, a tervezett látogatókra való tervezéssel, s általános szempontok alapján lehet elkészíteni. Az oldal megjelenésének ehhez az elképzeléshez illenie kell, tehát a designer szempontjai (csili-vili) nem lehet erősebb, mint az ergonómia, de ez nem feltétlenül köti meg a jó designer kezét.

Egy ergonómikus szék tervezésekor kinek a feladata foglalkozni az ergonómiával? Talán a designernek kell, hogy legyenek ilyen ismeretei, talán konzultál egy szakemberrel.

-boogie-
15

Én pl a grafikusommal

Fekete Ferenc GDA · 2005. Már. 30. (Sze), 20.57
Én pl a grafikusommal közösen. Így még sosem volt problémánk.

ferenc voltam
8

Nagyon jó cikk, bár 1-2

an-dee · 2005. Már. 30. (Sze), 12.28
Nagyon jó cikk, bár 1-2 konkrétumot hiányolok belőle.

Azért van egy nagy próbléma ezzel az ergonómiával, mégpedig a megrendelő :)
Szerintem 2 fajta "webes" van, az egyik aki AZT csinálja amit kérnek, a MÁSIK meg az eszével gondolkodik és megpróbálja kicsit irányítani a megrendelőt.

Ti csinálnátok olyan oldalt ami se a szabványoknak se az ergonóminák semmilyen fokon nem felel meg, csak azért mert a megrendelő igy akarja? Én nem, de sokan igen, és amig ez nézett van inkább terjedőben addig a többieknek nehéz.

A fix széleségről annyit, hogy nekem - de gondolom másiknak is - nagyon nehéz a megrendelőből kihámozni a tartalmat, vagy ha van is az is kevés, így elég furán nézne ki egy 200 szóból álló szöveg egy 1280*1024-es képernyőn, ahol a menü 6 sor a tartalom meg 2.
10

Megrendelő

Bártházi András · 2005. Már. 30. (Sze), 13.27
A megrendelő nem könnyű eset, de hát ez a szép benne. Sajnos nem sajnos, nem minden megrendelőt lehet rábeszélni, hogy ne a saját gondolatai szerint, hanem az általánosabb ergonómiai irányelveket figyelembe véve legyen kialakítva az oldal. Amivel meg lehet őket győzni, az az, hogy egy használhatóbb oldallal több látogató lesz, szívesebben vannak ott, így várhatóan az oldal célja is jobban megvalósul. Lehet egy kicsit csúsztatni, s a keresőoptimalizálásról is beszélni neki - van közös terület -, ez szintén látogatókat jelent számára.

-boogie-
48

IMHO

balu ertl · 2005. Május. 8. (V), 17.54
Tanulságos cikk, hasznos és szemléletes felmérés. Nielsen "Bibilia"-ját magam is olvastam, valóban alapvető írás.

A gond azonban szerintem is ez lehet. Legyen az ember "4-in-1": HTML- és CSS-író (nem programozó, hisz' leírónyelvekről van szó), legyen grafikus, értsen az ergonómiához, és nem hátrány, ha önnönmaga a megrendelő is egyben, mivel ő ismeri magát, cégét, termékét a legjobban.
Ezzel a "legyél-minden" elvvel szemben áll az örök igazság: "Minél több funkciós egy készülék, annál kevésbé alkalmas az egyes feladataira".

balu.ertl
"A jó úttörő ott tud, ahol segít."
12

Ergonomia - mi is az?

mrbig · 2005. Már. 30. (Sze), 15.07
En csalodtam a cikkben. Az, hogy van akinek az itt leirtak ujat mondanak, az azt a sajnalatos tenyt bizonyitja, hogy ma meg mennyien nem ismerik az "uj" szabvanyokat. Ha vesszuk ugyanis a faradtsagot, hogy elolvassuk magunknak a w3c-s ajanlasokat, akkor a fent leirt problemak nagy reszerol mar hallottunk. Csak egy pelda, hogy honnan lehet hasonlo infokat beszerezni: http://www.w3.org/QA/Tips/ - az itt leirt tippek a w3c validator felett jelennek meg, ha sikerult ateroltetnunk az oldalunkat a validatoron.

Ugy erzem, elvarhato, hogy akik ma abbol probalnak megleni, hogy html oldalakat raknak ossze, azok ismerjek is ezen leiro nyelv aktualis szabalyait, filozofiajat.

Weblapok ergonomiaja
Visszaterve a temahoz, ime, mit is vartam volna ettol a cikktol:
Attekintest arrol, hogy milyen egy jol kezelheto, a felhasznalo szamara atlathato weboldal. Hogyan kell egy oldal elrendezest ugy kialakitani, hogy az a leginkabb celravezeto legyen.

Az, hogy egy oldal ergonomikus-e ugyanakkor nem itelheto meg annak tartalma nelkul. Konnyen belathato ugyanis, hogy nem ugyanugy kell kialakitani egy statikus informaciokat tartalmazo oldalt (pl.: bemutatkozo oldal, informacios portal), mint egy dinamikusat (webaruhaz, internetes bank, forum, stb).

Sajnalatos modon ugyanakkor ennek a temanak meg nincs igazan hasznalhato tudomanya, se szakirodalma. Volt alkalmam ugyan ilyesmit hallgatni az egyetemen, de a hozzaallas vagy tul tudomanyoskodo volt, es a gyakorlatban total hasznalhatatlan, vagy rendkivul feluletesen kezeltek a temat.

Sem szakmai hozzaertesem, sem ezen hozzaszolas keretei nem teszik lehetove szamomra, hogy errol a temarol ertekezzek. Csupan probaltam ramutatni arra, hogy szerintem mit is kellene reszletesebben koruljarni.

Reagalasaim a cikk tartalmara
Par velemenyem meg maradt azzal kapcsolatban is, ami a cikkben szerepel :)

Letoltesi meret:
Egyetertek azzal, hogy az oldalainkat probaljuk minel kissebbre irni, de hibas feltetelezes a cikkben az, hogy az idealis letoltesi ido 0,1-1 masodperc. Ez az ido jelenleg csak szelessavu kapcsolat eseten elvarhato, a modemes felhasznalok altalaban tisztaban vannak kapcsolatuk hatulutoivel, es tovabb varnak. Az 56K-s modem eseteben 1 masodperc alatt (az overheadet nem szamitva) max 7kbyte toltheto le, ebbe a meretbe nem sok tartalom fer el.

Rogzitett oldalszelesseg, rogzitett betumeret:
Ez a ket dolog viszonylag osszetartozik: aki rogzitett oldalszelesseggel dolgozik, az altalaban kenytelen a betumeretet is rogziteni.
A cikk elfelejti szetvalasztani az ergonomia, es az altalanos hasznalhatosag kerdeset. Ez a ket feltetel ugyanis egymasnak ellent mond. Mobil telefonon, PDA-n eleve nem tul ergonomikus dokumentumokat olvasni.
Ha tehat kifejezetten az ergonomiat tartjuk szem elott, akkor szerintem a fix oldalszelesseg alkalmazando. Aki probalta mar, az tudja, hogy sokkal kellemesebb weblapokat allo ablakban (pl kb 900x1020px) nezni, mint fekvoben. Az igy kapott kep sokkal kozelebb all a megszokott, papir alapu oldalelrendezeshez (ujsag, konyv). Egy sorba nem jo tul sok szoveget irni, mert akkor az olvaso konnyen elveszti, hogy hol jart. Az ajanlott oldal szelessegrol mar sok tanulmany talalhato.

A fix oldalszelessegnek nem kell azonban teljesen fixnek lennie. Elkeszithetjuk fix szelessegu oldalainkat ugy is, hogy a dobozok szelesseget/magassagat nem pixelben, hanem a betumeret aranyaban adjuk meg (em). Ebben az esetben az oldalunk elmeletileg a betumerettel egyutt skalazodik. Sajnos a szabvanyok hianyos tamogatasa miatt valoszinuleg lehetetlenseg igy bongeszo kompatibilis oldalt kesziteni. :(

Ha fontos, hogy mobil eszkozokon is megtekintheto legyen az oldalunk, akkor inkabb keszitsunk tobb css-t, amik kozott a felhasznalo valthat.

Keretek (frame-ek)
Felejtsuk el oket. Se a HTML4.01 Strict-nek marpedig a cel az, hogy elobb-utobb erre a szabvanyra alljunk at.
Leggyakoribb hasznalatait ez a szabvany a kovetkezo modokon potolja:
- Az oldalon rogzitett informacio elhelyezese (tipikusan menu): hasznaljuk helyette a "position: fixed" css attributumot - tudom, az explorer ezt meg nem tamogatja. Attol meg hasznalhatjuk, legfeljebb a menu exploreren a dokumentumhoz rogzul, es nem a kepernyohoz
- Kulso tartalmak behuzasa az oldalba: kivalthato az <OBJECT> tag-gel

Vegezetul
Egyetertek a cikkiroval abban, hogy atfogo szemleletvaltasra van szukseg. Ertekelem azt a munkajat is, ami soran a magyar oldalakat megvizsgalta, es a statisztikakat osszeallitotta. Remelem, hogy cikke egy komolyabb parbeszed meginditoja lehet.

Sok sikert kivanok!
13

A cikktől személy szerint

Tome · 2005. Már. 30. (Sze), 16.16
A cikktől személy szerint én is "többet" vártam. Több új tippet, több új tanulnivalót.
A bevezető elolvasása után arra számítottam, hogy majd előjönnek a "nagy" oldalak/portálok hibái (http://www.hszk.bme.hu/~hj130/css/list_menu/index.html), és ezekre egy-két ötletes megoldás. Sajnos nagy oldalak alig (egyátalán nem?) kerültek szóba a cikkben.
Másik. Ez az 0,1-1 mp oldalletöltődési idő szerintem is inkább álom, mint elérhető valóság (Leginkább az IE szabványtámogatásához tudnám hasonlítani!). Elvégre még csak most kezd fejlődni valamennyire a számítástechnikai infrastruktúra Magyarországon.

Talán azért lehet csalódni ebben a cikkben, ahogy mrbig is írta, mert (a hozzászólásokban én így érzékelem) a Weblabort sokkal több középhaladó illetve ennél profibb webfejlesztő látogatja, mint kezdő, így nem sok újdonságot hordoz számokra. Ennek ellenére mindenképp dícséret illeti a szerzőt, mivel még nem sok ilyen cikk jelent meg magyar nyelven.

Ui.:Lesz folytatás?;)
17

középhaladók és mégsem

Hojtsy Gábor · 2005. Már. 30. (Sze), 22.07
Én inkább azt mondanám, hogy jellemzően a nagyon kezdők és a középhaladók (illetve ennél profibb) webfejlesztők szólnak hozzá, azaz ők látszanak. Mint szinte minden webes közösségben, itt is nagy számban vannak jelen a megfigyelők, akik csak befogadnak... Az, hogy nekik mennyire tetszett a cikk, arról sajnos nem tudunk semmit, de sok szemhez eljut, nem csak a látható aktív olvasótáborhoz!
22

Szinte gondoltam, hogy ez a

Tome · 2005. Már. 31. (Cs), 16.12
Szinte gondoltam, hogy ez a meglátámsom nem (teljesen) felel meg a valóságnak. ;)

Erről jut eszembe! Nem terveztétek a Weblaboron a cikkeknél minősítés (rating) bevezetését? Szerintem jó lenne, de csak 1-5-ig, a 10-esbe már nehéz belőni, hogy pontosan 6 vagy 7 pontot érdemel az adott cikk!
14

ez igen!

warchief · 2005. Már. 30. (Sze), 16.47
"1KB HTML kódra mindössze 102 ténylegesen megjelenő betű jut, vagyis a „hatékonyság” 10,2%. Természetesen nem a 100% a cél, de az ember talán joggal várna el magasabb értéket.
ez eddig az év egyik legjobb és legfontosabb cikke. szerintem.
külön köszönet, ugyanis nagy lökést adott a szakdolgozatomhoz!

viszont:
ez a 0,1-1 másodperc tényleg eléggé sántít, pláne hogy:

- az ember szeret multitaszkolni, és ez gyakran a hálozati kapcsolat megosztását (akár két gép, akár több program (p2p, streming media)) is magában foglalja
- ez elérés egy jó átlagos kapcsolat (saját tapasztalat) esetén is függ a napszaktól: du. 4-től, 5-től akár 30 százalékot gyorsul az internetelérésem - kivéve nyáron, amikor egész nap hasít a kábelnet
- én egy seo fórumon 3-4 másodpercet olvastam (most újra elolvastam, itt volt.), az jóval élményközelibb
16

Közönség

Anonymous · 2005. Már. 30. (Sze), 21.34
Sok-sok minden elhangzott ebben a témakörben egy két szám és talán valós vagy annak tűnő adat. A fent említett könyvet kicsit úgy kell olvasni, hogy már nem mai gyerek és azóta vannak új adatok és csapásirány. Gondolok én az egyre gyorsabb sávszélességre és a képernyők méretének növekedésére az oldalak egyre specifikusabbak. Tehát amiről beszélünk az a nagy átlag mindennapos böngészés alá eső oldalak.

Sajnos be kell vallani akármennyire nem szeretnénk is, hogy így legyen de a böngészők igen nagy többsége Internet Explorert használ általában min. 1024-es felbontást használva. Egy általam üzemeltetett statiszitka oldal ~2003 óta mér oldalakat és az ottani adatok alapján az IE ~90%-ot tud magának az operációs rendszerek terén pedig közel ugyanennyi a Windows. A febontásnál 50% felett vn az 1024 pixel széles képernyőfelbontás használta.
Egy oldalt belőni úgy, hogy minden felbontáson elfogadható képet adjon 1 féle képpen lehet mégpedig úgy, hogy szinte alig van tartalma tehát nagyon laza felépítésű, így a sok üres hellyel lehet játszani. Ezt a helyet azonban mindenféle értelmetlen (de a webet kétségkívül meghatározó) reklámokkal tömik tele. Így az oldal elég nagy része fölösleges az értékes információért kutatónak és egy-egy letöltés alkalmával sokkal kevesebb haszos információt kap.
A másik, hogy aki nagy monitort vesz az szeretné ki is használni (azt hiszem ez is benne volt a könyvben) és nem hunyorogni az ici pici oldalon középen egy csíkban vagy állandóan kapcsolgatja a felbontást.

Régebben volt szokás az oldalt kitenni 640x480, 800x600 és a fölötti felbontásra optimalizálva csak kérdezem me kinek van erre ideje megcsinálni, már külön programot használnak csak hogy azt a több száz vagy ezer oldat kezeljék és ha még ebből 3x ennyi lenne....
Ehhez hasonló az trend, hogy flash és a nélküli oldalakat készítenek, hogy ez által is "mindekihez szóljanak".

Végül még annyit, hogy úgy ahogy a wapos telefonok miatt külön oldalakat készítettek erre a célre úgy ha megrendelő azt kéri akkor el kell készíteni a kivonatolt verziót pda-ra vagy egyébb kis képernyős kliensre. Nem tudom ki hgy van vele, de én pl. ilyenkor nem szívesen töltenék le reklámokat csakis a szöveges tartalmat amire gyorsan szükségem van.

Lehtne még ragozni pro és kontra a dolgokat, de még annyit, hogy TD vs. CSS amire mindeki azt mondja manapság, hogy CSS hmmm.... hát a webaboron is volt nem egy megjelenítési probléma és maga a CSS jó lenne, de egyre csak bonyolódik, mindig csak hozzátesznek és szerintem ebbe fog belefulladni.
Meg kell találni az aranyközéputat.
18

td vs. css

warchief · 2005. Már. 31. (Cs), 00.01
szerintem a td versus CSS dolog teljesen lefutott.
minden friss technológiának vannak gyermekbetegségei - biztos emlékszel még te is a flash felfutására: mindenhol örökké tartó intrók és "skip intro"-linkek; buta animációk -; de amint a törő arcok más után néznek, vagy - mint én - megpróbálják megtanulni (vagy megtanulják) a használatukat, és akkor nagyszerű dolgok születnek. a flash azóta egy nagyszerű kreatív eszközzé vált: kisalkalmazások százai készültek ebben a programban (vagy ezen a platformon - melyik a helyes?), és a flashnek köszönhetjük a modern tipográfia érkezését a webre.
asszem angelday (http://plastik.hu) írta a blogján egyszer, hogy ő és a hozzá hasonló öreg szakik, akik évekig csináltak spacergifes, táblázatos oldalakat, már nem tudják megtanulni az új módszereket.
és voilá: az oldalak, amelyek sokáig kitartottak a táblázatok mellett, szépen lépésenként állnak át css-layoutra, mert rájöttek, a hosszútávú előnyök sokkal kecsegtetőbbek, mint a pillanatnyiak:
centralizált design - így könnyebb áttervezés -, tisztább forráskód - több keresőtalálat -, kisebb méret - kisebb sávszélesség és gyorsabb letöltés - és hozzáférhető oldalak - új közönség.
ilyen egyszerű az egész.
19

Csak még egy gondolat a

airwalker · 2005. Már. 31. (Cs), 01.16
Csak még egy gondolat a cikkhez:
A fent említett könyv talán legnagyobb tanulsága (számomra legalábbis),az h arra próbál ösztönözni, h a felhasználók szemével nézd a weboldalakat. Ehhez pedig többet kéne azzal foglalkozni, hogy hogyan viselkednek a felhasználók netezés közben. Persze lehet, h ez már inkább a pszihológia témakörébe tartozik.
Végül itt van két oldal, ahol rengeteg érdekes dolgot lehet olvasni (főleg angolul), ha valakit érdekel a téma:
www.hasznalhatosag.lap.hu
www.ergonomia.lap.hu
airwalker
airwalker##kukac##freemail.hu
20

1 second

gerzson · 2005. Már. 31. (Cs), 02.24
hiszen a szakirodalom általában 0,1 és 1 másodperc közötti letöltési időt javasol,
Nielsen ezt a korlátot egyszerűen az ember interakció-érzetére alapozva állapítja meg.

Minél rövidebb a válaszidő, annál folyamatosabbnak érzi a felhasználó az oldallal való kapcsolattartást, nem csökken a felhasználói élmény, szívesebben marad. Minél többet kell várnia, annál kevésbé szívesen marad.

Az, hogy az ember menetközben multitaskol, igaz, de én pl. munka közben minél hamarabb végezni szeretnék, és néha kényszerből végzek pótcselekvést, amíg a letöltésre várok - napközben műholdas kapcsolaton.
21

0,1 - 1 másodperc

Bártházi András · 2005. Már. 31. (Cs), 07.31
Én nem gondolom ezt az időt elérhetetlen álomnak. Például a Firefox.hu is simán hozza ezt (talán még egy lassabb kapcsolaton is a képek, CSS becachelése után).

-boogie-
24

Ergonómia - mi is az valójában

Slac · 2005. Már. 31. (Cs), 22.35
Az ergonómia egy speciális tudományága a szoftverergonómia, amely a weblapokra is érvényes irányelveket ad. Ezek egy része megfogalmazható valóban ilyen műszaki, mértékegységekre fordítható formában, ugyanakkor jórészt az ízlés is befolyásolja. A böngészők felhasználói a szoftverergonómiában jól ismert "explorációs tanulás" módszerével közelítenek egy-egy weblaphoz, azaz megpróbálják felfedezni és a korábbi tapasztalataik alapján értelmezni.

Ez a cikk sok mindent tartalmaz, ám magát az ergonómiát - úgy érzem - csak felületén érinti. Mivel a felhasználók az előző tapasztalataikra támaszkodnak, célszerű olyan lapokat készíteni, amelyek felhasználják a webbel kapcsolatban kialakult kognitív sémákat, azokat az íratlan szabályokat, amelyek alapján a legtöbb lap felépül. (Csak egy példa: kattintottatok-e már olyan szövegre, amely a megtévesztésig hasonlított egy linkre? Láttatok-e már olyan felhasználót, aki nem talált meg egy funkciót, csak azért, mert az - a tervező szerint kiemelve - a többi navigációs eszköztől távol volt? Hmmm... Ez kettő volt.)

Az ergonómia sokrétű. Foglalkozhatunk azzal, hogy egy lapon mekkora a hasznos információk aránya a navigációs és reklámfelületekhez képest. Ugyanakkor ezt csak a lap által strukturált információk ismeretében tehetjük meg pontosan és egzakt módon. Ebben a mondatban a "strukturált" is hangsúlyos volt. A HTML lényege a hipertext - kapcsolat mindenek között. Hogyan gondolkodik egy felhasználó? Milyen sémák szerint keres? Mit keres egy adott lapon? Gondoltunk-e azokra a felhasználókra, akik a képekkel nem képesek mit kezdeni? Speciális felhasználókra? A nagyikra, akik nem tudnak már olyan jól bánni az egérrel? A nagypapira, aki csak az unokájának szeretne egy mesét keresni? A vakokra, akik csak hallják a lapjainkat? A rosszul látókra, akik csak a nagybetűkkel boldogulnak? A kisgyermekekre, akik játéknak tekintik az egészet, és semmi perc alatt romba dönthetnek egy rosszul felépített rendszert?

Ezek csak költői kérdések, mert persze nem gondolhatunk mindenkire. De vajon, amikor egy csilivili, parasztvakítós, it izgő, ott mozgó oldalt előállítunk, gondolunk-e arra, hogy mi a Web (így nagybetűvel) lényege? Hogy az egész az információ megosztásáról szól? Amikor egy üzlet fotói semmitmondóak, hisz ha érdekel, bemegyek, de a nyitvatartás és tán a cím sincs fenn a honlapon. Amikor a struktúra átgondolatlan. Nézzétek meg például a Libri online könyvesboltját. Próbáljatok meg bejelentkezni, mint regisztrát felhasználó. Fontos funkció? Igen. Mégis el van dugva a nyolcadik oldal legaljára. Pedig amúgy király a lap. Mégis használhatatlan. Nem csak a szélességen múlik. Láttál már olyan lapot, ahol a piros háttéren fekete szöveg van? Kifolyik a szemed egy mondat után. Pedig van ott még tíz másik.

Véget vetek a példálózásnak és röviden megpróbálok néhány komoly észrevételt tenni.
A szellemi kapacitás (nem az IQ és társai :)) ) vizsgálatánál péládul kiderült egy számunkra nagyon fontos ökölszabály: Miller-féle 7+/-2 szabálynak hívják. Az ember rövidtávú emlékezete képtelen 7+/-2 dolognál többet megjegyezni. Akkor miért rakunk egy oldalra 22 főmenüt? (Példa: a planetárium honlapja) Legyen 5 (max 7), amiben mindent el kell tudnunk helyezni. Logikusan.
A honlapok designja nagyban számít. A színeknek jelentése van, a szövegek kinézetének szintúgy. Nézzétek meg az IBM honlapját, szerintem navigációs szempontból az egyik legjobban felépített.
Nehézség még az Internet időtlensége. Bármi, ami felkerült, elvileg bármeddig fennmarad. Hogyan találhatok meg egy számomra érdekes cikket, amikor már csak pár szóra, egy gondolatra emlékszem belőle. Ez kicsit elvihet a mesterséges intelligencia, a kontextuselemzés felé.
És most már van a speciális felhasználókra is Guideline, amely szerint terveznünk kell(ene): http://bobby.watchfire.com . De legalább azoknak a vacak képeknek adjuk értelmes altot, hogy ha nem elérhetők, véletlenül letöröltük, legalább lehessen tudni, mi volt ott.
És a legeslegfontosabb: Szakadj el attól, hogy programozó/designer/szakavatott amatőr vagy. Légy felhasználó. Egyszerű felhasználó, aki azon bosszankodik, hogy nem tudja megnézni, mennyibe kerül egy telefon, egy fogkrém, aki nem tudja megnézni, meddig rendel a szakorvosa.

Hát ennyi. Persze még megtölthetnénk oldalakat, de félek, már így is sikerült. :) Majd legközelebb.

Üdv mindenkinek!
25

Ezt öröm volt olvasni...

Dualon · 2005. Már. 31. (Cs), 23.06
Folyamatosan azt mondogattam magamban: "egyetértek", "igaza van", és így tovább.
A jó ízlés és a józan megfontolás szerintem is alapvető fontosságú, de van, hogy az ember nem gondol mindenre - úgyhogy kedvet csináltál pár, a (szoftver)ergonómiával foglalkozó könyv elolvasásához. :)
26

Nézelődni érdemes...

Dualon · 2005. Már. 31. (Cs), 23.10
Ó, annyit még elfelejtettem: a most kezdő titánoknak azt tanácsolnám, hogy böngészgessenek a neten teljesen ismeretlen honlapok közt, használják őket, és amelyikeknél kifejezetten jók a tapasztalataik, azokban tudatosan keressék a hasonlóságokat, a tetsző elemeket, motívumokat. Ezzel a rendkívül egyszerű módszerrel elég sokat lehet tanulni, mégis elég ritkán használják ki az emberek.
27

magic seven

Jano · 2005. Ápr. 1. (P), 00.52
Ez a buvos 7-es mindig elo jon amikor hasznalhatosgrol, szoftver ergonomiarol van szo, azonban szerintem ez weblapokra nem alkalmazhato. Foleg a navigacioval szoktak osszekapcsolni.

Maga a teny, hogy az ember rovidtavu memoriaja atlagosan 7+/-2 dolgot kepes a rovidtavu memoriajaban tarolni es felidezni nem befolyasolja azt ahogy egy honlapon navigal.

A klasszikus kiserletben azt a 7 dolgot meg kellett jegyezni, mikozben a honlapnal errol szo sincs. Ott folyamatosan lathato elotted a valasztasi lehetoseg.

A honlapoknal bizonyitott vizsgalatokkal, hogy az emberek nem nezik vegig az osszes lehetoseget, majd valasztjak ki a legjobbat, hanem az elso jonak tuno lehetosegre kattintanak. Ehhez nem kell meg a rovidtavu memoriat sem hasznalni.

Egy egyszeru bizonyitek:
A yahoo kezdo oldalan is minimum 3-szor annyi kategoria link van, a startlap egy-egy oldalan szaznal is több link van. Megis tudjuk hasznalni.

Fontos kiemelni, hogy a 7 egy atlagos szam. A 7+-2 also korlatja 5. Ha szeles korben akarunk tervezni akkor 5 menupontra kene maximalizalni a navigaciot?? Ez lehetetlen.
39

Bűvös 7es

tiny · 2005. Ápr. 9. (Szo), 21.32
Abban nem értek egyet, hogy egyáltalán nem befolyásolja a dolgot. Azért minél kevesebb link van, annál jobb. Én a microsoft honlapján is sokszor szoktam keresni, ami nekem kell, s időbe tellik megtalálni. Hogy nem mindenre alkalmazható, abban egyetértek. Ti meg tudjátok jegyezni a lottószámokat? (csak költői kérdés, nem várok választ) A cikknek pedig ha lesz folytatása, kíváncsian várom... Üdv
Mr.Tiny
28

elozetes ismeret

Jano · 2005. Ápr. 1. (P), 01.04
Elozetes ismeret: ezt a tenyezot nagyon jo hogy megemlitette Slac!
En ugy fogalmaznam: Mukodjon ugy aminek latszik, latszodjon hogyan mukodik.

Nagyon sokan elnek (vissza) a CSS es grafika lehetosegeivel a GUI elemek atszabasaban. Ujito szandekkal ujfele kinezetet, mukodesi modot talalnak ki. Nem gondolnak bele, hogy ami nekik evidens az annak a felhasznalonak aki eloszor jar az oldalon nem az!
Nem gondolnak bele, hogy a felhasznalo - megha altalaban fogekony is az ujdonsagokra - amikor siet csak ideges lesz ha talanyok ele allitjak.

Egyik tipikus ilyen dolog a lehullo menus navigacio.
Legtobbszor nem jelzi semmi, hogyha a menu fole megyunk akkor onnan almenuk fognak megnyilni. Ez csak akkor derul ki amikor a felhasznalo mar eldontotte, hogy melyik menupontra kattint, oda viszi az egeret, kattint es kozben megjelenik az almenu, immar keson!

A honlap nem kalandjatek! Ha valaki jatszott ilyennel az tudja, hogy neha pixelrol pixelre vegig kell menni a kepernyon, hogy megtalald az ott eldugott targyat amit fel kell hasznalnod hogy tovabb jus. Az ilyenek rettento idegesitoek.
A user nem fogja az egeret mindenhova odavinni, hogy vajon ott tortenik-e valami. Olvassa a kepernyot, az eger pihen. Ha lat valamit akkor visszi csak oda. Ezert lathatova kell tenni, utalni kell ra vizualisan hogy ott torteni fog valami.

Kigombolyodik:megnyomhato.
Reces:draggelheto.
Lefele/oldalra mutat nyil:arra kell tovabbmenni:almenu nyilik meg.
30

Egyetértek veled abban,

airwalker · 2005. Ápr. 1. (P), 14.24
Egyetértek veled abban, hogy a lehulló menü a legtöbbször nem jó másra, csak, h szép csili-vili oldalunk legyen. Az se segít, ha oda van téve a kis nyíl, ami mutatja, h lenyíló menüről van szó. Az emberek ugyanis először kipróbálják mi történik, ha fölé viszik az egeret. Csak azután gondolkodnak arról, h hova kéne tovább menni, miután megcsodálták a menü jópofa megoldásait. Ekkor legtöbben valóban az első érdekesnek tűnő menüpontra kattintanak. De mi van azokkal akik valóban rendeltetésszerűen használják a webet, vagyis egy konkrét témáról akarnak információt szerezni, és nem csak nézelődnek? Ők sorban több menüpontot is lenyitnak, hogy megtalálják a legmegfelelőbb almenüpontot. De mire a menü végére érnek már nem tudják mi volt az első menüpontban. Szerintem a felhasználók egyáltalán nem olvasnak a döntéseik előtt. Az egész számítógépes felületen (nem csak weben) az emberek gondolkodás nélkül döntenek, mert tudják, hogy a döntést vissza lehet vonni, vagy ha veszélyes dolgot csinálnánk úgyis jön a kérdés, h biztos vagy-e a döntésben (Az x fájl már létezik. Kívánja felülírni?).
Vannak olyan emberek (például én is), akik úgy olvasnak, hogy közben mindig tologatják az egeret. Akaratlanul is ott van az egér ahova éppen figyelek. Ezért nagyon hasznos lehet a linekeket valamilyen hover megoldással kiemelni.
Valaki azt írta, h érdemes magunkat is figyelni netezés közben, h megtudjuk melyik oldal használható jól, és melyik nem. Ez így igaz, de azért annyit hozzá kell tennni, h nekem aki naponta legalább 1-2 órát eltöltök a neten egészen más felhasználói szokásaim vannak, mint azoknak akik csak ritkábban jutnak net közelbe.
Persze már az is valami, h mi itt beszélünk ilyen témákról. Én még nagyon kevés ilyen irányú eszmecserét láttam magyar nyelvü oldalon, ha valaki mégis ismer ilyet ossza meg velem!
airwalker
airwalker##kukac##freemail.hu
31

Én is tologatom az egeret,

csla · 2005. Ápr. 1. (P), 14.43
Én is tologatom az egeret, és pl. egy ilyen témánál, ahol ilyen sok hozzászólás van, örülnék egy kis linknek, amivel egy pillanat alatt visszaugorhatok az oldal tetejére, hogy elérjem a gyorslinkjeim, anélkül, hogy nagyon messze kéne mennem az egérrel (értsd: gördítősáv), vagy görgetnem kéne fél percig, vagy a billentyűzethez kéne nyúlnom... ;)
33

[i]Home[/i] billentyű?;)

Tome · 2005. Ápr. 1. (P), 17.15
Home billentyű?;)
32

lehullo menu

Jano · 2005. Ápr. 1. (P), 16.10
Pont azert mert visszavonhato a dontes azert nem gondolkodnak tul sokat, es azert nem nezik vegig az osszes menupontot hanem boknek az elso jonak tunore!

Azert a lehullo menus megoldasnak is megvannak a maga elonyei! kis helyet foglal, gyorsan kezelheto, kozvetlen ugrasi lehetoseg belso oldalakra.

Ide kapcsolodik a masikfajta lehullo menu (select). Mostanaban sokfele drivert kellett keresnem es tudtam pontosan a termek nevet amihez kellett. Ha a fooldalon volt egy select amiben szepen fel volt sorolva (akar tobb tucat) termekkod is, onnan egybol a megfelelo helyre tudtam ugrani, mindenfele termekek/kategoria/alkategoria/leiras utvonal vegigjarasa nelkul!

Ezt az eger tologatast nem nagyon ertem. Amerre a szemedet mozgatod arra viszed az egeret? Tehat mintha az ujadat vinned a konyben a sorok felett? Ha igy van akkor meg nem ertem hogy annyi egerezes utan miert olyan sok mozgas a scrollbar elerese...
34

Azt hiszem erre szokták

Tome · 2005. Ápr. 1. (P), 17.17
Azt hiszem erre szokták mondani, hogy tudni kell értelmesen használni a kezünkben levő eszközöket...
35

Bolond nap van, ne

csla · 2005. Ápr. 1. (P), 19.24
Bolond nap van, ne ragozzuk... ;)
29

Ezerszer voltmár, de

prezi · 2005. Ápr. 1. (P), 09.27
Ezerszer voltmár, de szerintem sosem lehet elégszer belinkelni, a design guideline-okat:

Nemcsak a kinézetekhez ad segítséget, de szó van benne a cikkben és a hozzászólásokban emlegetett dolgokról:
apple - http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/
kde - http://developer.kde.org/documentation/design/ui/index.html
windows - http://msdn.microsoft.com/library/en-us/dnwue/html/welcome.asp

Persze a fentiek nagyrészben az asztali rendszerekre vonakozó segítséget adnak, de IMHO érdemes megismerni azt is, hiszen vannak közös szabályok.
36

két dolog:egy oldal ami

toxin · 2005. Ápr. 2. (Szo), 23.50
egy oldal ami szorosan kapcsolódik ehhez a témához:
http://usability.gov/

és az oldalon lévő szines szélesvásznú 40MB-os ebook
http://usability.gov/pdfs/guidelines_book.pdf

ajánlom őket mindeki szives figyelmébe :)
37

Csak egy kis magánvélemény...

monghuz · 2005. Ápr. 4. (H), 23.44
Szeretnék csatlakozni a cikket dicsérők táborához, jó látni, hogy vette valaki a fáradságot és tényeket közölt (file méretek, betüszám stb.).

A CSS-t illentően én most tértem át a használatára, és sokkal szabadabb kezet ad mint egy táblázattal tagolt weblap.

Frame-ket szerintem is már már fölösleges tárgyalni, mert nagyon kevés helyen látni és CSS-sel vagy egy kis php-s cuccal simán meglehet oldani hogy egy oldalon belül csak a tartalom változzon, a feljéc ill. menü a cache miatt meg úgy is egyböl megjelenik a második letöltéstöl...

Egy dologban viszont nem teljessen értek egyet a cikk írójával, mégpedig a felbontás kérdésében. Természetessen úgy kell megcsinálni egy weblapot hogy minnél több felbontás mellett élvezhető és használható maradjon. DE a statisztikákat elnézve manapság az emberek döntö többsége 1024*768-as, vagy nagyobb felbontásban nézegeti a weblapokat ez úgy 70-90% közt ingázik a fennmaradók 800*600-ban és 1-3% nézi ennél kisebb felbontásban.

A fentieket amúgy a http://www.statsector.hu és a http://www.hungariantop1000.com alapján szürtem le.

Ergó én min 800*600ra készítek egy weblapot, és lehet hogy ez kicsit rossz megközelítése a dolgoknak, de egy weblapot, ne egy mobilon vagy valami kiszupereált monocrom monitoron nézzenek meg!!!

Kiváncsi vagyok hogy kinek mi az álláspontja, az enyém ez :)

bye Tomi
38

Nem mind nagy, ami annak látszik

aurum · 2005. Ápr. 5. (K), 14.48
Attól, hogy nekem 1600 pixelen megy a monitorom, meg 1400-n a laptopm, még nem biztos, hogy 1024-ben akarom látni a honlapokat. Nem azért hasznáálok nagy felbontást, hogy ugyan úgy egy ablakkal letakartassam. Szóval én is a 800-s felbontást preferálom, legfeljebb két böngésző is elfér egymás mellett, vagy miközben olvasok, még látom a többi ablakot. Ráadásul szerintem egy 1024-s, vagy nagyobb ablak már áttekinthetetlen, állandóan ingázik a szemem, hogy befogja a képet. Legyen csak az az ablak 6-800 pixel széles, azt egyben tudom látni.
40

Felbontás...

kgyt · 2005. Ápr. 12. (K), 16.41
Nekem 3840x1024 van beállítva, de nem szoktam 1280-nál szélesebb ablakokat használni... :-)
Operát használok és nagyítani szoktam a weblapokat, ha olvasok, mert könnyebb úgy olvasni, ha nagyobbak a betük. Egyébként én is mozgatom az egeret, méghozzá úgy, hogy kijelölöm a már olvasott szöveget, így vezetve a szememet.
Nekem is csak két szemem van és vigyázni akarok rájuk... ;-)

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
41

weblapok ergonómiája

nemecsek · 2005. Ápr. 14. (Cs), 09.55
Üdv! Nem vitatva, hogy a cikk írója jelentős munkát fektetett a témába, szeretnék vitába szállni az egyik megállapításával az eddigi tapasztalataim alapján. A szerző szerint nagyobb képernyő felbontás esetén rögzített web oldal szélesség esetén kihasználatlan csíkok jelennek meg a képernyőn, és szerinte azért vesznek nagyobb képernyőt az emberek, hogy azon több információ jelenhessen meg egy web lapról. Nos, én ezt nem tartom helyes okoskodásnak, mert nagyobbb monitort nem azért vesz az ember, hogy a web lapokat jó nagy méretben megnézhesse, hanem azért, mert például honlapot készít egy editorral, képeket vagy videót szerkeszt speciális programokkal, programot ír sokféle eszköz használatával, épületet tervez speciális programokkal stb.

Számomra egy rögzített oldalszélességű weblap nem azt jelenti, hogy a felhasználó szabadon méretezheti, és ezzel én szamadságot adok neki, hanem azt, hogy nem azt a képet látja, amit én terveztem. Egy weblapot nem úgy kell kényelmesen olvasni, ahogy egy könyvet. Tagolni kell a szöveget, rövidebb részekre vágni, színekkel, egyéb elemekkel kiemelni, megvezetni a usert, jó navigációt adni hozzá stb. Az már rég rossz, ha a felhasználó széthúzhatja az oldalt 1024 vagy nagyobb pixel szélességben, esetleg megnöveli kétszer akkorára a betűméreteket, majd a balról jobbra hosszan elterülő szöveget olvasgatja.
Erről bővebben olvashattok a Carnation vagy a Kirowski honlapján.
42

1280*1024

Anonymous · 2005. Ápr. 26. (K), 11.41
Nekem bizony 1280*1024 képernyőfelbontásnál a Weblabor oldalát megjelenítve is jókora üres sáv látható mindkét oldalon... Nem azért vettem 19"-os monitort, hogy a nagy semmit nézegessem kétoldalt. ;-)))
43

Na ja!

kgyt · 2005. Ápr. 26. (K), 12.15
3840x1024-ben is rettentő ronda.
Nem tudom kinek jó hogy így néz ki... Hát...
Oldalt akkora üres sávok vannak, hogy két külön monitort direkt arra tartok...
;-)

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
44

szomorú így az élet :)

Hojtsy Gábor · 2005. Ápr. 27. (Sze), 22.37
Megcsináljuk a kedvetekért, hogy a szürke csíkozás kitöltse a teljes hátteret? :)
47

Háttér

kgyt · 2005. Ápr. 28. (Cs), 11.25
Nem lehetne, hogy a két oldalon fennmaradó helyen valamilyen szép festmény, vagy fotó helyezkedjen el?
pl. Gustav Klimt valamely alkotása... ;-)

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
45

1280x1024

Granc Róbert · 2005. Ápr. 28. (Cs), 10.33
Te talán egy vagy azok közül, akik teljes képernyőn böngésznek, de nagyon sokan vagyunk olyanok is, akik nem így teszik: az én képernyőfelbontásom is 1280x1024, de szinte soha nem böngészek teljes képernyőre nagyított ablakkal - általában 1000 pixelnél keskenyebb a böngészőablakom, így még elég jelentős mennyiségű információ fér el mellette is (pl. akár WinAmp, GetRight letöltési ablakok, stb.)

Érdekesnek tartom ugyanakkor, hogy ha felmérést végeznénk, szerintem egyedül a Windows felhasználók körében lenne jelentős azok aránya, akik szinte állandóan teljes képernyős ablakokkal dolgoznak, legyen ez böngésző- vagy levelezőprogram, szövegszerkesztő, akármi.
Tapasztalataim szerint sem Unix/Linux rendszereken, sem a Mac OS alatt nem ez az általános használati mód...

/Robi
46

megszokás

Anonymous · 2005. Ápr. 28. (Cs), 11.10
Biztos azért, mert nem kézenfekvő, hogy egyáltalán más is tud futni a böngésző mellett... :)
49

Tapasztalataim

Anonymous · 2005. Aug. 20. (Szo), 18.49
Én mindig nagyon sietek, mert nem szabadna engedély nélkül neteznem - mégis várok akár 20-30 másodpercet is amíg letöltődik egy weblap - 56kilós modemmel ez nem is csoda...

A másik, hogy a weblapokat fölösleges 640x480-ra is optimizálni, mert elég sok barátom van, de egyikük sem használ ilyen gyenge képességű monitort.

Ami nagyon idegesít, hogy ha nem lehet mindent egyszerre megtalálni a bal oldali navigációs sávban.

Ne feledjük, hogy a szerző, akinek a könyvét olvastad, jobb anyagi helyzetű országban él, ahol már nagyobb a szélessávú internet aránya, így joggal várható el a rövid letöltési idő.

És íme itt egy példa, pont most - megírtam ezt az üzenetet, de két percbe tellett, mire megtaláltam, hogy lehet elküldeni...