Projektowanie UI: Tooltipy

0:00No dobrze, przejdźmy do tego, jak

0:02wyglądają te komponenty i na co zwrócić uwagę.

0:06Podstawą będzie kontener, czyli tło naszego okienka.

0:10W związku z tym, że wyświetla się nad inną treścią, raczej odradzam tworzenia pół

0:15przezroczystych teł, bo wpłynie to na czytelność komponentu.

0:19Nie oznacza to jednak, że musimy

0:21ograniczać się do klasycznej bieli czy szarości.

0:25Ważne, by dostosować kolory tak, by

0:27eksponowały treści w okienku, a nie odwracały od nich uwagę.

0:33Najczęściej spotkacie się z okienkami w

0:35formie prostokąta z lub prostokąta z zaokrąglonymi rogami.

0:40Ale jeśli potrzebujemy, jeśli wynika to z identyfikacji marki i stylu aplikacji, to

0:46nasze okienka mogą przyjąć dowolny kształt.

0:49Warto pamiętać jednak, że zastosowanie nieregularnych kształtów będzie wiązało

0:54się z innym sposobem tworzenia takiego komponentu od strony kodu

0:58i dużo trudniej będzie nam myśleć o responsywności czy skrajnych przypadkach,

1:03gdy treści w okienku będzie bardzo dużo lub bardzo mało.

1:08Oprócz kształtu musimy przewidzieć również wielkość okna,

1:12bo to wraz z rozdzielczością prawdopodobnie będzie się zmieniać.

1:17Małe okienko, które zgrabnie wygląda na

1:19ekranie telefonu, nie będzie już zbyt wygodne w użyciu na dużym monitorze.

1:24Dlatego musimy przewidzieć skalowanie

1:26okienka, a to będzie zależne od tego, jakiego typu treści znajdą się w środku.

1:31Jeśli są to tylko teksty, prawdopodobnie nie będzie powiększało się dużo bardziej.

1:36Jeżeli na ekranie mobilnym policzyliśmy,

1:39że nasze okno nie powinno być mniejsze niż np.

1:4280% szerokości i wysokości ekranu, to na monitorze Full HD i wyższym będzie mieć

1:48będziemy mieć okno giganta, a w środku masę pustej przestrzeni.

1:54Na szerokość okna trzeba uważać również w

1:56przypadku komponentu z dużą ilością tekstów.

2:00Jeśli będzie zbyt szerokie, wiersz tekstu zrobi się nieznośnie długi,

2:05a to sprawi, że czytanie będzie niewygodne.

2:08Musimy więc założyć maksymalne wielkości takiego okna i tę informację najlepiej z

2:13wizualizacją przekazać programistom, którzy będą wdrażać nasze rozwiązania.

2:20Okno nie powinno również przekraczać

2:21wysokości ekranu, bo jest szansa, że stworzymy niechcący podwójnego scrolla.

2:27Wewnątrz okna i na zewnątrz, co znacznie utrudni korzystanie z interfejsu.

2:33Najlepiej nie planować sztywnych wysokości okienka na stronach w pikselach.

2:38Przede wszystkim dlatego, że nie mamy

2:40pewności, ile miejsca faktycznie zajmie przestrzeń strony.

2:45Możemy co prawda sprawdzić

2:46najpopularniejsze rozdzielczości stron internetowych,

2:50korzystając z ogólnodostępnych statystyk, ale weźmy pod uwagę, że te statystyki

2:54sprawdzają rozdzielczość ekranu, a nie faktyczną zawartość strony.

3:00Strony internetowe przeglądamy w

3:02przeglądarkach, więc musimy doliczyć wysokość interfejsu tej przeglądarki.

3:08To wysokość tabów, paska do wpisywania adresu, ale często również paska zakładek.

3:14To odejmuje nam na wysokości strony, dlatego bezpieczniejsze będą np.

3:19wartości procentowe i określenie maksymalnej i minimalnej wysokości.

3:25Warto zastanowić się, w jaki sposób chcemy odcinać nasze okienko od reszty treści.

3:32Możemy zrobić to przez zastosowanie półprzezroczystego tła pod okienkiem.

3:36Wtedy skupiamy użytkownika wyłącznie na tym komponencie,

3:41Ale jeśli okienko nie jest najbardziej kluczowym elementem na ekranie, możemy

3:45skorzystać z cieni, które wyciągną okienko trochę na wierzch.

3:50Jeżeli wymagamy od użytkownika akcji,

3:52która znajduje się w obrębie tego okienka, to raczej stosujemy pełne tło pod oknem

3:57tak by użytkownik przypadkiem go nie przeoczył i nie denerwował się, że np.

4:02nie może przewijać treści lub klikać w

4:05inne elementy, bo wyskakujące okno automatycznie je zablokowało.

4:10Warto jeszcze pamiętać o jednej rzeczy w kontekście tła.

4:14Jeśli projektujemy okienko i pozwalamy

4:17użytkownikowi je po prostu zamknąć bez interakcji z elementami w środku,

4:23to możemy funkcję zamknięcia dać również na kliknięcie lub tapnięcie w tło.

4:29To samo dotyczy klawisza Escape na klawiaturze, który

4:34często pozwala nam właśnie zamykać takie wyskakujące okienka.

4:39Wszystko zależy oczywiście od tego, jaki jest cel tego okienka i jakie decyzje

4:43podejmiecie razem z developerami tego rozwiązania.

4:46Dobrą praktyką jest jednak danie

4:48użytkownikowi możliwie szerokiego pola manewru.

4:52Zwłaszcza, gdy wiemy, że użytkownicy mogą

4:55właśnie w ten sposób korzystać z naszego interfejsu.

5:01No właśnie, a jak już przy wyłączaniu okienka jesteśmy, to warto przewidzieć

5:06miejsce na ikonkę krzyżyka, która zamyka okienko.

5:10Zachęcam do tego, żeby umieszczać ją na

5:12tle okna, dzięki czemu będzie bardziej widoczna.

5:15Bo możecie spotkać się z projektami, które

5:18wyciągają opcję zamknięcia jako element poza okienkiem.

5:22To trochę nie ma sensu, bo tracimy kontekst ikony.

5:25Jeśli jest zamknięta w jakimś obszarze, no to

5:28raczej spodziewamy się, że działa właśnie na ten obszar.

5:32Dodatkowo umieszczane często cienkie ikony

5:35ciemne na ciemnym tle są po prostu niewidoczne.

5:38Jeśli damy możliwość zamykania okienka tylko taką ikoną, to użytkownik może

5:43nieźle zirytować się poszukiwaniem jej w takiej sytuacji.

5:47Oprócz ikony możemy dodać również oczywiście etykietę tekstową.

5:52No ale przydałby się jeszcze tytuł.

5:55W zależności od kompozycji naszego okienka będzie największym komunikatem.

5:59Lub wręcz przeciwnie będzie pełnił rolę dodatkowej informacji, która ma tylko

6:04wesprzeć zrozumienie kontekstu, w którym znalazł się użytkownik.

6:08Przy krótkich komunikatach błędu zdarza

6:11się, że tytuł jest jedyną treścią, którą znajdziemy w okienku.

6:14Ale warto od razu przewidywać, co stanie się, gdy trzeba umieścić więcej treści.

6:21I treści tych może być mniej lub więcej.

6:24Teksty mogą składać się z jednego zdania lub całych akapitów, na przykład, gdy

6:29okienko pokazuje regulamin serwisu albo politykę prywatności.

6:34Jeżeli mamy teksty, które nie mieszczą się

6:36w trzech linijkach, najlepiej formatować je do lewej strony.

6:40Przy długich, wyśrodkowanych tekstach będzie nam się czytało dużo trudniej,

6:45ponieważ nasz wzrok po skończeniu czytania linijki musi szukać początku kolejnej.

6:50A tak przez nierówną szerokość wierszy

6:52zaczyna się za każdym razem w innym miejscu.

6:55Dlatego długie teksty formatujemy do lewej strony, bo jest to dla nas naturalne.

7:01Czytamy od lewej do prawej i będzie wyglądało schludniej.

7:06Jeśli mamy długie treści, zaplanujmy

7:09wygląd scroll bara tak, by pasował do stylu aplikacji.

7:14A także zaplanujmy miejsce, gdzie jest scrollowana

7:17przestrzeń zaczyna się i kończy, by mieć

7:19pewność, że nie znajdzie się zbyt blisko tytułu czy przycisków.

7:25Poza tekstami w obrębie okna dialogowego mogą oczywiście pojawiać się inne typy

7:29treści, jak zdjęcia i ilustracje czy interaktywne komponenty,

7:35pola formularzy, rozwijanej listy czy pola wielokrotnego wyboru.

7:40Im więcej elementów, tym bardziej będziemy

7:42musieli przemyśleć grid, który zastosujemy w środku.

7:47To ważne, by pamiętać, że grid, którego używamy w okienku, nie musi być dokładnie

7:52tym samym, którego używamy na pozostałej części strony.

7:56Często będzie nas po prostu ograniczał,

7:58dlatego warto przewidzieć grid do tak specyficznej, często małej przestrzeni.

8:04Pamiętajmy tym samym o dobrych praktykach, więc jeśli umieszczamy w oknie dialogowym

8:09dużo pól formularzy, to lepiej, żeby była to jedna z scrollowana kolumna.

8:14Zamiast próby umieszczenia trzech czy

8:16nawet czterech kolumn pól tylko po to, by zmieścić nasze treści w viewport'cie.

8:23I przyciski

8:24właściwie w wielu przypadkach jeden z najważniejszych elementów wyskakujących

8:28okienek, które mogą zaważyć na użyteczności komponentu.

8:33Pewnie nie raz spotkaliście się z okienkami, które niektórych niezrozumiałe

8:37polecenia w przyciskach wprawiły w konsternację.

8:43To jedna z rzeczy, na które musimy bezwzględnie zwrócić uwagę, bo nawet

8:48najładniej zaprojektowane okienko będzie bezużyteczne, gdy użytkownik nie będzie

8:53miał pewności, co stanie się po kliknięciu w jeden z przycisków.

8:58Dbajmy więc o to, by nazwy były przede wszystkim jednoznaczne

9:02i nie pozostawiały wątpliwości co do skutków dalszych działań.

9:06Żeby pomóc użytkownikowi zrozumieć główną

9:09akcję okienka, możemy również wyróżnić jeden z przycisków przez inne ostylowanie

9:15nadanie koloru, grubości obramowania czy powiększenie.

9:20Spotkacie się również z projektami, tak jak widzicie właśnie na ekranie,

9:25które dla jeszcze większego kontrastu układają obok siebie przycisk głównej

9:29akcji oraz tekstowy link z akcją drugorzędną.

9:33Mając te wszystkie elementy zamknięte w jakiejś przestrzeni, pamiętamy o roli

9:38pustych przestrzeni marginesów w naszym projekcie.

9:42Teksty i przyciski nie powinny znaleźć się zbyt blisko krawędzi, bo będą dawały

9:47wrażenie ściśniętych, nieprzyjemnych dla oka.

9:50Jeśli stosujemy grid wewnątrz okienka,

9:53upewnijmy się, że marginesy zewnętrzne dyktujące odległość treści od krawędzi

9:58nie będą mniejsze niż marginesy między elementami w okienku.

10:03Na koniec warto zaplanować też położenie okienka.

10:06Zazwyczaj wyświetlamy je w górnej części

10:09ekranu na środku, ale to też może zależeć od kontekstu.

10:13Jeżeli projektujemy okienka, które

10:16wyświetlają się w trakcie on boarding użytkownika,

10:20będące tak naprawdę formą instrukcji i zachęcenia do wykonania jakichś działań,

10:25lepiej będzie pokazać je w pobliżu elementu, którego dotyczą.