Puneți pur și simplu, eroarea de scalare este fenomenul în care oamenii presupun în mod greșit că ceva care funcționează la aceeași mărime va funcționa, de asemenea, la o altă dimensiune. În acest articol, vom discuta modul în care această eroare intră în joc în lumea fizică reală, iar apoi vom explica cum să aplicăm lecțiile propriei dvs. modele de web.
Am văzut recent filmul pentru remake-ul filmului Ciocnirea Titanilor când acest principiu de design vechi a venit în minte. Într-o scenă climatică timpurie, scorpionii giganți continuă să atace eroul filmului într-o luptă epică cu moartea. Scorpionii, scalați la proporții uriașe, au fost agitați și morți, așa cum v-ați putea aștepta atunci când v-ați confruntat cu un astfel de dușman înfricoșător ...
Puterea efectelor digitale speciale în zilele noastre face să pară în întregime posibil ca o asemenea monstruozitate să poată apărea, având în vedere alinierea corectă a lui Zeus și a Ray de creștere de la Dragă, eu am copii (un alt exemplu minunat de ce știința și Hollywoodul nu ar trebui să facă copiii). Cu toate acestea, realitatea unui monstru gigantic mărit este fizic imposibilă.
În timp ce multe se spune despre insecte mici care pot să ridice greutăți uriașe în comparație cu dimensiunea relativă a corpului lor, realitatea pură a aceleiași puteri fiind transferată la o versiune superioară a aceleiași insecte pur și simplu nu funcționează în lumea fizică.
Un furnică minusculă poate să ridice 50 de ori greutatea sa, dar asta nu înseamnă că o furnică masivă de 1.000 de lire s-ar putea ridica 50.000 de lire. Efectele gravitației asupra unei insecte mici sunt practic inexistente, dar gravitatea devine o putere foarte reală odată ce dimensiunea este mărită. O furnică de 1.000 de lire s-ar fi confruntat cu dificultăți în a se rula în pat dimineața.
Eroarea scalabilității nu lucrează numai la scalarea lucrurilor mici până la mare - Un munte masiv poate rezista unei mii de ploi și furtuni de zăpadă ... dar un mic deal de murdărie va fi spălat de cea mai blândă briză.
Aduceți-vă ... ceea ce funcționează la o mărime nu funcționează întotdeauna când este scalat dincolo de intențiile de design originale. Designul, funcția și utilitatea aproape a oricărui lucru din întreaga lume sunt legate între ele prin scară. Eroarea apare atunci când un designer presupune că utilizabilitatea va fi reținută atunci când un design este scalat în sus sau în jos.
Fallacy Scaling vine în joc în designul web în două domenii cheie: interactivitate și ipoteze de încărcare. Vom discuta amândouă într-o clipă, dar pe măsură ce citiți, vreau să vă gândiți cât de ușor se rezolvă aceste probleme de scalare.
După cum spune vechea zicală, "retrospectivitatea este 20/20"... este capabil să prezică cu exactitate viitorul care este atît de dificil.
În majoritatea cazurilor, rezolvarea acestor probleme de proiectare este destul de simplă (adăugând un sistem de paginare, protejând un aspect de imaginile supradimensionate prin utilizarea CSS overflow: ascuns proprietate, instruindu-i pe clienți să nu se confrunte niciodată cu sistemul de navigație etc.). Toate aceste sarcini sunt ușor de făcut ... identificarea acestor probleme înainte de a se întâmpla, care necesită un gând atent și pregătire.
În regulă, hai să ne aruncăm în pietre:
Ipoteze de interacțiune apare atunci când creați un design pe baza unei presupuneri că comportamentul utilizatorului va fi același la diferite nivele de scară.
Exemplul clasic este acela al unui plan de evacuare a incendiilor: un plan general de evadare a unei case mici este simplu: ieșiți din clădire cât mai repede posibil, sunați la poliție. Aceeași strategie de ieșire, atunci când este aplicată unei clădiri de birouri din zgârie-nori, plină de oameni, ar duce la o catastrofă. Problema nu este design-ul pe cuvânt, este faptul că designul nu a reprezentat noua scală.
În designul web, presupuneri de interactivitate similare pot apărea atunci când presupuneți că un client va popula designul dvs. de web cu conținut cum vă așteptați să.
De exemplu, destinația de plasare, stilul și dimensiunea unei bare de navigare pot avea un sens perfect atunci când un blog are doar 4 sau 5 categorii, dar aceeași bară de navigare devine aproape inutilizabilă atunci când se adaugă 20 sau mai multe linkuri:
În acest caz, soluția este destul de simplă: instruiește clientul care folosește site-ul web să-și păstreze legăturile principale de navigare limitate la o mână (sau să utilizeze un meniu derulant pentru linkuri suplimentare).
Identificarea ipotezelor de interacțiune nu este știința rachetelor, ci necesită un fel de gândire flexibilă care să confere posibilități diferite. În ceea ce privește designul web, dacă proiectați un element, presupunând că va fi utilizat numai într-un singur mod (fie de către un utilizator, fie de persoana care introduce conținutul la un an după ce părăsiți proiectul), există o șansă foarte bună ca elementul va funcționa defectuos atunci când este folosit într-un mod în afara a ceea ce ați intenționat.
Iată doar câteva exemple în care sunt făcute ipoteze de interacțiune simple ... acestea nu sunt toate prin toate mijloacele, dar ar trebui să vă dau o idee bună despre cum funcționează acest lucru:
Cele mai multe dintre aceste probleme ar trebui să fie ușor de rezolvat ... doar câteva linii suplimentare de cod sau o simplă întâlnire educațională cu un client pot preveni apariția oricăror probleme ... dar ceea ce vreau să renunțați la acest lucru este că trebuie să anticipați întotdeauna scenarii în care desenele dvs. sunt utilizate în moduri pe care nu le planificați inițial pentru a fi utilizate.
Ipotezele de încărcare sunt puțin diferite - ele apar atunci când un designer presupune că tensiunile pe un sistem dat vor fi aceleași la fiecare scară. Ipotezele de încredere se întâmplă foarte mult pe partea de dezvoltare a unui proiect de web design; Efectuând presupuneri că un design web greu de imagine care funcționează atunci când 1.000 de oameni vizitează site-ul pe lună pot fi suflate din apă atunci când mai mult de un milion de oameni vizitează într-o zi și pune un stres suplimentar pe server. Același principiu se poate aplica și designului vizual actual al unui site ...
De exemplu, proiectați un aspect al galeriei de imagini, care este ușor de navigat atunci când sunt doar 10 imagini ... dar prin faptul că nu se oferă un sistem de "paginare" adecvat, întregul aspect devine dificil de navigat atunci când sunt adăugate mai mult de 25 de imagini.
Soluția este destul de simplă în acest caz: prin adăugarea unui sistem simplu de paginare, același design poate fi făcut "scalabil" cu câteva modificări mici. Se adaugă un sistem de paginare numerotat, iar whallah !, proiectarea dvs. este utilizabilă din nou ... la orice scară rezonabilă. Veți întâlni din nou problema de scalare numai dacă biblioteca de imagini a depășit rezonabil limitele sistemului de paginare ... la care punct va trebui să luați în considerare un sistem de etichetare și căutare mai rafinat.
Identificarea ipotezelor de încărcare este destul de simplă: imaginați-vă că orice parte specifică a designului dvs. este întinsă la limitele sale în ceea ce privește conținutul ... apoi planificați în consecință. Soluția ar putea fi un design sau un UI tweak (cum ar fi exemplul de paginare), dar ar putea fi, de asemenea, la fel de simplu ca instruirea utilizatorilor ce limite sunt. Dacă designul tău permite doar 100 de imagini și nu poți face nimic despre asta, spune-le utilizatorilor că în față. Vedeți cât de simplu este?
Ultimul tip de ipoteză pe care aș dori să îl descriu este cel pe care majoritatea dintre voi îl cunoașteți: ipoteze privind mărimea ecranului. Numai acest subiect este demn de blogul său propriu (mai multe despre această săptămână următoare), așa că voi încerca să păstrez acest scurt:
Dacă proiectați un site web și nu vă opriți niciodată pentru a testa cum arată într-o altă rezoluție, opriți-vă chiar acum și faceți-o!
Au trecut mult timp zilele în care 75% dintre surferii de internet navighează pe un monitor de 1024x768. În zilele noastre, oamenii navighează pe net pe ecrane de toate formele și dimensiunile ... de la ecrane minusculă la televizoarele HD masive.
Proiectarea unui site web presupunând că toată lumea de acolo are o anumită dimensiune a ecranului nu este doar vizibilă, ci subminează gradul de utilizare central al site-ului dvs. Deși este posibil să nu aibă sens să creați un site web diferit pentru fiecare tip de dispozitiv diferit, merită cu siguranță să luați o oră sau două pentru a lua în considerare cel puțin modul în care site-ul dvs. va cădea pe diferite tipuri de ecran și rezoluții.
Găsirea doar a câteva ajustări pe care le puteți face în timpul fazei de proiectare a unui site vă va salva o mulțime de durere pe termen lung. Iată câteva sfaturi rapide pentru a evita ipotezele de dimensiune a ecranului:
Nici un plan de luptă nu supraviețuiește contactului cu inamicul.
Singura modalitate reală de a evita eradicarea scalabilității este aceea de a fi în permanență în căutarea acesteia. Pe tot parcursul procesului de proiectare, ar trebui să fii conștient de propria dvs. tendință de a face acest tip de ipoteze.
Nu creați doar presupunerea că tot ce creați în Photoshop sau Focuri de artificii va rămâne același atunci când site-ul va fi lansat. Cu excepția cazului în care vă aflați într-un proiect în care veți fi singura entitate care proiectează și adaugă conținut pe site, este posibil ca cineva, la un moment dat, să adauge conținut care vă va sparge așteptările cu privire la modul în care a fost proiectat acest design fi folosit.
De asemenea, evitați proiectarea unor lucruri care funcționează numai într-o scară sever limitată. După cum știm cu toții, realizarea personalizărilor și revizuirilor la un design web poate fi un proces dureros, greoi și costisitor ... proiectarea sub eroarea de scalare face ca aceste probleme să se înmulțească, deoarece vi se va cere să vă revizuiți vechile desene ori de câte ori comportamentul oamenilor cade în afara ipotezelor proprii.
Atât deocamdată! Sper ca toată lumea să găsească acest post util ... Scala Fallacy este unul dintre acele principii enigmatice care sunt ușor de explicat în abstract, dar greu de înnebunit în proiecte concrete ... deci este nevoie de o mulțime de exerciții și vigilență constantă pentru a evita capcanele majore care vin de la ipotezele pe care le-am discutat.
Dacă ți-a plăcut postul sau ai ceva de adăugat, poți posta mai jos în comentarii. Noroc!