Jak touchscreeny zmienią projektowanie?

Żyjemy w ciekawych czasach. My, projektanci stron internetowych. Dzisiejsza sieć została pomyślana tak, aby operować nią za pomocą myszki i klawiatury. Właściwie nie tyle „została pomyślana”, co my ją taką stworzyliśmy. Formularze, dropdowny, hovery i rozmaite inne elementy dzisiejszych stron www – doskonale wiemy, jak je robić, aby działały. Jednak nie sposób nie dostrzec, że gdzieś obok dojrzewa nowa rzeczywistość projektowania witryn. I tutaj nasza dotychczasowa wiedza coraz częściej się nie sprawdza.

Oczywiście mam na myśli telefony komórkowe z ekranami dotykowymi i tablety. Powiecie: żadna nowość, mobilne odpowiedniki stron www powstają już od dawna (choćby technologia WAP). OK, ale dzisiaj za pomocą iPhona, iPada czy telefonu z Androidem można przeglądać nie odpowiedniki, ale takie same strony internetowe i to w ten sam sposób, jak na zwykłym komputerze. A to oznacza, że prędzej czy później musimy nauczyć się projektować tak, aby to, co robimy, wyglądało dobrze na także na tych (i wszystkich innych) urządzeniach.

Oczywiście można rozpoznawać użytkowników surfujących przez iPada lub inne urządzenie i serwować im specjalnie przygotowaną wersję sajtu. To proste, ale nieuchronnie prowadzi do powstania czegoś w rodzaju alternatywnej Sieci. Z innymi stronami, choć tym samym kontentem. Z innym interfejsem, choć tymi samymi funkcjonalnościami. Do tego dochodzą podwójne koszty (utrzymania, produkcji), podwójne deploymenty, podwojne środowiska testowe, podwójny czas.

Zamiast tego, lepiej robić strony tak, żeby na dotykowych urządzeniach działały równie dobrze. Ale to jest wyzwanie. Nowe podejście rodzi problemy, które wciąż nie mają zbyt wielu dobrych rozwiązań. Musimy je dopiero odkryć.

Przejdźmy do konkretów. Zebrałem kilka najciekawszych lub największych problemów, jakie niesie za sobą projektowanie na dotykowe telefony i tablety.

Śmierć hoverów

Trochę pompatyczne, ale to prawda: ekrany dotykowe zabijają hovery. To wcale nie błahostka, jeśli zastanowić się, do czego dziś wykorzystuje się najazd myszką.

  • Hovery stosuje się przede wszystkim do podświetlania linków. Dziś jak nigdy ważne staje się więc prezentowanie odnośników w taki sposób, żeby były jednoznaczne i widoczne. Skoro bowiem na touchscreenach nie ma hoverów i myszki w pobliżu, to nie można za ich pomocą „szukać” ukrytych klikalnych elementów, co robią czasem użytkownicy na źle zaprojektowanych stronach.
  • Poważniejszy problem zaczyna się, gdy strona posiada nawigację zbudowaną na bazie rozwijanego przy hoverze menu. Na ekranie dotykowym nie można osiągnąć akcji rolloveru kursora. Można klikać, ale nierzadko kliknięcie wywołuje już inną akcję. A to powoduje, że nagle stajemy przed koniecznością zbudowania nowej nawigacji dla serwisu.
  • Podobnie ma się sytuacja z wszelkimi javascriptowymi tooltipami. Z tym problemem zetknął się Basecamp, który wyświetla przyciski „usuń” i „edytuj” po najchaniu myszą na obiekt. W wersji iPhone’owej projektanci z 37signals zmodyfikowali swój sajt w taki sposób, że linki pojawiają się dopiero po tapnięciu palcem. To jednak niezbyt dobre rozwiązanie, bo nie jest intuicyjne. Lepszym pomysłem jest stałe pokazywanie wszystkich ważnych opcji i informacji (show everything – tak robi w touchscreenowej wersji WordPress)
źródło:trentwalton.com

Z lewej Basecamp na PC, z prawej na touchscreenie. źródło:trentwalton.com

źródło:trentwalton.com

Z lewej WordPress na PC, z prawej na touchscreenie. źródło:trentwalton.com

Sytuację hoverów na urządzeniach dotykowych może nieco odmienić patent Apple na touchscreen wykrywający zbliżanie (proximity-sensing touchscreen). Choć – jak pisze trentwalton.com – to nieco przerażające, bo może wkrótce będziemy wyglądali jak idioci bojący się dotknąć swoich smartfonów :)

Warto przeczytać:

Grube paluchy

Kursor myszy jest o niebo dokładniejszy od palców, które operują ekranami dotykowymi. To pociąga za sobą morze konsekwencji. Zaczynając od fundamentów – linki. Spójrz na opuszek swojego palca wskazującego. Ile może mieć pikseli? :) Mniej więcej o taką ilość musisz odsunąć od siebie odnośniki, aby strona pozostała użyteczna. To nie drobnostka, bo może kompletnie odmienić design strony. A jeśli tego nie poprawisz, może wręcz uniemożliwić nawigację. Część użytkowników będzie mimowolnie naciskać jednocześnie kilka linków. Nie dotrą do poszukiwanej treści i sfrustrowani porzucą stronę. Dopóki chodzi o Twój blog, nie ma sprawy. Jednak kiedy zaczynasz tracić na tym realną kasę, bo tak się składa, że prowadzisz sklep internetowy, a Twoi klienci przez swoje palce wypadają z flow zamówienia, to masz problem. Niektórzy projektanci proponują, by rozwiązywać ten problem, częściej stosując buttony zamiast linków tekstowych.

Fluid design vs. 960 px

Tablety, iPhone, iPad czy telefony z Androidem mogą być używane do przeglądania internetu w trybie wertykalnym i horyzontalnym. Oba te tryby są równoprawne. Tymczasem jesteśmy przyzwyczajeni do projektowania na monitory, którym raczej nie zdarza się obracać. Z tego powodu często (a może najczęściej?) wybieramy layouty o stałej szerokości (fixed design). Zakładamy, że strona ma 960 px szerokości i nie martwimy się o nic. To daje pełną kontrolę nad środkiem. Problem w tym, że na przykład na iPadzie o rozdzielczości 1024×768 te 960 px może okazać się problematyczne. Na szczęście akurat w tym przypadku mamy całkiem sporo wiedzy, jak stosować fluid/liquid design (gdzie szerokość określamy w procentach) lub elastic design (proporcjonalny do wielkości fontu).

Zmianę orintacji ekranu można zresztą obsłużyć jeszcze bardziej efektownie. Na przykład tak jak Sports Illustrated. Od razu zaznaczę, że nie jestem przekonany czy to akurat dobry pomysł (ważna zasada: unikaj radykalnych zmian layoutu):

źródło: http://graphicdesignblender.com

źródło: http://graphicdesignblender.com

Warto przeczytać:

Flash

Jak wiadomo, gdzieś na górze, między gigantami, toczy się wojna o przyszłość flasha. Fakty są jednak takie, że w wiodących urządzeniach (iPhone, iPad) tej technologii nie ma. Trzeba się z tym pogodzić i zastanowić, jak projektować w takiej rzeczywistości. Zastosowania flasha nie kończą się przecież na animowanych stronach. Flash jest stosowany w nawigacjach, playerach oraz przy wielu specyficznych operacjach, jak np. multiupload plików (np. zdjęć). Czasem nie ma dla niego sensownych zamienników i pewne funkcjonalności trzeba w dość dużym stopniu ograniczyć lub przeprojektować.

Specyficzne UX

Wciąż niewiele jest wiedzy na temat skutecznego projektowania UX na nowe platformy. Wiedziało o tym Apple, wprowadzając na rynek iPhone’a, a potem iPada. To ta firma przygotowała poradnik dotyczący user experience na iPadzie (iPad User Experience Guidelines). Warto się z nim zapoznać, nawet jeśli nie planujesz w najbliższej przyszłości projektować specjalnie na dotykowe platformy. Wskazówki zawarte w poradniku dobrze jest mieć z tyłu głowy, projektując standardowe sajty (np. de-emphasize User Interface Controls, minimize Modality).

Nie tak dawno miałem przyjemność rozmawiać z Andrzejem Sienkiewiczem, znanym polskim projektantem UX (m.in. Onet, Grono). Jego zdaniem sajt przygotowany z rozsądnym zastosowaniem wytycznych Apple znakomicie sprawdzi się też na standardowym monitorze z myszką i klawiaturą. Być może powinniśmy wręcz zacząć projektować strony z przekonaniem „multi-touch first” i dodawać takie elementy jak hovery jedynie dodatkowo (to nie mój pomysł, tylko lekka modyfikcja idei Luke’a Wroblewskiego - mobile first!).

Oczywiście można mieć obawy czy rzeczywiście warto zmieniać wszystko w swoim warsztacie z powodu tylko jednego nowego typu urządzenia. Może to strata czasu? Dla nieprzekonanych parę faktów:

No i jak?

Warto przeczytać:

Ten wpis umieszczono w kategorii projektowanie i otagowano jako , , , . Możesz dodać go do zakładek permalink. Dodaj komentarz lub dodaj odpowiedź (trackback): Trackback URL.

Skomentuj

Twój adres email nie zostanie opublikowany i nie będzie rozpowszechniany. Wymagane pola są oznaczone *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>