eduardweb.
UI / UX & CSSIntermediar#css#frontend#responsive#ui-ux

Cum faci un dashboard B2B să nu crape pe mobil: sidebar, tabele și carduri

De Ioana Marinescu, 28 sept. 2026 · 12 vizualizări · 2 like-uri

Postat acum 3 zile
css
.table-wrapper {
  overflow-x: auto;
  -webkit-overflow-scrolling: touch;
  position: relative;
}

.data-table {
  width: 100%;
  border-collapse: separate;
  border-spacing: 0;
}

.data-table th:first-child,
.data-table td:first-child {
  position: sticky;
  left: 0;
  background: var(--bg-surface);
  z-index: 2;
  box-shadow: 2px 0 4px -2px rgba(0, 0, 0, 0.15);
}

Să bagi un dashboard plin de grafice și tabele pe un ecran de telefon e una dintre cele mai frustrante sarcini de frontend. Am refăcut anul trecut o aplicație internă pentru vreo 1.400 de agenți de vânzări care intrau de pe telefoane mid-range, iar experiența inițială era o bătaie de joc cu zoom manual. Iată cele trei tipare pe care le folosesc mereu ca să împac datele dense cu un viewport îngust.

1. Sidebar-ul: colapsabil pe desktop, drawer complet pe mobil

Marea greșeală pe care o văd des e încercarea de a păstra același comportament pe toate rezoluțiile. Pe un ecran de 1440px vrei un sidebar care se restrânge la iconițe (de la 260px la 64px) ca să lași loc tabelelor. Pe mobil, dacă lași o bandă de 64px de iconițe în stânga, ai mâncat deja 17% dintr-un ecran de iPhone.

Pe desktop merg cu un layout CSS Grid pe container: grid-template-columns: var(--sidebar-width) 1fr. Când utilizatorul dă collapse, schimb doar variabila CSS la 64px, cu un transition pe width. Sub 768px rup complet regula asta. Sidebar-ul iese din grid, devine position: fixed cu transform: translateX(-100%) și acționează ca un drawer clasic cu overlay. Trade-off-ul e că trebuie să gestionezi focus trap-ul și atributul inert pe restul paginii când drawer-ul e deschis, altfel pierzi complet accesibilitatea pe mobil.

2. Tabelele: scroll orizontal curat bate transformarea în carduri

Mulți devin obsedați de trucul acela de CSS unde pui display: block pe td și injectezi headerele prin content: attr(data-label). Am încercat abordarea asta la un tabel cu 14 coloane și 80 de înregistrări. A ieșit un dezastru: pagina avea o lungime infinită, iar userii nu mai puteau compara două valori între rânduri.

Pentru date analitice dense, scroll-ul orizontal nativ rămâne soluția corectă, dar are două condiții obligatorii:

  1. Prima coloană (numele clientului, ID-ul comenzii) trebuie să fie position: sticky; left: 0 ca să nu-și piardă omul reperul când dă swipe spre dreapta.
  2. Containerul tabelului are nevoie de un container scrollabil cu overflow-x: auto și un minim de umbră pe marginea din dreapta pentru a semnaliza vizual că mai există date.

3. Cards stack cu container queries

Când ai widget-uri de tip KPI (cifre mari, grafic mic dedesubt), media queries sunt adesea rigide dacă sidebar-ul tău își poate schimba lățimea pe desktop. Dacă ai 3 coloane de carduri și utilizatorul colapsează sidebar-ul, spațiul se mărește, dar breakpoint-ul de ecran rămâne același.

Aici folosesc container-type: inline-size pe wrapper-ul secțiunii de carduri. Dacă secțiunea are sub 350px, cardul afișează valoarea și badge-ul de status pe verticală. Când spațiul permite, trec în layout orizontal cu flex-direction: row. E mult mai modular decât să umpli fișierul de @media (max-width: 640px).

Trade-off sincer: scroll-ul orizontal cu coloane sticky e excelent pe B2B unde utilizatorii caută eficiență, dar e destul de prost primit în aplicațiile B2C unde oamenii se așteaptă la feed-uri ultra-simple.

Voi cum abordați tabelele masive pe telefon: preferați scroll orizontal cu sticky sau le ascundeți coloanele mai puțin importante în spatele unui dropdown modal?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.