Projektowanie interfejsu uŝytkownikau. uŝytkownika. Zagadnienia. Zawartość. projektu interfejsu

Transkrypt

1 Jarosław aw Kuchta Rozproszonych Projektowanie interfejsu uŝytkownikau Zagadnienia Podstawowe zasady projektowania interfejsu uŝytkownika Proces projektowania interfejsu uŝytkownikau Projektowanie struktury interfejsu uŝytkownikau Prototypowanie i ocena interfejsu uŝytkownikau 2/32 Zawartość projektu interfejsu uŝytkownika Charakterystyka uŝytkowniku ytkowników Wyszczególnienie okien i projekt nawigacji między oknami Projekt wizualny okna głównegog Projekt funkcjonalności ci interfejsu akcje uŝytkownikau menu Scenariusze uŝycia 3/32 1

2 Klasyfikacja uŝytkowniku ytkowników Doświadczenie i umiejętno tności niskie średnie wysokie eksperckie Uprawnienia decyzyjne kierownik administrator zwykły y uŝytkowniku PrzynaleŜno ność organizacyjna członek personelu współpracownik pracownik klient 4/32 Charakterystyki uŝytkowniku ytkowników Nazwa uŝytkownikau Cel korzystania z systemu Klasyfikacja przynaleŝno ność organizacyjna doświadczenie i umiejętno tności uprawnienia decyzyjne Dodatkowe cechy wiek poziom wykształcenia zastrzeŝenia enia Krytyczne czynniki powodzenia potrzeby i moŝliwo liwości preferencje i uprzedzenia Scenariusze zadań 5/32 Składowe interfejsu uŝytkownikau Mechanizm wejściowy (input( input) realizuje wprowadzanie danych przez uŝytkownika u do systemu (np. formularze). Mechanizm wyjściowy (output( output) realizuje dostarczanie danych przez system dla uŝytkownika (np. raporty, strony Web). Mechanizm nawigacji realizuje sterowanie systemem przez uŝytkownika u (np. menu, przyciski). 6/32 2

3 Podstawowe zasady projektowania interfejsu uŝytkownikau Wygląd interfejs powinien być podzielony na róŝne r obszary przeznaczone do róŝnych r celów. Uświadamianie zawartości interfejs powinien uświadamiau wiadamiać uŝytkownika, w którym miejscu się znajduje i co oznaczają prezentowane informacje. Estetyka interfejs powinien zapewniać równowagę pomiędzy ilości cią prezentowanej informacji a jej atrakcyjności cią wizualną. Doświadczenie uŝytkownikau interfejs powinien uwzględnia dniać zarówno łatwość nauki dla początkuj tkujących jak i łatwość uŝycia dla doświadczonych uŝytkowników. w. Spójno jność interfejs powinien być spójny dla ułatwienia u uŝytkownikowi u przewidywania skutków w podejmowanych przez niego działań. Minimalizacja wysiłku interfejs powinien ułatwiau atwiać działania ania uŝytkownika, u tak by ilość kroków w wiodących do osiągni gnięcia celu była a jak najmniejsza. 7/32 Podział interfejsu na obszary Obszar nawigacji przeglądarki Obszar nawigacji strony Obszar nawigacji strony Obszar nawigacji strony Obszar statusu przeglądarki Obszar informacyjny strony 8/32 Proponowane obszary Obszar menu głównego Obszar przycisków sterujących Identyfikacja strony Nawigacja między stronami Nawigacja między sekcjami Nawigacja na stronie Treść główna Obszar statusu Nawigacja dodatkowa 9/32 3

4 Zasady podziału KaŜdy obszar powinien mieć jasno wytyczone granice. KaŜdy obszar powinien mieć jasno określone przeznaczenie. KaŜdy obszar powinien zawierać tylko te informacje, które sąs potrzebne do realizacji określonego przeznaczenia. Obszary informacyjne powinny być uszeregowane w kolejności przetwarzania tej informacji przez uŝytkownika (z góry g w dół, d, od lewej do prawej). 10/32 Dane klienta Imię Nazwisko Adres Miejscowość Uszeregowanie pionowe Kod poczt Ulica Nr domu Nr lokalu 11/32 Imię Nazwisko Miejscowość Kod poczt. Uszeregowanie poziome Adres Ulica Nr domu Nr lokalu Dane klienta Układ poziomy ułatwia zastosowanie róŝnych języków! 12/32 4

5 Zasady uświadamiania u zawartości (1) Wszystkie okna i raporty muszą mieć tytuły jednoznacznie identyfikujące ich zawartość ść. Menu musi pokazywać,, w którym miejscu jest uŝytkownik (i jak się tu dostał). Przyciski powinny mieć napisy identyfikujące ich funkcje. Jeśli napisy te nie sąs pokazywane cały y czas na ekranie, to powinny być pokazywane przy najechaniu na przycisk wskaźnikiem myszy. Przyciski odpowiedzi na oknach komunikatów w powinny być łatwo interpretowane w kontekście treści komunikatu. 13/32 Zasady uświadamiania u zawartości (2) Forma informacji na sąsiadujs siadujących obszarach powinna być róŝna (np. tekst-grafika, róŝne r czcionki). RozróŜnianie kolorem nie jest wystarczające. ce. Jeśli informacje na sąsiadujs siadujących obszarach sąs podobne w formie, to muszą być oddzielone dodatkowym elementem (np. linią). KaŜe e pole edycji musi mieć etykietę jednoznacznie identyfikującą zawartość pola. Pola edycji, których format wewnętrzny nie jest oczywisty (np. pola z datą), muszą mieć dodatkowe oznaczenie formatu wprowadzanych danych. Raporty powinny mieć datę sporządzenia. 14/32 Zasady estetyki (1) powinien być zarówno funkcjonalny jak i przyjemny dla oka. Ilość wolnego miejsca pomiędzy elementami interfejsu powinna być dostosowana do wymagań uŝytkownika (50% dla początkuj tkujących, 10% dla zaawansowanych). NaleŜy y unikać tworzenia formularzy lub raportów duŝych, zawierających ponad 50 pól p l danych. Formularz lub raport powinien zawierać tylko informacje, które mogą być jednorazowo przetworzone przez człowieka. 15/32 5

6 Zasady estetyki (2) Tekst główny g powinien być prezentowany czcionką 8-10 punktową.. Na formularzach powinna być uŝywana czcionka bezszeryfowa,, na raportach czcionka szeryfowa. NaleŜy y unikać stosowania więcej niŝ dwóch róŝnych r czcionek. Stanowczo trzeba unikać czcionek ozdobnych, lecz trudnych do czytania. Stosowane kolory powinny być stonowane (kontrastowe zwracają uwagę,, lecz sąs męczące ce dla oka). Kolor nie moŝe e być jedynym wyróŝnikiem informacji. Interfejs uŝytkownika u nie moŝe e ukrywać informacji przed osobami cierpiącymi cymi na daltonizm. 16/32 Doświadczenie uŝytkownika u (1) powinien być łatwy do nauczenia się posługiwania się nim przez początkuj tkujących uŝytkowniku ytkowników. w. powinien ułatwiau atwiać i przyspieszać wykonywanie działań przez zaawansowanych uŝytkowniku ytkowników. w. Menu powinno składa adać się nie więcej niŝ z trzech poziomów w w przypadku menu głównego g i nie więcej niŝ z dwóch poziomów w przypadku menu kontekstowych. Menu powinno prezentować wszystkie dostępne funkcje aplikacji, tzn. nie powinno być takiej funkcji, do której nie moŝna by się było o dostać z menu. Menu na kaŝdym poziomie powinno zawierać nie więcej niŝ kilka pozycji. W przypadku bardziej rozbudowanego menu wskazane jest, by pozycje menu były y logicznie pogrupowane oraz by częś ęściej uŝywane u funkcje były y w pewien sposób b wyróŝnione. 17/32 Doświadczenie uŝytkownika u (2) Częś ęściej wykorzystywane funkcje powinny być dostępne bezpośrednio poprzez przyciski narzędziowe. Przyciski narzędziowe powinny mieć obrazek kojarzący się z wykonywaną funkcją oraz nazwę funkcji. Jeśli nazwy funkcji na przyciskach nie mogą być pokazane, to powinny być pokazywane przy najechaniu myszą na przycisk. Przyciski powinny być logicznie pogrupowane na paskach narzędziowych. W przypadku aplikacji realizującej liczne funkcje wskazane jest, aby umoŝliwia liwiała a ona konfigurację pasków w narzędziowych, w tym umieszczanie na paskach przycisków wiodącyc do wszystkich funkcji aplikacji, równier wnieŝ tych rzadziej wykorzystywanych. 18/32 6

7 Doświadczenie uŝytkownika u (3) Wskazane jest, aby bardziej złoŝona z ona aplikacja prezentowała swoje moŝliwo liwości za pomocą podpowiedzi. Jeśli podpowiedzi te zajmują istotnie duŝo o miejsca na ekranie, to aplikacja powinna umoŝliwi liwić wyłą łączenie podpowiedzi i włąw łączenie ich ponownie na Ŝądanie. Aplikacja powinna umoŝliwia liwiać szybki dostęp p do funkcji za pomocą skrótów w klawiszowych. W przypadku bardziej złoŝonej z onej aplikacji wskazane jest zapewnienie moŝliwo liwości definiowania własnych skrótów w klawiszowych. Aplikacja powinna mieć system pomocy ekranowej wyjaśniaj niającej podstawowe mechanizmy zastosowane w aplikacji i wyjaśniaj niającej sposób b wykorzystania tych mechanizmów. 19/32 Spójno jność powinien być spójny dla zapewnienia przewidywalności podejmowanych działań przez uŝytkownika. u Wszystkie formularze i raporty w aplikacji powinny być zaprojektowane w jednolity sposób, tzn. z uŝyciem u jednolitego aparatu pojęciowego (terminologii) i z zastosowaniem jednolitej formy (takiego samego układu, czcionek i kolorów) oraz sposobu nawigacji. aplikacji powinien być spójny z innymi aplikacjami z tej samej dziedziny zastosowania wykorzystywanymi w określonym systemie operacyjnym. 20/32 Minimalizacja wysiłku powinien ułatwiau atwiać uŝytkownikowi wykorzystanie funkcji aplikacji tak, aby wysiłek uŝytkownika u była a jak najmniejszy. Zaleca się,, aby ilość kliknięć myszą wiodących poprzez menu lub przyciski narzędziowe do kaŝdej funkcji nie przekraczała a trzech. W przypadku funkcji wielokrotnie wykorzystywanych zaleca się zastosowanie mechanizmu powtarzania funkcji lub grupowania przedmiotów w działania ania funkcji. W przypadku bardziej złoŝonych z onych aplikacji zaleca się zastosowanie mechanizmu umoŝliwiaj liwiającego łączenie wielu róŝnych r funkcji w jedną. 21/32 7

8 Proces projektowania interfejsu uŝytkownika Opracowanie scenariuszy uŝycia Ocena interfejsu Projektowanie struktury interfejsu Prototypowanie projektu interfejsu Projektowanie standardów interfejsu 22/32 Scenariusz uŝyciau Scenariusz uŝycia u jest opisem podstawowych kroków, które musi przejść uŝytkownik dla osiągni gnięcia określonego celu. Podstawa do opracowania: model przypadków uŝycia, diagramy sekwencji (interakcji). Nie rozpatruje się wszystkich moŝliwych scenariuszy uŝycia, u lecz dwa lub trzy najczęś ęściej realizowane. Sposób b prezentacji: opis tekstowy 23/32 Scenariusz uŝycia u 1.Klient przeglądaj dający ofertę 1. Klient przegląda ofertę szukając c interesujących go towarów w w określonej kategorii 2. Klient przegląda podstawowe informacje dla kilku towarów. w. Porównuje informacje między sobą łącznie z ofertą cenową. 3. Klient umieszcza wybrany towar (towary) w koszyku i dalej przegląda ofertę. 4. Przed złoŝeniem z zamówienia klient przegląda koszyk dla zorientowania się,, czy łączna kwota do zapłaty aty jest do zaakceptowania. Ewentualnie klient usuwa pewne towary z koszyka. 5. Klient składa zamówienie wybierając c formę płatności. 24/32 8

9 Scenariusz uŝyciau 2. Klient szukający określonego towaru 1. Klient szuka określonego towaru po nazwie lub typie. 2. Klient oczekuje podania ceny i terminu dostawy. 3. W przypadku niezadowolenia klient oczekuje innej oferty w tym samym typie. 4. Klient składa zamówienie lub przechodzi do innej witryny. 25/32 Struktura interfejsu Struktura interfejsu określa podstawowe komponenty interfejsu i sposób b ich współdzia działania ania dla dostarczenia określonej funkcjonalności ci dla uŝytkowniku ytkowników. w. Sposób b prezentacji: Window Navigation Diagram (WND) 26/32 Projekt nawigacji «window» Main Menu «window» Menu A zdarzenie / akcja «window» Menu B «form» Form A «form» Form B «form» Form C «report» Report A 27/32 9

10 Prototypowanie interfejsu Storyboard Prototypowanie HTML Prototypowanie w języku j docelowym 28/32 Menu klienta Dodaj klienta Znajdźklienta Lista klientów Lista klientów Abacki Adam Babacki Bartosz Cabacki Czesław ListaKlientów DodajKlienta ZnajdźKlienta DodajKlienta Znajdźklienta Imię Nazwisko Adres Miejscowość Kod poczt ZnajdźKlienta Storyboard Ulica PodajDaneKlienta ListaKlientów Nr domu Nr lokalu ZnajdźKlienta ListaKlientów Dane klienta Imię Nazwisko Adres Miejscowość Kod poczt Ulica Nr domu Nr lokalu KlientZnaleziony PoprawDaneKlienta Dane klienta Imię Nazwisko Adam Abacki Adres Miejscowość Kod Nieznane poczt Ulica Zapole Nr domu 13A Nr lokalu 13 29/32 Prototypowanie w HTML interaktywne szybkie w wykonaniu nie odpowiada obrazowi docelowemu języku docelowym interaktywne wolniejsze odpowiada obrazowi docelowemu 30/32 10

11 Ocena interfejsu ocena heurystyczna ocena zgodności z zasadami min. 3 ekspertów przegląd d interfejsu z uŝytkownikiemu ocena interaktywna u uŝytkownikau formalne testowanie uŝytecznou ytecznościci 31/32 Literatura Dennis A., Wixom B.H., Tegarden D., Systems Analysis & Design. An Object-Oriented Oriented Approach with UML,, John Wiley and Sons,, USA, 2002 Rolf Hennicker,, Nora Koch: Modeling the User Interface of Web Applications with UML,, muenchen.de /personen/kochn/puml2001 /puml2001-hen-koch.pdf Coad P., Yourdon E.: Projektowanie obiektowe, Oficyna wydawnicza Read Me, Warszawa /32 11