Cinci verificări înainte de zbor pentru tabloul de bord

Așa că v-ați construit conducta de date, v-ați proiectat tabloul de bord și le-ați conectat pe cele două printr-o aplicație reală. Capturile de ecran se potrivesc cu designul și le puteți arăta și uimiți părțile interesate. Gata de lansare, nu? Ei bine, poate. În această postare vom acoperi cinci lucruri care sunt ușor de trecut cu vederea: unele merită o verificare rapidă, altele pe care poate nu te-ai fi gândit să le adaugi.

Exemplu de tablou de bord

Cu toate acestea, înainte de a ne aprofunda în aceste cinci lucruri, voi prezenta exemplul de tablou de bord. Utilizează date de la {nycflights13} Pachetul R dezvoltat de Hadley Wickham, dar este construit în totalitate fără R. În schimb, este construit folosind tehnologii web standard de front-end: HTML, CSS și JavaScript, cu date provenind dintr-un singur fișier JSON monolitic gzipped. JavaScript adaugă apoi ceva zgomot la date, astfel încât să arate mai mult ca date live (și astfel tabloul de bord nu pare binecuvântat cu previziune 20/20).

Prezentarea vizuală reală este cea a panourilor de plecare online pentru cele trei aeroporturi din New York/New Jersey — John F. Kennedy Intl, La Guardia și Newark Liberty Intl — împreună cu unele informații despre vreme și unele KPI presupuse.

Fiecare rând de tabel și fiecare card KPI se poate face clic, afișând un mod cu informații mai detaliate. Vă rugăm să rețineți că, alertă spoiler, tabloul de bord nu (încă) funcționează bine pe mobil. Vom ajunge la asta în scurt timp.

Dezvăluire completă: pentru prototiparea rapidă, tabloul de bord a fost construit printr-o sesiune extinsă de promptare cu Claude Code. Cele mai multe dintre problemele pe care le voi acoperi sunt probleme autentice care au apărut în sesiune, dar într-un caz i-am cerut lui Claude să omite o caracteristică pe care dorea în mod clar să o adauge, doar în scopuri ilustrative. Acest exemplu, în starea în care se află, este menit să reprezinte un tablou de bord pe care o inteligență – umană, artificială sau marțiană – ar putea considera în mod rezonabil că este gata să-l livreze. Restul acestei postări expune câteva defecte rămase.

Cinci lucruri de verificat

Designul funcționează la diferite dimensiuni ale ecranului?

Acesta este cel mai ușor de verificat și, poate, cel mai important. În timp ce tablourile de bord sunt încă în primul rând construit pe mașini desktop, realizându-le vizibilă pe tablete și telefoane mobile ar trebui să facă parte din majoritatea planurilor de dezvoltare. Mulți, probabil majoritatea (datele sunt inconsecvente și foarte dependente de subiect și regiune), oamenii folosesc dispozitive mobile pentru a consuma conținut pe World Wide Web și ar trebui să aveți un motiv foarte bun pentru a le exclude din tabloul de bord. Nu doar îmbunătățirile aduse hardware-ului mobil îi împing pe oameni în acest sens; extinderea tehnologiei de rețea mobilă de generația a cincea (5G) poate face experiența mult mai plăcută decât era înainte, mai ales atunci când consumatorii înșiși sunt mobili.

Această captură de ecran a eșantionului nostru de bord evidențiază rapid o mare problemă cu acesta: este literalmente imposibil să afișați datele pentru aeroportul La Guardia, deoarece „butonul” său (nu este chiar un buton, care este o altă problemă la care vom aborda mai târziu) este în partea dreaptă a paginii, fără posibilitatea de a derula la el.

Mai puțin critică, dar care merită totuși reparată, este derularea în două sensuri a tabelului. Acest lucru poate fi evitat prin stivuirea coloanelor de tabel pe ecrane înguste. Ambele remedieri sunt afișate în următoarea captură de ecran. (Conținutul este mult mai înalt acum, așa că arătăm întreaga pagină, nu doar partea vizibilă. Pe telefonul meu, de exemplu, partea de sus a tabelului poate fi văzută fără derulare.)

Există de fapt o problemă cu aspectul în ambele dimensiuni: pe un ecran mai scurt – poate o fereastră mică de browser pe un notebook înghesuit – masa poate deveni inaccesabilă. Problema aici este că, în proiectarea pentru browsere desktop (mai mari), designul a presupus o înălțime minimă a browserului și apoi derularea numai pe masă și nu pe fereastra browserului în sine. Acest lucru funcționează bine când fereastra browserului este suficient de înalt, deoarece obțineți informații fixe în partea de sus, fără derulare imbricată. Dar când această condiție (arbitrară) de înălțime minimă nu este îndeplinită, proiectul eșuează. Deci, acesta este un alt lucru care ar trebui remediat înainte de lansare.

Aplicația acceptă ecrane tactile?

Sprijinirea dispozitivelor mobile și tabletelor nu se referă doar la aspect. Interacțiunile trebuie să funcționeze atunci când intrarea vine de la un deget sau un stilou, mai degrabă decât de la mouse și tastatură. De fapt, sunt două lucruri de luat în considerare aici:

1. Toate interacțiunile pot fi realizate prin atingere?
2. Este evident ce interacțiuni sunt de fapt posibile?

Aplicația de bază permite utilizatorului să „schimbe ora” printr-un dialog care se deschide numai când apăsați butonul T cheie. Acest lucru, evident, eșuează 1). O putem remedia făcând ceasul însuși într-un obiect de atingere care afișează același dialog ca și apăsarea tastei T (acest lucru oferă și utilizatorului acces la opțiunea de pauză care anterior era posibilă doar prin apăsarea butonului). P cheie). Acest lucru ne aduce clar la punctul 2): ​​nu este în mod inerent evident că ceasul poate fi apăsat. Nici nu este evident că cărțile și rândurile pot fi atinse pentru informații detaliate. Cu un mouse cel puțin, acestea își schimbă culoarea (ușor) atunci când treci cu mouse-ul deasupra. Mai avem nevoie de ceva: putem merge cu o pictogramă comună și ceva text explicativ.

Este aplicația accesibilă?

Dincolo de utilizarea pe mobil, există o serie de probleme suplimentare de accesibilitate cu versiunea de bază a aplicației. Cel puțin trei dintre acestea se referă la utilizarea tastaturii:

1. Elementele interactive asemănătoare butoanelor nu sunt HTML button elemente și, prin urmare, nu au interacțiuni și semantică adecvate pentru a îndeplini cerințele WCAG;
2. Nu tot ceea ce poate fi făcut clic/atingat poate fi interacționat de către un utilizator de tastatură;
3. Modalul care apare la selectarea elementelor interactive nu implementează captarea focalizării, ceea ce înseamnă că un utilizator de tastatură poate pierde focalizarea undeva în fundal, în spatele ferestrei modale.

Putem rezolva toate aceste probleme cu o mai bună utilizare a elementelor HTML: buttons pentru selecția aeroportului, lansarea modală KPI și lansarea modală de zbor și dialog element pentru ferestrele modale. În plus, unele texte din aplicația de bază nu îndeplinesc cerințele de contrast de culoare, așa că vrem să remediem și acest lucru.

Indicatorul de focalizare de la tastatură folosește culoarea de accent galben găsită în altă parte în aplicație. În retrospectivă, aceasta a fost probabil o greșeală. Un indicator de focalizare diferit de culoare ar face mai clar ceea ce a avut focalizarea tastaturii, spre deosebire de ceea ce a fost selectat de fapt (adică ce aeroport este afișat în prezent).

Este aplicația performantă?

Aplicația este menită să simuleze date reale, dar permite utilizatorului să selecteze, să întrerupă și să accelereze timpul. În consecință, datele nu sunt transmise în formatul în care ar fi dacă ar fi a real urmărirea aplicației trăi evenimentelor. Dar încă putem încerca să optimizăm modul în care transmitem datele în aplicația noastră de date simulate. Cel mai mare câștig pe care l-am găsit aici a fost conversia datelor din rânduri în coloane. Acest lucru a redus dimensiunea datelor (gzipped) cu o treime, de la 4,8 MB la 3,2 MB, iar timpii de analiză JSON de la ~550 ms la ~250 ms.

Desigur, este important să nu pierdeți timp și resurse cu optimizări premature și inutile. Așadar, luați în considerare modificarea datelor de mai sus ca un exemplu de unde s-ar putea dori să căutați, mai degrabă decât o schimbare care era strict necesară.

Un alt loc de privit este dimensiunea imaginilor. Pentru tablouri de bord, asta înseamnă adesea vizualizarea datelor. Imaginile raster mari, care se schimbă frecvent, trimise de pe server pot duce la atingeri de performanță. Aceasta este ceea ce obțineți, în mod implicit, în aplicațiile Shiny atunci când utilizați renderPlot()/plotOutput(). Pachete care redau SVG sau HTML canvas direct în browser poate reduce foarte mult cheltuielile generale.

Se pare că aplicația răspunde imediat la interacțiune?

Performanța reală este un lucru, dar performanța percepută poate fi și semnificativă. Dacă un utilizator dă clic pe un buton și nu se întâmplă nimic pentru o secundă sau două, lucrurile „se simt” rupte chiar dacă, în realitate, browserul doar procesează lucrurile în tăcere în fundal. În cazul nostru particular, există o întârziere simulată de ~2 secunde la schimbarea aeroportului. Faceți clic sau atingeți un aeroport și nu se întâmplă nimic. (Dezvăluire: aici a trebuit de fapt să-l forțez pe Claude să nu pună ceva pentru a-mi expune punctul de vedere.) Există o serie de opțiuni aici pentru cum să rezolv acest lucru. Cel mai simplu ar putea fi să setați cursorul la o valoare de „așteptați” în CSS, dar acest lucru nu i-ar ajuta în mod evident pe utilizatorii de dispozitive cu ecran tactil care nu au un cursor. O alternativă mai bună este să arăți tuturor un indicator de încărcare. Acestea se rotesc de obicei, astfel încât să putem folosi un GIF animat sau un fișier imagine static și animații CSS.

Pentru așteptări mai lungi, un indicator de progres ar fi o opțiune mai bună dacă ar fi posibilă estimarea efectivă a progresului. Acest lucru s-ar asigura că nu părea că pagina s-a blocat. Pentru o așteptare de o secundă sau două, acest lucru nu este necesar; cerința este doar ca utilizatorul să vadă că acțiunea sa de a face clic pe un aeroport a avut efect imediat.

Rezumat

Puteți vedea toate remediile discutate în această postare (și altele pe care a trebuit să le omitem pentru concizie) în versiunea finală a tabloului de bord. Sperăm că acest articol a ilustrat că pot exista destul de multe probleme cu un tablou de bord nou proiectat, care pot fi subtile sau ascunse, mai ales dacă testați doar cu un mouse pe un computer desktop. Scopul aici nu a fost să vă sperie să nu publicați în întregime, așa că sper că nu am făcut asta, ci să subliniez că dispozitivele prin care se dezvoltă și se consumă un tablou de bord sunt adesea destul de diferite: nu uitați să proiectați pentru acesta din urmă. În mod similar, doar pentru că știi că ceva funcționează și se va încărca în cele din urmă nu înseamnă că te poți aștepta ca utilizatorii tăi să fie la fel de răbdători și iertatori.

Pentru actualizări și revizuiri ale acestui articol, consultați postarea inițială