Komponenty w iOS

Podczas nauki programowania było kilka rzeczy, których zrozumienie zajęło mi bardzo dużo czasu, ponieważ w kursach, materiałach blogowych oraz w dokumentacji często przedstawiano je przy pomocy zdjęcia. Do takich rzeczy z pewnością zalicza się układanie interfejsu użytkownika, a w szczególności projektowanie jego komponentów. Zbierałam więc informacje malutkimi kroczkami przez wiele lat, do niektórych rzeczy dochodząc samodzielnie i to najwolniejszą możliwą drogą, czyli metodą prób i błędów. Zadawałam też sporo pytań, które dla wielu osób były częściowo niezrozumiałe, ponieważ pytałam o rzeczy, które wizualnie wydawały się oczywiste.

Odrobina kontekstu

Kiedy w 2014 roku przesiadałam się na Maca, bo mój laptop z Windowsem XP właśnie dogorywał, odkryłam przy okazji, że z wbudowanym w systemie czytnikiem ekranu mam o wiele większy dostęp do zawartości okna wielu aplikacji, niż gdy korzystałam z czytników takich jak NVDA dla Windows (którego obsługa w dużym stopniu nadal mi umyka).

Pamiętam jeszcze z czasów, kiedy widziałam, jak wiele zawsze było ikonek na paskach narzędzi u góry okna i do jak wielu funkcjonalności aplikacji dawało to szybki dostęp. Ucieszyłam się więc, że ponownie mam taką możliwość. Uprościło mi to, jak wielu widzącym użytkownikom, odkrywanie nowych funkcjonalności bez potrzeby przekopywania się przez ogromne ilości dokumentacji i zapamiętywania wielu skrótów klawiszowych, co na wcześniejszym sprzęcie okazywało się niezbędne do skutecznej pracy.

Jaki to ma związek z programowaniem?

Spodziewałam się, że gdy zajrzę do dokumentacji, wykorzystywane komponenty, jak pola tekstowe, przyciski, czy inne kontrolki, zostaną opisane na tyle dokładnie, że da mi to spory ogląd nie tylko na ich działanie, ale też na stronę wizualną. Oczywiście zdaję sobie sprawę, że większość kontrolek można modyfikować i na wiele sposobów przerysować. Miałam jednak nadzieję, że na samym początku zyskam na ich temat znacznie więcej informacji, także o ich stronie wizualnej.

Nie spotkałam się również z jakimś kursem czy tutorialem dedykowanym osobom niewidomym, który adresowałby to konkretne zagadnienie w sposób na tyle zrozumiały, że byłabym w stanie swobodnie poruszać się w temacie. Pozostawała więc znana mi droga działania, czyli metoda prób i błędów. Dlatego właśnie zbieranie niektórych informacji zajęło mi lata.

Wnioski

Moje odkrycia pozwoliły mi dokładnie zrozumieć sens działania UIAccessibility, który jest przecież protokołem opierającym swoje działanie na roli konkretnych komponentów oraz ich kontekście.

Opiszę to na przykładzie. Jeśli jakiś obszar ekranu jest przyciskiem, to musi określić  na nim swoje położenie, żeby system mógł poinformować użytkownika w odpowiednim momencie, że natrafił na przycisk. Musi też właściwie reagować na naciśnięcie, w tym także to niestandardowe, wykonywane między innymi przez czytnik ekranu. Do programisty zaś należy określenie całej reszty. 

Częścią tej całej reszty dla przycisku jest sposób, w jaki będzie działał w kontekście danej aplikacji. Dlatego tak ważne jest, by doprecyzować znaczenie na przykład za pomocą etykiety, a czasami także podpowiedzi. Zwłaszcza gdy przycisk jest obrazkowy, do czego w ogóle nie będę mieć dostępu.

Jak daje się zauważyć, powyższe akapity nie mówią dokładnie nic na temat wyglądu przycisku, a raczej skupiają się na jego funkcji lub ewentualnie statusie, czyli czy jest wciśnięty, zaznaczony, wyłączony itp. O stronie wizualnej, poza wielkością na ekranie, nie mam dokładnie żadnych informacji. 

Jestem więc w stanie umieścić przycisk na ekranie, nadać mu odpowiednie wymiary, ale na tym moja wiedza często się kończy, ponieważ nawet dokumentacja wiele nie mówi o jego stronie wizualnej. Przy ostatnim projekcie, nad którym pracowałam, pytałam więc często kolegów, czy przyciski wyglądają tak, jakby tego oczekiwali użytkownicy. Podobne pytania dotyczyły także pól tekstowych, list, tabel, czy innych komponentów. Chciałam zrozumieć, czy zaprojektowałam je w typowy sposób. Doświadczenie to było niezwykle pouczające.

Na zakończenie

Wygląd oraz ikonografia komponentów komunikują tak samo wiele, jak ich funkcja. Kwestią perspektywy pozostaje, co będzie ważne dla konkretnego użytkownika. Odpowiednio dobrane ikony z pewnością wpływają na odbiór aplikacji przez pewną część użytkowników. Inni, jak na przykład osoby posługujące się czytnikiem ekranu, potrzebują słów do zrozumienia działania danej rzeczy. I tak jak ja codziennie uczę się czegoś nowego o wyglądzie i estetyce projektowania aplikacji, tak i Was zachęcam do bliższego spojrzenia na stronę funkcjonalną. Ostatecznie obie przecież można sprowadzić do wspólnego mianownika, którym w tym przypadku będzie skuteczniejsza i bardziej precyzyjna komunikacja.