Nu aduce anul ce aduce ceasul.

Acum vreo 3 ore m-am logat pe blogger ca să scriu un articol pe blogul meu. Toate bune şi frumoase, exact aşa cum le lăsasem.

Acum, m-am logat pe acelaşi blogger, ca să-mi pun deoparte nişte notiţe pentru câteva idei de articole care m-au pocnit între timp. Şi nu mică mi-a fost mirarea să văd o nouă interfaţă de editare, mai sclipicioasă dar mai ales, mai simplă şi uşor de folosit (sunt singurul care nu înghiţea fereastra aia nasoală de JavaScript folosită pentru introducerea unui link?) + suport pentru geolocaţie, via GoogleMaps.

Aşteptăm să vedem ce suprize ne mai pregătesc cei de la Google. Până atunci, Crăciun fericit şi Sărbători cu pace şi linişte vă dorim!

miChou, ConcreteWeb

Bounce rate

De ce despre Bounce rate? Pentru că ridică nişte întrebări interesante legate de cum gândim un site de prezentare, un blog sau orice fel de interfaţă (deşi problemele se resimt mai ales la interfeţele web, problema nu-şi pierde în totalitate importanţa nici pentru aplicaţiile „desktop-enabled”).

Conform paginii de pe wikipedia, bounce rate-ul reprezintă ce procent din vizitatorii care ajungând iniţial pe prima pagină a unui site (sau pe o pagină oarecare), pleacă pe un alt site în loc sa continue navigarea pe alte pagini ale aceluiaşi site. Se consideră ca un user a „sărit” (nu găsesc o traducere mai bună pentru bounced) dacă a navigat pe un alt site înainte de expirarea unui timeout - stabilit de obicei de software-ul de tracking.

Care e relevanţa bouce rate-ului? Conform lui Avinash Kaushik: „It is really hard to get a bounce rate under 20%, anything over 35% is cause for concern, 50% (above) is worrying.” Cu toate astea, în condiţiile în care o proporţie mare din trafic vine pe canale indirecte (userul nu scrie de mână URL site-ului în bara de adrese a browserului), vine următoarea întrebare: nu cumva un bounce-rate mare poate însemna şi faptul că userul a găsit repede şi „din prima” ceea ce căuta?[1] Şi de aici poate deriva uşor următoarea chestiune de fond: când realizăm o interfaţă este de preferat să îi dăm utilizatorului din prima mai multă informaţie în speranţa că va găsi „din prima” ceea ce caută sau e de preferat rafinarea succesivă a prezentării informaţiei.

Motivul pentru care am afirmat că problema caracterizează atât interfeţele web cât şi cele desktop ţine de latenţă. În web, în ciuda creşterii vitezei medii de acces la resurse, latenţa poate fi o problemă - fiind inerentă atât protocolului folosit (HTTP), dar şi modului în care o interfaţă este proiectată. În cazul aplicaţiilor desktop, latenţa efectivă de acces este cu nişte ordine de mărime mai mică, dar în acelaşi timp volumul de date prezentat sau implicat în prelucrări creşte considerabil.

Este de preferat un timp de încărcare iniţial mai ridicat, urmat de o experienţă ulterioară „fără sughiţuri”, sau „încărcările mici şi dese-s cheia marilor succese”? Întrebarea este bineînţeles una deschisă (retorică nu cred că e :) ), dar poate face diferenţa între un serviciu de succes şi unul folosit când şi când. (În situaţia asta sunt eu cu mailul - motivul pentru care am trecut de pe Yahoo!Mail pe GMail este că în GMail, am acces la mail încă de la prima încărcare a paginii, în timp ce pe Yahoo! mă separă un click de mouse şi două încărcări de pagină până la accesarea Inbox-ului - and don't get me started cu noua ţestoasă interfaţă a la Outlook. 10 minute de utilizare m-au lecuit definitiv de ea.)

____
[1] după cum se menţiona şi în articolul de pe Wikipedia, această metrică are mai multă relevanţă şi este de dorit să aibă o valoare mică în cazul site-urilor care aduc valoare din timpul petrecut de către user în site - de exemplu site-urile de eCommerce.

De ce iubim f...acebook-ul?

Facebook este una din reţelele sociale în mare creştere la ora actuală. Lansat în mai 2007, are în prezent peste 120 de milioane de utilizatori activi, fiind al patrulea site ca trafic la nivel mondial şi reţeaua socială cu cel mai mare trafic (comunicat de presă oficial).

Trebuie să mărturisesc că în urmă cu 10 minute habar n-aveam lucrurile astea şi că până în iulie nu auzisem de Facebook decât de pe la alţii. Recent, discutând cu unii prieteni şi dând peste tot felul de aplicaţii care mai de care mai integrate, am decis să fac un efort de voinţă şi să investesc un pic de timp în fenomenul Facebook.

Vă veţi întreba poate, de ce e nevoie de un efort de voinţă? Sunt o persoană care are simpatii şi antipatii destul de puternice şi - de multe ori - greu de argumentat logic (aşa se face că Java e un limbaj care îmi place deşi nu prea înghit conceptul de JSP, la fel cum .NET şi C# îmi plac la nebunie dar nu suport ideea de WPF). Aşa se face că şi Facebook şi-a câştigat destul de repede şi cam fără drept de apel eticheta de „mdeah, să fiţi sănătoşi voi cu Facebook-ul vostru”.

Asta cu toate că, tehnic şi... social Facebook mi se pare un exemplu foarte bun de ce se poate face cu o interfaţă web bine gândită, susţinută de o arhitectură robustă şi modulară. Sunt chiar de părere că, alături de GMail şi Flickr, Facebook a dus conceptul de interfaţă web până în punctul de maximă forţă, dovedind cam tot ce se poate face cu actualele tehnologii web. Aici discutăm atât de AJAX, de diverse integrări, mash-up-uri dar şi de folosire deşteaptă a tehnologiilor mai „rich” orientate pe client, ca Adobe Flash.

Arhitectura deschisă şi extensibilă a Facebook permite dezvoltatorilor de aplicaţii să se lege practic în orice punct esenţial din interfaţa web, pentru a oferi facilităţi noi. În acelaşi timp, majoritatea funcţionalităţilor sunt expuse într-o manieră standard astfel că pot fi uşor create diverse interfeţe, web sau stand-alone care să agrege informaţiile din profile Facebook şi din alte surse.

Şi aici cred că rezidă succesul Facebook: posibilitatea de-a adăuga funcţionalităţi extrem de bogate şi de variate, păstrând însă o interfaţă web uşor de înţeles, folosit şi - de ce nu - înţeles.

Cu toate acestea (şi-n ciuda recentei explozii de activitate) pe mine nu mă atrage Facebook. Opinii? Sfaturi pentru rătăciţi? :)

miChou (on Facebook)

Crawlere şi interfeţe web Flash

Multe companii preferă să-şi impresioneze vizitatorii site-urilor lor prin realizarea de interfeţe în totalitate în Flash. Această platformă oferă experienţe multimedia superioare unui conţinut exclusiv HTML+CSS şi în plus, în ultima vreme, odată cu lansarea framework-ului de aplicaţii rich client Adobe Flex, a devenit accesibilă unei baze mult mai largi de dezvoltatori.

Una din problemele cu care totuşi aceste site-uri s-au confruntat până recent a fost invizibiltatea pe motoarele de căutare. Crawler-ele lor nu erau capabile decât să indexeze conţinut HTML (text), în timp ce obiectele SWF integrate in pagină erau total opace. Adobe era conştient de acest lucru, astfel încât în această vară a lansat o variantă simplificată de Flash Player, capabilă să parseze conţinutul text din clipurile SWF, şi pe care a pus-o la dispoziţie principalelor motoare de căutare (Google şi Yahoo), pentru ca acestea să poată indexa inclusiv conţinutul Flash.

Astfel, astăzi am pornit un mic experiment pentru a verifica dacă într-adevăr Google sau Yahoo indexează conţinutul Flash. Pentru acest experiment, am avut nevoie de:

• O pagină cu conţinut Flash/SWF. Pentru aceasta, cel mai la îndemână a fost să realizez o aplicaţie Flex simplă, care conţine câteva componente cu conţinut text (Label-uri).
  
• Un search term oarecum original (ca să nu stăm să căutam acul în carul cu fân... I mean în search results pages :) ). Imaginaţia mea debordantă a ales Any Donkey Owns Basically Everything.
  
• Un link către pagina noastră, pentru ca Google crawler-ul să poată ajunge la ea şi s-o indexeze. La asta e bun post-ul acesta.

Long story short, aplicaţia de test rezultată poate fi accesată aici.

Puteţi oricând verifica dacă textele din clipul SWF au fost indexate căutând pe Google search term-ul magic. Este de aşteptat ca acest lucru să se întâmple (dacă este cazul), peste câteva zile. Voi reveni şi eu oricum, cu un post cu rezultatele mele, so stay tuned!

Ștefan

PS: Are 10 puncte cine găseşte modul în care am construit search term-ul :)

Zooomr + Twitter = LOVE

Încercând să configurez contul de Zooomr am dat peste o opţiune foarte interesantă: sincronizarea zip-line-ului Zooomr cu contul de Twitter. Practic, de fiecare dată când postaţi ceva pe zip-line, va apărea şi pe twitter :)
Paşii sunt destul de simpli şi presupun că ai un cont funcţional de Zooomr, respectiv Twitter:

1. Loghează-te pe contul de Zooomr
2. Click pe Settings (partea de sus, în dreapta lui Hello, )
3. O dată încărcată pagina de setări, selectează External Services (ultima opţiune din dreapta)
4. De aici ne interesează Twitter account
5. Aici introduceţi userul şi parola de Twitter şi click pe Save.

Din acest moment, tot ce postaţi pe zip-line în Zooomr va apărea şi pe Twitter cu un tinyurl către intrarea din zipline (cred că ăsta e unul din motivele pentru care un post pe zip-line e mai scurt cu vreo 10-15 caractere decât unul de pe Twitter)

Mihai

Şi a fost şi a treia ediţie de FlexCamp...

... iar noi am fost acolo :)

Pe scurt: programul serii a fost următorul:

• 17:45 - 18:15: Înregistrare participanţi (aka bere & pizza :D )
• 18:15 - 18:30: Deschidere
• 18:30 - 18:45: Keynote Matt Chotin
• 18:30 - 19:00: Keynote follow up
• 19:00 - 19:30: Why/Where AIR applications use case (Mihai Corlan)
• 19:30 - 20:00: Cristian Pascu - FlairBuilder
• 20:00 - 20:30: Pauză
• 20:30 - 21:00: Boost your UI in AIR (Dragoş Dăscăliţa)
• 21:00 - 21:30: Bending pixels and more (Mihai Pricope)
• 21:30 ~ 22:00: o prezentare scurtă despre Cabanova (îmi scapă numele prezentatorului pe moment) intrată în program pe ultima sută de metri :)

Pe larg
Dacă am înţeles eu bine, ăsta a fost primul FlexCamp organizat simultan în 3 locaţii din Europa: Hamburg, Viena şi Bucureşti. Ideea iniţială era să fie broadcast-uite cu video cu tot toate cele 3 FlexCamp-uri. Însă din motive de logistică, particularităţi de infrastructură (o transmisie video cere broadband pentru o vizualizare decentă) şi diferenţe de limbă s-a decis transmiterea doar a prezentărilor, însoţite de sunet.

Să trecem deci la prezentări:

1. Keynote - Matt Chotin
Ca orice keynote, a fost un speech destul de general orientat pe noutăţile pe care le introduce FlashPlayer 10 şi pe ce ni se pregăteşte o dată cu Flex 4 şi Thermo.

2. Why/Where AIR - AIR apps use case
Prezentarea a fost ţinută de Mihai Corlan, unul din cei 4 platform evanghelişti din Adobe România. Un exemplu foarte fain de situaţie unde nu numai că folosirea unei aplicaţii AIR se preta, dar adăugă valoare şi feature-uri destul de importante unei aplicaţii Flash deja existente. Este vorba de MotorPlay şi de revista lor pe care aşteptăm să o vedem cât de curând în format .air . Practic Mihai Corlan şi Miţi Pricope au lucrat împreună cu dezvoltatorii de la MotorPlay pentru a trece revista lor dintr-un format Flash exportat cu Projector într-o aplicaţie AIR cu funcţii de offline browsing, auto update şi alte bunătăţi.

3. Flair Builder cu Cristi Pascu
Cristi a prezentat produsul la care lucrează singur de 6 luni şi care se doreşte să fie un tool de prototipare rapidă pentru Flex. E un fel de FlexBuilder, dar care conţine deja scriptate o sumă de comportamente, suport pentru stări şi tranziţii, etc. Prezentarea a fost interesantă atât prin prisma faptului că e vorba de un produs dezvoltat de o singură persoană cât şi a punctului de vedere (deseori neglijat) de la care pleacă - punct de vedere foarte bine sintetizat în „Clients are from Mars, Developers are from Jupiter and Project Managers are still on the Moon”.

Deşi nici Cristi nu e încă sigur de direcţia sau abordarea pe care o va avea Flair Builder, mie personal mi se pare o aplicaţie faină care permite dezvoltatorilor să facă rapid un prototip arătabil clientului şi care în mare să se comporte ca o aplicaţie reală, lăsându-le astfel mai mult timp de dezvoltare pentru ceea ce va deveni aplicaţia finală. (Cristi puncta bine că deşi dezvoltarea iterativă e foarte bună, datorită problemelor inerente de comunicare între client şi dezvoltatori, de multe ori progresul este destul de lent şi diferenţele între iteraţii pot fi puţin vizibile ceea ce poate duce la frustrarea clientului).

4. Boost your UI in AIR
Prezentarea lui Dragoş Dăscăliţa a vrut să atingă mai multe aspecte legate de UI ale dezvoltării aplicaţiilor AIR, dar, din păcate, Dragoş n-a apucat să-şi facă tot spectacolul.
Grosul prezentării a fost legat de skinarea aplicaţiilor AIR/Flex, Dragoş argumentând soluţia skinării programatice. Aceasta are avantajul scalabilităţii şi a unei oarecare flexibilităţi folosind CSS faţă de skinarea „grafică” ce foloseşte PNG-uri. A treia variantă de skinare (care-l sperie groaznic pe Miţi) este cea folosind simboluri Flash „pure” încărcate dintr-un SWF generat (cel mai probabil) cu Flash Authoring Tool.
Al doilea punct din prezentare a fost o comparaţie între DataGrid şi Repeater. În afară de nişte concepte de performanţă şi două-trei lucruri legate de limitările celor două abordări, partea asta a fost cam păsărească pentru mine (lucru deloc de mirare având în vedere experienţa mea deloc vastă în Flex).
Prima din cireşele de pe tort şi ultimul punct din prezentarea lui Dragoş a fost legată de PixelBender, subiect continuat cu mare artă de către Miţi în prezentarea următoare.

5. Bending Pixels and more
Într-o formă de zile mari şi cu un stil numai bun pentru a ţine audienţa trează la ora 21 şi ceva (şi după câteva beri), Miţi a prezentat unul din feature-urile foarte faine din FlashPlayer 10 şi anume PixelBender.
PixelBender este practic un limbaj de shadere pentru runtime-ul Flash. Marele lui avantaj este că ştie să profite de arhitecturile multi core şi ni se promite că în curând va şti să se execute şi pe placa grafică, acolo unde există posibilitatea. Astfel, se pot scrie diverse shadere în PixelBender care apoi sunt compilate în bytecode Flash şi încărcate într-o aplicaţie Flash/Flex. De aici pot fi aplicate pe imagini, pe video sau chiar pe componente Flash/Flex.

Un foarte fain exemplu de thinking outside the box a fost folosirea unui shader PixelBender pentru a mixarea a două sunete. Şi aici sporul de performanţă era vizibil, codul care folosea PixelBender fiind de 3-4 ori mai rapid decât cel implementat echivalent în ActionScript.

Magda a promis să urce o arhivă cu codul demonstrat de Dragoş şi Miţi pe myadobe cât de curând :)

6. Cabanova
O prezentare intrată „în concurs” pe ultima sută de metri a fost prezentarea despre Cabanova. Cabanova e un site builder realizat în Flex care ştie tot felul de lucruri interesante şi care în plus arată şi foarte bine. Singura mea nelămurire (pe care am uitat să o lămuresc) e cât şi unde diferă Cabanova faţă de nou lansatul ICE.

Per total a fost un eveniment foarte fain, prezentat de oameni entuziaşti şi entuziasmaţi pe bună dreptate. Câteva poze furate în timpul prezentărilor găsiţi aici.

Mihai

I'm here to talk about rounded corners...

...ahem, menus.
Am dat zilele trecute peste un articol foarte interesant al lui Jono DiCarlo despre design-ul interfeţelor web (deşi conceptele pot fi uşor extinse şi pentru interfeţele „clasice”) şi uzabilitate. Recomand cu căldură parcurgerea articolului original şi mai ales a exemplelor comparative, dar voi încerca să fac aici atât un scurt sumar al articolului cât şi o analiză comparativă a aspectelor prezentate de Jono pe blogul său. Din păcate în acest moment exemplele pot fi rulate doar sub Firefox 3, întrucât este singurul browser cu suport extins pentru tag-ul <canvas> din HTML 5.

Articolul promovează elementele cunoscute sub numele de pie menu şi discută cazurile de folosire ale lor, situaţiile în care sunt recomandate şi comparaţii cu soluţiile clasice. Să începem aşadar cu un pic de istorie. Punctul de plecare îl constituie o lege enunţată empiric, dar care de câteva zeci de ani deja se verifică statistic la fel de riguros. Este vorba de legea lui Fitts, care precizează timpul necesar deplasării unui pointer (fie că e vorba de mouse, touchpad sau stylus) până la o destinaţie (ţintă).

În formula anterioară T reprezintă timpul necesar mişcării în zona de ţintă, a şi b sunt două constante care depind de utilizator (şi deci sunt în afara controlului celui care face design-ul interfeţei) iar D şi W sunt, respectiv, distanţa de la punctul de start până la centrul ţintei iar W este lăţimea ţintei calculată pe direcţia deplasării. Întrucât a şi b depind de utilizator (gradul de familiaritate cu interfaţa, gradul de eficienţă în utilizarea dispozitivelor de intrare, tipul dispozitivelor - este cunoscut faptul că unele dispozitive de intrare sunt inerent mai rapide decât altele), singurele modalităţi prin care acest timp (oarecum mort din punct de vedere al productivităţii) poate fi scăzut sunt fie scăderea distanţei de la sursă la destinaţie, fie mărirea zonei de ţintă.

Acesta este un prim aspect. Un alt aspect fundamental în designul interfeţelor îl reprezintă gradul de memorizabilitate al unei interfeţe sau suite de interfeţe. Astfel, sunt preferate interfeţele care sunt uşor de învăţat şi care permit utilizatorilor să le folosească într-o măsură cât mai mare „pe orbeşte” (în sensul folosirii lor fără a mai depunde un efort conştient de operare a lor). Şi aici apare al doilea aspect în care susmenţionatele „meniuri plăcintă” au un avantaj faţă de meniurile „clasice”: la nivel psihomotor este mult mai uşor de memorat o direcţie/sens decât o distanţă propriu-zisă.

În plus, meniurile „clasice” mai păcătuiesc într-un aspect: de cele mai multe ori, direcţia de parcurgere a unui astfel de meniu este perpendiculară pe latura lungă zonei de ţintă, ceea ce face ca W-ul considerat anterior să scadă şi mai mult şi cerând din partea utilizatorului un grad mai ridicat de concentrare în operarea interfeţei (câţi nu am nimerit măcar o dată altă opţiune dintr-un meniu pentru simplul fapt că ne-a alunecat mouse-ul sau am fost prea aproape de marginea itemului pe care vroiam să-l selectăm?)

Bineînţeles că există şi dezavantaje în folosirea pie-menus. Acestea sunt aproape în totalitate de suprafaţa relativ constantă care poate fi folosită pentru prezentarea informaţiei şi a opţiunilor. Dacă un meniu clasic poate fi spart pe mai multe coloane (bad!) sau poate fi implementat un mecanism de scrolling (slow!) un pie-menu nu are nici un astfel de mecanism de evitare a suprapopulării. Iar în acest caz, problemele de precizie devin mai mari decât problemele pe care le rezolvă. A doua problemă în cazul folosirii inconsistene sau pur şi simplu neinsipirate a unui pie-menu se referă exact la aspectul memorizabilităţii. O suită de astfel de meniuri în care numărul de opţiuni variază semnificativ (şi eventual nici măcar în aceeaşi succesiune) scade dramatic gradul de memorizabilitate a unei astfel de interfeţe.

Articolul original prezintă cu mai multe ilustraţii şi cu exemple palpabile cele rezumate de mine mai sus şi ridică o serie de întrebări interesante despre evoluţia şi teoria design-ului interfeţelor, fie ele web sau nu.

Şi atunci stau şi mă gândesc: cum se face că deşi teoria există de ani buni, la nivel de concepte şi interacţiune fundamentală s-au schimbat prea puţine. Să fie interţia utilizatorilor atât de mare sau e doar frica de-a încerca ceva total revoluţionar?

Vă las să vă delectaţi, spre comparaţie, cu http://www.guidebookgallery.org/screenshots/full .

Mihai

GUI Archive

Căutând nişte imagini de interfeţe grafice pentru un articol pe care-l am în lucru (stay tuned!), am dat peste GUIdebook Gallery. E un site care intenţionează să fie un „muzeu online al interfeţelor grafice, mai ales al celor vechi, obscure şi cu o mare nevoie de-a fi conservate”. De ce îl menţionez aici? Pe lângă valoarea istorică (pentru că 20 de ani în termeni de IT&C actual înseamnă vreo 2 ere geologice), e un instrument foarte bun de analiză comparativă a interfeţelor cu utilizatorul, a evoluţiei şi rafinării lor.

Curioşii (sau nostalgicii) pot găsi aici screenshot-uri cu Windows 1.0, AmigaOS, iar amatorii de sisteme sau build-uri exotice se pot delecta cu imagini de Irix, Apollo sau build-uri nepublice de Windows Vista.

Lorem ipsum sau despre cum să umpli o pagină

Cine a ajuns pe blog în ultimele 2 zile probabil că a dat peste o pagină al cărei text arăta aşa.

Eu m-am întâlnit prima dată cu textul ăsta acum vreo 10 ani (ce departe pare), pe când mă jucam, în lipsă de altceva, cu Microsoft PowerPoint. La momentul respectiv nu ştiam decât vag de existenţa limbii latine, aşa că nu i-am dat prea multă importanţă. Fast-forward vreo 4 ani şi iată-mă jucându-mă cu Dreamweaver şi făcând site-uri care mai de care. Pe care mă chinuiam să le umplu cu un text oarecare, ca să văd dacă ideile mele se transpuneau grafic aşa cum îmi doream.

Aveam însă o problemă: chiar dacă grafica arăta OK, textul pus ca să „umple” pagina arăta extrem de ciudat. De ce? Respectivul text de umplere era realizat printr-un procedeu „avansat” de Copy/Paste din cel mult una sau două fraze cu un înţeles îndoielnic în limba română. Problema? Repetate de un număr suficient de mare de ori, duceau la apariţia unor linii verticale sau oblice formate din spaţiile dintre cuvinte. Soluţia (de atunci)? din când în când mai adăugam un cuvânt sau alternam textul pe care îl copy/paste-am.

Fast-forward până în prezent: acum câteva luni am descoperit lipsum.com. Pe scurt este un site cu care poţi genera, la comandă text de tip „Lorem ipsum”.

Utilitatea unui astfel de site (sau a unui astfel de text)? Obţinerea unui text care simulează/aproximează destul de bine distribuţia literelor şi a spaţiilor (în limba engleză). Textul în sine nu are sens şi, deşi la prima vedere pare a fi fiind scris în limba latină, asemănarea e doar aparentă. Şi totuşi, de ce ai prefera să umpli o pagină (un layout de carte, o pagină de revistă/ziar sau un sit web) cu astfel de text în pseudo-latină care pe deasupra nici nu are sens?

Primul motiv ar fi unul destul de pragmatic: în etapele iniţiale ale dezvoltării unui layout (şi uneori chiar până la final - dacă discutăm de un sit cu conţinut dinamic sau de o revistă) este foarte probabil să nu existe şi conţinutul care va fi pus în layout-ul în curs de realizare. Cu un astfel de text, se poate simula cum va arăta şi cum se va comporta layout-ul în momentul când va fi umplut cu conţinut.

Al doilea motiv este mai adânc legat de psihologia utilizatorului/beneficiarului: aceştia sunt obişnuiţi să se concentreze mai mult pe conţinut, lăsând mai puţin timp de efort conştient pentru analiza layout-ului. Iar cum în etapele preliminare, când se doreşte feedback de la utilizator/beneficiar tocmai asupra modului de prezentare, folosirea unui text fără sens este un mic truc prin care se canalizează atenţia spre layout.

Ar fi interesant de văzut cum ar arăta un text de tip „Lorem ipsum” pentru limba română. Se bagă cineva? :)

Mihai

De ce „Concrete web”?

Una din întrebările mele favorite este „De ce?”. „De ce?” este esenţa curiozităţii umane şi e motorul multor întreprinderi care au adus de foarte multe ori răspunsuri interesante, chiar dacă nu la întrebarea care le-a generat.
Aşadar, de ce Concrete web?

• pentru că ne plac lucrurile concrete. Generalităţile le ştiu mulţi, dar puţini le implementează într-un mod deştept.
• pentru că ne place să facem lucrurile pe fundaţii solide. După cum spunea un artist: „nu e nimic mai rău decât o imagine clară a unui concept neclar”
  
• nu în ultimul rând pentru că poate fi interpretat în multe feluri - la fel de variate ca şi noi
  

Să renunţăm acum la de şi să vedem ce veţi găsi aici:

• articole despre tehnologii noi, despre probleme interesante sau despre teorii mai vechi (cât de curând un articol pe această temă)
  
• soluţii interesante sau probleme care ne-au aţâţat curiozitatea
• diverse bucăţele de cod sau de înţelepciune care nouă ne-au fost utile la un moment dat sau care, dimpotrivă ne-au băgat beţe în roate (ca să ştiţi şi să vă feriţi de ele)
• orice legat de web, beton, sau amândouă ce-ar putea fi interesant :D
  

Şi dacă până-n acest moment v-aţi întrebat măcar o dată cine e acest „noi”, o să fac şi prezentările. Aşadar, Concrete web înseamnă (in no particular order):

• Vlad Ureche
• Ştefan Bucur
• Anamaria Stoica
• Mihai Balan

O să mai auziţi mai multe despre fiecare dintre noi noi cât de curând în zilele ce urmează. Până atunci, vă invităm să citiţi şi restul de articole, să comentaţi şi, dacă vă place ce-aţi citit, să vă abonaţi.

Mihai