.table-container {
width: 100%;
overflow-x: auto;
-webkit-overflow-scrolling: touch;
}
.dashboard-table {
width: 100%;
border-collapse: collapse;
white-space: nowrap;
}
/* Înghețăm prima coloană pentru context la swipe */
.dashboard-table th:first-child,
.dashboard-table td:first-child {
position: sticky;
left: 0;
background: #ffffff;
z-index: 1;
box-shadow: 2px 0 5px -2px rgba(0, 0, 0, 0.1);
}
/* KPI Grid fluid fără media queries */
.kpi-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
gap: 1rem;
}Să bagi un dashboard de desktop într-un ecran de telefon fără să arate ca o ciorbă reîncălzită e o provocare clasică de UI. Anul trecut am refăcut interfața unui SaaS B2B unde vreo 25% dintre manageri intrau să aprobe comenzi direct de pe mobil, între două ședințe. Dacă abordezi corect trei elemente cheie — sidebar, tabele și carduri —, scapi de 90% din tichetele de suport legate de layout.
Sidebar: drawer pe mobil, mini-bar pe tabletă
Când ai 10-15 link-uri în meniu, nu le lași vizibile pe ecran mic. Pe desktop ții sidebar-ul clasic la 240px lățime, dar pe tabletă (între 768px și 1024px) îl strângi la 64px, afișând doar iconițele centrate cu un tooltip simplu la hover.
Pe mobil (<768px), sidebar-ul devine obligatoriu un off-canvas drawer peste conținut, activat de un hamburger button. Am văzut colegi care încercau să împingă conținutul paginii spre dreapta la deschiderea meniului. Pe un viewport de 375px, dacă muți layout-ul 260px în dreapta, userul vede un dezastru orizontal. Nu împingi nimic: pui drawer-ul cu position: fixed, acoperi restul paginii cu un backdrop semi-transparent de rgba(0,0,0,0.5) și blochezi scroll-ul pe body cât timp meniul e activ.
Tabele late: de ce prefer horizontal scroll în loc de carduri
Aici e marea dezbatere. Mulți încearcă hack-ul acela celebru din CSS unde fiecare <tr> devine un card cu display: block, iar valorile sunt afișate sub etichete generate din pseudo-elemente ::before. Pare o idee sclipitoare până când dai de date reale.
La un modul de facturare cu 40 de rânduri și 9 coloane, conversia automată în carduri a transformat pagina într-un ecran lung de 10 metri. Managerul voia doar să compare rapid statusurile comenzilor din aceeași zi, dar trebuia să dea scroll nebunește timp de 30 de secunde. Pierzi complet capacitatea de a scana datele vizual.
Soluția mult mai pragmatică pe care merg de atunci: wrapper cu scroll orizontal nativ și coloană înghețată. Pui overflow-x: auto pe container, white-space: nowrap pe celule, iar prima coloană (numele clientului sau ID-ul) o fixezi cu position: sticky. Utilizatorul dă swipe natural ca într-un spreadsheet, dar știe mereu pe ce rând se află.
Cardurile de KPI: auto-fit fără breakpoint-uri rigide
Pentru zona de sumar din topul paginii (venituri, comenzi noi, clienți activi), nu te complica cu 5 media queries diferite pentru diverse modele de telefoane. Folosește puterea CSS Grid cu auto-fit și minmax.
Setezi un grid cu repeat(auto-fit, minmax(240px, 1fr)). Pe un monitor 4K sau 1080p o să ai 4 sau 5 carduri pe rând, pe tabletă pică frumos două câte două, iar pe mobil se așază automat într-o singură coloană, fără să scrii un singur @media (max-width: 600px).
Trade-off-ul sincer
Scroll-ul orizontal pe tabele nu e cel mai iubit de designerii puriști de Dribbble, dar pentru un utilizator care lucrează cu volume de date e de zece ori mai eficient decât cardurile stivuite la nesfârșit. Păstrează cardurile doar pentru formulare sau liste scurte (sub 5 elemente).
Voi ce abordare preferați când aveți de afișat tabele mari pe mobil: scroll orizontal asistat sau view-uri complet separate construite nativ pentru ecran mic?