ugrás a tartalomhoz

Így készül a Weblabor.hu

Joó Ádám · 2015. Feb. 11. (Sze), 18.26

Ahogy a megújuló Weblabor mozaikdarabjai egyre inkább egésszé állnak össze, úgy szeretnénk olvasóinkat is bevonni a történésekbe. Éppen ezért ismét útjára indítjuk werkszájtunkat az igy.keszul.a.weblabor.hu címen, ahol időről időre a fejlesztői ágból kiemelünk egyes elemeket, hogy amolyan előzetesként közzétegyük, a visszajelzéseket pedig becsatolhassuk a folyamatba.

Elsőként új, reszponzív dizájnunkat szeretnénk megosztani, mely a fenti címen már megtekinthető. A teljes egészében az új oldalhoz készült dizájn megőrzi a meglévő látványvilágot, azonban törekszik arra, hogy szebb, áttekinthetőbb, olvashatóbb legyen. Emellett reszponzív, így végre kisebb képernyővel rendelkező eszközökön is, bárhonnan, bármikor olvasható lesz a Weblabor.

Ismét van külön a nyomtatáshoz fenntartott stíluslapunk is, amit az évek folyamán valahol elhagytunk.

Jelenlegi rendszerünkkel szemben különös figyelmet fordítunk a minifikálásra, tömörítésre és gyorsítótárazásra, illetve hogy minden oldalon csak olyan elemeket kérjünk le, amelyeket valóban használunk is, ezzel is hozzájárulva a lehető leggyorsabb navigációhoz és legkisebb adatforgalomhoz.

Természetesen továbbra is törekszünk arra, hogy JavaScript, képek és stílusok nélkül is jól használható maradjon webhelyünk.

Első előzetesünk február 13-án éjfélig lesz elérhető, kérjük, hogy próbáljátok ki minél több eszközön, minél több böngészőben, észrevételeiteket pedig írjátok meg nekünk, hogy az esetleges hibákat javíthassuk!

 ■
1

Design

janoszen · 2015. Feb. 11. (Sze), 18.47
Ne vedd bantasnak, de annak mi ertelme, hogy ugyanaz a usability szempontbol igen csak aggalyos menurendszer es design marad meg?
4

Nem veszem, azért van

Joó Ádám · 2015. Feb. 11. (Sze), 19.18
Nem veszem, azért van közzétéve, hogy kitárgyaljuk. Mit tartasz usability szempontból aggályosnak a menün vagy a dizájnon? Én úgy gondolom, hogy a Weblabor használhatósági problémái a részletekben rejlenek, nem mondjuk általában a layoutban.
7

A menu azert nehezkes, mert

Sanyiii · 2015. Feb. 12. (Cs), 00.39
A menu azert nehezkes, mert nem erheto el gyorsan, pl. a lap aljarol. A dropdown is rosszabb megoldas egy klasszikus hamburger menuhoz kepest.

Nekem egyebkent 1 merettel nagyobb betu, es egy lehellettel sotetebb jonne be a tartalomban. Amoleden nincs a szurkenek meg mind az otven arnyalata (ergo ami nalad jo, itt vilagosabbnak hat, mert a kornyezet feherje nem olyan feher), ellenben nem is barnulok ugy le, mint az ips-tol.
12

A menu azert nehezkes, mert

Joó Ádám · 2015. Feb. 12. (Cs), 11.29
A menu azert nehezkes, mert nem erheto el gyorsan, pl. a lap aljarol.


Itt mobilról beszélünk, gondolom. Lehet, hogy kellene kapjon a fejléc egy position: fixed-et?

A dropdown is rosszabb megoldas egy klasszikus hamburger menuhoz kepest.


Az oldalról behúzhatóra gondolsz? Miért tartod rosszabbnak a dropdownt?

egy lehellettel sotetebb jonne be a tartalomban


A szövegszín most #111, mit találnál jónak?
19

A fixed jó lenne, de csak

Sanyiii · 2015. Feb. 12. (Cs), 12.08
A fixed jó lenne, de csak felfelé görgetéssel jöjjön elő, különben kitakar, és ha előjön, akkor is maradjon valamennyire átlátszó a téglalap.

Az oldalról behúzósnak benne van a nevében: hamburger lenyomása nélkül is behúzhatod a menüt a képernyő oldalirányú végigsimításával. Dropdown minimum egy klikk valahol. Ez személyes preferencia csak.

A menü kinyitása után mobil vissza gombja nem csukja be a menüt, azaz a menügomb nem generál oldal aktivitást, ez is hiba sztem.

A #111 jó, akkor a betű kicsi, vagy eleve túl vékony fajta.

Amúgy persze, mobil megjelenésről beszélek, a desktop szörfözésre eleve visszaszorulóban.
36

A szövegszín most #111, mit

saxus · 2015. Feb. 13. (P), 01.36
A szövegszín most #111, mit találnál jónak?


#000

Rohadt idegesítő, mikor fehéren elkezdenek szürke betűkkel írni.
21

Nekem

janoszen · 2015. Feb. 12. (Cs), 12.58
Nekem az egesz oldal elrendezesevel van bajom. A munka es allas rovat jelen formajaban kukazhato, mert sztem nem kepvisel erteket. Szinten problemasnak erzem a fooldal elrendezeset, sztem a sidebaros-blogos kinezet helyett erdemesebb lenne valami tobb oszlopos, magazin-szeru elrendezest valasztani, hogy az adott rovatokbol (cikkek, leirasok, stb) ne tunjenek el olyan gyorsan a tartalmak, megis gyorsan lathato legyen az uj tartalom.
25

Nekem az egesz olyal

Joó Ádám · 2015. Feb. 12. (Cs), 13.55
Nekem az egesz olyal elrendezesevel van bajom.


Amiket írsz, azok inkább információs architektúra kérdései, mintsem látványvilágé.

A munka es allas rovat jelen formajaban kukazhato, mert sztem nem kepvisel erteket.


Ha ez így lenne, nem ez volna a legforgalmasabb része az oldalnak, de egyetértek azzal, hogy rossz a formátum, meg is fog változni.

Szinten problemasnak erzem a fooldal elrendezeset, sztem a sidebaros-blogos kinezet helyett erdemesebb lenne valami tobb oszlopos, magazin-szeru elrendezest valasztani, hogy az adott rovatokbol (cikkek, leirasok, stb) ne tunjenek el olyan gyorsan a tartalmak, megis gyorsan lathato legyen az uj tartalom.


Én is ilyesmire gondoltam.
26

Munka

janoszen · 2015. Feb. 12. (Cs), 14.02
Munka-allas tekintetben kicsit meg lehetne emelni a belepo szintet, ha pl. a hirdetoknek kotelezo lenne grafikai elemeket feltolteni, pl logo, stb. hogy kellemesebb legyen olvasni, illetve ha a Weblabor tagoknak lenne lehetosege - LinkedIn mintara - oneletrajzot kesziteni. Tudom, sok munka, de sztem igy lesz ertelme.
27

Teljes mértékben egyetértünk.

Joó Ádám · 2015. Feb. 12. (Cs), 14.10
Teljes mértékben egyetértünk.
2

Mobilról nézve nem látok

pythonozok · 2015. Feb. 11. (Sze), 18.57
Mobilról nézve nem látok különbséget a mobilos tartalom és az "asztali nézet" között. (Android beépített böngésző )
5

Nem biztos, hogy jól értelek,

Joó Ádám · 2015. Feb. 11. (Sze), 19.21
Nem biztos, hogy jól értelek, media query-k változtatják az elrendezést, leginkább a navigációra tekintettel.
8

Ez nekem kínai. Megszoktam,

pythonozok · 2015. Feb. 12. (Cs), 00.50
Ez nekem kínai. Megszoktam, hogy ha normál böngészőből nézek egy oldalt, az általában eltér megjelenésében a mobilról (android, elsősorban a beépített, nem chrome alapú böngésző) látottól. Lásd pl. index.hu! Egyébként ott is megvan, hogy hiába kérem a mobilos böngészőből, hogy desktop oldalt akarok, akkor is a mobilt kapom.
Ellenpéldának ott a blog.hu vagy a google.com. Ezeknél alapállapotban a mobil változat jelenik meg a telefonomon, míg ha desktopot kérek, akkor a desktop változat.

Itt ráadásul az külön fura, hogy ha álló formátumban nézem, akkor van menü, ha fekvőben, akkor nincs.
13

Ez nekem kínai. Húzd

Joó Ádám · 2015. Feb. 12. (Cs), 11.36
Ez nekem kínai.


Húzd folyamatosan össze egy asztali böngészőben az ablakot, és megérted.

Megszoktam, hogy ha normál böngészőből nézek egy oldalt, az általában eltér megjelenésében a mobilról (android, elsősorban a beépített, nem chrome alapú böngésző) látottól.


El is kellene térjen. Ha van elég hely, akkor a jelenlegihez hasonló horizontális navigációt és oldalsávot kell láss, míg kisebb képernyőn egy lenyíló navigációt és a tartalom utáni ajánlót. Nálad nem így van?

Egyébként ott is megvan, hogy hiába kérem a mobilos böngészőből, hogy desktop oldalt akarok, akkor is a mobilt kapom.


Nem tudom, hogy technikailag mit jelent az, ha bizonyos nézetet kérsz a böngészőtől.

Itt ráadásul az külön fura, hogy ha álló formátumban nézem, akkor van menü, ha fekvőben, akkor nincs.


Hogy-hogy nincs? Éppen állóban várható, hogy biztosan összecsukódik a navigáció, hisz nem férne ki vízszintesen.

Ha tudsz adni képet, az segít.
15

Épp azt írtam: csak álló

pythonozok · 2015. Feb. 12. (Cs), 11.46
Épp azt írtam: csak álló formátumban van menüm.

Képet egyelőre nem tudok mellékelni. Itt gyakorlatilag ugyanazt látom a menüt leszámítva, mindegy honnan, miből nézem.

Indexnél, origonál már van eltérés: mobil nézetben általában van egy m. a domain név előtt, míg desktopnál www. vagy semmi. A megjelenésben meg olyan eltérés van, hogy a desktop változat több hasábos, a mobilban egyetlen oszlop, kevesebb témával. Na az indexnél ezt a mobil megjelenést nem tudom kiiktatni. És látszólag itt sincs változás, de a tényleges hatás csak akkor derül ki, ha valami tartalom is lesz az új oldalon.
24

Épp azt írtam: csak álló

Joó Ádám · 2015. Feb. 12. (Cs), 13.42
Épp azt írtam: csak álló formátumban van menüm.


És mi történik vele fekvő formátumban?

Indexnél, origonál már van eltérés: mobil nézetben általában van egy m. a domain név előtt, míg desktopnál www. vagy semmi. A megjelenésben meg olyan eltérés van, hogy a desktop változat több hasábos, a mobilban egyetlen oszlop, kevesebb témával. Na az indexnél ezt a mobil megjelenést nem tudom kiiktatni. És látszólag itt sincs változás, de a tényleges hatás csak akkor derül ki, ha valami tartalom is lesz az új oldalon.


Nincs ilyen: ugyanazt a HTML-t kapod, bármilyen eszközről is nézed, csak a stílusok mások a képernyőméret függvényében.
32

Fekvő formában nézve elég

pythonozok · 2015. Feb. 12. (Cs), 21.11
Fekvő formában nézve elég széles a mobilom kijelzője, hogy ne jelenjen meg a menü, így gyakorlatilag 1:1-ben ugyanazt látom, mintha PC-n nézném.
Valahogy mindig arra számítok, mióta valakivel (talán épp itt) beszéltünk róla, hogy miért is kell mobilra optimalizálni(*), hogy ha mobilról nézek egy oldalt, akkor más megjelenése lesz, mint egy nagyobb gépről.


* pl. tapiképernyőn kicsit nehezebb navigálni, mint egérrel, mert ujjal kitapogatni nem lehet olyan precízen.
35

638 pixeltől felfele jelenik

Joó Ádám · 2015. Feb. 12. (Cs), 21.37
638 pixeltől felfele jelenik meg a teljes fejléc és a vízszintes navigáció, mert utóbbi innentől fér el a képernyőn. A betűméret nem változik, a térközök pedig még nagyobbak is, úgyhogy az érintőképernyőn ez nem jelenthet gondot.

De tényleg próbáld ki, hogy folyamatosan összehúzod a böngészőablakot, és akkor látni fogod a töréspontokat.
3

Mobilos nézet

_lacus_ · 2015. Feb. 11. (Sze), 19.07
Ha kicsit bele lehet pofáddzani, akkor a mobil nézeten nagyobbra venném a menü gombot (a "v"-t).
Egérrel alig lehet becélozni, nemhogy ujjal.
Ugyanez érvényes a lenyíló menüre, az egyes menülemeket magasabbra venném és nemcsak a szövegre kattintással működhetne, hanem az adott menüelem egész szélességben működhetne a kattintás.
6

Oké, simán lehet, hogy nem

Joó Ádám · 2015. Feb. 11. (Sze), 19.25
Oké, simán lehet, hogy nem elég jól érinthetőek, ezzel kapcsolatban várom mások visszajelzését is.
10

megerősítem

Pepita · 2015. Feb. 12. (Cs), 08.32
Igen, túl kicsi a menü és a linkek is a Láblécben.
Itt pedig túl nagy a két kép. ..
Bővebben holnap.

Szerk
Kellene Láblécbe top link.
Comments: figyelj majd, hogy túl sok bal margin ne legyen, Kb max 50%. Ha mélyebb a fa, inkább szöveges thread jelenjen meg, mint túl keskeny box.
Lehet választani a nézetek között? Ne maradjon ki.
Mobilra felesleges hely pazarlás a fejléc kép. Pl Legyen rajta a menü.
Egyelőre ennyi.
Ja, alapjában tök jó.
14

Kellene Láblécbe top

Joó Ádám · 2015. Feb. 12. (Cs), 11.45
Kellene Láblécbe top link.


Akkor már jobb fixszé tenni a navigációt, nem?

Comments: figyelj majd, hogy túl sok bal margin ne legyen, Kb max 50%. Ha mélyebb a fa, inkább szöveges thread jelenjen meg, mint túl keskeny box.


Ez minden nézetben rendezve lesz végre.

Lehet választani a nézetek között? Ne maradjon ki.


Nem, miért akarnál választani? Ugyanazt a tartalmat látod minden eszközön, csak a képernyőmérettől függő elrendezésben.

Mobilra felesleges hely pazarlás a fejléc kép.


17 pixel? :)
29

félig

Pepita · 2015. Feb. 12. (Cs), 20.17
Mint fentebb javasolt a valaki, félig fix menü jó.

Nézetek között szeretek én választani. Nem baj ha link, de menjen. De hadd döntsem el én, ha akarom.

Nekem biztos, hogy többnek tűnt 17 pixelnél. :) Mindjárt rá nézek még.

Comments: big like.

Szerk
Biztos több, mint 17. Főleg fekve. :)
33

Nézetek között szeretek én

Joó Ádám · 2015. Feb. 12. (Cs), 21.24
Nézetek között szeretek én választani. Nem baj ha link, de menjen. De hadd döntsem el én, ha akarom.


De ennek nincs semmi értelme. Miért akarod, hogy lelógjon a képernyődről az oldal? Ez olyan, mintha azt akarnád, hogy a tenyérni mobilképernyőn ugyanott legyenek a sortörések, mint az asztalin. Le lehet fejleszteni, de minek :)

Biztos több, mint 17. Főleg fekve. :)


Én az illusztráción látható elrendezésről beszélek. Az oldal tetején a fejlécből szabadon hagyott sáv pontosan 17 pixel.

Ami az eggyel nagyobb elrendezést illeti: ha több mint 638 pixel széles a kijelződ, akkor legyen 148 pixeled a fejlécre :)
37

fizikai méret, látás

Pepita · 2015. Feb. 13. (P), 08.51
Ezért kell tudni váltani.
A 638 px nem mindegy, hogy 4 cm vagy 12...

És lehet jobb vagy rosszabb szemem.

És lehet, hogy pusztán jobban tudom használni a "mini" menüt.

És még lehet kismillió oka, ami miatt indokolt a kézi váltás.

17 px: ez is felesleges.
Ok, maradjunk az iillusztráción.
Azt a telót fektetés, szélesebb lesz 638, de a magasság kisebb!
Ebből a kisebb magasságból veszel el sokkal többet. Ez nem jó.
49

+1

Szigyártó Mihály · 2015. Feb. 17. (K), 15.29
A választás szerintem is jó. Bár már nem tudom megnézni, hogy mi a különbség, de én amikor csak lehet, az eredeti oldalt használom. Ha a menü más lesz, akkor már lehet, hogy görgetni kell stb. ami macerás.
9

fasza

imehesz · 2015. Feb. 12. (Cs), 05.03
Jó ez, nyomjátok! Akik meg nem tudnak a párizsi ujjaikkal a 'v'-re taposni, használjanak tablet-et :P

Amúgy menühöz hamburger lehet tényleg jobb lenne, vagy a Materiál UI-os balról újjal húzható menü (lásd MateiralizeCSS).

Üdv... iM
16

Kösz :) A hamburger alatt is

Joó Ádám · 2015. Feb. 12. (Cs), 11.47
Kösz :) A hamburger alatt is a balról becsúszót érted, csak gombnyomásra, vagy valami mást?
11

win phone 8.1

retnek · 2015. Feb. 12. (Cs), 09.41
win phone 8.1 alatt a megjelenés és használhatóság teljesen rendben van. A megszokott weblabor designt én is felejteném. Olyan hatást kelt mint ha csak ráncfelvarrás történne akkor amikor dózer utáni teljes újjáépítés szükséges.
17

win phone 8.1 alatt a

Joó Ádám · 2015. Feb. 12. (Cs), 11.52
win phone 8.1 alatt a megjelenés és használhatóság teljesen rendben van.


Kösz, hogy megnézted!

A megszokott weblabor designt én is felejteném. Olyan hatást kelt mint ha csak ráncfelvarrás történne akkor amikor dózer utáni teljes újjáépítés szükséges.


Egy részem egyetért veled, egy másik viszont azt mondja, hogy egy amúgy is nagy átalakítás után egy ismerős látványvilág kapaszkodó a felhasználónak.

Egyelőre erre lehet építkezni, de ha később valaki előáll egy meggyőző látvánnyal, akkor semmi akadálya a váltásnak.
18

Apróság, de számomra zavaró:

pythonozok · 2015. Feb. 12. (Cs), 11.57
Apróság, de számomra zavaró: JS nélkül a "Címkék" helyén csak valami fura, unicode-os karakter jelenik meg. :(
Ezt látom:
20

Ennek nincs köze a JS-hez, az

Joó Ádám · 2015. Feb. 12. (Cs), 12.15
Ennek nincs köze a JS-hez, az egy Unicode címke karakter (U+1F3F7). Ha se a beépített betűtípusaidban nem szerepel, se egyedi betűtípusokat nem jelenít meg a böngésződ, akkor sajnos csak a fallback glyph látszik.
22

Valami köze mégis kell, hogy

pythonozok · 2015. Feb. 12. (Cs), 13.12
Valami köze mégis kell, hogy legyen, mert ha engedem a JS-t, akkor megjelenik.
23

Vagy elnézel valamit, vagy

Joó Ádám · 2015. Feb. 12. (Cs), 13.38
Vagy elnézel valamit, vagy bugos a böngésző. A JavaScript csak annyit csinál, hogy egy osztály átkapcsolásával display: none-t rendel hozzá vagy vesz el a navigációtól.
28

Egyik sem. A noscript plugin

pythonozok · 2015. Feb. 12. (Cs), 17.57
Egyik sem. A noscript plugin csinál valamit a unicode karakterekkel is, úgy mellékesen.
Hogy miért, azt nem tudom.
30

Utánanéztem, nem a

Joó Ádám · 2015. Feb. 12. (Cs), 20.43
Utánanéztem, nem a karakterekkel, az egyedi betűtípusokat (@font-face) tiltja. A beállítások közt tudod őket külön engedélyezni.
31

Hogy te miket találsz...

pythonozok · 2015. Feb. 12. (Cs), 20.52
Hogy te miket találsz... Mondjuk a gyakorlati értelmét nem igazán látom a dolognak, de a lényeg, hogy nem nálatok van a hiba. :)
(na jó, sejtem: rosszindulatú kódot mintha a fontok közé is be lehetne csempészni, ahogy pl. képekbe is)
34

A TrueType betűtípusokat egy

Joó Ádám · 2015. Feb. 12. (Cs), 21.31
A TrueType betűtípusokat egy virtuális gép értelmezi, és valaki nem bízik a FreeType Pascalról nem reentráns C-re és arról reentráns C-re átírt kódjában…
38

EM :)

szabo.b.gabor · 2015. Feb. 13. (P), 11.41
Nem akarok nagy hittérítésbe belemenni, de a css-ben px kb egy helyen kellene legyen az pedig mondjuk a body-n beállított font-size.

ahogy Pepita is írta, a felbontás már nem hordoz információt, az hogy az ájfónon megy, csak az alapértelmezett zoom-nak köszönhető, amit az ios rárak.

próbálj meg abból kiindulni, hogy egy kényelmesen olvasható bekezdés mondjuk ~35em széles, vagy akármennyi. ha van 70em-nyi hely akkor legyen desktop, a mobil nézet meg full széles de nagyjából 35em-re van belőve a betűméret.

ha em-mel csinálod meg az oldalt, akkor jöhet 8K monitor is, annyi történik, hogy a body-n felrakod 40px-re a font-size értékét és ennyi.

persze sajnos azt hiszem, hogy a media-query furán viselkedik em-ekkel, de nem biztos (mintha nem venné figyelembe a body-n beállított értéket, hanem a rendszer által beállítottat használja)

amúgy mókás nézni, ahogy állítja az ember a body-n a font-size értékét és nő, csökken minden arányosan.

szánj rá egy kis időt szerintem, akár csak kipróbálni.

nézet váltót én is raknék amúgy, bármennyire is hülyén hangzik. és lehet, hogy az alapértelmezetten megjelenő nézet típusát (ha nincs cookie-ban meg sehol) az alapján határoznám meg, hogy álló vagy fekvő módban nézik az oldalt.

mobil nézetben az a 'v' az kicsi, a header legyen akkora mint a vizuálisan megjelenő rész, és a kattintható részek töltsék ki függőlegesen teljesen és legalább legyenek olyan szélesek, mint magasak.
42

3 éve készítettem egy

Max Logan · 2015. Feb. 13. (P), 13.57
3 éve készítettem egy egyszerű, minimalista designt, amin minden em-mel volt beállítva (padding, margin, border, stb) – sajnos már nincsen meg. Így könnyű volt megcsinálni, hogy van small-normal-large gomb, ami JS-sel állítja a body betűméretét és ahogyan írod, aránytartóan zoomolod az egész oldalt.
43

Közben megnéztem tableten is,

szabo.b.gabor · 2015. Feb. 14. (Szo), 06.03
Közben megnéztem tableten is, tényleg nem kell nagyobb menü V, de egy kicsit esetleg rakd arrébb, mert volt hogy kezdőlapra ugrás lett az eredmény. Esetleg 3 vonal a V helyett jobb lehet, behúzhatnál esetleg vmi icon fontsetet
39

Az em alapú media queryket én

Endyl · 2015. Feb. 13. (P), 12.04
Az em alapú media queryket én is ajánlani tudom, mert logikusabb, ha a szöveg méretéhez igazodik az elrendezés, illetve van nézetváltási lehetőség, mert a user beállítja a számára kényelmesen olvasható betűméretet (ha nem jó az alap), és igazodik hozzá az oldal (más nézetváltásra szerintem sincs szükség, ha minden tartalom és funkció elérhető minden elrendezésen).

A menü és a lábléc linkek (betű)méretét kicsit talán nagyobbra venném, bár elég okosnak tűnnek a touch alapú eszközök, hogy kitalálják, hova is akart bökni az ember (így például a menü lenyitása szerintem nem okoz gondot).

Egyébként nekem tetszik, az pedig különösen, hogy hű a megszokott kinézethez.
40

engem az erdekelne hogy miert

gergely · 2015. Feb. 13. (P), 13.05
engem az erdekelne hogy miert emelted ki a nyomtatas segitsegehez szukseges stiluslapot. ki nyomtatja ki a weboldalt 2015-ben?!
41

Cikk

janoszen · 2015. Feb. 13. (P), 13.26
Siman van aki kinyomtat egy jo cikket. Ne tudd meg hanyszor latok embereket nyomtatott jegyzettel, kimarkerezve rohangalni.
44

Hadjáratom a margin ellen

vbence · 2015. Feb. 14. (Szo), 14.09
Az konkrét probléma

A "tablet nézetben" a tartalmat két oldalról 4 pixel fehér "margin" veszi körül. Ezen a méreten ki szokás küldeni a tartalmat teljes szélességre; én kivenném a következő szabályt:
media="screen, print"
@media screen and (min-width: 638px)
.page {
    padding: 0 4px;
}
A szélesebb felvetés

A fenti csak egyetlen példa a (jelenlegi) oldal redundáns térközeire. Ezeket a korszerüsítés jegyében eliminálnám az oldal minden nézetéből - csak fölöslegesen bonyolítják a látványt.

Persze ésszel, az adott eseteket megvizsgálva, de úgy érzem a különböző margin-padding párosok 90%át el lehetne hagyni a jelenlegi dizájnból. Jó példának ott a theverge.com vagy a gog.com - ott felfedezhető irányelv, hogy a tartalmi doboz sajátja a padding (vagy margin), nem pedig a konténer teszi rá mindenre.

A képes tartalom általában kiér a dobozok széléig, a szöveges tartalom pedig magának állítja a megfelelő térközt. A dobozok között nincs inherens térköz, legfeljebb 1 pixel border ahol szükséges.
45

Kérdések

Hidvégi Gábor · 2015. Feb. 15. (V), 10.53
Lenne pár kérdésem, de előttük egy kis elmélkedés:

Amikor nagyjából tíz éve lecseréltük a korábban használatos táblázatos modellt a div plusz css kombinációra, sorra jelentek meg a cikkek, hogy az osztályainkat szemantikusan nevezzük el, azaz ne egy jellemző alapján, hanem a szerepe alapján válasszuk meg, hogyan fogjuk hívni. Tehát nem <div class="piros">, hanem <div class="kiemelt">. Ezt azzal indokolták, hogy így, ha későbbiekben dizájnváltás lesz, akkor elég lesz a stílusdefiníciókat átírni.

Ezzel szemben a gyakorlatban dizájnváltás esetén az oldal struktúráját, valamint ezzel együtt a HTML kódot is le szokták cserélni. Az is jellemző, hogy egy dizájn általában nem szokott olyan szinten változni, hogy ami két évig piros volt, azt hirtelen átszínezik barnára.

Első kérdés: A fentiek alapján van-e értelme arra különösebb energiát áldozni, hogy css osztályainkat hogyan nevezzük el, ha következő dizájnváltáskor úgyis dobjuk az egészet?

Ádám, korábban kifejtetted, hogy a stílusdefiníciókat nem szereted konkrét elemekhez kötni, hanem osztályokat használsz. A mostani kódban például ez van <main class="main">, azaz így elég a classnevet átmásolni bármilyen elemre, és pont ugyanúgy fog kinézni.

Második kérdés: Egységen belüli egyedi elemek (main, fejléc, lábléc stb.) esetében miért használsz osztályneveket?

Joel on Software-nek van egy nagyon jó írása arról, hogy milyen hibákat nem szabad fejlesztőként elkövetni. Röviden arról szól, hogy a legrosszabb, amit tehetünk, hogy újraírunk egy kódot teljesen, mert ezzel sokat vesztünk: időt, új bugok jelennek meg és így tovább. Fontos tétele, hogy egyszerűbb kódot írni, mint a régit megérteni.

Ezt az egészet azért hozom fel, mert az új weblabornak adatbázis és működés tekintetében a régi kiterjesztésének kéne lennie (például azért, hogy át tudd importálni az adatokat különösebb erőfeszítés nélkül). Ha ez így van, akkor ...

Harmadik kérdés: miért kezdtél új fejlesztésbe?

Írod, hogy a dizájn marad hasonló (legalábbis első körben). Ha ez így van, akkor ...

Negyedik kérdés: miért írsz teljesen új HTML-t? Nem lenne elég a meglévő stílusdefiníciókat átírni/kiegészíteni, hogy reszponzív legyen az oldal?

A fentiek alapján nekem úgy tűnik, rengeteg felesleges időt öltél bele a projektbe, de legalábbis nem látom, hogy miben fog ez megtérülni. Már csak azért sem, mert öt-tíz év múlva valószínűleg megint egy új HTML/CSS fog készülni az újratervezéskor.
46

egy érdekes cikk

szabo.b.gabor · 2015. Feb. 16. (H), 09.42
hogyan kerüljük el mobil oldalakon, hogy 300ms-t késsen a click

http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
47

A kapcsolat alaphelyzetbe állt

EL Tebe · 2015. Feb. 17. (K), 11.51
Sajnos nem elérhető a fenti url-en levő tartalom:
http://igy.keszul.a.weblabor.hu/
48

"Első előzetesünk február

pythonozok · 2015. Feb. 17. (K), 13.04
"Első előzetesünk február 13-án éjfélig lesz elérhető,"
50

igaz,

EL Tebe · 2015. Már. 4. (Sze), 14.49
köszi h felhívtad rá a figyelmem
51

Az még messze lesz. :)

atomjani · 2015. Már. 20. (P), 09.19
Az még messze lesz. :)
52

Le maradtál

Pepita · 2015. Már. 21. (Szo), 16.56
Nem, mert már elmúlt...:)
53

Évszám meg volt jelölve? :D

city99 · 2015. Már. 25. (Sze), 11.14
Évszám meg volt jelölve? :D
54

@

Pepita · 2015. Már. 25. (Sze), 20.31
Jaj de kis kukacos vagy. :)
55

jahj..

EL Tebe · 2015. Már. 26. (Cs), 11.26
..jahj de raertek sracok :D
56

Fejlődés

tlof · 2015. Ápr. 9. (Cs), 19.08
A mai nap kérdése:
Eltelt két hónap azóta, hogy egy statikus, reszponziv html elkészült, kikerült, majd lekerült a webről. Ez bizonyította, hogy a fejlesztés halad.

Bennem pusztán az a kérdés merült fel, hogy mi olyan extra funkciója van jelenleg a weblabornak, amit egy wordpressel, egy 40$ -os magazin sablonnal, és egy ember egy havi munkájával nem lehetne létrehozni.

A tartalom migrálása nagy feladat, de ennyi idő alatt annak is el kellett volna már készülnie.

Amit én látok a weblaborból:
- Cikkek - Wordpress támogatja.
- Blogmarkok - Egyedi wp plugint kellene hozzá irni / keresni
- Fórum - bbpress. Amilyen ütemben a fórum pörög bőven elbirja
- Munka és állás - Vannak wp pluginok erre a célra.
- Könyvajánló - sima cikkek, esetleg egyedi post tipus.

A kérdések ezzel kapcsolatban
- Milyen alapokon folyik a fejlesztés? framework, cms?
- Mikor várható bármilyen információ a fejlesztés jelenlegi állapotáról?
- Ki végzi a fejlesztést, és hetente kb mennyi időt tud rászánni?
- Hol érhető el az új weblabor funkcionális specifikációja?
57

A Wordpress egy költséghatékony kulimász

Gixx · 2015. Ápr. 10. (P), 12.08
A Wordpress azoknak jó, akik nem értenek hozzá. Csak "telepítik" és használják. Fejlesztési szempontból viszont egy horror.

Persze mindenhez lehet plugint találni, de nem garantált, hogy ezek pontosan olyanok, amik kellenek. Akkor meg bele kell nyúlni (itt ugrik az update lehetősége), ami önmagában is borzalmas élmény azoknak, akik egy rendezett, jól dokumentált, neadjisten PSR-2 szabványhoz igazított kódokhoz szoktak.
62

Wordpress Biztonság

tlof · 2015. Ápr. 10. (P), 21.28
Az elmúlt években megjelentek igen komoly wp plugin fejlesztők, akik több éve árulják / kinálják a pluginjeiket. Gyorsan lehet velük oldalt fejleszteni, és stabilan fejlesztik is ezeket a plugineket.

Nem mindegyik lesz természetesen ingyenes, de szerintem egy 5-10$/euro -s plugint meg kell venni, ha több napi fejlesztést spórolsz meg vele.

Ha ezen múllik a dolog vállalom, hogy a legdrágább plugint mint szponzor megfinanszirozom.

https://wordpress.org/plugins/cms2cms-automated-drupal-to-wp-migration/ pl itt van a konverziós script. Ezzel rögtön megoldódna a jelenlegi tartalom migrációs probléma.

De legalább látnánk, hogy a site mozdul valamerre, nem pedig csendben tart az enyészet felé.
63

+1

bamegakapa · 2015. Ápr. 10. (P), 23.45
A Wordpresstől az ég óvjon. Sima blogmotornak biztos remek volt még régen, de aztán megfojtotta saját magát. Ekkora projektnél már kijön, miért papol mindenki a kódszervezés (és zárójelben, suttogva jegyzem meg: a modern OOP technikák) fontosságáról.
64

Nagy project

tlof · 2015. Ápr. 11. (Szo), 18.35
A weblabor miért nagy project?

Van benne legjobb esetben is 5 fajta tartalom plussz a commentek, ráadásul ha több tucat nagy hirportálnak (napi 100-200 post, pár százezer látogató) megfelel, akkor szerintem a weblabor alatt is müködni fog.

Ráadásul ez erősen szakmai sznobizmus,
hogy jaj csak wordpress-t ne


Tudod, ha azon vitatkoznánk, hogy wordpress mint platform akadályozza-e a weblabor fejlődését, vagy a jelenlegi állapotok, akkor én inkább a jelenlegi állapotokra szavazok.

Biztonság tekintetében, meg egy ősrégi agyonpatkolt Drupal, ismeretlen pluginekkel, vagy egy új wordpress 3-4 nagyobb pluginnel akkor inkább az utóbbi.
65

szerintem

zzrek · 2015. Ápr. 11. (Szo), 18.55
Elnézést az illetlenségért, de én azt mondanám, hogy az lendítene a dolgon, ha ti, hozzáértők írnátok ide egy-két cikket arról, hogy hogyan indulhatna neki egy fejlesztő a wordpress/drupal/whatever fejlesztésnek ajánlásokkal, tapasztalatokkal stb. Szóval az új tartalom hiányzik leginkább nekem. A keret az másodlagos, nekem a mostani is megfelelne.
66

Új tartalom

Arnold Layne · 2015. Ápr. 12. (V), 13.55
Szóval az új tartalom hiányzik leginkább nekem.

Nem csak neked.
67

Hogy érdemes-e fejleszteni,

Hidvégi Gábor · 2015. Ápr. 12. (V), 20.42
Hogy érdemes-e fejleszteni, attól függ, mennyire lyukas a mostani rendszer. Néha bejön egy bot, átlagosan havonta egy, azt kimoderálják, és kész. Ha nem törik fel az oldalon keresztül a szervert, ennyi kellemetlenséggel nyugodtan el lehet operálni a meglevő drupálon.

A weblabort nyilvánvalóan a tartalom hajtja. Mert mi lesz akkor, ha lecseréli Ádám HTML 5-re a kódot? Nyilván páran el fognak egy hatalmasat élvezni, amikor meglátják az új tag-eket – no, és akkor mi lesz utána? Nagyobb öröm lesz nézegetni, hogy nem érkeznek be újabb írások?

A weblabor vérfrissítése – látszólag legalábbis – menedzsmentkérdés. Lehet itt új drupál, új HTML kód, de ha nincs új tartalom, akkor csak elvesztegetett Ádám egy csomó időt az életéből, de nem léptünk előre egy centit sem. Max. egy mobil css-t érdemes csinálni.
69

+1

city99 · 2015. Ápr. 14. (K), 15.03
egy ket cikk jol jonne ;) mar csak a blogmarkoknal lehet nemi hazai szakmai megnyilvanulast latni. (hogy trollkodjak, leginkabb HG szapulasa kornyeken :D )
70

Irnek

janoszen · 2015. Ápr. 15. (Sze), 15.22
Irnek, ha nem lenne olyan irdatlanul fajdalmas es ertelmetlen. Mire beformazol egy cikket, kertszer annyi ido mint megirni es eleg keves ido alatt leporog az oldalrol es utana a kutya se talalja meg. Mit gondolsz, miert szuletett a Webtudor? OK, kicsit mas, de ott sajat belatasunk szerint tudunk tartalmat gyartani es ertelmesen katalogizalhato formatumban kerul eltarolasra.
71

Be lehetne vezetni egy olyat,

Hidvégi Gábor · 2015. Ápr. 15. (Sze), 15.28
Be lehetne vezetni egy olyat, hogy a cikkek legyenek ragadósak az oldal tetején mondjuk egy hónapig (mint pl. a web konferencia hirdetése).
72

Nem az ötletekben van a

inf · 2015. Ápr. 15. (Sze), 15.41
Nem az ötletekben van a hiány, hanem a megvalósításban.
73

Van olyan

janoszen · 2015. Ápr. 15. (Sze), 17.42
Van olyan, de egy ido utan akkor is eltunik a sullyesztoben. Plane ha tobb cikk is van. Gondolj bele, nekem jelenleg a Webtudor _heti szinten_ 4-8 munkaora. Szerinted hany cikket tudnek en ez alatt az ido alatt irni?
68

A nagy projektet a

bamegakapa · 2015. Ápr. 12. (V), 22.56
A nagy projektet a Wordpressre értettem.
58

Van bármi garancia arra, hogy

inf · 2015. Ápr. 10. (P), 12.14
Van bármi garancia arra, hogy az innen-onnan berántott plugin-ek nincsenek tele biztonsági résekkel?
59

Mert

janoszen · 2015. Ápr. 10. (P), 12.26
Mert egy agyontakolt, ezereves Drupallal mi? :) Erted, ezt barmirol el lehet mondani.
60

Drupal talán kevésbé

pythonozok · 2015. Ápr. 10. (P), 12.29
Drupal talán kevésbé rosszhírű e tekintetben ;)
61

Biztos van olyan rendszer is,

inf · 2015. Ápr. 10. (P), 16.23
Biztos van olyan rendszer is, aminek jó híre van ilyen téren. Ha jól tudom, akkor tipikusan nem az alap rendszerekkel szokott a gond lenni, hanem a 3rd party pluginekkel, amiknél erre sokszor nem fordítanak kellő figyelmet.
74

észrevételeiteket pedig

webproghu · 2015. Ápr. 20. (H), 13.33
észrevételeiteket pedig írjátok meg nekünk


Én észrevettem, hogy azóta semmi nem történt.
Most komolyan, miért nem lehet a közösség kezébe adni az oldal fejlesztését, ha a jelenlegi üzemeltetői konkrétan már semmit nem hajlandóak tenni vele? (ne áltassuk tovább magunkat, van ígérgetés, persze, de történt azóta bármi is?)
Vagy legalább átadni olyannak aki foglalkozna vele?
75

Menü

Delde · 2015. Dec. 1. (K), 13.45
A desktopos nézeten lehetne fixed a menü, akkor mindig a felhasználó keze ügyében lenne és nem kellene folyton felfelé vagy épp lefelé görgetni. Vagy mondjuk egy to top, to bottom nyilacska kéne, ha a menü nem megoldható :)

Összeségében nekem mint felhasználónak nincsenek problémáim az oldallal, ami van az meg semmiség, legalább is nem bosszant annyira hogy kiakadjak rajta. Mostanában az embereknek mindenben olyan nagy igénye van (nem csak a weboldalak tekintetében), ami követhetetlen és nem lehet mindenkinek megfelelni. Mondjuk a zöld csíkos design helyére lehetne valami modernebb, de igazából engem az se zavar ha ez marad meg :)