WPAM. W8 Mobilne interfejsy użytkownika Part II. Piotr Gawrysiak.

Transkrypt

1 WPAM W8 Mobilne interfejsy użytkownika Part II C-BY-SA Piotr Gawrysiak Piotr Gawrysiak Politechnika Warszawska Instytut Informatyki Zakład Systemów Informacyjnych 2012

2 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

3 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

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

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

6 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.)

7 Struktura nawigacyjna Źródło Kim Lenox

8 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

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

10 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

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

12 Breadcrumbs - przykład

13 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

14 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???

15 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

16 Mobilne dane cd.

17 Prototypowanie

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

19 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

20 Prototypowanie, projektowanie Rachel Hinman, Adaptive Path

21 Papier Funkcje Najpierw pytanie

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

23 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

24 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

25 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

26 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

27 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)

28 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ć

29 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

30 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 danych pomiędzy częściami aplikacji.

31 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

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

33 Intermedium Android i grafika Możemy mieć do dyspozycji format RGB_565 (2 bajty / pixel) albo ARGB_8888 (4 bajty / pixel) Ale im więcej bajtów przypada na piksel tym większa zajętość pamięci Standardowo pojedynczy proces jest ograniczony do 24MB to wystarcza na stworzenie zaledwie kilku obrazów Możliwe rozwiązania użycie tekstur (OpenGL) zamiast bitmap (dodatkowo tekstury nie wykorzystują kanału alpha), ew. wykorzystanie NDK Pamiętać warto, iż standardowe operacje graficzne nie przeskalują nam obrazów tak,