GUI - projektowanie interfejsów

Transkrypt

1 Katedra Inżynierii Wiedzy, Uniwersytet Ekonomiczny w Katowicach Wykład 2

2 Interfejs użytkownika dobry projekt interfejsu jest warunkiem niezbędnym powodzenia systemu; interfejs trudny w użyciu/posiadający liczne błędy w najlepszym wypadku doprowadzi do wielu pomyłek; w najgorszym wypadku użytkownicy mogą odmówić jego używania pomimo jego dobrej funkcjonalności; użytkownicy mogą mieć problemy z użytkowaniem systemu, jeżeli przestawine w nim informacje są błędne/niespójne.

3 Właściwości graficznego interfejsu okna - umożliwiają wyświetlanie informacji; ikony - reprezentują różnego rodzaju informacje; menu - obiekty umożliwiające wybranie określonej funkcji systemu; wskazywanie - możliwość wyboru konkretnego elementu z menu; grafika - elementy graficzne mogą zostać połączone z informacjami tekstowymi.

4 Rysunek: Proces projektowania interfejsu

5 Ogólna charakterystyka użytkownika Dane podstawowe: wiek, poziom wykształcenia; Klasyfikacja: przynależność organizacyjna, doświadczenie i umiejętności; Preferencje i uprzedzenia użytkownika; Cel korzystania z systemu; Podział na role w systemie; Scenariusze zadań dostępne dla każdej roli w systemie.

6 Rodzaje interakcji z użytkownikiem działanie bezpośrednie - użytkownik porozumiewa się bezpośrednio z obiektami - np. przeciągnięcie pliku do kosza; wybór z menu - wybór jednej z opcji dostępnych w obiekcie menu; wypełnienie formularza - wypełnienie pól/odpowiedź na pytania prowadzi do pewnej akcji; język poleceń - wydawanie specjalnych poleceń (wraz z parametrami) umożliwiających podjęcie akcji systemu; język naturalny - wydawanie poleceń w języku naturalnym.

7 Rysunek: Podstawowy podział interfejsów

8 Podstawowe zasady projektowania interfejsu Wygląd - interfejs powinien być podzielony na obszary przeznaczone do różnych celów; Uświadamianie zawartości - interfejs powinien uświadamiać użytkownika, w którym miejscu się znajdują i co oznaczają poszczególne elementy; Estetyka - równowaga pomiędzy funkcjonalnością a czytelnością; Doświadczenie użytkownika - uwzględnienie możliwości obsługi przez początkującego oraz zaawansowanego użytkownika; Spójność - interfejs powinien umożliwiać użytkownikowi przewidywanie skutków podejmowanych działań; Minimalizacja wysiłku - ograniczenie liczby kroków wiodących do celu do minimum.

9 Zasady projektowania interfejsu II zasada zbliżenia do użytkownika - użytkownik nie powinien być zmuszony do adaptowania się do systemu; potwierdzanie akcji destrukcyjnych; zapewnienie możliwości anulowania - czyli przywrócenia stanu systemu sprzed wykonania polecenia;

10 Czynniki określające funkcjonalność - projektowanie czynniki ludzkie - wpływ stresu, zmysły człowieka, proces zapamiętywania i zapominania; interakcjaa HCI - Human Computer Interaction - zagadnienia związane z logiką i funkcjonalnością parametrów, korzystanie z operacji we/wy, ergonomia korzystania z komputera; Projektowanie zorientowane na użytkownika - nie opiera się na zasadzie klient ma zawsze rację.

11 Rysunek: MVC dla interakcji z użytkownikiem

12 Rysunek: Przykładowa strona z podziałem na obszar nawigacyny

13 Zasady podziału każdy obszar interfejsu powinien mieć jasno wytyczone granice; każdy obszar powinien mieć określone przeznaczenie; każdy obszar powinien zawierać informacje potrzebne do realizacji wybranego zadania; obszary informacyjne powinny być uszeregowane w kolejności przetwarzania informacji przez użytkownika;

14 Uświadamianie zawartości wszystkie okna oraz sekcje powinny mieć tytuły jednoznacznie identyfikujące ich zawartość; menu powinno pokazywać ścieżkę - wskazywać sposób, w jaki użytkownik dostał się do danego punktu; przyciski powinny mieć napis jednoznacznie identyfikujący ich funkcje; forma informacji na sąsiadujących obszarach powinna być różna, np. tekst - grafika; jeżeli informacje nie są różne - powinny być oddzielone dodatkowym elementem; każde pole edycji musi mieć etykietę jednoznacznie identyfikującą to pole; pola edycji, których format nie jest oczywisty (np. data) muszą mieć dodatkowe oznaczenie formatu;

15 Estetyka interfejs powinien być funkcjonalny oraz mieć przyjemny wygląd; ilość wolnego miejsca pomiędzy elementami powinna być zależna od doświadczenia użytkownika - im mniej doświadczenia, tym więcej wolnego miejsca; należy unikać tworzenia dużych raportów i formularzy (kilkadziesiąt pól); tekst główny prezentowany czcionką 8-10 pkt; należy unikać stosowania dwóch różnych czcionek. Zdecydowanie unikać stosowania czcionek ozdobnych; stosowane kolory powinny być stonowane i nie powinny męczyć oka; kolor nie może być jedynym wyróżnikiem informacji.

16 Doświadczenie użytkownika a interfejs interfejs powinien być na tyle łatwy, aby początkujący użytkownik był w stanie go opanować; interfejs powinien ułatwiać i przyspieszać wykonywanie działać zaawansowanych użytkowników; menu powinno prezentować wszystkie dostępne funkcje; menu na każdym poziomie powinno być ograniczone i nie zawierać nadmiarowych informacji; najczęściej stosowane opcje powinny być dostępne bezpośrednio poprzez przyciski narzędziowe; przyciski powinny być logicznie pogrupowane; w przypadku bardziej złożonych aplikacji wskazane jest umożliwienie użytkownikowi konfiguracji paska menu; system podpowiedzi i skrótów klawiszowych dla bardziej złożonych aplikacji;

17 Spójność interfejs powinien być spójny dla zapewnienia przewidywalności podejmowanych działań przez użytkownika; wszystkie elementy: raporty i formularze powinny być zaprojektowane w jednolity sposób; jeżeli dana aplikacja powiązana jest z innymi narzędziami - to wszystkie powiązane elementy powinny być spójne.

18 Minimalizacja wysiłku interfejs powinien być przygotowany tak, aby minimalizować wysiłek użytkownika włożony w wykonanie czynności; 3 kliknięcia - czyli zalecana maksymalna liczba kliknięć służąca do wybrania interesującej użytkownika funkcji; dla bardziej złożonych aplikacji zaleca się łączenie kilku funkcji w jedną.

19 Dobór kolorów i schematów kolorów można stosować intensywne kolory, ale nie intensywne; najlepiej, by kolory były do siebie dopasowane (np. niebieski i zielony, czerwony i żółty itp.) lub kontrastowe: bialy i czarny; kolor tła nie powinien być zbyt intensywny; tło musi być spokojne, najlepiej jednolite, ewentualnie ze stopniowymi przejsciami koloru; stosowanie drobnych elementów i obiektów jako tła nie jest zalecane; niebieski jest bardziej prestiżowym kolorem (podobnie jak większość chłodnych kolorów i fioletowy).

20 Dobór kolorów i schematów kolorów II ograniczenie liczby stosowanych kolorów; zmiany kolorów do oznaczenia zmian stanów systemu; powiązanie kolorów z relizacją zadań - zadania podobne powinny być poznaczone kolorem podobnym; zwracanie uwagi na niektóre związki kolorów np. czerwony z niebieskim - które powodują szybkie zmęczenie oczu.

21 Rysunek: Projektowanie interfejsu

22 Rysunek: Use case 1

23 Rysunek: Use case 2

24 WND - Window Navigation Diagram każdy element wykresu reprezentuje pojedynczy komponent - menu lub formatkę; przejścia pomiedzy komponentami oznaczone są jako pojedyncza lub podwójna strzałka; strzałka pojedyncza oznacza, że informacja zwrotna do komponentu nadrzędnego nie jest potrzebna; każdy komponent opisany jest jako stereotyp, np. << form >>; każdy komponent ma etykietę.

25 Rysunek: Window Navigation Diagram WND

26 Jaki model wybrać? zależny od dostępnych środków; jaki jest sposób organizacji zespołu; jakie narzędzia są dostępne; na ile można korzystać z gotowych rozwiązań? Podejście podstawowe 1 Zaproponuj koncepcję; 2 Wykonaj projekt; 3 Uzgodnij z klientem/zespołem. 4 Zakończenie / powrót do punktu drugiego.

27 Rysunek: Model kaskadowy *Winston Royce, Managing the Development of Large Software Systems, 1970 rok.

28 Cechy modelu iteracyjnie następujące po sobie fazy utrudniają elastyczne działanie; ewentualne powtórzenie iteracji jest kosztowne; problem przy komunikacji z klientem; żeby przejść dalej, to musimy zakończyć bieżącą fazę; może być skuteczny, jeżeli wymagania są poprawnie zdefiniowane; standaryzacja podejścia dokładnie wiemy, jaki etap jest następny; ułatwia organizację; połowa zespołu może czekać druga połowa zakończy poprzednią fazę.

29 Model kaskadowy z nawrotami po każdej fazie następuje jej weryfikacja; powrót nie jest obligatoryjny daje możliwość korekty błędów; konieczny dodatkowy nakład czasowy związany z weryfikacją; łatwiejsze (niż w klasycznym modelu kaskadowym) planowanie.

30 Model przyrostowy Przygotowanie ogólnych wymagań oprogramowania na niskim poziomie szczegółowości oraz wyodrębnienie funkcji systemu; Wyselekcjonowanie funkcji przeznaczonych do realizacji w najbliższym przyroście; Uszczegółowienie wybranych funkcji - szczegółowe zaprojektowanie; Implementacja wybranych funkcji; Testowanie wersji wzbogaconej o nowe funkcje dodane w przyroście; Dostarczenie wersji demo wzbogaconej o funkcje z aktualnego przyrostu; Powtarzanie przyrostów aż do ukończenia projektu.

31 Rysunek: Model przyrostowy

32 Model z prototypem ogólne określenie wymagań; budowa i weryfikacja prototypu; dobry moment na ewentualne porzucenie koncepcji / zmianę założeń i ponowne przygotowanie prototypu; szczegółowe określenie wymagań (już po pozytywnej weryfikacji prototypu); realizacja pełnej wersji; prototyp istotnie zwiększa nakład czasowy a także generuje dodatkowe koszty.

33 Model RAD - Rapid Application Development podział projektu na niezależne składowe; równoległa realizacja poszczególnych funkcjonalności bazując np. na modelu kaskadowym; zespoły pracują niezależnie nad różnymi funkcjami; konieczność integracji podzespołów na finiszu projektu. Model reuse możliwość wykorzystania gotowych rozwiąząń/komponentów; znaczna redukcja kosztów i czasu realizacji projektu; narzucenie standardów.

34 Prototypowanie - definicja Rozwój oprogramowania/aplikacji (gry) poprzez tworzenie kolejnych wersji prototypów. Prototypowanie szybkie przedstawienie pierwszej wersji projektu i ewentualna jego dalsza analiza / udoskonalenie; wykrycie brakujących elementów/ funkcjonalności; wykrycie potencjalnych problemów; doprecyzowanie wymagań; testowanie w trakcie budowy danej wersji.

35 Rodzaje prototypowania prototypowanie aplikacji prototypowanie przyrostowe - punktem wyjścia jest bardzo ogólny schemat, który w kolejnych iteracjach jest modyfikowany aż do uzyskania akceptowalnej wersji, ale: po dostarczeniu elementu systemu nie zmienia się go; prototypowanie ewolucyjne - zbliżone do przyrostowego, ale poszczególne elementy są modyfikowane w trakcie tworzenia prototypu (pewnie to podejście zostanie wybrane przez Państwa na zajęciach) ; prototypowanie z porzuceniem - rozwijanie i modyfikowanie specyfikacji tak, aby na końcowym etapie znana była pełna specyfikacja, a sam prototyp zostaje porzucony.

36 Prototypowanie GUI prototypowanie interfejsu pozwala ustalić docelowy wygląd aplikacji (w porozumieniu z klientem / z zespołem); klient nie zawsze narzuca wymagania wizualne (czasami chodzi tylko o spełnienie funkcjonalności); konkretne gatunki gier narzucają określone elementy interfejsu, ale wyjście poza schemat może skutkować ciekawym efektem; w przypadku gier / serwisów online dobrym pomysłem może być wybranie narzędzi do tworzenia makiet (Axure RP lub UXPin).

37 Storyboarding koncepcja bazuje na rysowaniu na kartce/tablicy odręcznch szkiców interfejsu wraz z ewentualnym zaznaczeniem przepływu pomiędzy funkcjami; jedna z najłatwiejszych technik projektowania interfejsu; stosowana najczęściej do elementów, których działanie jest dobrze znane;

38 Rysunek: Storyboarding

39 Prototypowanie HTML zastosowanie języka HTML do opracowania prototypu interfejsu; istotną wadą jest fakt, iż opracowane elementy niekoniecznie pojawią się dokładnie w takim samym formacie, co końcowy produkt.

40 Prototypowanie językowe opracowanie prototypu interfejsu w docelowym języku aplikacji; finalny produkt wizualnie będzie odpowiadał dokładnie elementom, które widoczne będą na ekranie; wadą tego podejścia jest znacznie większy nakład czasowy wymagany do opracowania prototypu.

41 Ocena interfejsu ocena heurystyczna - zgodność z zasadami; przegląd interfejsu z użytkownikiem; ocena interaktywna u użytkownika; formalne testowanie użyteczności.

42 Rysunek: Za dużo tekstu

43 Rysunek: Za mało tekstu

44 Rysunek: Niewielka funkcjonalność przy zbyt dużej liczbie opcji

45 Rysunek: Możliwość bezmyślnych działań użytkownika

46 Rysunek: Źle dobrane kolory

47 Tyfloinformatyka Tyfloinformatyk Specjalista z zakresu technologii wspomagającej - osoba, która ma wiedzę na temat aktualnego poziomu rozwoju tej technologii, potrafi dobrać sprzęt i oprogramowanie wspomagające do rodzaju i stopnia dysfunkcji wzroku użytkownika komputera i nauczyć efektywnego ich używania. Osoby niepełnosprawne należą do tzw. grupy ryzyka, którą cechuje niekorzystne położenie i dyskryminacja w zatrudnieniu na rynku pracy. W Polsce jest tys. osób niepełnosprawnych, z czego ok. 59% jest w wieku produkcyjnym. Większość z nich (83%) jest bierna zawodowo.

48 Technologia wspomagająca Sprzęt komputerowy i oprogramowanie umożliwiające używanie komputera przez osoby niewidome i słabo widzące; programy udźwiękowiające oraz urządzenia brajlowskie; programy powiększające ekran; elektroniczne urządzenia powiększające dokumenty; notatniki brajlowskie; grafiki wypukłe.

49 Windows JAWS - Job Access With Speech Blind and Low Vision Group at Freedom Scientific of St. Petersburg; najpopularniejszy czytnik ekranowy na świecie; JAWS pozwala na użycie skryptów pisanych w wewnętrzym języku skryptowym JAWS; wsparcie składu HTML; wbudowany OCR rozpoznający grafiki na ekranie;

50 Rysunek: Windows JAWS Rysunek: MAGic - powiększanie ekranu

51 Rysunek: MAGic - klawiatura Rysunek: Kontrast kolorów

52 Rysunek: Przykład schematu kolorów z kontrastem

53 Rysunek: Przykład schematu kolorów z kontrastem II

54 Android Studio Rysunek: Producenci na rynku. Źródło: opensignal.com/reports/ Samsung posiada 43% udziałów w rynku

55 Rysunek: Liczba urzadzeń na rynku. Źródło: opensignal.com/reports/ Podział na konkretne modele

56 Rysunek: Urządzenia na rynku. Źródło: opensignal.com/reports/ Sierpień 2013

57 Rysunek: Urządzenia na rynku. Źródło: opensignal.com/reports/ Sierpień 2014

58 Rysunek: Wersje systemu Źródło: opensignal.com/reports/ Biała linia pokazuje procentowy udział wiodącej wersji

59 Rysunek: Wersje systemu w zależności od kraju Źródło: opensignal.com/reports/

60 Rysunek: Porównanie z ios Źródło: opensignal.com/reports/

61 Rysunek: Wielkość ekranu dostępnych urządzeń. Źródło: opensignal.com/reports/

62 Rysunek: To samo ale dla ios Źródło: opensignal.com/reports/

63 Rysunek: Wersje systemu (X 2016) Źródło:

64 Rysunek: Wersje systemu (X 2017) Źródło:

65 Rysunek: Widgety w środowisku Android

66 Właściwości Widgetów wysokość, szerokość, czcionka; wielkość elementu - match (dopasowanie do elementu rodzica); padding - margines wewnętrzny między ramką a obiektem (dlatego najpierw umieszczamy elementy wewnętrz pojemnika np. layout, a dopiero potem padding); margin - margines zewnętrzny pomiędzy ramką a sąsiednimi obiektami.

67 Rysunek: GUI - plik XML

68 View groups - LinearLayout i RelativeLayout układ w poziomie; układ w pionie; układ ustalany na podstawie parametru: android:orientation. View groups - RelativeLayout układ w odniesieniu do rodzica - np. Container; odniesienie: Bottom Parent, Top Parent, (left, right, center); położenie elementów w odniesieniu do innyc elementów;

69 Jak zapewnić sobie wsparcie dla różnych urządzeń? rozmiary w postaci dip (px = dp ( dip 160 )); dla tekstów używamy sp; < supports screens > - wskazujemy, jakie rozmiary ekranu są wspierane; dostarczamy różne elementy resources (dla różnych ekranów); stosujemy różne layout.

70 dpi, dip, dp, dps, sp? px - rzeczywiste piksele na ekranie; in - inches cale; pt - points 1 72 wielkości cala bazując na rzeczywistym rozmiarze ekranu; dpi - dots per inch (kropki na cal) (w przypadku ekranu o niższej rozdzielczości), lub 240 (w przypadku ekranu o większej rozdzielczości); pixels = dpi razy szerokość (1.5 cala), a więc odpowiednio 240 lub 360 pikseli; gęstość dla ekranów o niższej rozdzielczości oraz 1.5 dla większej rozdzielczości; Denisity-independent pixels (dip,dp, dps) - 240; scale-independent pixels - zależy od ustawień dotyczących czcionki.

71 Rysunek: Więcej szczegółów. Źródło: stackoverflow.com

72 Plik strings.xml i zasoby tworzenie aplikacji wielojęzycznych; ciągi znaków (jak np. opis przycisku) nie powinny być wpisane jako stałe w pliku layout.xml; korzystanie z informacji z pliku strings.xml umożliwi przygotowanie wersji dedykowanych dla różnych języków Rysunek: Struktura katalogów dla plikow strings.xml

73 The Draw 9-patch tool - tworzenie elementów GUI 9 części obrazy (np. przyciski) ze specjalnym rodzajem skalowania; określenie wyglądu obramowań; używane do android:background; cały obrazek podzielony jest na 9 obszarów. 4 narożniki - statyczne; 4 obszary pomiędzy narożnikami - powielane w jednym wymiarze (na szerokość, lub na wysokość); środek - skalowalny.

74 Bardziej złożone struktury więcej elementów niż 9; możliwe skalowanie tylko poziomo, lub tylko pionowo; wybrane fragmenty ramki mogą być stale. Rysunek: Przykład ramki

75 Rysunek: Stany przycisków Interaktywność kontrolek interaktywność kontrolek; osobne grafiki dla poszczególnych stanów przycisku; nie mamy Listenera do przycisku.

76 Stany kontrolek android:state enabled czy element jest aktywny; android:state focused czy element ma fokus; android:state pressed czy element jest wciśnięty; android:state checked czy element jest wybrany.

77 Dziękuję za uwagę