De ceva vreme, noi, la Jumping Rivers, am oferit o verificare a stării tabloului de bord (DHC) concentrată în mare parte pe funcțiile de backend și alte fațete pe care utilizatorul final nu le vede: lucruri precum controlul versiunilor, documentarea și implementarea. Cu toate acestea, DHC a inclus și câteva verificări legate de experiența utilizatorului și accesibilitate. Deși am crezut întotdeauna că acestea sunt completări utile, am dori să oferim clienților noștri îndrumări mai detaliate despre cum își pot face aplicațiile mai ușor de utilizat. Pentru a facilita acest lucru, introducem acum Verificarea sănătății tabloului de bord Frontend (FDHC).
Cu ce m-ar putea ajuta un FDHC?
Deci, ce fel de sfaturi puteți primi de la noi dintr-o verificare a stării de sănătate a tabloului de bord Frontend, s-ar putea să vă întrebați. Iată doar câteva dintre posibilități:
- Instrumente precum Shiny și Dash fac relativ rapidă și ușoară construirea de tablouri de bord de date. Acestea pot începe adesea ca o singură pagină fixă de date și, în timp, se transformă în ceva mult mai complex și interactiv, cu mai multe vizualizări. Astfel de aplicații pot fi incredibil de puternice, dar cu o putere mare vine grozav
responsabilitatecomplexitate. Pentru ca un tablou de bord să aibă succes, utilizatorii trebuie să înțeleagă cum să-l folosească eficient pentru a răspunde la întrebări. Acest lucru poate însemna descoperirea și/sau învățarea multor funcții de la navigarea de bază între vizualizări la modul de interogare a datelor conținute în folosind tehnici precum căutarea, filtrarea, sortarea, partiția, detalierea și rezumatul. Putem sugera locuri în care utilizatorii pot rămâne blocați sau confuzi și sugerăm mijloace de ameliorare. - Un tablou de bord de succes, pregătit pentru producție, trebuie, de asemenea, să fie robust. Cel puțin, asta înseamnă rezistență la intrările neașteptate ale utilizatorului și la propria incapacitate (poate temporară) de a furniza ieșirea pe care se presupune că (dacă un server este defect, de exemplu). O aplicație care se blochează doar când ceva nu merge bine va deruta și va frustra utilizatorii și poate duce la pierderi de timp și chiar la pierderea muncii. Vă putem arăta unde se poate prăbuși aplicația dvs., astfel încât să puteți lua măsuri pentru a o preveni.
- În prezent, consumăm pagini de pe World Wide Web folosind tot felul de dispozitive. Aplicația dvs. funcționează pe monitoare 4k și 5k? Mai important, la celălalt capăt al scalei, acum există de obicei așteptarea ca lucrurile să funcționeze pe dispozitive mobile și alte dispozitive cu ecran tactil. Vă putem arăta la ce dimensiuni aspectul aplicației dvs. poate deveni dificil sau imposibil de utilizat și unde utilizatorii care folosesc anumite metode de introducere – de exemplu mouse, atingere, tastatură – pot avea dificultăți.
Ce rezultate aș primi de la un FDHC?
Principiul livrabil de la un FDHC este o foaie de calcul detaliată care indică problemele pe care le-am găsit și unde pot fi găsite (sau cum să le reproducem). Oriunde este practic, vom include și capturi de ecran adnotate (sau ocazional înregistrări) care oferă o descriere vizuală a unei probleme (vezi mai jos). De asemenea, ne vom strădui să sugerăm posibile remedii.
Dar vechiul DHC?
Vom continua să oferim o verificare separată, bazată pe rapoarte, de sănătate pentru tablourile de bord de date. Această „Verificare a stării tabloului de bord” (BDHC) va acoperi lucruri precum controlul versiunilor, documentația, implementarea ca înainte. Desigur, suntem mai mult decât fericiți să rulăm un BDHC și un FDHC pe aceeași aplicație.
Cum aflu mai multe?
Vă rugăm să ne contactați prin acest formular de contact sau să ne trimiteți un e-mail la (e-mail protejat).
Pentru actualizări și revizuiri ale acestui articol, consultați postarea inițială
