Eredeti siralmam itt olvasható. Az update röviden pedig annyi, hogy leszarom.
Bővebben kifejtve: elég jó a blog.hu mobilos layout, illetve iPaden default a sima. Ott zavart volna ha a mobilos jön be, de így minden oké. Azért az továbbra is érdekel, hogy milyen készülék-tulajdonság alapján választ a sima és mobilos sablon között a rendszer.
Régóta gyötör a probléma, hogy ha egy szövegdoboz vagy bármilyen div kinézetén szeretnék változtatni padding vagy border segítségével, mindíg bele kell kalkulálni, hogy ezeket az elemeket a doboz valós méretén felül adja hozzá a böngésző.
#szovegdoboz {
width: 300px;
height: 100px;
border-left: 5px; }
A fenti példában a szövegdoboz 300 pixel szélességről 305-re dagad a hozzáadott border-nek köszönhetően. Ha pixelpontos dizájnt készítünk, ez tönkreteheti az egész layoutot, mivel ha a doboz nem fér el vízszintesen, a következő sorba (azaz a weboldal aljára) tolódik.
Az oldschool megoldás az lenne, hogy vonjuk ki a border méretét az eredeti doboz méretéből. Ez megoldja a problémát, de kevésbé flexibilis, mivel ha később változtatunk a dizájnon ezt fejben kell tartani.
Még súlyosabb a helyzet, ha reszponszív, azaz százalék értékeken alapuló a dizájn, mivel ez esetben a számolás még bonyolultabb, illetve nem is kivitelezhető igazán kompromisszum mentesen.
A megoldás a következő tulajdonságok hozzáadása a dobozhoz. Szerencsére még az IE is támogatja 8-as verziótól felfelé, így én nem igazán csinálnék lelkiismereti kérdést a használatából.
#szovegdoboz {
box-sizing:border-box;
-moz-box-sizing:border-box; /* Firefox */
-webkit-box-sizing:border-box; /* Safari */width: 300px;
height: 100px;
border-left: 5px; }
Készítettem egy összehasonlító példát Codepen-ben, ahol látványosabb a különbség. Ne feledjük, hogy a margin továbbra is a dobozon kívüli értéknek számít, mivel ezt akkor használjuk, ha valóban távolságot szeretnénk tartani két elem között.
Mostanában kerülöm a grafikai dizájn munkákat, de ezt egy barátom kérésére bírtam összerakni és szerintem egész jó lett. Nem eredeti az ötlet, de a név alapján kézenfekvő volt.
[sidenote: nem írogattam annyit magyarul, hogy valaha is zavarjon a spell check hiánya, de úgy látom ideje megoldani a problémát. Addig is elnézést a hibákért.]
Írtam korábban, hogy sokat fejlődött és szépült a blog.hu, és sírtam is a mobil layout miatt. A CSS írása és pár új poszt megírása után tettem még pozitív és negatív felfedezéseket egyaránt.
Kezdem a gecizéssel.
Értem én, hogy egységesíteni kell a felhasználói élményt. Valahol meg kell kötni a blogtulajdonosok kezét. A Twitter és Tumblr sikerét is abban látom, hogy okosan korlátozták a lehetőségeket. Akinek összetettebb rendszer kell, az balra el, a többiek viszont örülhetnek a rém egyszerű felhasználói felületnek.
A siralmam mégis az, hogy a korlátozások teljesen randomnak látszódnak a blog.hu esetében. Például lehetőségünk van az oldal HTML kódjába belenyúlni (tehát zűrzavart csinálhatunk simán), illetve a CSS-be is, azonban a bejegyzések struktúrájába már nem. Pedig ez elérhető volt anno. Nincs hozzáférés vagy inyekciós megoldás a <head>-hez, ami például lehetetlenné teszi a viewport beállítását vagy külső fontkészlet behívását.
Nem tudom eldönteni, hogy akkor most ez a hétköznapi felhasználónak próbál kedvezni, mert ahhoz túl bonyolult a rendszer - már ha valaki nem elégedett tökéletesen az előre beállított sablonok valamelyikével -, vagy a magamfajtának, aki viszont panaszkodik, hogy ez vagy az hiányzik. Valószínűleg népszerű lenne, ha a mobil sablonhoz hasonlóan lenne egy kő egyszerű sablon, aminek a színeit és logóját kódolás nélkül lehetne változtatni.
Ugyanakkor tetszenek a mikroblog funkciók, azaz gyors kép vagy videó posztolás lehetősége. Tetszik az admin felület és jobbnak tűnik a fájl rendszer. Jól működik az auto-save is és megmenthet sok kellemetlenségtől.
Összeraktam a CSS-t, de persze még messze a tökéletestől. A sima "Colors of the web" sablont vettem alapul. Az oldaldobozok jelenleg nem fontosak, így azokat lenyomtam alulra. Az egyik oldalhasábot feltettem a headerbe, így sikerült megoldani, hogy a kereső felül legyen. Még dolgozni kell a reszponszivitáson és az oldaldobozok megjelenítésén alul. Megint csak bánatom, hogy a szociál megosztás szarságok elég hülyén vannak elrendezve, de ezt !important megoldással talán felül tudom majd írni.
Felzárkóztató: a "hover", magyarra fordítva "lebegés". A web dizájnban arra a jelenségre utal, amikor az egér mutató valamilyen elem felett áll. Ilyen módon funkciókat rendelhetünk hozzá. Például: ha az egér mutató a sárga gomb felett hoverezik, akkor a gomb színe váltson pirosra.
Itt egy egyszerű példa: Codepen
Az érintőképernyők berobbanásával észben kell tartani, hogy hiába vonzó és kézenfekvő a hover, sajnos már csak úgy szabad rá gondolni, mint egy "nice to have". Legalábbis, ha olyan funkciót rendelünk hozzá, ami kulcsfontosságú az oldal kezeléséhez. Jó példa erre a legördülő menü, aminek megjelenítése rengeteg oldalon hoverhez kötött. Meghagyhatjuk a hovert a hagyományos eszközöket használóknak, de mindenképpen kell egy érintésbarát megoldás is.
Szerencsére a klikkelés és az érintés nem számít külön akciónak, habár a HTML5-ben van lehetőség összetettebb touch event-ek beállítására. Például csúsztatás, elhúzás (swipe), vagy akár több ujjas mozdulatok.
A hover kiválására elegendő lehet egy sima klikken alapuló beállítás. A legördülő menü esetében viszonylag egyszerű dolgunk van, hiszen a JQuery támogatja a klikkeléshez rendelt funkciókat. Ebben az esetben a .toggleClass tűnik a legkézenfekvőbb megoldásnak. Ez képes váltogatni az adott elemhez rendelt class-okat, ilyen módon egy display:none beállítású class tudja előhívni, majd újabb klikkre elrejteni az adott legördülő menüt. Persze lehet rajta szépíteni és variálni innen, de a lényeg, hogy elértük, hogy a lehető legszélesebb közönségnek tegyük elérhetővé a navigációt.
Hozzá kell tennem, háromszor is gondold át, hogy tényleg szükség van e arra a legördülőre. Conversion rate szempontjából nem biztos, hogy az a hatásos, ha sok lehetőséget zúdítunk a felhasználóra, illetve nem biztos, hogy mindennek egy menüben kell lennie.
