ugrás a tartalomhoz

Webes felületet kéne csinálni, mi a trend 2013-ban?

ern0 · 2013. Júl. 2. (K), 22.20
Van egy rendszer, az app maga serveren fut, ennek kellene UI-t csinálni. Nem egy kirívó eset. Az már látszik, hogy egy webes felület lenne a legjobb, mert akkor csak egyszer kellene lefejleszteni, egyszerű az upgrade stb. stb., de azért ez ennyire nem egyszerű. Kérdéseim a hajtás után.

Bemelegítésnek először a könnyen megválaszolható kérdéseket teszem fel, aztán az egyre nehezebbeket:

1. Milyen böngészőket támogassunk? A Windows XP-hez, ami még elterjedt operációs rendszer, MSIE6-ot adtak. Viszont az szar, mert semmi nem úgy van rajta, ahogy kéne. Mondhatjuk azt az MSIE6 felhasználóknak, hogy töltsön le valami értelmes browsert?

2. A későbbi MSIE verziókról se tudok sokkal kedvesebben nyilatkozni. Mondhatom, hogy Firefox/Chrome/Safari kell? Nem fog ez gondot okozni "konzervatív vállalati környezet" esetén, ahol senki semmit nem installhat, és az IT-n baromi nehéz átverni bármit is?

Olyan UI-t akarok, ahol a kép méretéhez illeszkednek az UI elemek, mondjuk telefonon a lista elfoglalja a teljes képernyőt, az itemre tappolva jön fel a details, ugyanez desktopon egyszerre látszik, bal oldalt az item lista, és amelyikre rábökök, annak a details-e kerül jobb oldalra. Tabletet elforgatom, és átrendeződnek a panelek, mindig kitöltik a teret. Responsive design magyarul.

3. A jegyzőkönyv kedvéért felsorolom azokat a technológiákat, amelyek nem mindenhol elérhetők, ezért fájó szívvel, de hanyagolni kell őket: Flash (ennek a hanyagolása azért annyira nem zavar), WebGL, SVG.

4. A megjelenés módját pixel felbontásra csekkolni nem elég, mert ezeken az újabb csodatelefonokon kis felületen rengeteg pixel van (Retina pl.). Honnan lehet megtudni a képernyő fizikai méretét? Vagy DPI-t? vagy bármit? Samsung Galaxy S4-en és iPhone5-ön a mobiltelefonos verziót szeretném látni, nem pedig a desktopos/tableteset miniatűrben.

5. És hát a végső kérdés az, hogy melyek azok a framework-ök, megoldások, amelyekkel egy ilyen responsive app-nak érdemes nekiugrani? Nem szeretnék 3-4 appot lefejleszteni (telefon, tablet, desktop), hanem valahogy úgy akarom organizálni a paneleket, hogy a lehető legkevesebbet kelljen a képernyőméret különbözőségével törődnöm. Nem kell pixelpontos design, hiszen egy app lesz csak, nem website.

Ritkán kérdezek, de akkor izmosat. Persze már kerestem válaszokat, de még nem vagyok teljesen elégedett azzal, amire magamtól jutottam. Ha esetleg a sorba illeszthető kérdés van, mert megfeledkeztem valamiről, az is jöhet.
 
1

Nem mindenre

Pepita · 2013. Júl. 2. (K), 23.22
merek válaszolni, de:

1-2. XP-hez IE8-at, nem olyan szar az. Mindjárt mentesülsz is attól, hogy vmit árnyékolnod, kerekítened kelljen, és ha kell valami wysiwyg szerkesztőt is beépítened, a régebbiek ezen futnak, IE9-10-en kevésbé. És kevesebbet kell nyűglődnie a rendszergizdának az upgrade-del. Szerintem ne forgass semmit, hagyd a Júzerre, mit akar. Esetleg sütibe tárolgasd a beállításait, hogy amikor újra jön, ugyanazt kapja.

3. Ez nem is kérdés.

4-5. Jól gondolod, ajánlom figyelmedbe, indulásnak jó, de muszáj leszel szerintem 2-3 frontendet csinálni. Fontos, hogy engedd választani a Júzert a különböző variációk közül, ne akarj mindenképp erőltetni dolgokat. Ha ki akarja próbálni Opera Mini-n (:)) az asztali nézetet, hát tegye! Ezen kívül én nem ismerek 100%-os megoldást eszközfelismerésre, és ne felejtsd el, hogy újabb és újabb eszközök jönnek ki.
2

Responsive dizájn témakörben

MadBence · 2013. Júl. 2. (K), 23.54
Responsive dizájn témakörben vannak keretrendszerek, bootstrap, foundation grid rendszere képes kezelni a telefon/table/desktop rendszereket. Dunát lehet velük rekeszteni.
3

Ha úgy döntenél, a régi

bamegakapa · 2013. Júl. 3. (Sze), 10.00
Ha úgy döntenél, a régi IE-ket nem támogatod, akkor az SVG-t érdemes mégis megfontolni. Az IE9 már tudja, elég jó a támogatottság. És persze mindig ott a lehetőség, hogy a régi IE-knek más képformátumot szolgálj ki.
4

1. Milyen böngészőket

inf · 2013. Júl. 3. (Sze), 10.06
1. Milyen böngészőket támogassunk? A Windows XP-hez, ami még elterjedt operációs rendszer, MSIE6-ot adtak. Viszont az szar, mert semmi nem úgy van rajta, ahogy kéne. Mondhatjuk azt az MSIE6 felhasználóknak, hogy töltsön le valami értelmes browsert?


Az attól függ, hogy milyen felhasználók köre. A másik, amitől függ, hogy milyen a technikai megoldása a dolognak. CORS csak IE10-től támogatott, és kényelmesebb azt használni, mint jnsonp-t. Belső céges alkalmazásnál nyugodtan mondhatsz bármit, mert néhány emberről van szó, akik tudnak alkalmazkodni a körülményekhez. Ha webre megy, ott már problémásabb a helyzet. IE 6-8 támogatása nehézkesebb, de vannak erre jól bevált lib-ek, amik segítenek. Pl html5 shiv, css3 pie, meg hasonlók. Én nem használtam ezeket, nem szívesen állnék neki IE9-nél alacsonyabb verzió támogatásának. Szerintem nem tudják megfizetni.

2. A későbbi MSIE verziókról se tudok sokkal kedvesebben nyilatkozni. Mondhatom, hogy Firefox/Chrome/Safari kell? Nem fog ez gondot okozni "konzervatív vállalati környezet" esetén, ahol senki semmit nem installhat, és az IT-n baromi nehéz átverni bármit is?

Az IE9 körülbelül annyit tud, mint egy firefox, egyedül a CORS nem támogatott, de már követi nagyjából a szabványt. Az a gond, hogy XP-n IE8 a maximum, amit lehet, szóval ott muszáj feltenni egy firefox-ot vagy chrome-ot, vagy támogatni kell IE8-at, de akkor meg már a többi alacsonyabb verziót is lehet, mert egyformán silányak.

4. A megjelenés módját pixel felbontásra csekkolni nem elég, mert ezeken az újabb csodatelefonokon kis felületen rengeteg pixel van (Retina pl.). Honnan lehet megtudni a képernyő fizikai méretét? Vagy DPI-t? vagy bármit?


Úgy, hogy rákeresel: http://stackoverflow.com/questions/476815/can-you-access-screen-displays-dpi-settings-in-a-javascript-function

5. És hát a végső kérdés az, hogy melyek azok a framework-ök, megoldások, amelyekkel egy ilyen responsive app-nak érdemes nekiugrani?


Ha van rá keret, akkor vegyél extjs-t. Ha nincs, akkor van rengeteg ingyenes megoldás. Az a közös bennük, hogy közel sem olyan átfogóak, inkább alapkoncepciót adnak, az UI komponenseket meg sok esetben neked kell megírnod kézzel. Én backbone-t használok, de kénytelen voltam hozzáírni validatort meg ui komponenseket is, mert nem voltam megelégedve azokkal, amik adottak voltak. Írtam egy browser detect-et is, ami browsehappy toolbar-hoz hasonló valamit tesz ki. Van még a requirejs, amit érdemes használni. Szóval nálam ilyen a lista jelenleg:

  1. https://github.com/inf3rno/browsehappy-toolbar
  2. http://requirejs.org/
  3. https://github.com/tyt2y3/requirejs-css-plugin
  4. https://github.com/requirejs/domReady
  5. http://underscorejs.org/
  6. http://jquery.com/
  7. http://backbonejs.org/
  8. backbonerelational.org
  9. https://github.com/joestelmach/laconic
  10. http://momentjs.com/
  11. perka.github.io/backbone-ui
  12. https://github.com/inf3rno/bb-validation-nek egy űrlapok terén jóval fejlettebb változata


Ehhez szerver oldalról JSON REST service szolgáltatja az adatot egy másik domain-ről, szóval CORS-t használ. Van még ezen kívül egy rakat másik MVC rendszer javascripthez, nézd meg, hogy neked melyik tetszik, aztán használd azt. Általában sablon html-eket használnak, ami nekem nem jön be, azért ragadtam le ennél a backbone.UI-s megoldásnál. Elvileg r.js-el szépen egybe lehet csomagolni a külső libeket, amiket betöltesz, de nem vagyok benne biztos, hogy szükség lesz rá. Amíg fejlesztek, addig nocache van a kliensek, utána felteszem a cache-t, és csak a REST service-en lesz nocache. Maga a kliens kizárólag statikus fájlokból áll szerver szempontjából, ami elég keményen csökkenteni fogja a betöltési idejét... Ezekkel a megoldásokkal max úgy tudnád megtámogatni IE9-et, az alacsonyabb verziókat, meg minden mást, hogy írsz egy szerver oldali klienst nekik a rest service-hez, ami egy hagyományos html oldalt ad. Körülbelül mint a gmail-nél van. Nyilván ez lassabb és körülményesebb lenne, de megoldható vele a dolgok nagy része. Nekem is 3 kliensem lesz attól függően, hogy kiknek szól. Ebből az egyik lesz kliens oldali, egy másik szerver oldali a harmadikat meg még nem döntöttem el, valószínűleg az is szerver oldali, hogy ne kelljen napi 3x elmagyarázni, hogy hogyan kell böngészőt telepíteni...
5

Ez a CORS milyen előnyökkel

Hidvégi Gábor · 2013. Júl. 3. (Sze), 10.18
Ez a CORS milyen előnyökkel rendelkezik a hagyományos megoldásokhoz képest? Azaz inkább az a kérdés, hogy miért akarna saját alkalmazáshoz más szerverről lekérni adatokat?
6

Gyakorlatilag semmivel. Nekem

inf · 2013. Júl. 3. (Sze), 10.21
Gyakorlatilag semmivel. Nekem így tisztább a kép, külön repo-ba tudom tenni a klienst és a szervert, nem keveredik sehogyan sem a kódjuk. Ugyanezt meg lehet csinálni egy htaccess fájllal és almappákkal azonos domain-en is. Nálam a legtöbb funkciót tartalmazó kliens localhoston (úgy értem az aktuális felhasználó gépéről, és nem webről) fog menni, szóval ott mindenképp szükség lesz a CORS-ra.
7

Ezt nyugodtan odaírhattad

Hidvégi Gábor · 2013. Júl. 3. (Sze), 10.30
Ezt nyugodtan odaírhattad volna az eredeti hozzászólásodba, mert nem zavar mindenkit (~ a túlnyomó többséget), ha "keveredik" a kliens- és a szerveroldal, lehet őket teljesen külön mappába tenni.

Ha localhostról fut a kliens, hogyan oldod meg a frissítését?
9

Többféleképp meg lehet

inf · 2013. Júl. 3. (Sze), 10.55
Többféleképp meg lehet oldani. A legfapadosabb, hogy elküldöm email-ben az új verziót, a legjobb meg hogy jelez a kliens ha van új verzió, aztán automatikusan feltelepíti. Ehhez mondjuk már kelleni fog más nyelv is, amihez van kész telepítő megoldás. Ebbe még nem gondoltam bele komolyabban, hogy melyiket kéne.
10

A hagyományos HTTP fejléces

Hidvégi Gábor · 2013. Júl. 3. (Sze), 11.02
A hagyományos HTTP fejléces ellenőrzéssel mi a gond, ha ígyis-úgyis a szerverhez kell fordulni adatokért? Biztos azért van, mert el szeretnéd különíteni a kliens- és szerveroldali kódot, erre egyébként mi motivál?

Ne vedd sértésnek, de én eddig bármit láttam tőled, feleslegesen túlbonyolítottnak éreztem. Persze nem ismerhetek minden körülményt, hogy miért is döntöttél úgy, ahogy.
11

Az motivál rá, hogy két külön

inf · 2013. Júl. 3. (Sze), 11.08
Az motivál rá, hogy két külön dologról van szó. Egy szerverhez tartozhat tetszőleges számú kliens, mint a mellékelt ábra is mutatja... Az ízlés kérdése, hogy ki mit érez túlbonyolítottnak, én szeretem a bonyolult dolgokat...

szerk:
A halálcsillag készülőben van :D
13

Részletes

Pepita · 2013. Júl. 5. (P), 00.56
Szerintem inkább túlrészletezed-bontod a dolgokat, ami nem feltétlenül baj. Viszont szerintem több idő (hosszútávon is), de ha így érzed jónak és még anyagilag is kijön (=megfizetik), akkor miért ne?
14

Hát figyelj, ha bolygókat

inf · 2013. Júl. 5. (P), 09.29
Hát figyelj, ha bolygókat lőhetek szét vele, már megéri :D

Anyagilag úgy érné meg, ha leragadnék egy technológiánál, és mindent azzal valósítanék meg. Az a bajom, hogy szeretek tanulni, és az ilyet nagyon hamar elunnám. Nem nekem való ez a szakma...
15

Halálcsillag

T.G · 2013. Júl. 5. (P), 10.01
Na, de azt ugye tudjátok, hogy nem éri meg halálcsillagot építeni? :)
A Halálcsillag Design Pattern
16

Az új technológiák

Hidvégi Gábor · 2013. Júl. 5. (P), 10.06
Az új technológiák megtanulása egy irány, a meglévők finomítása egy másik. Én az utóbbira mentem rá, nevezetesen arra, hogy minél hatékonyabb legyen a kód mind memória-, mind pedig sebességügyileg. Egy százezer forintos hardveren futtatni egy szolgáltatást nem nagy kunszt, de mondjuk egy tízezresen már kihívás.
17

no de akkor miért szöszölsz

szabo.b.gabor · 2013. Júl. 5. (P), 10.50
no de akkor miért szöszölsz még php-val, mikor a node js-sel sokkal hatékonyabb tudsz lenni?
18

1, a meglévő környezetből

Hidvégi Gábor · 2013. Júl. 5. (P), 11.19
1, a meglévő környezetből kell kihozni a legjobbat, ami épp PHP
2, próbálkoztam node.js-sel, de két perc alatt átláthatatlan kódot eredményezett a sok callback, ráadásul az alkalmazásunk jellege miatt csak nagyon kevés dolog párhuzamosítható, ráadásul azok sem jósolhatóak a legtöbb esetben
3, mivel a node.js-t csak a lekvárok használják, ezért C-ben kezdtem el újraírni a kódot : )
19

:D

szabo.b.gabor · 2013. Júl. 5. (P), 11.21
:D
20

Nem vagy egyedul

complex857 · 2013. Júl. 6. (Szo), 01.16
3, mivel a node.js-t csak a lekvárok használják, ezért C-ben kezdtem el újraírni a kódot : )

Úgy tűnik nem vagy egyedül ezzel az elképzeléssel, itt van pl egy speedy képes webszerver ami direkt C -ben írt appok supportjával pórbál kiemelkedni a tömegből: https://kore.io/ :-P
21

Köszönöm

Hidvégi Gábor · 2013. Júl. 6. (Szo), 06.53
Több szempontból is szimpatikus:
- C
- kiemelten támogatja az OpenBSD-t
- a licensz
A készítője rossz ember nem lehet.
8

böngésző

Poetro · 2013. Júl. 3. (Sze), 10.46
Én nem támogatok semmit IE9 alatt. Főleg mivel WinPhone 7.5 óta elérhető, a több mobilon meg tableten meg WebKit van. Mondjuk, hogy melyik WebKit az nem mindegy, mert azzal azért lehet küzdeni, főleg CSS szempontjából. iPhone / iPad / iPod esetén minimum iOS5, ugyanis alatta elég gyenge a JS /CSS támogatás. Android esetén pedig minimum 2.3 bár azzal is vannak azért néha komoly CSS / JS gondok. Asztali böngészők esetén pedig korszerű Firefox, Chrome, Safari (4+), IE (9+), Opera (12+) illetve amik ezekre épülnek.

Régebbi böngészőkkel ugye a szokásos CSS / JS / HTML problémák jöhetnek elő, amiknek egy részét nehéz debuggolni, a polyfill-ek sok teljesítményt elvesznek és nagyok (és szintén nehéz őket debuggolni).

Ha érintés eseményeket is akarsz kezelni, akkor Windows 8 alatt elég komoly problémákba fogsz ütközni. IE10 Pointer eseményeket kezel (a szokásos egér mellett). Minden más meg touch eseményeket és egér eseményeket. Szóval a dolgokat többféle képpen is meg kell oldani. Érintés képes eszközöknél pedig az aktív elemeket nagyobbra kell venni, hogy meg lehessen őket célozni.

Különbséget tenni mobil és tablet között nem egyszerű, mivel mindkettő mobil eszköznek azonosítja magát. A felbontásra pedig talán megoldást jelenthet a
<meta name="viewport" content="width=device-width, target-densitydpi=device-dpi">
12

A Windows XP-hez, ami még

Hidvégi Gábor · 2013. Júl. 4. (Cs), 08.21
A Windows XP-hez, ami még elterjedt operációs rendszer, MSIE6-ot adtak. Viszont az szar, mert semmi nem úgy van rajta, ahogy kéne. Mondhatjuk azt az MSIE6 felhasználóknak, hogy töltsön le valami értelmes browsert?
A (legfrissebb) Chrome sokkal bugosabb, jóval több kivételt kellett miatta tenni, mint például az IE6 miatt, ezer apróságban külön utakon járnak.