Najpierw ustal pytanie, na które odpowiada zestawienie
Tabela nie jest automatycznie dobrym sposobem pokazania wielu informacji. Sprawdź, czy odbiorca porównuje jedną cechę kilku ofert, czy poznaje pełny opis jednego wariantu. Przy pierwszym zadaniu układ kolumn może pomagać. Przy drugim karta z opisem bywa prostsza. Przykładowa firma wynajmująca sprzęt może porównywać udźwig, wysokość roboczą i warunki dostawy. Umieszczenie w tej samej tabeli całego regulaminu nie zwiększy jej użyteczności.
Zapisz scenariusz: klient ma znaleźć urządzenie pasujące do szerokości wjazdu i terminu pracy. To podpowiada kolejność parametrów oraz sens filtrów. Nie zaczynaj od liczby kolumn mieszczących się w projekcie. Usuń dane pozorne, takie jak identyczna zielona ikona przy wszystkich wariantach bez wyjaśnienia jej znaczenia. Ważniejsza od dekoracyjnej symetrii jest możliwość odnalezienia różnicy, która rzeczywiście wpływa na wybór.
Relacje między komórkami muszą istnieć również w HTML
W tabeli danych nagłówki oznacza się elementem th, a zwykłe komórki elementem td. Atrybut scope może wskazać, czy nagłówek dotyczy wiersza, czy kolumny. Przy bardziej skomplikowanych zależnościach potrzebne bywa jawne powiązanie komórek. Dzięki temu czytnik ekranu ma szansę przekazać kontekst wartości, a nie odczytać samotne „dwadzieścia”. Podpis caption wyjaśnia temat zestawienia bez konieczności odgadywania go z otoczenia.
W makiecie przetestuj odczyt pojedynczej komórki. Jeżeli zawiera „24”, użytkownik powinien rozumieć, czego dotyczy ta liczba, w jakiej jednostce i dla którego wariantu. Wizualne wyrównanie w pionie nie wystarcza jako jedyny nośnik tej relacji. Unikaj tworzenia zwykłych tabel danych z przypadkowych divów tylko dlatego, że łatwiej je ostylować. Semantykę projektuj razem z układem, a nie jako końcowy dodatek do gotowego ekranu.
Ujednolić trzeba jednostki, nie tylko kolory
W przykładowym porównaniu jedna kolumna może podawać cenę za dobę, a druga za tydzień. Nawet elegancki układ stanie się wtedy mylący. Zapisz jednostkę przy parametrze i wyjaśnij warunki, które zmieniają wartość. Znak „-” również wymaga jednoznacznego znaczenia: brak danych to nie to samo co brak funkcji. Gdy parametr jest niedostępny, nie zastępuj go zerem, ponieważ zero bywa prawidłową i istotną wartością.
Przy zakresach podawaj oba końce oraz warunek ich zastosowania. „Od 100” nie jest porównywalne ze stałym „150”, dopóki nie wiadomo, czego dotyczą kwoty. Warto osobno wyróżnić dane potwierdzone i szacunki, ale nie opierać tego wyłącznie na kolorze. Uzupełnij oznaczenie tekstem. Przygotuj próbkę z najdłuższą jednostką i największą liczbą, aby sprawdzić szerokość kolumn przed opublikowaniem rzeczywistego katalogu.
Wąski ekran wymaga wyboru, a nie automatycznego ściskania
Nie każda tabela musi zmienić się w karty. Jeśli porównanie dwóch wymiarów jest kluczowe, dopuszczalny może być niezależny, poziomo przewijany obszar samej tabeli. Nie powinien jednak rozszerzać całej strony. Użytkownik musi rozpoznać, że istnieją dalsze kolumny, a obsługa klawiaturą powinna pozwalać dotrzeć do danych. Widoczna wskazówka i zachowany kontekst są lepsze niż ukrycie paska przewijania dla samego wyglądu.
Przy prostszych danych można przygotować widok kart, ale nie wystarczy przestawić komórek bez etykiet. Każda wartość potrzebuje nazwy parametru. Rozważ też wybór dwóch wariantów do porównania zamiast pokazywania od razu dwunastu. Odbiorca powinien móc wrócić do listy bez utraty wyboru. Nie pobieraj dwóch niezależnych kopii danych dla tabeli i kart: łatwo wtedy o różnice po aktualizacji ceny lub dostępności.
Interakcje mają objaśniać, co zmieniło się w zestawieniu
Sortowanie po kolumnie musi mieć czytelną nazwę i stan. Strzałka bez etykiety nie wyjaśnia, czy uporządkowano dane rosnąco, ani czy przycisk w ogóle działa. Po zmianie kolejności zachowaj kontekst i nie przenoś niespodziewanie użytkownika na początek dokumentu. Przy filtrze „pokaż tylko różnice” określ, jak traktujesz brakujące dane. Brak wartości w jednym produkcie nie powinien zostać ukryty jako zgodność.
Dla tabel redakcyjnych osobno zaplanuj przypisy i rozwijane objaśnienia. Informacja konieczna do porównania nie może być dostępna jedynie po najechaniu myszą. Użytkownik telefonu nie ma takiej interakcji. Przyklejony nagłówek może pomóc w długiej tabeli, lecz sprawdź, czy nie zasłania treści po powiększeniu. Zbyt wiele nieruchomych elementów zmniejsza obszar pracy i utrudnia porównanie bardziej niż zwykłe przewinięcie.
Odbierz tabelę przez wykonanie konkretnego zadania
Przygotuj trzy pytania, na przykład o najtańszy wariant spełniający warunek, różnicę między dwoma pakietami i parametr, którego nie udało się potwierdzić. Poproś osobę spoza zespołu o znalezienie odpowiedzi na telefonie, potem sprawdź obsługę samą klawiaturą. Zapisz nie tylko czas, lecz także pomyłki i miejsca, w których trzeba było wracać do nagłówka. To pozwala poprawić strukturę, a nie tylko zmieniać grubość obramowania.
Testuj pusty wynik filtra, jedną kolumnę, bardzo długą nazwę i dane częściowo niedostępne. Ustal, kto aktualizuje zestawienie oraz skąd pochodzą parametry. Gdy każda komórka jest ręcznie kopiowana z innego ekranu, ryzyko niespójności rośnie. Dobra tabela ma jeden model danych, zrozumiałe jednostki i widok dostosowany do zadania. Jej sukces polega na trafnej odpowiedzi użytkownika, a nie na zmieszczeniu maksymalnej liczby pól na ekranie.