Monday 22 December 2008

JavaScript în Tema3IE

Tema 3 la Interfeţe Evoluate ne-a cerut să scriem, folosind Javascript pentru scripting, un webbased thingie care sa faca highlight pe cuvinte / fraze dintr-o pagina web, încărcată dinamic (eventual folosind Ajax). Ceva foarte simplu, menit să ne familiarizeze, presupun, cu Javascript.

Eu fug de Javascript încă de la începuturile experimentărilor mele web-astice, pentru ca ce am văzut atunci arăta foarte foarte aiurea pentru mine. E drept, cred, ce se spune despre Javascript, că e un limbaj Ok de scripting, dar care e folosit în cel mai hidos mod. Acum ceva vreme era folosit pentru nenorociri de-alea de animaţii de prost gust, ceasuri ascii care fug după mouse şi alte nenorociri care nu au ce căuta într-o intefaţă bună.

Acum vedem însă tot mai puţine utilizări negative (cel puţin din punct de vedere vizual) a Javascript, şi tot mai multe exemple pozitive. Nu ştiu exact istoria, şi sunt sigur că o călătorie scurtă pe wikipedia vă poată lămuri mai bine ca mine, dar eu cred că Javascript a început să devină widely accepted ca un limbaj de scripting serios odată cu trecerea la Web2.0, care, printre alte calităţi, se defineşte prin interfeţe web mult mai responsive. Dezvoltarea Javascript-ului ca limbaj a permis Web2.0 să existe, şi, la fel, nevoia de creştere a calităţii interfeţelor a dus la dezvoltarea limbajului. Cele mai populare trăznăi ce le folosim azi, Gmail, Y!Mail, Noul Wordpress, dar şi vechiul, aproape tot ce e Google-ish, toate folosesc la greu Javascript.

De ce avem aşa super nevoie de Javascript? Well, înainte de web2.0 şi de toată nebunia cu superinterfeţele web, problema comunicării cât mai responsive cu clientul se putea rezolva în două moduri. Prima strategie era cea locală (client-side scripting): aveai un script care încărca totul în pagina curentă, în javascript, şi atunci puteai interacţiona cu utilizatorul (să validezi date, să îi dai nişte opţiuni diferite în funcţie de alegerile pe car ele face …) într-o manieră limitată la informaţiile care existau la încărcarea paginii. Şi cum să trimiţi toate posibilităţile înseamnă cantitate mare de date şi cantitate mare de date e un big no-no pentru interfeţe web, interacţiunea era limitată.

A doua strategie (server-side scripting) implica de cele mai multe ori reîncărcarea paginii şi procesarea opţiunilor cu server-ul. Necazul era că şi pe legăturile rapide (gen intraneturi) se observa reîncărcarea paginii, iar pe legăturile lente (sau no, normale) asta devenea o problemă serioasă.

Toate problemele astea au primit o soluţie unică, elegantă şi foarte foarte folosită azi de toate aplicaţiile web ce le folosim frecvent: AJAX. Asynchronous Javascript And XML. Deşi tehnologiile care fac AJAX posibil există de prin 95, W3C a propus un draft pentru chestia asta doar în 2006. Ideea e relativ simplă, AJAX se bazează pe un obiect Javascript (da, JavaScript e şi OO :P) care face o cerere HTTP către un server şi înregistrează un handler (o funcţie) care se apelează în momentul când cererea întoarce ceva sau dă un timeout. Răspunsul cererii se presupune a fi un XML, deşi din ce am încercat eu se poate folosi şi HTML ca răspuns, dar nu sunt sigur de alte tipuri de date.

Avantajul cel mare e că toată bucătăria se întâmplă în culise, utilizatorul are o experienţă fluentă, care seamănă cu experienţele cu interfeţe ne-web. Există şi limitări. Deşi, teoretic, se pot cere fişiere oricât de mari, având în vedere că totul se întâmplă peste un mediu care are performanţe variabile indiferent de locaţie, se preferă ca răspunsurile să fie minime. O limitare de securitate care am observat-o (nu ştiu exact când a fost introdusă) este că cererile XMLttpRequest (obiectul de care vă ziceam) nu pot fi făcute decât către serverul de la care a fost încărcată pagina care execută scriptul.

Desigur, problema asta se poate rezolva urgent cu un urlfopen pe partea se server, şi asta e mirific la AJAX, posibilitatea de a trece peste limitările iniţiale impuse de modelul Web prin pasarea lor către partea celalată (client <-> server).

Anyway, pentru cine este interesat, tema mea 3 la IE este aici. Si, ca sa o testati, puteti incerca sa folositi pagina asta şi asta :)

Am devenit mult mai interesat după tema asta să investighez mai îndeaproape JavaScript şi, mai ales AJAX pentru yPHP (pentru început, un modul de formuri dinamice şi de verificare a formurilor pentru început :P). Vorbind de tehnologii, am înţeles că jQuery (ăla de aici, nu ăla care ţine de baze de date şi Java) e util. Are cineva vreo experienţă cu trăznaia asta? I will give it a try, and post here on the results :)

(Post-ul ăsta a apărut şi pe blogul meu personal)

Monday 24 November 2008

despre citrix

de ce citrix ?? pentru ca produsul principal este o interfata web prietenoasa ce se caracterizeaza prin simplitate si inovatie. si pentru ca succesul de care a dat dovada o recomanda (sursa wikipedia.org: Total assets 2.53 Billion USD (2007))

citrix e o firma de meseriasi specializata pe servicii de virtualizare si acces remote.
ideea de la care a plecat firma era incercarea de a oferi servicii (in principiu ms) intr-o interfata primitoare, prin intermediul netului. sa poti sa ai acces la "calculatorul tau" indiferent la ce calculator ai lucra. explic indata :)

printre certuri si impacari cu ms, s-a ajuns la un consens ca citrix sa poata folosi sursele de win (pana la 2003) pentru implementarea unui "enhanced win" numit initial WinFrame, mai apoi XenApp.
aplicatia este un serviciu remote care permite userilor sa ruleze aplicatii win (notepad, outlook, office, etc) de pe orice conexiune la net. Virtualizarea calculatorului personal se face pe server, a.i. eu sa pot accesa datele personale de pe pc, smart phones, etc. intr-un mediu securizat.
aplicatia a avut asa amploare incat a fost adoptata ca mediu de lucru de mai multe universitati.

watch this video:

Despre viitorul IT in Romania

Pentru cei care nu stiu inca, Varujan Pambuccian este presedintele Comisiei pentru Tehnologia Informatiei si Comunicatiilor din Camera Deputatilor.Zilele acestea a fost invitat de Hotnews.ro pentru o discutie pe tema sectorului IT din Romania si modul in care se va dezvolta piata muncii in acest domeniu. S-au discutat amanunte incepand de la programul OLPC, domeniile .ro si atribuirea lor pe viata, dezvoltarea de centre R&D , scutirea de impozit de care beneficiaza inginerii IT, viitorul securitatii IT si altele... Daca va intereseaza dati un click.

Sunday 23 November 2008

Link Prefetching

Nu stiu cati dintre voi sunt familiarizati cu notiunea de Link prefetching, asa ca o sa incerc sa povestesc cate ceva despre asta.
Link prefetching-ul este un mecanism folosit de unele browsere/ motoare de cautare prin care se incarca o pagina web in memoria cache inainte ca voi sa apasati pe butonul care ar trebui sa va redirectioneze catre acea pagina. Mai exact: dupa ce ati accesat o pagina si vi s-a incarcat intreaga pagina, pe baza unor tag-uri intalnite in sursa html a paginii, se vor incarca paginile indicate de tag-urile respective.
Motivul pentru care a aparut si a inceput sa fie folosit mecanismul acesta este ca paginile care cel mai probabil vor prezenta interes pentru cei care au intrat pe o pagina sa fie incarcate in avans, pentru ca atunci cand utilizatorul vrea sa le acceseze, ele sa "se incarce" aproape instantaneu. Browser-ele de la mozilla folosesc link prefetching si tocmai de aceea incarca(daca este actvivata optiunea de prefetch) paginile mai rapid.
Daca vrei sa testezi daca browser-ul pe care il folosesti are activ sau foloseste mecanismul de prefetch, da un click aici.
Si unele motoare de cautare folosesc partea asta de link prefetch. Google de exemplu foloseste mecanismul astfel: daca pentru un search este foooooarte probabil ca primul link afisat sa fie si cel dorit ( la cautari de genul wikipedia, cisco este 99% sigur ca site-ul cautat sa fie wikipedia.org sau cisco.com), pagina respectiva este incarcata in avans asa ca atunci cand te hotarasti sa dai click si sa o accesezi, apare intr-o clipita (:P), fara sa mai astepti cum o faceai pana acum(vorbesc aici de cei care nu au net prea reusit ).
Exista totusi unele restrictii cu privire la paginile ce pot fi incarcate in avans, link prefetch neputand fi aplicat in cazul paginilor ce folosesc https:// ci doar http://.
Toate bune si frumoase....sau NU :
- partea asta de prefetch foloseste din latimea de banda si daca vrei sa faci un download in paralel ce browserul tau face prefetch la o pagina, atunci download-ul o sa iti mearga mai greu, deoarece banda trebuie impartita intre cele 2. Desi daca faci download-ul folosind browserul care face si link prefetch, acesta ar trebui sa fie suficient de destept(si firefox este) incat sa dea prioritate download-ului si sa treaca pe plan secund incarcarea unei pagini pe care (inca) nu ai cerut-o.
- site-urile care realizeaza statistici ale vizitelor realizate pe pagina unui site pot fi usor induse in eroare, deoarece sunt inregistrate vizite care poate nu au fost facute si rezultatele obtinute nu mai sunt tocmai elocvente ( atentie colegilor de proiect :P )
- daca platesti netul in functie de traficul realizat, iarasi nu este bine pentru ca ajungi sa platesti si pentru site-uri pe care nu le-ai accesat

Cum sa dezactivezi link prefetch la mozilla firefox

- tasteaza "about:config" in bara de adresa a browserului
- cauta in lista de setari "network.prefetch-next" si seteaza-i valoarea pe false

Saturday 22 November 2008

Off topic

Putina diversitate nu strica:P
Nu sunt inca sigura pe semnificatia uneia dintre caricaturile de mai jos, cea cu siluetele complet negre...
any idea?
Thinkfull Caricatures
View SlideShare presentation or Upload your own.

p.s. 10x Sonia pt .ppt ;)

Tuesday 18 November 2008

CTTE & Tema 2

Saptamana aceasta s-a afisat enuntul cu tema 2 la Interfete Evoluate care, spre surprinderea mea este extrem de scurt (colegii care fac LPD stiu la ce ma refer :D), cerinta fiind formulata succint si la obiect: proiectarea interfetei utilizatorului uman cu siteul blogger.com folosind CTTE.
Pentru aceia dintre voi care nu ati fost saptamana trecuta la laborator, dar si pentru cei care vor sa afle mai multe despre acest utilitar o sa incerc sa ofer in cateva randuri o serie de informatii suplimentare... poate va ajuta in rezolvarea temei.

Pentru inceput "Ce este CTTE"?
Abrevierea provine de la ConcurTaskTreesEnvironment si este un editor care ofera posibilitatea dezvoltarii de modele de sarcini. Este scris in java si momentan a ajuns la versiunea 2.3 desi ultimul update s-a facut acum 2 ani, in decembrie 2006.

Cum fac rost de el?
Utilitarul este free source si poate fi downloadat de la urmatoarea adresa. Pentru a putea obtine ultima versiune trebuie sa completati un mic formular (nume, prenume, resedinta, scopul in care doriti sa folositi aplicatia) si veti primi in schimb un link de la care puteti downloada o arhiva continand clasele necesare rularii acesteia. In interiorul arhivei se gaseste un script , ctte.bat, cu ajutorul caruia puteti porni aplicatia.Trebuie amintit insa ca ultima versiune are si o limitare: functioneaza doar cu Java 1.5 and above, de aceea este posibil sa fie necesara instalarea acesteia inainte de a rula scriptul respectiv.

Cum il folosesc?
Aici ar fi multe de spus. Interfata CTTE este una destul de prietenoasa dupa cum se poate observa din imaginea de mai jos:


Avand la baza notatia CTT, utilitarul ofera o gama intreaga de simboluri pentru reprezentarea task-urilor si a relatiilor dintre ele. In CTTE putem avea 4 tipuri de sarcini(tasks):
  • user tasks : efectuate integral de catre utilizator, care nu interactioneaza cu sistemul => spre exemplu cand utilizatorul analizeaza o serie de informatii primite de la sistem pentru a lua o decizie
  • application tasks : executatate integral de catre sistem, care furnizeaza informatii utilzatorului => de exemplu executia unui program si trimiterea de mesaje catre user
  • interaction tasks : efectuate de utilizator cu sistemul => ex. formularea unei interogari catre o baza de date, selectarea(simpla sau multipla) a unor actiuni
  • abstract tasks : sarcini care necesita actiuni complexe si nu se pot incadra in nici una din categoriile de mai sus
Sarcinile au asociate obiecte (entitati manipulate de acestea) si atribute. In CTTE atributele pot fi de trei feluri :
  • generale (ex numele sarcini, categoria, tipul si frecventa acesteia etc)
  • referitoare la obiectele folosite de sarcina respectiva
  • referitoare la constrangerile de timp asociate cu sarcina curenta: timpul minim, maxim sau mediu de executie
Puteti sa accesati si sa editati atributele unei sarcini foarte usor : un "simplu" double click pe sarcina dorita va deschide un panel cu Task Propreties (panelul se poate accesa si din meniul principal de la optiunea View -> Task Proprieties - aveti grija sa fie selectat taskul dorit ca task curent).

Aplicatia ofera de altfel suport pentru vizualizarea nu numai a unei singure sarcini ci a a intregului arbore de task-uri construit (este o fereastra in partea dreapta sus a interfetei care permite un overview al arborelui realizat deja). Exista, de asemenea, si o serie de operatori care facilitateaza modificarea modului de vizualizare prin aranjarea nodurilor, afisarea unui singur nivel din arbore sau prin condensarea unor subarbori cu numar mare de noduri si afisarea doar a parintelui insotit de simbolul + etc. In plus se pot vizualiza si statistici asupra modelului construit folosind optiunea Info -> Task Model Statistics din meniul principal.

Partea mea favorita ramane insa cea de verificare si simulare a modelului implementat. Toate optiunile din submeniul Tools sunt extrem de utile pentru a va asigura de corectitudinea modelului vostru (sunt afisate eventualele erori insotite de explicatii) si va permit sa faceti si o simulare a acestuia fie prin stabilirea sarcinilor de inceput si de sfarsit si urmarirea task flow-lui, fie prin crearea unui scenariu propriu de executie. In plus, pentru a va face munca mai usoara, un scenariu o data creat se poate salva si poate fi incarcat ori de cate ori aveti nevoie :).

Tips and tricks utile la realizarea temei 2
Here are some tips that helped me get started:
  • cititi laboratorul 7 de la IE (pdf-ul despre CTT de pe curs.cs) -> nu va ia mai mult de 20 de minute si va familiarizeaza cu notiunile de baza. Exista un mic tutorial si pe site-ul de download iar link-ul urmator poate fi util
  • daca nu ati fost data trecuta la laborator: deschideti si rulati exemplul cu infofer -> o sa va ajute sa intelegeti "ce se vrea de la voi"
  • incercati sa identificati si sa descompuneti ierarhic sarcinile : va veti creea o imagine de ansamblu despre "cum trebuie sa arate" modelul vostru si va va ajuta sa stabiliti mai usor ce sarcini sunt pe fiecare nivel si tipul de relatii existent intre acestea
  • un F7 din cand in cand este util pentru verificarile de consistenta :D
  • dupa ce ati construit partial arborele puteti face o serie de simulari pentru a vedea daca abordarea voastra este corecta si ordinea de executie a task-urilor corespunde cazului real (recomand Tools->Reachability Analysis).
Sper ca informatiile de mai sus sa ii ajute pe cei care inca nu s-au apucat de tema. Momentan si eu sunt la inceput, dar o sa revin pe masura ce tema avanseaza si o sa ma lovesc de alte probleme...

Monday 10 November 2008

Hi5 api & Me

Saptamana trecuta cred ca am fost una din persoanele care si-au petrecut cel mai mult timp pe hi5:) Dar am avut o scuza buna: implementarea primei teme de casa de la Interfete Evoluate.

Nu are rost sa mai spun ce poti face cu un API de genul asta, deoarece este amintit intr-un articol scris de colegul meu micvs.

O sa incep prin a spune care a fost partea cea mai dificila pentru mine: sa ma hotarasc ce anume sa folosesc din oferta de API-uri: o librarie deja implementata in JAVA sau partea de REST.
Am incercat la inceput sa folosesc libraria de Java, care promitea sa poata extrage informatii despre profilul unui utilizator, lista de prieteni si comentariile pe care acesta le primise - deci cam tot ce imi trebuia ca sa fac tema. Dupa ce: am facut rost de un application key, am downloadat .jar -urile pentru partea de client + toate celelalte n-spe librarii de care depindea partea de client java am trecut la scrisul primelor linii de cod:
AuthApiImpl auth = new AuthApiImpl();
AuthToken token = auth.auth_plain(app_key, my_email_add, my_password);
am primit o eroare cu de 10X mai multe linii decat ce scrisesem eu :((.

Dupa ce am google-uit cat de mult am putut si am cautat pe forum-uri, singura concluzie la care am ajuns a fost ca : there was something wrong with xfire jar. Asa ca m-am decis sa trec la cealalta solutie, folosind partea de REST si FOAF.

REST este un model folosit pentru a accesa un set de resurse printr-un set de operatii. De fapt notiunea de resursa este strans legata de REST. Fiecare resursa este adresata folosind un anumit identificator, iar pentru a manipula aceste resurse, partile componente ale unei retele ( atat clientii cat si serverele) comunica folosind o interfata standardizata(ex. http) si schimba intre ele reprezentari ale acestor resurse. Cand vorbim de hi5, resursele la care ne putem referi, sunt: widget-uri, albume de poze, fotografiile dintr-un album, lista de prieteni ai unui utilizatori, informatii generale despre un anumit profil etc...

Inconvenientul la aceasta metoda de a culege informatii despre un anumit utilizator este ca, cel putin pentru moment, API-ul de hi5 nu permite, folosind REST, adunarea informatiilor cu privire la comentariile adresate unui anumit profil/journal entry/unei fotografii...
Am pomenit mai sus de FOAF (Friend of a Friend) - care este un proiect ce isi propune adoptarea unei tehnologii necentralizare de conectare a site-urilor cu caracter social, dar si a utilizatorilor acestora. FOAF urmareste dezvoltarea unui web in care paginile sa fie organizate astfel incat sa faca legatura intre persoane si ceea ce le defineste- ce stiu sa faca, ce prieteni au etc...

URI-ul pe care l-am folosit in tema pentru a extrage informatiile cu privire la prietenii unui utilizator a fost: http://api.hi5.com/rest/profile/foaf/user_id .Daca vreti puteti face un test cu id-ul meu: http://api.hi5.com/rest/profile/foaf/9423817 :P

Notiunile de mai sus sunt cele de care m-am "lovit" eu in dezvoltarea temei, si pot spune ca (si) de data asta partea cea mai .... nu neaparat grea cat lunga am dedicat-o gasirii tehnologiei pe care sa o folosesc in dezvoltarea temei.

Tuesday 4 November 2008

CSS Crash Course

CSS (Cascade Style Sheets) este o tehnologie care permite adăugarea informaţiilor vizuale suplimentare paginilor web.

HTML a definit iniţial o serie de atribute pentru taguri (align = center, spre exemplu), dar care au limitările lor. Odată cu ieşirea WWWului din mediul academic şi cu intrarea lui în mediul comercial, a apărut o nevoie crescută să ai un control vizual mai strict asupra ce şi cum se afişează în fereastra browserului. Astfel a apărut CSS.

Post-ul ăsta nu este însă despre istoria CSS-ului, despre vremurile vechi când browserele aveau tag-uri specifice, şi site-urile erau hackuite laolaltă în 2 sau mai multe versiuni (eh, pentru IE şi acum mai facem asta ...). Postul ăsta este despre cum poţi pune pe picioare un site ca http://www.interfete-web-beton.eu în câteva ore.

Pentru început, câteva avantaje distinctive ale CSS-ului. Un fişier CSS este o înşiruire de reguli de afişare, care se pot aplica la 3 categorii distincte de elemente:
  • tag-uri - redefineşte modul cum un browser afişează un anumit tag html
  • clase - defineşte clase, care se pot aplica mai multor elemente
  • definiţii pentru un anume element din pagină (ids). Se referă concret la afişarea unui singur element din pagină.

Fişierul se încarcă în secţiunea head a html-ului, şi poate fi un fişier extern (ca scripturile javascript externe, spre exemplu). Acelaşi fişier de reguli CSS poate fi încărcat în mai multe (toate) paginile unui site, şi astfel oferă un control centralizat a cum arată vizual un site.

Exemplu:
Avem un site care are 3 pagini, şi toate titlurile trebuie să fie roşii (#FF0000). Avem mai multe posibilităţi. Prima ar fi să scriem în fiecare tag <h1> ceva de genul <h1 style="color: '#FF0000';">. O grămadă de muncă, pentru că trebuie să facem asta în fiecare document. Dacă nu aveam 10 documente ci aveam 1000. Mai rău, dacă conţinutul era stocat într-o bază de date sau generat dinamic.

O soluţie mai eficientă este să definim o regulă într-un fişier CSS pentru toate titlurile, şi apoi să legăm CSS-ul la toate paginile.

O definiţie pentru aşa ceva arată cam aşa:

h1 {
color:#FF0000;
}

Dacă vrem să modificăm modul în care titlurile sunt afişate în cele n documente ale site-ului nostru, sau în conţinutul dinamic, e suficient să modificam o dată, în acest fişier atributul color.


Ok, trecem mai departe. Design-ul de bază - layere. La început, paginile web erau o simplă pagină, încărcată în browser odată, cu textul scris de mână de cineva. Pe măsură ce web-ul a devenit WW (world wide), au apărut şi alte nevoi.

Cred că apoi a urmat frame-based design-ul. Browserul accepta să defineşti mai multe regiuni pe ecran (frame-uri) şi să deschizi o pagină nouă în fiecare regiune. Regiunile (frame-urile) erau practic independente, singurul control care exista între ele era definirea unui atribut target pentru un link sau JavaScript.

Mai târziu s-a renunţat la frame-uri şi s-a trecut la table-based designs, care se folosesc şi azi, mai ales pentru site-urile cu o grafică pretenţioasă. Practic, table-based design presupune că tot site-ul se împare într-un tabel, si apoi se aranjează tabelul ăla să semene cu ce se doreşte.

Apoi CSS-based designs au devenit foarte populare, mai ales pentru că au puţine limitări, mai ales în zilele IE7. Practic, CSS-based design se referă la definirea de atribute pentru toate elementele într-un fişier de reguli CSS. Design-ul se referă la culori, la modul în care sunt aranjate elementele în pagină, fundale, font-uri ...

Cele mai comun folosite în internet azi sunt soluţii hibride, cu CSS şi tabele.

Ok, deci, începuturile pentur un CSS-based design încep cu ... un pix şi o foaie. Trebuie să plecăm de la o idee iniţială. Ştim cum vrea să arate site-ul nostru, sau poate că graficianul ne-a facut deja un desen pentru cum ar trebui să arate.

Primul pas: proiectarea layer-elor. Practic, în funcţie de experienţă şi de cunoştiinţe, definim pe foaie care sunt layerele de care avem nevoie (fie pentru conţinut sau pentru structură), şi cum sunt ele organizate în pagină. (fişierele HTML sunt parsate de sus în jos, o singură dată, deci un element care apare mai sus este afişat default deasupra celorlalte elemente).

Pasul al doilea: resetarea atributelor default. Browserele au un CSS intern (sau alte moduri de a specifica reguli) care definesc regulile default pentru afişarea diferitelor elemente. Din păcate, aceste reguli diferă de la browser la browser, aşa că pentru a nu avea surprize, se setează de obicei padding-ul şi margin-ul la 0. O idee bună e să definiţi font-family-ul şi font-size-ul aici.

Pasul al treilea: scrierea definiţiilor layerelor. Pentru început, e important să vedem cum potrivim layerele cu design-un iniţial. Nu sunt secrete, cele mai utile atribute aici sunt width, care stabileşte lăţimea, height care stabileşte înălţimea (pentru conţinut e bine să fie lăsată pentru auto, pentru chestii de dimensiune fixa, gen poze, se setează de mână).

O practică bună pentru a face lucrurile mai clare e să definiţi un background-color pentru fiecare layer. Şi dacă vă asiguraţi că e o culoare ţipătoare, sunteţi siguri că nu o să aveţi colţuri şi nealinieri pe care să nu le vedeţi.

Pentru a defini coloane (elemente unul lângă altul, nu unul sub altul), în CSS se foloseşte atributul float. Citiţi documentaţia pentru mai multe info, dar atenţie la cum îl folosiţi, IE nu e foarte fericit cu float-uri. Tot legat de float e atributul clear, ar fi util să citiţi şi despre el.

Pasul patru: eye candy. Avem acum un set de dreptunghiuri colorate ţipător, dar în forma site-ului nostru. Acum tot ce avem de făcut e să venim cu grafica. Se definesc stilurile pentru text, fundalele şi bannere-ele. Câteodată pentru partea grafică apare nevoia de a despărţi un layer în mai multe layere componente, pentru a permite alinierea corectă a elementelor grafice.

Un fişier CSS pentru un site ca interfete-web-beton.eu are cateva zeci de definiţii, şi cam 1k. Revin cu informaţii mai detaliate despre cum să faci un meniu în CSS, şi site-uri interesante în care nu se foloseşte altceva decât CSS.


Flickr API

la ce bun API-ul asta ? poti extrage tot felul de date despre useri flickr pe care le poti folosi in aplicatii desktop/web. simple enough. decat sa stai sa parsezi fisiere, mai bine trimiti (cu multa politete) o cerere catre serverul lor, primesti raspuns cu ce te interesa, integrezi imediat in aplicatia ta...

pornesti de la o cheie (comerciala/non-comerciala, in functie de intentiile aplicatiile tale) pe care o primesti de la ei si de la un "secret". te autentifici, s-apoi n-ai decat sa "tragi" cat poti info de-acolo.

(probabil) principalul scop al API-ului ramane cel de manageriere a conturilor flickr prin intermediul aplicatiei proprii: upload de poze, adaugare comentarii, stergere poze, stuff like that.

exista 2 tipuri de date oferite (la cerere) de catre serverul lor. publice si private. evident in cazul 2 iti trebuie autentificare. partea buna e ca API-ul e bine documentat, se specifica daca pentru apelarea metodelor e nevoie de autentificare initiala sau nu.

API-ul e impartit frumos pe cateva directii. si daca tot zic de el, sa postez si un link...http://www.flickr.com/services/api/. dupa cum se vede, poti sa alegi dintre vreo 15 limbaje in care iti poti dezvolta aplicatia care sa suporte API-ul. flexibilitate e cuvantul.

un exemplu de aplicatie la care m-am jucat putin a fost extragerea de cunostinte referitoare la relatiile sociale in cadrul comunitatii. plec de la un user si caut toti prietenii sai, toti userii care au postat commenturi la pozele sale, etc. recursiv pe cateva nivele.

few snippets:
  • autentificare: flick = new Flickr(key, secret, new REST());
  • user by name: flick.getPeopleInterface().findByUsername(username).getId();
  • URL for user: flick.getUrlsInterface().getUserProfile(userID);
  • favourite contacts: flick.getContactsInterface().getPublicList(userID);
pretty straight-forward :)
enjoy it!

Sunday 26 October 2008

Ajax - the best possible user experience ...

Cred ca fiecare dintre noi, care folosesc Google Suggestions sau au intrat cel putin o data pe Google Maps si au scrollat timp de cateva secunde au observat ca totul se intampla extrem de rapid: cuvintele sugerate apar aproape instantaneu pe masura ce tastezi (intocmai ca la o aplicatie desktop), iar hartile se updateaza imediat,fara a mai astepta ca o intreaga pagina sa se incarce... Google Suggestions si Google Maps sunt doar cateva exemple de aplicatii online ce folosesc o tehnica speciala de dezvoltare a paginilor web denumita Ajax.


Ca definitie, Ajax, sau "Asynchronous JavaScript and XML" nu este o tehnologie in sine ci un grup de tehnologii folosite la crearea de pagini web interactive, in care datele de la server sunt preluate asincron si salvate intr-un buffer local, fara a mai afecta displayul si functionalitatea paginii curente. Intr-un cuvant, intregul proces este "invizibil" end-userului si creaza impresia ca totul se produce instantaneu ceea ce face aceasta metoda atat de interesanta!!


Totusi, ea nu este una recenta : tehnici de incarcare asincrona a datelor erau folosite inca din anul 1996 cand Internet Explorerul a introdus elementul IFrame. Jesse James Garrett a fost cel care i-a dat un nume - destul de "catchy" - in urma cu 3 ani (2005) iar Ajax-ul a devenit extrem de popular o data cu aparitia Gmail si a altor aplicatii "Ajax based" de la Google iar toata lumea si-a pus fireasca intrebare "how did they do it??".


Raspunsul este unul destul de simplu: o aplicatie "Ajax based" functioneaza prin crearea unui layer intermediar (un motor Ajax) intre user si server. La o prima vedere aceasta abordare pare defectuoasa : adaugarea unui layer suplimentar in aplicatie poate face ca aceasta sa devina mai lenta, mai putin prietenoasa. Dar lucrurile stau cu totul diferit, efectul este chiar invers! Si asta deoarece, la inceputul unei sesiunii, in locul incarcarii unei noi pagini web, se va incarca un engine Ajax (realizat in JavaScript) care va fi responsabil cu redarea paginii si comunicarea cu serverul in numele utilizatorului (nu va mai exista o relatie directa intre end-user si server).Engine-ul va permite ca interactiunea utilizator - aplicatie sa se produca independent de comunicarea cu serverul. Prin urmare nu vom mai avea situatii de genul "start-stop-start-stop" de fiecare data cand utilizatorul ii cere serverului sa-i furnizeze sau sa valideze niste date ;).


Ganditi-va, spre exemplu, la o pagina web in care utilizatorul trebuie sa completeze un formular de inscriere si in care trebuie sa astepte incarcarea unei noi pagini pentru a vedea rezultatul. Procesul este lent si neprietenos ("nobody likes to stare at a blank page, does he??"). Acum ganditi-va la alte aplicatii precum Youtube sau Flickr in care datele voastre sunt trimise si updatate fara ca voi sa "parasiti" pagina curenta! Toate acestea constituie "the magic of Ajax"...


Si acum, intrebarea care s-ar putea pune este : de ce avem nevoie pentru a realiza o astfel de aplicatie?Jesse James Garrett mentioneaza, intr-un articol din 2005, intreaga stiva de tehnologii care stau la baza Ajax:
  • XHTML si CSS pentru partea de prezentare
  • Document Object Model pentru display dinamic si interactiunea cu datele
  • XML si XSLT pentru manipularea datelor
  • XMLHttpRequest pentru o comunicare asincrona
  • si JavaScript "to bind everything together" :).
Trebuie remarcat ca toate acestea se intamplau prin 2005. De atunci stiva s-a imbogatit considerabil, gasindu-se alternative pentru JavaScript -> VBScrip iar JavaScript Object Notation poate fi folosit pentru a inlocui formatul de reprezentare XML.
Ajax-ul a devenit destul de matur si este folosit de mai toate aplicatiile web populare azi. Sistemul de rating de la Amazon in care selectezi numarul de stele ca punctaj acordat unui cd sau unei carti este doar unul dintre ele.
Popularitatea Ajax-ului este demonstrata si de numarul mare de tutoriale puse la dispozitia celor care vor sa "experimenteze". Implementata corespunzator, o pagina web poate deveni o RIA (Rich Internet application) cu functionalitatea si avantajele unei aplicatii desktop. Scopul este, pana la urma, de a crea "the best possible user experience"...

Thursday 23 October 2008

Ce ar trebui evitat la dezvoltarea unei intefete web "beton"?

Cel mai bine se invata din greseli, asa ca o sa incerc sa evidentiez o parte din greselile care se intalnesc adesea in dezvoltarea interfetelor web, poate va ajuta pe cineva sa le evite :D.

Sa incep cu inceputul: atunci cand vrem sa realizam o pagina web, trebuie sa ne gandim la scopul ei, si cel mai adesea(daca nu intotdeauna) urmarim multumirea end-userului, a celui care acceseaza pagina, pentru ca altfel va cauta un alt furnizor al aceluiasi serviciu, dar care stie sa isi vanda mai bine marfa ( fie ca este vorba de un bilet la teatru, o melodie sau de o informatie).

Una dintre problemele cu care se confrunta aceia dintre noi care au renuntat la Windows in favoarea Linux-ului este aceea ca exista site-uri ( si nu sunt putine la numar, o lista cu o parte din acestea putand fi accesata la link-ul urmator ) care nu pot fi vizualizate decat folosind browser-ul Internet Explorer. Si asta nu este o situatie tocmai roz, in conditiile in care statisticile arata doar 48,6% dintre cei ce folosesc un browser au apelat la Internet Explorer in luna septembrie ( 2008). Nu ca ar fi o cifra insignifianta, dar asta ca inseamna ca mai bine de 50% dintre utilizatorii internetului sunt defavorizati de aceasta "politica de implementare", desi daca ne gandim mai bine cei care sunt in pierdere pana la urma sunt tocmai beneficiarii site-urilor ( statisticile pot fi vizualizate aici).

Unul dintre testele pe care trebuie sa le treaca o pagina pentru a nu te "alunga" este asa numitul "The Four seconds Test": o data ce ai accesat o pagina, ar trebui sa iti poti da seama intr-un timp foarte scurt( estimat undeva la 4 secunde) la ce anume se refera, daca are vreo legatura cu ceea ce te intereseaza pe tine. Iar daca home page-ul este foarte incarcat sau se incarca mult prea greu, multi dintre noi nu mai dam nici o sansa paginii si renuntam inainte ca acesta sa se incarce( example here ).

O alta problema cu care se confrunta unii dintre dezvoltatorii de interfete web este aceea ca, din dorinta de a realiza un design cat mai reusit , uita care este scopul textului sau cum sa il evidentieze: fie folosesc o culoare pentru text care nu contrasteaza cu fundalul, fie il inlocuiesc cu imagini sau animatii in flash.De ce ar fi aceasta a doua practica ineficienta? Mareste dimensiunea paginii in mod nejustificat, cel mai adesea elementele grafice sunt de calitate slaba si erorile sunt mult mai greu de corectat, iar "textul" astfel reprezentat nu este "search-engine friendly".
Pentru a testa daca ai ales bine culorile pentru text/fundalul paginii web, poti accesa link-ul acesta.

Un exemplu de don't este site-ul http://www.arngren.net: prea multa informatie adunata pe o singura pagina, incat este extrem de dificil sa te poti concentra pe ceva anume.

Uneori inainte de a intra intr-un site apare o animatie de intro(realizata adesea in flash), care poate fi simpatica prima data cand accesezi pagina sau daca ai tot timpul din lume, dar intotdeauna este de preferat sa existe optiunea de "skip", la fel cum pentru site-urile care au drept continut multimedia melodii ar trebui sa existe intotdeauna optiunea de "turn off".

Evident exemplele de don't pot continua, dar o sa ma opresc aici, cel putin pentru moment:)