WPAM. W6 (Mobilny) interfejs użytkownika cz. 1. Piotr Gawrysiak.

Transkrypt

1 WPAM W6 (Mobilny) interfejs użytkownika cz. 1 CC-BY-SA Piotr Gawrysiak Piotr Gawrysiak pgawrysiak@supermedia.pl Politechnika Warszawska Instytut Informatyki Zakład Systemów Informacyjnych 2012

2 Interfejs mobilny czyli jaki??? Interfejs dla aplikacji mobilnej tj. działającej na urządzeniu mobilnym Urządzenie mobilne == smartphone (ad. 2011) Przypomnienie #1: Smartphone to nie jest telefon (To jest telefon)

3 Interfejs mobilny czyli jaki??? Przypomnienie #2: Smartphone to nie jest komputer (to jest komputer) Przewidywalne środowisko pracy Przewidywalny scenariusz pracy (sesja) Wygodne mechanizmy wprowadzania danych (klawiatura, mysz) Duży monitor (prezentacja informacji, multitasking itd.) Foto - Avi Abrams

4 OK, i co z tego??? Smartphone to jednocześnie komputer, telefon a także notatnik, książka, aparat fotograficzny, magnetofon, kamera wideo, konsola do gier, portfel, latarka, zegarek, budzik Środowisko pracy (czy nawet scenariusz użytkowania) trudny do przewidzenia Sesja jeśli jest sens ją definiować bardzo krótka Mały ekran, klawiatura (jeśli jest) Jednocześnie najbardziej bodajże ludzkie urządzenie techniczne jakie do tej pory udało się nam wymyśleć

5 Sposób użytkowania (vs. komputer) Różnice sprzętowe (mały ekran itp. ale wiele czujników, zasilanie bateryjne itp.) Urządzenie osobiste należy (zwykle) do jednego tylko użytkownika Urządzenie przenośne używane w ruchu (obsługa jedną ręką, krótki czas dostępu do urządzenia ) Zawsze włączone może być obudzone w dowolnym momencie, przez użytkownika lub np. przez sieć Zawsze podłączone zarówno samo posiada dostęp do sieci, jak też jest w każdej chwili osiągalne, ale Zasilane bateryjnie co wymaga oszczędności energii, zaś z połączeniami bywają problemy

6 Sposób użytkowania (vs. komputer) Zaczynamy używać więcej niż jednego urządzenia do wykonania pojedynczej czynności (workflow) np: Sprawdzamy pocztę elektroniczną wykorzystując telefon, zaś dłuższe odpowiedzi tworzymy używając komputera Wybieramy najciekawsze zdjęcia z kolekcji używając telefonu, a następnie retuszujemy w programie komputerowym itd. Urządzenia (nie tylko mobilne) mogą (i powinny) uzupełniać wzajemnie swoją funkcjonalność Dearman, D. and Pierce, J. S "It's on my other computer!": computing with multiple devices, CHI 2008, Florence, Italy, 2008

7 Sposób użytkowania (vs. komputer) Charakterystyka interakcji mobilnej: Przede wszystkim konsumpcja informacji Krótki czas trwania (średnio mniej niż 1 minuta) i łatwość przerwania sesji (np. ktoś dzwoni, wreszcie przyjechał autobus itp.) Inny sposób wykorzystania urządzeń w zależności od lokalizacji (dom, praca, podróż itd.) Ważny czas dostępu i inicjalizacji interakcji - np. odpowiadanie na Access Mobile Desktop #1 Desktop #2 Initialize Work

8 Wniosek? Tak się nie da tylko czy to źle??? Miniaturyzacja zła! Umobilnienie dobre!

9 Mobile opportunity Tworzenie aplikacji mobilnej może być okazją do wynalezienia nowych sposobów obsługi i interakcji z użytkownikiem. W 1996 roku też nie bardzo wiedzieliśmy na czym polegają silne strony Internetu

10 Intermedium - UI vs UX vs Usability Kilka skrótów (i problemów): UI user interface UI user interaction (także HMI human machine interface/interaction) UX user experience Obecnie UI to raczej niemodny skrót, obowiązuje UX jako określenie obejmujące całokształt doświadczeń związanych z korzystaniem z aplikacji i urządzenia mobilnego (a zatem nie tylko Usability ( użyteczność ) łatwość obsługi, łatwość opanowania interfejsu, jego przyjazność dla użytkownika Interfejs łatwy do nauczenia wcale nie musi być łatwy/efektywny w użyciu (np. VIM, narzędzia CAD itp.) Discoverability łatwość odkrycia funkcji i możliwości interfejsu Czy zawsze potrzebna jest ta interakcja???

11 Problem #1 brak klawiatury Wprowadzanie danych (interakcja!) jest jednym z największych problemów w przypadku interfejsu mobilnego. Typowe rozwiązania: Stosowanie sensownych (najbardziej prawdopodobnych) wartości domyślnych Auto-completion (inteligentne nie tylko oparte tylko o słownik) Alternatywne metody wprowadzania danych: Barcode Mowa Kamera Specjalizowane (ale sensowne) kontrolki Cel: Minimalizacja liczby

12 Problem #1 brak klawiatury Np. zegarek

13 Problem #2 interfejs dotykowy Dokładność ekranów pojemnościowych jest wciąż marna palcem możemy wskazywać jedynie duże obiekty Urządzenie może być obsługiwane jedną ręką najczęściej wykorzystywane elementy interfejsu powinny znajdować się w strefie dostępnej (pamiętajmy także o osobach innoręcznych ) albo przynajmniej w dolnej części ekranu Wykorzystujmy (jeśli urządzenie jest w nie wyposażone) fizyczne przyciski First ELSE (RIP)

14 Problem #2 interfejs dotykowy

15 Problem #2- wielkość

16 Powtórka prawo Fitts a Formalnie : MT = a + b log2(2a/w + c) gdzie MT czas reakcji A odległość do środka celu W szerokość celu a, b, c stałe, zależne od urządzenia Po ludzku łatwiej jest trafić w element interfejsu który jest blisko i który jest duży Fitts,P.M. (1954). The information capacity of the human motor system in controlling the amplitude of movement. Journal of Experimental Psychology, 47,

17 Wnioski z prawa Fitts a W interfejsach klasycznych istnieją elementy, które: mają nieskończone wymiary: rogi ekranu brzegi ekranu do których odległość jest zawsze zerowa: pop-up menu (magic pixel) Co prawo Fitts a oznacza dla interfejsów dotykowych wielkość elementów interfejsu ma znaczenie Pop-ups są wciąż istotne (ale trudniej je aktywować ) Nie możemy korzystać z efektu rogów ekranu, ale możemy wykorzystywać gesty (gestures) (NOKIA N9!!!)

18 Spatial memory "Spatial or spacial adj - relating to or occurring in space." Spatial (ew. muscle) memory pamięć motoryczna, pozwalająca nam (tj. ludzkiemu mózgowi) automatyzować często wykonywane czynności. Znacznie łatwiej trafić te elementy interfejsu, które znajdują się w miejscach których użytkownik się spodziewa.

19 Intermedium conceptual model Jeśli użytkownik będzie miał niewłaściwe wyobrażenie o tym, w jaki sposób jego akcje wpływają na działanie naszej aplikacji, to z pewnością sobie z nią nie poradzi Klasyczne przykłady (Donald A. Norman) : kuchenka (physical mapping) lodówka (conceptual mapping)

20 Lodówka D. Normana Problem: Zamrażalnik za bardzo ziębi, a lodówka chłodzi tak jak powinna. Jak ustawić pokrętła, aby zamrażalnik był cieplejszy, a temperatura lodówki się nie zmieniła?

21 Lodówka D. Normana

22 Lodówka D. Normana

23 Prezentacja informacji Skoro interakcja jest kosztowna to należy jej unikać. W niektórych przypadkach samo zaprezentowanie informacji może okazać się wystarczające dla użytkownika E. Tufte, Visual Display of Quantitative Information, Graphics Press, 2001

24 Prezentacja informacji Teoretycznie dysponujemy ponadto informacją o kontekście użytkownika, która może ułatwić nam ograniczenie możliwych sposobów interakcji (np. automatyczny tryb nocny/dzienny - ale należy pamiętać o override )

25 Kontekst A Foto - Rachel Hinman

26 Prezentacja informacji Bret Victor, Magic Ink,

27 Problem #3 Mały ekran A dokładniej: Aplikacja zajmuje zawsze cały ekran (pomimo, iż może nie być jedyną działającą) - multitasking Dzielenie informacji pomiędzy aplikacjami nie jest proste (copy-paste jest trudne, przeciąganie właściwie niemożliwe) Zdarzenia zewnętrzne (wiadomości SMS, telefony itp.) powodują, z konieczności, zmianę trybu pracy całego urządzenia (i zmianę scenariusza użytkowania) Wreszcie - wizualizacja dużych ilości danych nie jest prosta (ba, nawet czytanie dużej ilości tekstu nie jest przyjemne)

28 Problem #3 typowe rozwiązania Ograniczanie do minimum konieczności wymiany informacji klasycznymi metodami (zatem zamiast copy-paste rozpoznawanie typowych typów danych np. adresów stron WWW, numerów telefonów itp. i możliwość bezpośredniego wywołania pewnych akcji) Customization pozwólmy użytkownikowi zdecydować które elementy interfejsu powinny być większe, a które mniejsze Unikanie modalnych elementów interfejsu, właściwe odtwarzanie stanu aplikacji

29 Problem #3 nietypowe rozwiązania Ekran jest większy niż nam się wydaje: 1.ZUI (zooming user interfaces) Jef Raskin Pinch gesture mobilne przeglądarki internetowe Microsoft Seadragon (teraz zoom.it) 1.Microsoft Hubs (Windows Phone 7, 8)

30 Przykład PULSE RSS Tu próba rozwiązania zarówno problemu #2 jak i #3

31 Problem #4 Zasilanie bateryjne i sieć Energię należy oszczędzać, zaś dostęp do sieci wykorzystywać jak najbardziej efektywnie (to także kwestia kosztów) Należy unikać ciągłej komunikacji z siecią Najczęściej wykorzystywane dane należy zapisać w pamięci urządzenia Do maksimum wykorzystać możliwość przechowania kopii roboczych danych (cache) Użytkownik powinien mieć możliwość pełnej kontroli nad przechowywanymi danymi (w szczególności możliwość ich przygotowania a priori Gdy dane są nieaktualne, nie należy tego ukrywać przed użytkownikiem

32 Spójność (consistency) Większość platform mobilnych posiada spisane reguły tworzenia elementów interfejsu użytkownika (tzw. HIG Human Interface Guidelines) np.: Nokia Series 40 UI Style Guide Bada Application UI Guide iphone Human Interface Guidelines ipad Human Interface Guidelines UI Guidelines for BlackBerry 6.0 Smartphones W większości przypadków warto zastosować się do wytycznych, niż starać się tworzyć własną estetykę interfejsu użytkownika. Jeśli zaś się odróżniać to drastycznie!

33 Co staramy się stworzyć? Typologia aplikacji mobilnych wg. Briana Flinga (w zależności od kontekstu użycia): Utility przeznaczone do krótkiego wykorzystania, realizujące jedną, konkretną funkcję (np. kalkulator, latarka, itd.) Locale zależne od fizycznego kontekstu (np. analizator spalania benzyny, Wikitude, itd. ) Informative dostarczająca informacji nie wynikających bezpośrednio z akcji użytkownika (Google News) Productivity zwiększająca nasz zasób czasu, ułatwiająca pracę (Allegro, Amazon) Immersive przeznaczona do dostarczenia rozrywki (gry!, ale także programy typu czekadełko np. Fish Pond., Fleya) Większość ma swój odpowiednik w istniejących aplikacjach / usługach Nie starajmy się ich miniaturyzować raczej je umobilniajmy!

34 Dla kogo tworzymy aplikację? Czy też raczej jakie wrażenie chcemy wywrzeć na użytkownikach Wrażenie wizualne prosty design, bogaty interfejs, kolorowy, intuicyjny, barokowy itp. Niektóre kwestie stają się (znów) problemem w przypadku urządzeń mobilnych np. kolor, czy wielkość czcionki 12 bitów / pixel 24 bity / pixel

35 Intermedium crossing the chasm Geoffrey Moore Jesteśmy tu ale często obsesyjnie myślimy jak dostać się tutaj I powinniśmy starać się dojść tu Źródło Craig Chelius

36 Projektowanie the mobile ( ) strength lies in doing small tasks in idle time Christian Lindholm Nokia Interaction Designer vs.

37 Ekspresja Interfejs mobilny nie pozostawia zbyt dużego marginesu błędu twórcy aplikacji: Zanim zaczniemy pisać kod zastanówmy się zatem przez chwilę

38 Span of attention Krótki czas trwania sesji i częsta aktywacja: Minimalizacja startu aplikacji / activity Struktura nawigacyjna jak najprostsza lub pozwalająca na powrót do ostatnio wykonywanej lub ulubionej czynności (shortcuts) Mechanizm typu auto-save (także do sieci) Wybaczanie błędów / brak modality (okienka dialogowe itd.)

39 Minimalizacja wysiłku nawigacyjnego To niekoniecznie musi oznaczać uproszczenie polegające na zmniejszeniu liczby funkcji raczej należy dążyć do maksymalizacji liczby funkcji dostępnych bezpośrednio, tj. w odległości pojedynczego dotknięcia palcem np. Źródło Opera

40 Struktura nawigacyjna Źródło Kim Lenox

41 Struktura nawigacyjna cd. Należy jednak zawsze dać możliwość powrotu do wersji bardziej skomplikowanej / zaawansowanej dla power users

42 Nie dać się zgubić Interfejs mobilny nie pozwala na łatwą wizualizację kontekstu / lokalizacji w strukturze nawigacyjnej O ile to możliwe należy pomóc odnaleźć drogę: Breadcrumbs Favourite places Zooming Płynne przejścia pomiędzy ekranami aplikacji Właściwe wykorzystanie przycisku / koncepcji back Wykorzystanie wyszukiwania ew. ze wsparciem po stronie serwera Prostota interfejsu nie mnożymy bytów

43 Zooming - przykład Źródło Paul Watson

44 Breadcrumbs - przykład

45 Mobilne dane Mobilne czyli powolne, zawodne i drogie Podstawowe pytanie jak nasza aplikacja zachowuje się w trybie online i offline (oraz przy różnej szybkości transmisji danych): wybaczanie okresowych braków łączności Inteligentne ładowanie danych w tle (caching) ale w zależności od pojemności urządzenia i wymagań użytkownika Ograniczenie zużycia baterii i ograniczenie ilości pobieranych danych Częstotliwość aktualizacji Data cap ile wolno nam pobrać danych W trybie offline czasem możemy zdać się na wiedzę użytkownika

46 Mobilne dane cd. Problemy z jakością usług mobilnych to nie jedyna przyczyna braku łączności równie istotne może być wymuszone wyłączenie urządzeń radiowych (tryb samolotowy) ale to także oznacza brak: GPS Bluetooth WiFi NFC???

47 Mobilne dane - latency Mikrointermedium progress bar Znajdź istotną różnicę Brak płynności jest szczególnie zauważalny w przypadku interfejsów mobilnych (dlaczego?) a jednocześnie bardzo łatwo osiągalny : Network latency Lokalne przetwarzanie danych Niedoskonałości systemu operacyjnego (np. Android) Strategia płynność należy udawać tam gdzie to możliwe (najpierw zmiany interfejsu, przetwarzanie asynchroniczne w tle)

48 Mobilne dane cd.

49 Prototypowanie

50 Prototypowanie, projektowanie Narzędzia którymi dysponujemy są ograniczone W przypadku małych projektów papier jest wystarczający W większych przedsięwzięciach zaczyna być ograniczeniem Trudność w przekazaniu na odległość (do/od klienta) Trudność w interpretacji przez osoby trzecie

51 Prototypowanie, projektowanie Rachel Hinman, Adaptive Path

52 Papier Funkcje Najpierw pytanie

53 Papier Czy możemy z naszych funkcji złożyć odpowiedź?

54 Typowe rozwiązanie wireframes Wireframe reprezentacja funkcji i pozycjonowania elementów nawigacyjnych oraz architektury informacyjnej interfejsu nie zawierająca docelowych elementów graficznych Popularność zyskały wraz z rozpowszechnieniem WWW i koniecznością projektowania wyglądyustron we współpracy z klientem

55 Wireframes cd. Obfitość narzędzi służących do tworzenia mobilnych wireframes: Od wciąż związanych z papierem (Notepod, iphone Stencil Kit, ) Poprzez oprogramowanie biznesowe (zestawy ikon i elementów do Omnigraffle czy Powerpoint np Stencil PSD) Poprzez narzędzia dedykowane (zarówno uniwersalne, jak też i przeznaczone wyłącznie do tworzenia mobilnych wireframes) np. Firefox Pencil Mockingbird iplotz

56 Wireframes cd. Wireframes jednak także mają wady: Pokazują projekt jedynie wycinkowo trudno zorientować się jak działa cała aplikacja Wymagają wysiłku umysłowego do interpretacji to ogranicza liczbę zaangażowanych w proces kreacji osób Interpretacja wymaga złożenia wielu wireframes razem ewentualne poprawki wymagają modyfikacji w wielu miejscach Modyfikacje są kosztowne to ogranicza możliwość eksperymentowania z wariantami projektu Typowe rozwiązanie alternatywne - prototyp

57 Prototyp Prototypy jednak także nie są bez wad Pytanie czy wysiłek włożony w stworzenie prototypu jest wysiłkiem straconym??? Z pewnością jest kosztowny czas poświęcony na tworzenie prototypu może być wykorzystany na pisanie kodu bezpośrednio dla klienta (np. innego) Prototyp zatem nie może być zbyt skomplikowany ale też nie może być zbyt prosty! Problem wyboru poziomu abstrakcji Ryzyko zamrożenia pierwszej wersji prototypu jako wersji ostatecznej Ryzyko zastąpienia procesu projektowania procesem kodowania (zbyt duży wpływ ograniczeń technologii) w przypadku ekstremalnym mamy wypaczenie metodyk zwinnych (agile)

58 Nie ma dobrych rozwiązań Brian Rieger (Yiibu) sugeruje sięgnięcie do metod używanych w przemyśle filmowym (storyboards, layouts, timelines) i ich implementację w postaci interaktywnych wireframes (definiowane w XML, rendering w Processing)

59 UI Checklist Kilka rad dobrego wuja na koniec (konkretnie Jakob Nielsen usability heuristics ): Widoczność stanu systemu W każdym momencie użytkownik powinien wiedzieć co się dzieje np. w trakcie wykonywania obliczeń / pobierania danych itp. należy wyświetlić odpowiednie powiadomienie estymując także czas zakończenia Zgodność systemu i świata użytkownika Używajmy metafor (języka, identyfikacji wizualnej, koncepcji) których spodziewa się użytkownik. Inaczej powinna wyglądać aplikacja typu modlitewnik a inaczej mobilna wersja Kamasutry

60 UI Checklist cd. Koło ratunkowe Użytkownik może uruchomić funkcje systemu przez pomyłkę, szczególnie w przypadku interfejsu mobilnego. Każda (w praktyce prawie każda) funkcja powinna posiadać opcję undo i redo (to się da zrobić nawet w przypadkach pozornie niemożliwych vide Gmail send) Standardy Należy do minimum ograniczyć czyhające na użytkownika niespodzianki. Stosujmy standardy platformy lub wypracowane dla naszych aplikacji (budując jednocześnie pozycję marki firmy)

61 UI Checklist cd. Unikanie błędów Komunikaty o błędach są dobre. Jeszcze lepszy jest interfejs, który uniemożliwia popełnienie błędu. Przejrzyjmy wszystkie ścieżki wykonania, które kończą się informacją o błędzie użytkownika Odkrywalność interfejsu Elementy systemu powinny być widoczne i odkrywalne, tak aby użytkownik nie musiał ich zapamiętywać. Podobnie należy unikać konieczności zapamiętywania (przez użytkownika) danych pomiędzy częściami aplikacji.

62 UI Checklist cd. Elastyczność interfejsu Początkującym użytkownikom elastyczność i konfigurowalność interfejsu użytkownika nie będzie potrzebna. Początkującym jednak jest się jedynie przez chwilę Minimalistyczny design Prezentowaną informację (visual clutter) należy ograniczyć do niezbędnego minimum, prezentując tylko te dane, które są w danym momencie istotne dla użytkownika.!pytajmy użytkowników projektant / programista bowiem zawsze wie za dużo ( curse of knowledge )!

63 Beauty A przede wszystkim interfejs użytkownika powinien być piękny