Projektowanie UI: Czym są zakładki?
Komponenty
3 godz. 56 min · Figma · UI, UX i Webdesign
Natalia BieniasHead of Design w Mobee DickCzego się nauczysz
- Elementy wizualne, które trzeba wziąć pod uwagę przy projektowaniu
- Omówienie stanów interakcji na przykładzie popularnych design systemów (Material, Carbon, Fluent)
- Przedstawienie często używanych i projektowanych komponentów
- Zasady i komponenty, z których składają się formularze
- Co robić, a czego nie, gdy projektujemy tabele i listy?
- Praktyczne wskazówki do zastosowania w każdym projekcie
- Jak można zaprojektować wyskakujące okna?
Szczegóły w projektowaniu UI
Dla UI designera każdy szczegół ma znaczenie. Patrząc na to, z czego składają się interfejsy, można uprościć i powiedzieć, że są to właśnie kształty geometryczne, teksty lub ewentualnie ikony. Do tego dochodzi aspekt stosowania barw i dodatkowych efektów, które mają zbudować hierarchię wizualną w projekcie. Aby budować skuteczne interfejsy, trzeba dokładnie przyjrzeć się każdemu elementowi – a w tym warsztacie omówimy przyciski i linki tekstowe.
Praktyczne wskazówki
Oczywiście, nie będziemy opowiadać o projektowaniu tylko na bazie teorii. W Kursie poznasz wiele praktycznych wskazówek opartych między innymi na popularnym Material Designie. Poznasz porady, które z łatwością zastosujesz w swoich projektach, a także omówimy stany interakcji. Przekonasz się jakie najważniejsze elementy wizualne trzeba wziąć pod uwagę w projektowaniu.
Różnorodne elementy interfejsów
W Kursie omówimy projektowanie takich elementów interfejsu, jak przyciski, formularze, taby i zakładki, listy i tabele czy wyskakujące okna. Przekonasz się jakich zasad warto przestrzegać, tak, by całość była estetyczna i wygodna dla użytkownika.
Praktyczne wskazówki
Dużą część Kursu poświęciliśmy na omówienie praktycznych wskazówek, dzięki którym będziesz sprawnie projektować wygodne interfejsy. Dowiesz się co robić, a czego unikać, tak, by nie powielać częstych błędów w projektowaniu.
Design Systemy
W trakcie Kursu omówimy również stany interakcji na przykładzie popularnych Design Systemów - czyli Material, Carbon czy Fluent. Dowiesz się czym się różnią i jak wpłyną na proces projektowania elementów interfejsu.
Dla kogo jest ten kurs?
Ten Kurs stworzony został z myślą o początkujących projektantach, którzy chcą stosować najlepsze techniki podczas projektowania interfejsów. Kurs pomoże też świetnie ugruntować zdobytą już wiedzę na temat elementów wizualnych.
OK.
Omówiliśmy już jak możemy dać użytkownikom wybór np.
używając checkboks'ów radio button'ów albo switcha.
Jednak są sytuacje, w których opcji do
wyboru jest dużo, dużo więcej niż tylko kilka i pokazywanie ich w formie list
wyboru byłoby nieczytelne i trudne do zeskanowania wzrokiem.
Dlatego czasami wykorzystuje się coś, co nazwać możemy rozwijanym listami czy po
angielsku selection input albo drop downloads.
I w tej części warsztatu chciałabym opowiedzieć właśnie o nich.
Warto pamiętać, że rozwijane listy wcale nie muszą występować tylko w formularzach.
Spotkacie się z nimi również w nawigacji oraz kontekstowych menu.
Skupmy się jednak najpierw na formularzach.
No dobra, czym są te rozwijane listy i z czego w ogóle się składają?
Rozwijana lista to jedna z podstawowych kontrolek wyboru, która w najczęściej
spotykanej wersji działa podobnie do radio button'a, czyli listy jednokrotnego wyboru.
To znaczy, że z listy wybierzemy tylko
jedną z opcji, ale można zaprojektować rozwijane listy
tak, by pozwalały na wielokrotny wybór, np.
łącząc je z checkbox'ami, które pojawiają się na liście.
Możemy również wykorzystać tzw.
chipsy, które łączą w sobie funkcje pola tekstowego i autouzupełnienia.
Przewagą rozwijanych list jest fakt, że w
stanie wyjściowym zajmują dużo mniej miejsca niż checkbox'y i radio button'y.
W miejscach, gdzie potrzebujemy zmieścić mnóstwo informacji, ale nie mamy
do tego za dużej przestrzeni, mogą okazać się dobrym rozwiązaniem.
Pamiętajmy jednak, by przede wszystkim
dobierać komponenty do typu treści i brać pod uwagę wygodę użycia.
Rozwijane listy składają się z dwóch głównych części.
W stanie spoczynku, kiedy wchodzimy na
stronę i nie wchodzimy jeszcze w interakcję z komponentem,
po kliknięciu, kiedy rozwija się lista wyboru, początkowy stan nie różni się z
reguły bardzo od zwykłych pól tekstowych, natomiast dodanie, dodajemy do niego ikonę,
która sugeruje użytkownikowi, że coś po kliknięciu po kliknięciu może się rozwinąć
i z reguły jest to ikona strzałki w prawym rogu.
Czasami możecie spotkać się również z
innymi ikonkami, ale o tym opowiem też trochę później.
Nadawanie podobnego stylu rozwijanym
listom jak w przypadku pól tekstowych nie robi się bez powodu.
Chodzi o to, żeby utrzymać spójność w interfejsie i żeby ten formularz, który
składa się z różnych komponentów, faktycznie wyglądał jak jeden duży
komponent, a nie zbiór przypadkowych kontrolek.
Warto zastanowić się również tutaj nad
placeholder'em czyli tym takim tekstem, który znajduje się wewnątrz komponentu.
I tu możemy wykorzystać kilka takich najpopularniejszych wariantów.
W języku polskim spotkamy się najczęściej
z komunikatem wybierz albo z już konkretną nazwą akcji
jak wybierz miasto, zaznacz miasto
cokolwiek właściwie, co będzie dawało jasno do zrozumienia użytkownikowi, że tam
pod tym komponentem czai się jeszcze kilka opcji do wyboru, będzie dobrym wyborem.
Po kliknięciu w kontrolkę pojawia się lista z opcjami do wyboru.
Lista zazwyczaj pojawia się pod polem,
ale zdarza się również, że pojawia się dokładnie w jego miejscu.
W zależności od design systemu i wytycznych dla konkretnych
rozwiązań, programów, środowisk możecie spotkać się z różnymi wersjami,
ale możecie spotkać się również z opcją, gdzie lista pojawia się nad polem.
I robimy tak zazwyczaj dlatego, że zdarzają się sytuacje, w których ten
dropdown, ta rozwijana lista znajduje się bardzo nisko końca ekranu, albo w takim
miejscu, w którym jasnym jest, że jeżeli użytkownik kliknie i ta lista rozwinęła by
się w dół, to opcje nie byłyby dla użytkownika widoczne
musiałby najpierw zeskrolować całą stronę,
a dopiero później mógłby zobaczyć listę i skrolować przez listę.
Dlatego zdarzają się sytuacje, w których
pokazujemy tą listę nad polem i dzięki temu mamy pewność, że ten użytkownik
będzie w tym swoim polu widzenia zawsze widział te opcje do wyboru.
Lista wizualnie powinna być dopasowana do innych komponentów formularza.
Trzeba więc zadbać o jej kształt cienie, obramowania, separatory między opcjami,
ikony czy sam styl tekstu i podświetlenia elementu.
Tutaj warto zwrócić uwagę na takie drobne szczegóły, niewidoczne na pierwszy rzut
oka, jak odległości i marginesy wewnętrzne.
Musimy zastanowić się, jaki powinien być
margines od lewej strony w przypadku opcji, które wyświetlają się na
rozwiniętej liście, jaki powinien być margines u góry?
Jaki powinien być margines?
Od ostatniej opcji wyboru do końca tej rozwijanej listy.
Więc jest kilka takich szczegółów, na które warto zwrócić uwagę, bo to sprawi,
że ten nasz interfejs będzie wyglądał na bardziej dopracowany i też podziękują nam
za to programiści, którzy później będą musieli wdrażać nasze rozwiązanie.
Jeżeli będziemy spójnie stosować marginesy
w naszych komponentach i ustalimy, że zawsze np.
odległość listy, która rozwija się pod kontrolką do tej kontrolki to dajmy na to
5 10 pikseli, to jeżeli mamy jeszcze w jakimś miejscu takie rozwijane listy, to
upewnijmy się, że zawsze ta odległość będzie taka sama.
To samo tyczy się spójności między opcjami do wyboru.
One mogą być podobne jak np.
odległości w radio button'ach albo checkbox'ach, które
stosujemy w innym miejscu naszego interfejsu.
Ta rozwinięta lista może składać się nie tylko z tekstów.
Jak już wspomniałam, zdarzają się listy, które zawierają również checkbox'y
pozwalające na wielokrotny wybór opcji, ale spotkacie się też z ikonami, jak np.
w przypadku list państw, numerów
kierunkowych czy czegoś w tym stylu, co wzbogaca się np.
o małe flagi, które znajdują się po lewej
stronie albo po prawej stronie od etykiety tekstowej.
Listy rozwijane zazwyczaj wykorzystywane
są w sytuacji, kiedy mamy dużo opcji do wyboru.
W związku z tym wszystkie nie mieszczą się na jednej liście.
Stosujemy wtedy skrolowanie.
Na liście powinien pojawić się scroll bar, który sugeruje, że mamy więcej opcji po
scrollu, ale również sam projekt powinien od razu sugerować, że tych opcji jest
więcej i możemy zrobić to tak, by koniec listy ucinał się np.
w połowie jednej z opcji i użytkownik
domyśli się, że musi zeskrolować treść, żeby zobaczyć całość.
Rozwijana lista nie należy do najwygodniejszych komponentów formularzy.
Przede wszystkim dlatego, że wymaga od
użytkownika większej liczby kliknięć niż alternatyw.
Dlatego zanim wyposażymy interfejs w same
rozwijane listy, zastanówmy się, czy nie możemy zrobić tego lepiej.
No dobra, ale przejdźmy sobie teraz przez różne rodzaje rozwijanych list.
Pokażę Wam to na przykładach z sieci.
Zacznijmy od takiej standardowej rozwijanej listy.
Tutaj na przykładzie Carbon Design System
to ta pierwsza, która przychodzi nam na myśl, gdy mowa o tej kontrolce.
Pozwala rozwinąć i wybrać spośród
dostępnych jedną opcję, jeśli chcemy ją zmienić.
Rozwijamy listę jeszcze raz i zaznaczamy inną opcję.
Kolejny typ listy, z którym możecie się spotkać to lista z autouzupełnieniem.
To jedno z wygodniejszych rozwiązań, gdy mamy do wyboru całą masę opcji.
Żeby przyspieszyć i uprościć wybór użytkownikowi, pozwalamy na wpisywanie
znaków, na podstawie których filtruje się lista.
Z tej zawężony listy użytkownik może
dokonać wyboru, ale też kasując wpisany tekst może wrócić do pełnej listy.
Zdarzają się listy, które pokazują jakąś hierarchię opcji.
Możecie spotkać się wtedy z grupowaniem wyników, gdzie pojawia się nieklikalna
nazwa grupy i opcje do wyboru poniżej, albo po prostu grupy oddzielone są
separatorami, jak choćby w interfejsie Figmy.
Możecie to zobaczyć np.
wchodząc w ustawienia typografii i wybierając jakąś inną grubość tekstu.
Zobaczcie, że tutaj pierwsza część oddzielona jest od drugiej
i twórcy tego interfejsu postanowili oddzielić takie standardowe odmiany od
italici, która być może jest rzadziej używana.
Takie grupowanie możecie zobaczyć też na
innych rozwijanych listach, mianowicie w nawigacji.
Zerknijcie na dowolny program, np.
graficzny i zobaczcie jak rozdzielone są typy funkcji po rozwinięciu.
Tutaj Figma również przychodzi nam z pomocą.
Jeżeli wejdziemy w menu główne to
zobaczycie, że po pierwsze już w tej pierwszej liście, która się pojawia tutaj
te opcje rozdzielane są separatorami, ale też w każdej
w każdym kolejnym zagnieżdżenia te opcje również są od siebie oddzielone
i to samo możemy stosować oczywiście w formularzach.
Wspominałam już o liście z wielokrotnym wyborem.
Tutaj możemy zobaczyć jak robi to Microsoft.
Jak już wspomniałam, możecie spotkać się z
tymi listami, które zawierają w sobie checkbox'y.
Nie są to najwygodniejsze kontrolki w użyciu, ale myślę, że warto wiedzieć, że
takie również warianty można zaprojektować.
Tu zresztą widzicie w tej kontrolce także tą opcję grupowania.
I tutaj nie tylko pojawiają się
separatory, ale wcześniej wspomniane, nieklikalne tytuły grup.
I o tym pamiętacie już być może z ostatnich lekcji, gdzie opowiadałam Wam o
tym, żeby pamiętać, aby nadawać aktywne pola przy
radio button'ach i checkboxach, również na etykietach tekstowych, a także w jakimś takim
większym polu, żeby użytkownik nie musiał konkretnie kliknąć w ten mały kwadracik,
żeby zaznaczyć jakąś opcję, ale może po prostu zbliżyć się do tej opcji i już
wiesz, że ta opcja jest aktywna, że można w nią kliknąć.
Zwróćcie również uwagę projektując takie
kontrolki, by odległości między kolejnymi opcjami były odpowiednio duże.
I też warto zadbać od tak od takiej
estetycznej strony o odpowiednie odległości, kontrolki do etykiety
tekstowej i tej kontrolki od lewej krawędzi rozwiniętej listy.
Okay, na razie pokazywałam Wam takie,
powiedziałabym podstawowe rodzaje list rozwijanych, ale zdarzają się również
trochę bardziej skomplikowane i mniej standardowe.
I na pewno spotkacie się z data picker'em, czyli
opcją wyboru daty.
Po aktywacji pola otwiera nam się widok
kalendarza, z którego możemy wybrać jedną opcję bądź oznaczyć kilka, np.
wybierając zakres dat.
I tutaj wszelkiej maści rezerwacje.
Inne serwisy mogą posłużyć Wam za inspirację albo źródło researchu.
Również linie lotnicze, gdzie rezerwuje
się jakieś loty to to to wszystko te miejsca, w których możecie szukać pomysłów.
Wygląd samej tej listy i kalendarza w ogóle jest dowolny.
Tu powinniśmy kierować się czytelnością,
użytecznością i łatwością wyboru konkretnej daty.
Warto pamiętać o tym, by zapewnić
użytkownikom szybkie nawigowanie po miesiącach czy nawet latach.
To, co będzie najważniejszym elementem, będzie zależało od kontekstu użycia.
Trzeba również pamiętać, że daty i kary
nie będą idealne do każdego pola wyboru daty, np.
datę urodzenia albo datę ważności karty
kredytowej wpiszemy zdecydowanie szybciej do zwykłego pola tekstowego.
Zamiast wybierać opcję z listy.
I ostatnia rozwijana lista, o której chciałabym jeszcze opowiedzieć, to
multiple selection połączona z searchem, ale też niekoniecznie.
Możemy wykorzystać tzw.
chipsy, które łączą w sobie funkcje pola tekstowego i auto uzupełnienia.
Opcje wyboru pojawiają się na podstawie wpisanych fraz.
W formie rozwijanej listy i użytkownik może wybrać jedną z tych opcji.
Po wybraniu natomiast może dodawać kolejne.
I te wybrane opcje, jak widzicie,
pojawiają się w formie takich małych komponentów, które można wykorzystać do
pokazania wpisanych danych, atrybutów i akcji.
Oczywiście możemy zaprojektować czy też
powinniśmy zaprojektować te komponenty tzw.
chipsy w taki sposób, żeby można było łatwo
je usunąć, no bo może zdarzyć się w każdym momencie tak, że użytkownik przez
przypadek oznaczy opcję, której nie chciał.
Zawsze dajemy tą kontrolę użytkownikowi,
pozwalamy mu na edytowanie tych pól, które już wcześniej uzupełnił.
No dobra, ale mamy interaktywne elementy,
więc oczywiście musimy również opowiedzieć o stanach list.
W przypadku rozwijanych list mamy trochę
więcej elementów do zaprojektowania przy zmianie stanów, bo oprócz kontrolki
wyjściowej, która stany ma analogiczne do pól tekstowych, są jeszcze interakcje z
listą i to na tej liście chciałabym się skupić, żeby nie powtarzać stanów, które
pojawiły się już w pierwszej części warsztatów
formularzowych.
Tak jak mówiłam mamy te stany podstawowe.
W przypadku tej kontrolki wyjściowej, zanim wejdziemy w interakcję, właściwie
zanim zaczniemy klikać po tej kontrolce, czyli ten default, hover i focus.
Ale to, co interesuje nas najbardziej to
ten aktywny stan, kiedy lista jest rozwinięta.
Niektóre komponenty pozwalają na jednoczesne wpisywanie tekstu w pole
wyżej, co na przykład filtruje wyniki wyświetlające się na liście.
Ale w tej podstawowej wersji po prostu możemy kliknąć na jedną z opcji.
No i jak już mamy rozwiniętą listę to możemy najechać na opcje kursorem.
Takie najechanie kursorem na listę również
powinniśmy zaprojektować i oczywiście opcje możemy wybrać.
Jeśli to zwykła lista rozwijana wybierzemy
jedną, która sprawia, że lista zwija się, a w polu wyżej pojawia się wybrana opcja.
Musimy pamiętać o pokazywaniu wybranego elementu w możliwie czytelniejszy sposób.
Jeśli wiemy, że odpowiedzi są długie, ten
element również powinien mieć dużo miejsca na wypełnione treści.
Oczywiście to w jaki sposób będzie wyglądać wybrana opcja, a jak będzie
wyglądać opcja przed wyborem zależy tylko od Was i zawsze powinniście
dopasowywać ten wygląd do reszty elementów interfejsu.
W naszym projekcie.
To wyróżnienie to może być inny kolor, ale
oczywiście powinniśmy pamiętać o tym, że nie wszyscy te kolory rozróżniają, więc
nie powinien być to jedyny wyróżnik w naszym interfejsie.
Możemy bawić się grubością linii wokół komponentu, możemy również bawić się
grubością tekstu czy też innym ułożeniem tego wybranego elementu.
To czasami są choćby jakieś tła, które pojawiają się pod tą kontrolką.
No ale okej, mogą zdarzyć się tak, że
przez przypadek kliknęliśmy w złą opcję i chcemy ją zmienić.
Rozwijając listę powinniśmy wiedzieć
widzieć na niej już wybraną opcję oznaczoną w odpowiedni sposób.
To będzie zwłaszcza bardzo wygodne, kiedy np.
te odpowiedzi na liście będą do siebie bardzo podobne i na pierwszy rzut oka
chcielibyśmy zobaczyć, którą opcję już mieliśmy zaznaczoną i wybrać inną.
No i mamy ten stan zablokowany i to czego nie powinniśmy raczej robić.
Jeżeli jest sytuacja, w której jest lista
i nie możemy wybrać z niej ani jednej opcji, to nie dawać użytkownikowi
możliwości kliknięcia, rozwinięcia tej listy i dopiero przekonania się, że tam
nic nie można wybrać, tylko raczej blokujemy już ten pierwszy stan tą
kontrolkę wyjściową, żeby nie irytować użytkownika.
No bo same dropdown'y same te rozwijane listy w sobie są
już na tyle irytujące, że wymagają tego rozwijania, żeby zeskanować możliwe opcje.
I w tym przypadku, jeżeli mielibyśmy takie rozwijane listy w interfejsie, i co
któraś na przykład miałaby te poblokowane opcje wewnątrz, no to możecie domyślać
się, że czas na zeskanowanie tych zablokowanych opcji
byłby czasem straconym, no a tego nie chcemy robić naszym użytkownikom.
OK. Możemy też walidować rozwijane listy.
Może się okazać, że jakaś rozwijana lista była polem wymaganym.
No i wtedy musimy odpowiednio poinformować użytkownika, jeżeli tej opcji nie wybrał I
teraz w jakiś sposób pokazujemy taką walidację.
No przede wszystkim
powinniśmy dać jakiś komunikat, żeby dla użytkownika było to jasne, dlaczego
właściwie nie może przejść dalej, dlaczego coś tam się podświetla na czerwono.
I to o czym warto zapamiętać to to, że ten komunikat on się pojawia pod tą
kontrolką i dobrze by było pomyśleć, żeby on pojawiał się w taki sposób, żeby
wyglądał też dobrze, kiedy tą kontrolkę rozwiniemy.
Czyli jeżeli mamy listę, która pojawia się niżej to warto zaplanować tę odległość i
szerokości komunikatów w taki sposób, żeby np.
ta lista ładnie wypełniła tą przestrzeń i zasłoniła ten komunikat błędu.
Natomiast jeżeli o to nie zadbamy, to jest ryzyko, że gdzieś elementy tej walidacji
będą wystawać i to po prostu nie będzie wyglądało zbyt dobrze.
To jest drobny szczegół,
to jest detal, który jest bardziej kwestią wizualną niż taką użytecznościową.
Ale myślę, że jeżeli mamy się uczyć dobrych praktyk i zwracać uwagę na
najdrobniejsze szczegóły, to również warto zwrócić uwagę na takie rzeczy.
No i klasycznie trzeba sobie to wszystko podsumować, czyli kilka zasad
na koniec. Liczba opcji
nie powinniśmy stosować rozwijanych jest dla dwóch lub 3 opcji.
W przypadku małego wyboru zdecydowanie
lepiej wykorzystywać listy jednokrotnego wyboru radio buttons
przyspieszy to działania użytkownika.
Spotkacie się z wytycznymi, że nie powinniśmy wybierać list dla mniej niż 5
opcji i myślę, że można trzymać się tej zasady.
Kolejna rzecz to typy opcji.
Nie wrzucajmy rozwijanych list tam, gdzie
łatwiej jest wpisać wartość niż scrolować przez dziesiątki opcji.
To irytujące, zwłaszcza gdy nie dajemy jednocześnie opcji na zawężanie wyników.
Myślę, że niejedno z Was miało okazję na przykład wybierać z listy wszystkich
paczkomatów w Polsce ten jeden właściwy, bliski Waszej lokalizacji.
Albo wybieracie rok urodzenia scrolując się od tego obecnego.
To samo tyczy się wartości numerycznych, np.
wybór liczby produktów do dodania do koszyka.
Zamiast klikać i wybierać np.
dwie sztuki i dużo szybciej będzie wpisać je z palca, albo skorzystać z przycisków
dodawania i odejmowania, często pojawiających się przy polu z liczbą.
No i kolejna rzecz to wysokość listy.
Minusem rozwijanej listy jest to, że
użytkownik nie widzi od razu wszystkich dostępnych opcji.
Pojawiają się dopiero po wejściu w interakcję.
Unikajmy jednak sytuacji, w której rozwija się ta lista prawie na całą wysokość
strony albo w przypadku mniejszych urządzeń.
Zdarza się też, że ona wykracza poza ekran, bo jest np.
niedostosowana ta wysokość tej listy do ekranu i czasami zdarza się również, że
nie da się zeskrolować wtedy tej treści, więc blokujemy sobie tak naprawdę
możliwość wyboru przez użytkownika tej opcji, na której mu zależy.
Nie przesadzajmy też w drugą stronę jeśli listy są za niskie, użytkownikom będzie
trudno przeskanować wzrokiem dostępne opcje.
Dopasowujemy wysokość na podstawie treści,
które użytkownik w nich znajdzie i całego otoczenia interfejsu.
Możemy ustalić, że np.
listy rozwijają się zawsze na wysokość np.
8 opcji widocznych na liście.
Myślę, że warto wspomnieć też o czymś takim jak proporcje elementów.
Dokładnie chodzi o szerokość listy względem pola.
Dopasujemy wizualnie szerokość pola do
listy, tak by nie tworzyć dziwnie wyglądających dysproporcji.
Jeśli mamy bardzo wąskie pole i super szeroką listę, bo np.
opcje do wyboru mają długie nazwy,
po wybraniu opcji w polu nazwa nie zmieści się, to nie tylko będzie wyglądało mało
atrakcyjnie, ale przede wszystkim będzie nieczytelne.
Zupełnie niezrozumiałe jest tworzenie
bardzo, bardzo szerokich list, które zawierają w sobie tylko krótkie frazy.
Także zwracajcie uwagę na typy treści, które będziemy mieć w danej kontrolce, a
później zastanówmy się, jak odpowiednio dopasować szerokość pola i szerokość
rozwiniętej listy, żeby to dobrze ze sobą wyglądało.
One nie zawsze muszą być dokładnie tej samej szerokości.
Zdarzają się, że zdarza się, że
to pole jest węższe niż rozwinięta lista, ale tutaj warto po prostu patrzeć na to,
jak ostatecznie prezentuje się ta rozwinięta lista z kontrolką.
Czy tam faktycznie nie ma tego efektu, że ona jest np.
3 albo 4 razy szersza niż ten komponent, który znajduje się wyżej?
No i taka rzecz, która również trochę ułatwi pracę programistom, z którymi
będziemy współpracować później w projektowaniu interfejsów.
Ważne jest po prostu projektowanie tych skrajnych przypadków, gdy teksty są zbyt
długie, żeby zmieścić się na liście lub w samym polu.
Po wyborze opcji no to trzeba się zastanowić, jak to się
będzie prezentować, jak my to pokażemy użytkownikom.
Najłatwiej przewidzieć to na etapie doboru
szerokości kontrolki do typu treści, czyli tym co mówiłam dokładnie przed chwilą.
Ale przy wielojęzycznych stronach możemy nawet nie wiedzieć jeszcze na etapie
projektu, że dojdzie jakiś język, w którym słowa są dłuższe niż np.
w angielskim lub polskim.
Dość często jest chociażby język niemiecki.
Więc odpowiednio wcześniej zadbajmy o to, żeby te pola były odpowiednio duże.
I to zawsze jest jakiś taki punkt dla nas, bo jest mniejsze ryzyko, że po prostu w
momencie wypełnienia właściwymi tekstami tam nic nam się nie posypie.
Ale już doskonale wiemy, że nie nauczymy
się niczego, jeżeli nie wypróbujemy nowo zdobytej wiedzy w praktyce.
Więc czas na pracę domową.
Tym razem do zaprojektowania będzie filtrowanie hoteli.
Zaprojektujemy filtry, które będą zawężać
wyniki wyszukiwania hoteli na stronie z rezerwacjami.
Zastanówmy się, jak ułatwić użytkownikom wyszukiwanie konkretnych miast, np.
przez autouzupełnienie.
Jak zoptymalizować wybór dat?
Pola, które powinny znaleźć się w tym komponencie to miasto rezerwacji dzień
zameldowania, dzień wymeldowania, liczba gości, liczba pokojów i przycisk
który będzie ostatecznie aktywował tę akcję, czyli przycisk wyszukiwania.
Powodzenia!