Smartweb e un eveniment anual dedicat designerilor, dezvoltatorilor și antrepenorilor din Europa de sud-est. Anul acesta, datorită revistei Today Softwere Magazine, am avut ocazia să particip și eu la Smartweb, eveniment organizat de Evensys și desfășurat la București. Evenimentul este alcătuit din două părți care au loc pe durata a două zile: în prima zi se țin, în paralel, două workshop-uri de câte opt ore, iar în a doua zi, se desfășoară o conferință cu prezentatori de talie mondială. Anul acesta la București au fost prezenți Jeremy Keith, Kaelig, Marko Dugonjic, Harry Roberts, Remy Sharp, Zoe Gillentwater, Ana Tudor și Bruce Lawson. Prezentările lor au tratat teme ca responsive design, Html, Css, Javascript și standarde web.
Jeremy Keith este autorul cărților "Bulletproof Ajax", "DOM Scripting" și "HTML5 for designers". Acesta a venit cu propunerea: website-urile nu trebuie să arate la fel pe toate browser-ele. Susține că este acceptabil ca anumite elemente să apară diferit pe unele browser-e, în principiu pe versiunile mai vechi care nu vor mai fi folosite foarte mult timp de acum încolo. Dezvoltatorii ar trebui să se orienteze cu prioritate înspre funcționalitatea unui website, apoi asupra formei. Utilizatorii își aleg browser-ele și dispozitivele în funcție de necesități și rezoluție agreată. Ar trebui să le respectăm aceste decizii prin construirea unor website-uri adaptabile și receptive.
Ne sfătuiește să ne investim timpul în versiunile mai noi , să fim "future friendly" și a dat ca exemplu în acest sens primul website apărut vreodată: http://info.cern.ch/hypertext/WWW/TheProject.html. Website-ul a apărut în 1989 în cadrul unui institut de cercetare nucleară din Suedia. Deși primele pagini nu au un design modern, dar funcționează și pe browser-ele de azi cu același scop cu care a fost creat la început (de-a lungul timpul s-au adăugat și pagini cu un design modern).
Se așteaptă ca developer-ii să înțeleagă că diferențele dintre browser-e sunt o trăsătură a webului și trebuie luate ca atare. Adevărata problemă stă în înțelegerea acestor diferențe, iar soluția ar fi să ne convingem clienții, chiar și managerii de proiect de acest fapt. Vă doresc succes în a convinge echipa de testare. În acest sens, există un website http://dowebsitesneedtolookexactlythesameineverybrowser.com/ care ne poate ajuta să ne susținem punctul de vedere.
Fiind de acord cu propunerea lui Jeremy, amintesc și ceea ce spune Brad Frost într-un articol pe o tema similară:
"există o mulțime de versiuni diferite de Blackbery și nu este suficient timp într-o zi pentru a face un website să arate consistent pe fiecare versiune."
Datoria noastră ca developer-i rămâne să oferim utilizatorilor o experiența decentă pe website-ul pe care îl construim, pe diversele browser-e.
Kaelig a fost front-end developer la ziarul online http://www.theguardian.com/uk și autorul cărții "Css maintenable with Saas". La theguardian.com contribuie treizeci de ingineri din diverse părți ale lumii doar pe partea de Css și Html, iar codul css are aproximativ 25000 de linii. Ne-a povestit cum s-a redus decalajul în comunicare dintre developer-i și designeri în cadrul theguardian.com cu ajutorul Saas. Acesta din urmă este un preprocesor CSS care adaugă programare CSS-ului prin utilizarea funcțiilor, operațiilor și variabilelor. La theguardian.com sunt utilizate destul de multe fonturi și culori astfel încât să devină dificilă folosirea numelor acestora în Css. Prin declararea variabilelor ca în exemplul de mai jos, în Saas se poate defini un anumit font o singura dată, iar mai departe poate fi utilizată variabila care îi conține numele fără a reține fiecare nume de font:
$font-stack: Helvetica, sans-serif;
body {
font: 100% $font-stack;
}
Se pot imbrica selectorii la fel ca în HTML pentru o mai bună vizualizare a ierarhiei elementelor. Blocurile de declarații pot fi reutilizabile prin mixins, pot avea chiar și parametrii de intrare și pot fi folosite mai târziu cu directiva @include
, de exemplu:
@mixin border-radius($radius) {
-webkit-border-radius: $radius;
-moz-border-radius: $radius;
-ms-border-radius: $radius;
border-radius: $radius;
}
Se mai pot crea în Saas fișiere parțiale în care se poate păstra o bucată de stil refolosibilă; fișierele vor avea _
în fața numelui, extensia .scss (exemplu _header.scss) și se pot folosi în fișierele CSS principale, cu directiva @import
plus numele parțialului (exemplu: @import 'header';
). Se poate face uz și de avantajele moștenirii în Saas:
.message {
border: 1px solid #ccc; padding: 10px; color: #333;
}
.success {
@extend .message;
border-color: green;
}
Revenind la theguardian.com, care în trecut avea parte de aproximativ 20 de lansări pe an, azi a ajuns la patru lansări pe zi. În acest context, o comunicare eficientă și bine organizată pare mai mult decât necesară pentru succesul website-ului, astfel încât cei care lucrează la theguardian.com au pus cap la cap o matrice de fonturi pe care le utilizează frecvent și în care și-au notat pentru fiecare font folosit în diferite secțiuni ale paginii (titlu, subtitlu, corpul articolului, etc) valori pentru: numele fontului în Photoshop, numele real al fontului din Css, un nume abstract pe care developer-ii îl folosesc în denumirea variabilelor și o a patra denumire "prietenoasă" folosită în discuții și ședințe.
Marko Dugonjic din Croatia este fondatorul website-ului http://www.creativenights.com/, editor la revista Smashing Magazine și coautor al cărții "The Smashing Book #4". Prezentarea lui a avut ca țintă înlocuirea conținutului de tip lorem ipsum cu prototipuri de conținut. Atunci când nu cunoaștem ce fel de conținut va avea website-ul pe care îl construim, cel mai probabil vom porni cu un design generic.
Primul pas recomandat de el este să facem orice pentru a colecta conținut din: broșuri, rapoarte, întrebări frecvente din domeniul companiei pentru care se implementează website-ul și să ne interesăm personal despre compania respectivă. Dacă avem șansa să vizităm sediul clientului, consideră că e bine să avem un aparat de fotografiat pentru a face poze la logo-urile prezente în sediu care ajută atât în stabilirea designului, culorilor, cât și în transformarea lor în resurse. Crede că e o idee bună să furăm conținut de la competitorii clientului nostru, pentru a-i servi clientului ca punct de plecare în formularea conținutului propriu: va încerca să își depășească competiția, să vină cu un conținut mai bun. Recomandă stabilirea timpurie a duratei de viață a conținutului: poate exista conținut permanent (profil, date de contact) și poate exista conținut temporar, format din campanii sau promoții. Putem să stabilim de la început scheletul viitoarelor pagini în CMS, dacă folosim unul, și ar fi important să nu adăugăm nici un fel de design în această fază, pentru a lăsa la vederea clientului că pagina respectivă nu e finalizată; altfel, dacă o pagină are un oarecare design implementat, clientul are tendința de a considera pagina respectivă finisată și o va ignora, chiar dacă implementarea funcționalității nu este finalizată. De mare ajutor ar fi implementarea autentificării încă de la început si asignarea de roluri clientului, pentru a împărți cu acesta responsabilitatea de a naviga și umple golurile din conținut cât mai devreme.
Odată ce avem schițele de mai sus, putem stabili mult mai ușor arhitectura website-ului și designul optim pentru a scoate conținutul cât mai bine în evidență. Putem, în acest moment, să stabilim șabloanele conținutului. Marko ne recomandă să distribuim conținutul gradual pe pagină, în funcție de experiența posibililor utilizatori. Pentru utilizatorii noi ar trebui grupată informația în porțiunea din pagină cea mai accesibilă vizual. Pentru utilizatorii intermediari ne recomandă o alta porțiune a paginii. Pentru utilizatorii frecvenți, care sunt deja familiarizați cu website-ul și care știu deja unde vor găsi informația de care au nevoie, este acceptabil să le acordăm o porțiune retrasă a paginii. Tot pentru a grada conținutul ar fi bine să ne folosim de meta data unei pagini și să includem acolo informații concise pentru utilizatorii noi. Pentru o navigare cât mai ușoara în cadrul website-ului, Marko recomandă crearea unui ghid pentru utilizatorii noi, cu pași simpli și clar explicați, iar dacă sunt implicate metode de plată, consideră că ar fi bine să expunem explicația desfășurată și pentru acestea și să ținem seama cât mai devreme de șabloanele pentru acest tip de conținut. Putem lua în considerare un șablon pentru un glosar în care să punem la dispoziție definiții pentru termenii din domeniul în care se încadrează website-ul, și alt șablon pentru a prezenta istoricul companiei. Se vehiculează că afișarea profilurilor angajaților companiei pe website cu informații succinte despre activitatea, educația și, cel mai important pasiunile lor, ar umaniza compania respectivă.
Următorii pași pe care îi recomandă sunt utilizarea unor imagini de rezoluție înaltă și implementarea anticipată a unor limite configurabile de conținut.
Pentru conținutul temporar, destinat clienților fideli, consideră că ar fi optim să stabilim cât mai devreme cu clientul:
Având posibilul conținut cât mai devreme, realizăm o arhitectură stabilă, putem seta așteptările clientului cât mai repede și mai presus de toate design-ul va fi unul specific.
Remy Sharp este fondatorul conferinței despre Javascript din UK, "Full Frontal", co-autor al cărții "Introducing HTML5" și unul din administratorii Html5Doctor.com. Ne-a făcut o mică demonstrație în NodeJS a unei aplicații în timp real, în testarea căreia a implicat participanții la conferință.
Harry Roberts, autor a numeroase articole pe teme de UI, a ținut o prezentare a framework-urilor CSS prin comparație cu toolkit-urile UI cu care sunt adesea confundate. Un framework Css este evident un framework care facilitează lucrul cu Css oferind câteva instrumente ajutătoare, dar nu complete. Exemple de framework-uri CSS sunt: Bootstrap, Foundation și Inuit CSS. A colectat personal motivele pentru care acestea sunt evitate: au prea multe avertismente, prea multe opinii, nu oferă instrumente complete. Aparent nu este înțeles exact scopul framework-urilor CSS: un framework CSS este util pentru proiecte unice, în care avem nevoie să scriem de la zero o soluție particulară, specifică, avem deci nevoie de "o mână de ajutor". Dacă framework-urile Css existente nu ne oferă ceea ce avem nevoie, ne recomandă implementarea propriului CSS framework în favoarea personalizării unui UI toolkit.
Zoe Gillentwatter , de la Booking.com a vorbit despre avantajele lui CSS3 Flexible Box (sau flexbox), un mod foarte eficient de a așeza elementele html în cadrului unui container, raportându-le coordonatele sau direcția la acesta. Elementele se pot extinde sau comprima pentru a se încadra cât mai bine în container-ul părinte. Deși are o acoperire destul de mare, nu toate browser-ele îl suportă încă. Este implementat de către FF18+, Chrome 21+, IE11, Opera 12.10+, Safari 6.1 și în unele dintre browser-e trebuie precedat de --webkit. Ne-a dat ca exemplu spațierea antetului unui tabel cu table-layout:fixed
. Ca celule, coloanele tabelului vor fi astfel la distanță egală una de alta. Dar dacă privim doar textul dinăuntrul lor, care evident că nu va avea aceeași lungime în fiecare celulă, textele vor fi la distanțe diferite două câte două.
Flexbox are soluția pentru această problemă cu următoarele două proprietăți aplicate pe container:
display: flex;
justify-content: space-between;
Ana Tudor a fost singura prezentatoare româncă de la conferință. Titlul prezentării sale a fost "CSS use and abuse". Utilizând Codepen, un "teren de joacă" pentru web designeri, în care se poate folosi HTML, CSS, și JavaScript, ne-a facut câteva demonstrații de animații 3d în CSS3, fără Javascript. A amintit de exemplul tabloului Mona Lisa creat în CSS pur cu peste 7500 de linii de cod: http://cssdeck.com/labs/mona-lisa-with-pure-css. A implementat un poliedru expandabil, un icosidodecaedru 3D, rotația unei suprafețe elastice curbate, o animație de sezon: o figură ce aduce cu un dovleac de Halloween care sare pe axa x și se expandează și se contractă la limitele axei, și altele. Munca ei poate fi găsită la adresa http://codepen.io/thebabydino/.
Ultima prezentare a fost una foarte amuzantă, aparținând lui Bruce Lawson, care a fost și gazda evenimentului. Este co-autorul cărții "Introducing HTML 5", face parte din organizația Web standards project și lucrează în prezent la Opera. În cadrul prezentării a făcut un sumar al momentelor importante din istoria standardelor web într-o manieră umoristică. Ne-a prezentat momentul din 2009 când HTML5 a câștigat bătălia cu XHTML2 nu pentru că HTML5 încearcă să suporte browser-ele vechi ci pentru că acesta suportă conținut vechi. Ne-a atras atenția asupra unei greșeli ciudate din HTML3.0 în care a apărut un element nou, <figure>
, care includea și elementul <caption>
dar aceasta combinație nu a funcționat. Motivul a fost acela că în versiunile anterioare, <caption>
era creat să funcționeze doar în cadrul elementului <table>
, așa că s-a înlocuit cu elementul <figcaption>
în HTML5.
Întreaga conferință a fost captivantă, informativă, bine organizată și mi-a lăsat impresia că nu s-a adresat doar developer-ilor și designerilor, ci au fost informații utile pentru oricine din domeniul IT. Sponsorii de la booking.com au lansat o provocare: primul care a realizat stema Amsterdamului în CSS și HTML a câștigat o excursie la Amsterdam. Am avut ocazia să schimb impresii cu colegii de branșă din București. Numărul de participanți a fost foarte mare, câteva sute de persoane, de unde înțeleg că a fost un succes și în anii trecuți. Prezentatorii au fost relaxați, foarte bine pregătiți atât cu demonstrațiile tehnice și sfaturi (pe care încerc să le aplic mai departe în proiectele la care lucrez) cât și cu exemple clare, interesante și ultimele tendințe din domeniu. Mulțumesc revistei Today Software Magazine pentru invitația la conferință și vă recomand să participați la ediția viitoare!