Poti fura niste milisecunde dintr-o actiune cu mouse-ul daca te folosesti de evenimentul onMouseDown() din DOM.
Anticipezi logic actiunea de click odata ce butonul mouse-ului este apasat asa ca poti declansa un fir de executie in JS imediat ce ai inregistrat inceputul.
Acest truc iti permite sa “furi” cateva milisecunde pretioase din timpul unui download.
Un truc poate fi aplicat cu success este sa te folosesti de onMouseOver pe controalele dintr-o galerie foto intr-un sistem de livrare prin AJAX.
Mi se pare o actiune logica sa incepi preload-ul in background a pozei determinate de un thumbnail cand ai o constructie de navigatie similara cu cea de la Flickr. Din punct de vedere al interfetei ai putine motive sa faci hover peste acele imagini daca nu doresti sa navighezi prin galerie.
Desigur, e o jonglerie de performanta. Daca lansezi prea multe download-uri bazate pe actiuni incomplete ale userului poti deteriora experienta, dar cred ca daca iti gandesti bine planul de preload iti poti face galeria sa para mai rapida (as in responsive) pentru ca te folosesti de milisecundele dintre onMouseDown() si onClick()-ul complet pentru a incarca in browser o parte din continut.
Foloseste onMouseDown cu responsabilitate!
Uneori imi dau seama ca fac un click din greseala si imi mut cursorul de pe link, apoi dau drumu butonului. Asta impiedica actiunea de click.
Ai concurenta serioasa pe nisa pe care ai ales-o dar produsul tau ofera servicii mai bune.
Un mod prin care poti convinge mai multi utilizatori sa renunte la produsul concurentei in favoarea ta este sa oferi functii de import a continutului lor de acolo. Cineva care a muncit mult sa isi construiasca tab-uri, categorii si articole la ceilalti este reticent in a schimba produsul daca trebuie sa isi reconstruiasca preferintele in aplicatia ta.
Este frumos sa oferi la randul tau o metoda de export, si daca esti om bun, scuipi datele intr-un format oarecum standard de XML usor de interpretat. Acest lucru este benefic pentru ca nu iti permite sa te plafonezi cat timp ai concurenta care te tine in priza constant si te impinge la creativitate.
Intr-o lume perfecta datele tale nu ar trebui sa te tina legat de un sistem proprietar, inchis.
Un utilizator nemultumit care iti foloseste produsul doar pentru ca este obligat de circumstante poate fi nociv pentru aplicatia ta si imaginea sa. Brandul Microsoft a avut adesea de suferit din aceasta cauza.
Daca folosesti Netvibes drept feed reader si vrei sa stii cate feed-uri se ascund in tab-urile tale poti exporta feed-urile intr-un fisier opml si poti folosi urmatorul snippet de JS impreuna cu jQuery:
$.get("feeds.opml", function(data){
var count = $(data).find('outline[type="rss"]').length;
console.log(count);
});
In exemplu feeds.opml reprezinta fisierul tau cu feed-uri.
Poti exporta un opml cu feed-urile tale din Netbvibes din meniul “Your profile” > “Feeds”.
Denumirea claselor sau id-urilor in CSS dupa proprietatile elementului este improprie. Exemple de denumire gresita sunt:
#rounded-menu sau .blueLink
Argumentul cel mai comun adus impotriva acestor denumiri este ca face dificila mentenanta codului in sensul ca proprietatile elementelor se vor schimba in timp ce numele de clasa / id raman aceleasi. Pe termen lung denumirile de acest gen isi pierd relevanta si fac debugging-ul dificil.
Un aspect care mi se pare des pierdut din vedere este ca aceste denumiri impiedica reutilizarea usoara a codului.
De multe ori te vezi construind componente similare in structura: meniuri liniare, box-uri de search, butoane proeminente.
Daca meniul tau se cheama #rounded-menu sau #top-menu implementarea sa intr-un alt site necesita niste renaming pentru a-i da ceva relevanta daca proprietatile nu raman similare.
OOCSS este un concept foarte bun in care iti construiesti componente generice pe care le poti extinde apoi in site-urile in care le implmenetezi.
.pipe-menu sau .tab-menu mi se par mai usor de reutilizat.
.box, .box-header, .box-footer, si .box-content pot fi niste componente foarte utile pe termen lung.
Cand iti trebuie continut dintr-un input cu un format special si ti-e lene sa aplici niste logica sau expresii regulate pe server poti folosi un plugin de jQuery care iti ajuta userul sa introduca datele corect.
Mi se pare un plugin indispensabil celor care prezinta formulare care cer date / numere de telefon intr-un format inflexibil.
Acest plugin iti poate reduce numarul de useri frustrati care primesc o eroare dupa submitarea formularului pentru ca au uitat sa introduca o cratima intre prefix si numarul de telefon.
Niciodata nu ar trebui sa te bazezi pe datele prelucrate doar pe client pentru ca JavaScript-ul se poate dezactiva si cineva iti poate face ravagii pe server.
Sectiuni in constructie
Este gresit sa oferi utilizatorului ceva ce nu poate folosi. Creezi utilizatorului asteptari pe care nu le poti implini si asta iti lasa vizitatorul frustrat. Un principiu de baza in usability este “If I see it, I click it!”.
Nu trebuie sa ai sectiuni “in constructie”. Daca nu e gata, nu exista.
Planuri de viitor
Nu este bine sa ai in descrierea site-ului tau ce planuri de viitor ai cu el. Nu incerca sa promiti feature-uri pe care nu esti sigur ca le vei construi. Este irelevant pentru utilizator ce vei construi. Este mult mai important ca ceea ce ai construit sa functioneze foarte bine.
In acelasi timp, nu este bine sa divulgi planurile de viitor in cazul in care ai concurenta serioasa pe care vrei sa o devansezi.
Daca te gandesti la un feature care va rupe gura targului dar nu ai in plan sa il implementezi curand, a-l mentiona in documente este o greseala de strategie din partea ta. Concurenta care are bani, timp si este deschisa la nou iti poate sufla ideea construind feature-ul intr-o clipita.
Nu trebuie sa faci promisiuni, s-ar putea sa nu le indeplinesti si asta e frustrant pentru userul care asteapta ceva promis de tine.
Nicholas Zakas scrie despre cum aruncatul de erori in JS este benefic developerilor.
Si nu doar actiunea de throw a erorilor ci mai degraba mesajul util care sa te ajute sa identifici mult mai usor de unde vine problema.
Nicholas sustine ca ar trebui sa arunci erori in consola atunci cand metoda este susceptibila de a primi argumente neasteptate. Este impractic sa faci error checking si error throwing pe orice metoda, mai ales cand ai control asupra argumentelor pasate acesteia (vezi metode private in JS).
E un articol sanatos de citit si recomand sa urmezi sfaturile.
Recent am avut de implementat o componenta JS ceva mai complexa si din experienta stiu ca cei ce o vor implementa tind sa nu citeasca specificatiile. E ok, nici eu nu RTFM.
Este mult mai rezonabil sa arunci errori in consola browserului care descriu problema decat sa primesti email-uri si telefoane de la oameni confuzi care nu inteleg de ce nu le merge jucaria.
Suna profan in lumea CSS dar Nicole Sullivan propune ceva foarte sanatos: sa iei conceptele din programarea orientata pe obiecte si sa le aplici in dezvoltarea fisierelor tale de CSS.
In termeni simpli propunerea consta in a-ti scrie module generice pe care le vei reutiliza in paginile tale. Aceste module generice se vor extinde prin adaugarea mai multor clase.
Necesitatea OOCSS o vei simti atunci cand lucrezi la site-uri de talie mare cu multe pagini. Desi un site simplu poate beneficia de principiile OOCSS, atunci cand ai de intretinut zeci, sute de pagini suna mult mai rational sa iti standardizezi CSS-ul.
Prin standardizare nu ma refer la validare ci la construirea de elemente cu aspect general similar peste tot in paginile site-ului tau. In principiu nu ar trebui sa scrii CSS suplimentar pentru fiecare modul nou pe care il adaugi decat daca acesta este radical diferit de ceea ce ai deja la dispozitie.
In general developerii de front-end nu au incredere si prefera sa nu foloseasca din codul scris de ceilalti inaintea lor.
Nicole propune un framework (4kb !) construit pentru a ilustra principiile OOCSS pe care le sustine in aceasta prezentare:
Poti sa iti iei framework-ul OOCSS de pe github
Nicole Sullivan este un Perfomance Engineer de la Yahoo! care se ocupa si de tool-urile de la Exceptional Performance
Uite un articol care ilustreaza foarte bine principiul KISS (Keep It Simple, Stupid)
Teaser:
…six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time.
Sursa: lixo.org
Cand faci un sistem de rating (notare) sa nu construiesti ca boul un call de tipul:
rating.php?post_id=1&stars=5
Unde valoarea lui stars este cea care intra in formula de calcul pentru medie (ponderata, de regula) De ce esti un bou daca faci asta?
Inchipuie-te ca eu pun in url:
rating.php?post_id=1&stars=9999
Iti cam fute calculele “Top rated”, nu-i asa?
Rating for dummies:
- Sa nu ai incredere in client
- Valoarea care vine din client trebuie sa fie un id pentru valoarea propriu-zisa a votului
Pe server iti faci match-ul si calculezi rezonabil. Id-ul nu corespunde? un sincer ip userului si treci mai departe.
Ai fi surprins sa stii ca sunt foarte multe sisteme de rating pe web care sufera de vulnerabilitatea asta.
Chiar si la case mari.
