Projektowanie interfejsu uŜytkownika
Transkrypt
Projektowanie interfejsu uŜytkownika
Jarosł Jarosław Kuchta Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu uŜytkownika [email protected] [email protected] Zagadnienia Podstawowe zasady projektowania interfejsu uŜytkownika Proces projektowania interfejsu uŜ uŜytkownika Projektowanie struktury interfejsu uŜ uŜytkownika Prototypowanie i ocena interfejsu uŜ uŜytkownika Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 2/32 Zawartość Zawartość projektu interfejsu uŜytkownika Charakterystyka uŜ uŜytkownikó ytkowników Wyszczegó Wyszczególnienie okien i projekt nawigacji mię między oknami Projekt wizualny okna gł głównego Projekt funkcjonalnoś ś ci funkcjonalno interfejsu akcje uŜ uŜytkownika menu Scenariusze uŜycia Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 3/32 1 Klasyfikacja uŜ uŜytkownikó ytkowników Doś Doświadczenie i umieję umiejętnoś tności Uprawnienia decyzyjne niskie średnie wysokie eksperckie kierownik administrator zwykł zwykły uŜ uŜytkownik PrzynaleŜ PrzynaleŜność ność organizacyjna czł członek personelu wspó współpracownik klient Projektowanie Aplikacji Rozproszonych Ŝ Projektowanie interfejsu u ytkownika 4/32 Charakterystyki uŜ uŜytkownikó ytkowników Nazwa uŜ uŜytkownika Cel korzystania z systemu Klasyfikacja Dodatkowe cechy wiek poziom wykształ wykształcenia zastrzeŜ zastrzeŜenia Krytyczne czynniki powodzenia przynaleŜ przynaleŜność ność organizacyjna doś doświadczenie i umieję umiejętnoś tności uprawnienia decyzyjne potrzeby i moŜ moŜliwoś liwości preferencje i uprzedzenia Scenariusze zadań zadań Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 5/32 Skł Składowe interfejsu uŜ uŜytkownika Mechanizm wejś wejściowy (input (input)) – realizuje wprowadzanie danych przez uŜ uŜytkownika do systemu (np. formularze). Mechanizm wyjś wyjściowy (output (output)) – realizuje dostarczanie danych przez system dla uŜytkownika (np. raporty, strony Web). Mechanizm nawigacji – realizuje sterowanie systemem przez uŜ uŜytkownika (np. menu, przyciski). Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 6/32 2 Podstawowe zasady projektowania interfejsu uŜ uŜytkownika Wyglą Wygląd – interfejs powinien być być podzielony na ró róŜne obszary przeznaczone do ró róŜnych celó celów. Uświadamianie zawartoś zawartości – interfejs powinien uś uświadamiać wiadamiać uŜytkownika, w któ którym miejscu się się znajduje i co oznaczają oznaczają prezentowane informacje. Estetyka – interfejs powinien zapewniać zapewniać równowagę wnowagę pomię pomiędzy iloś ilością cią prezentowanej informacji a jej atrakcyjnoś atrakcyjnością cią wizualną wizualną. Doś Doświadczenie uŜ uŜytkownika – interfejs powinien uwzglę uwzględniać dniać zaró zarówno łatwość atwość nauki dla począ początkują tkujących jak i łatwość atwość uŜycia dla doś doświadczonych uŜytkownikó ytkowników. Spó Spójność jność – interfejs powinien być być spó spójny dla uł ułatwienia uŜ uŜytkownikowi przewidywania skutkó skutków podejmowanych przez niego dział działań. Minimalizacja wysił wysiłku – interfejs powinien uł ułatwiać atwiać dział działania uŜ uŜytkownika, tak by ilość ilość krokó kroków wiodą wiodących do osią osiągnię gnięcia celu był była jak najmniejsza. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika 7/32 Ŝ Podział Podział interfejsu na obszary Obszar nawigacji przeglądarki Obszar nawigacji strony Obszar nawigacji strony Obszar nawigacji strony Obszar statusu przeglądarki Obszar informacyjny strony Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika 8/32 Ŝ Proponowane obszary Obszar menu głównego Obszar przycisków sterujących Identyfikacja strony Nawigacja między stronami Nawigacja na stronie Nawigacja dodatkowa Nawigacja między sekcjami Treść główna Obszar statusu Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 9/32 3 Zasady podział podziału KaŜ KaŜdy obszar powinien mieć mieć jasno wytyczone granice. KaŜ Ŝ dy obszar powinien mieć Ka mieć jasno okreś określone przeznaczenie. KaŜ KaŜdy obszar powinien zawierać zawierać tylko te informacje, któ które są są potrzebne do realizacji okreś określonego przeznaczenia. Obszary informacyjne powinny być być uszeregowane w kolejnoś kolejności przetwarzania tej informacji przez uŜytkownika (z gó góry w dó dół, od lewej do prawej). Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 10/32 Uszeregowanie pionowe Dane klienta Imi ę Nazwisko Adres Miejscowo ś Kod poczt. ć 00-000 Ulica Nr domu Nr lokalu Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 11/32 Uszeregowanie poziome Dane klienta Imi Nazwisko ę Adres Miejscowo ś Ulica ć Kod poczt. 00-000 Nr domu Nr lokalu Układ poziomy ułatwia zastosowanie róŜnych języków! Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 12/32 4 Zasady uś uświadamiania zawartoś zawartości (1) Wszystkie okna i raporty muszą muszą mieć mieć tytuł tytuły jednoznacznie identyfikują identyfikujące ich zawartość zawartość.. Menu musi pokazywać pokazywać, w któ którym miejscu jest uŜytkownik (i jak się się tu dostał dostał). Przyciski powinny mieć mieć napisy identyfikują identyfikujące ich funkcje. Jeś Jeśli napisy te nie są są pokazywane cał cały czas na ekranie, to powinny być być pokazywane przy najechaniu na przycisk wskaź wskaźnikiem myszy. Przyciski odpowiedzi na oknach komunikató komunikatów powinny być być łatwo interpretowane w kontekś kontekście treś treści komunikatu. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 13/32 Zasady uś uświadamiania zawartoś zawartości (2) Forma informacji na są sąsiadują siadujących obszarach powinna być być róŜna (np. teksttekst-grafika, ró róŜne czcionki). Rozró RozróŜnianie kolorem nie jest wystarczają wystarczające. Jeś Jeśli informacje na są sąsiadują siadujących obszarach są są podobne w formie, to muszą muszą być być oddzielone dodatkowym elementem (np. linią linią). KaŜ KaŜe pole edycji musi mieć mieć etykietę etykietę jednoznacznie identyfikują identyfikującą zawartość zawartość pola. Pola edycji, któ których format wewnę wewnętrzny nie jest oczywisty (np. pola z datą datą), muszą muszą mieć mieć dodatkowe oznaczenie formatu wprowadzanych danych. Raporty powinny mieć mieć datę datę sporzą sporządzenia. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 14/32 Zasady estetyki (1) Interfejs uŜ uŜytkownika powinien być być zaró zarówno funkcjonalny jak i „przyjemny dla oka” oka”. Ilość Ilość wolnego miejsca pomię pomiędzy elementami interfejsu powinna być być dostosowana do wymagań wymagań uŜytkownika (50% dla począ początkują tkujących, 10% dla zaawansowanych). NaleŜ NaleŜy unikać unikać tworzenia formularzy lub raportó raportów duŜ duŜych, zawierają zawierających ponad 50 pó pól danych. Formularz lub raport powinien zawierać zawierać tylko informacje, któ które mogą mogą być być jednorazowo przetworzone przez czł człowieka. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 15/32 5 Zasady estetyki (2) Tekst gł główny powinien być być prezentowany czcionką czcionką 810 punktową punktową. Na formularzach powinna być być uŜywana czcionka bezszeryfowa, bezszeryfowa, na raportach – czcionka szeryfowa. szeryfowa. NaleŜ NaleŜy unikać unikać stosowania wię więcej niŜ niŜ dwó dwóch ró róŜnych czcionek. Stanowczo trzeba unikać unikać czcionek ozdobnych, lecz trudnych do czytania. Stosowane kolory powinny być być stonowane (kontrastowe zwracają zwracają uwagę uwagę, lecz są są męczą czące dla oka). Kolor nie moŜ moŜe być być jedynym wyró wyróŜnikiem informacji. Interfejs uŜ uŜytkownika nie moŜ moŜe ukrywać ukrywać informacji przed osobami cierpią cierpiącymi na daltonizm. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 16/32 Doś Doświadczenie uŜ uŜytkownika (1) Interfejs uŜ uŜytkownika powinien być być łatwy do nauczenia się się posł posługiwania się się nim przez począ początkują tkujących uŜ uŜytkownikó ytkowników. Interfejs uŜ uŜytkownika powinien uł ułatwiać atwiać i przyspieszać przyspieszać wykonywanie dział działań przez zaawansowanych uŜ uŜytkownikó ytkowników. Menu powinno skł składać adać się się nie wię więcej niŜ niŜ z trzech poziomó poziomów w przypadku menu gł głównego i nie wię więcej niŜ niŜ z dwó dwóch poziomó poziomów w przypadku menu kontekstowych. Menu powinno prezentować prezentować wszystkie dostę dostępne funkcje aplikacji, tzn. nie powinno być być takiej funkcji, do któ której nie moŜ moŜna by się się był było dostać dostać z menu. Menu na kaŜ kaŜdym poziomie powinno zawierać zawierać nie wię więcej niŜ niŜ kilka pozycji. W przypadku bardziej rozbudowanego menu wskazane jest, by pozycje menu był były logicznie pogrupowane oraz by częś ciej uŜ częściej uŜywane funkcje był były w pewien sposó sposób wyró wyróŜnione. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 17/32 Doś Doświadczenie uŜ uŜytkownika (2) Częś ciej wykorzystywane funkcje powinny być Częściej być dostę dostępne bezpoś bezpośrednio poprzez przyciski narzę narzędziowe. Przyciski narzę narzędziowe powinny mieć mieć obrazek kojarzą kojarzący się się z wykonywaną wykonywaną funkcją funkcją oraz nazwę nazwę funkcji. Jeś Jeśli nazwy funkcji na przyciskach nie mogą mogą być być pokazane, to powinny być być pokazywane przy najechaniu myszą myszą na przycisk. Przyciski powinny być być logicznie pogrupowane na paskach narzę narzędziowych. W przypadku aplikacji realizują realizującej liczne funkcje wskazane jest, aby umoŜ umoŜliwiał liwiała ona konfigurację konfigurację paskó pasków narzę narzędziowych, w tym umieszczanie na paskach przyciskó przycisków wiodą wiodącyc do wszystkich funkcji aplikacji, ró równieŜ wnieŜ tych rzadziej wykorzystywanych. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 18/32 6 Doś Doświadczenie uŜ uŜytkownika (3) Wskazane jest, aby bardziej zł złoŜona aplikacja prezentował prezentowała swoje moŜ moŜliwoś liwości za pomocą pomocą podpowiedzi. Jeś Jeśli podpowiedzi te zajmują zajmują istotnie duŜ duŜo miejsca na ekranie, to aplikacja powinna umoŜ czenie podpowiedzi i włą czenie ich ponownie na umoŜliwić liwić wyłą wyłączenie włączenie Ŝądanie. Ŝądanie. Aplikacja powinna umoŜ umoŜliwiać liwiać szybki dostę dostęp do funkcji za pomocą pomocą skró skrótów klawiszowych. W przypadku bardziej zł złoŜonej aplikacji wskazane jest zapewnienie moŜ moŜliwoś liwości definiowania własnych skró skrótów klawiszowych. Aplikacja powinna mieć mieć system pomocy ekranowej wyjaś wyjaśniają niającej podstawowe mechanizmy zastosowane w aplikacji i wyjaś wyjaśniają niającej sposó sposób wykorzystania tych mechanizmó mechanizmów. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 19/32 Spó Spójność jność Interfejs uŜ uŜytkownika powinien być być spó spójny dla zapewnienia przewidywalnoś przewidywalności podejmowanych dział działań przez uŜ uŜytkownika. Wszystkie formularze i raporty w aplikacji powinny być być zaprojektowane w jednolity sposó sposób, tzn. z uŜ uŜyciem jednolitego aparatu poję pojęciowego (terminologii) i z zastosowaniem jednolitej formy (takiego samego ukł układu, czcionek i koloró kolorów) oraz sposobu nawigacji. Interfejs uŜ uŜytkownika aplikacji powinien być być spó spójny z innymi aplikacjami z tej samej dziedziny zastosowania wykorzystywanymi w okreś określonym systemie operacyjnym. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 20/32 Minimalizacja wysił wysiłku Interfejs uŜ uŜytkownika powinien uł ułatwiać atwiać uŜytkownikowi wykorzystanie funkcji aplikacji tak, aby wysił wysiłek uŜ uŜytkownika był była jak najmniejszy. Zaleca się się, aby ilość ilość kliknięć kliknięć myszą myszą wiodą wiodących poprzez menu lub przyciski narzę narzędziowe do kaŜ kaŜdej funkcji nie przekraczał przekraczała trzech. W przypadku funkcji wielokrotnie wykorzystywanych zaleca się się zastosowanie mechanizmu powtarzania funkcji lub grupowania przedmiotó przedmiotów dział działania funkcji. W przypadku bardziej zł złoŜonych aplikacji zaleca się się zastosowanie mechanizmu umoŜ umoŜliwiają liwiającego łączenie łączenie wielu ró róŜnych funkcji w jedną jedną. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 21/32 7 Proces projektowania interfejsu uŜytkownika Opracowanie scenariuszy uŜycia Projektowanie struktury interfejsu Ocena interfejsu Prototypowanie projektu interfejsu Projektowanie Aplikacji Rozproszonych Projektowanie standardów interfejsu Projektowanie interfejsu u ytkownika Ŝ 22/32 Scenariusz uŜ uŜycia Scenariusz uŜ uŜycia jest opisem podstawowych krokó kroków, któ które musi przejść przejść uŜytkownik dla osią osiągnię gnięcia okreś określonego celu. Podstawa do opracowania: model przypadkó przypadków uŜycia, diagramy sekwencji (interakcji). Nie rozpatruje się się wszystkich moŜ moŜliwych scenariuszy uŜ ciej uŜycia, lecz dwa lub trzy najczęś najczęściej realizowane. Sposó Sposób prezentacji: opis tekstowy Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 23/32 Scenariusz uŜ uŜycia 1.Klient przeglą przeglądają dający ofertę ofertę 1. 2. 3. 4. 5. Klient przeglą przegląda ofertę ofertę szukają szukając interesują interesujących go towaró towarów w okreś określonej kategorii Klient przeglą przegląda podstawowe informacje dla kilku towaró towarów. Poró Porównuje informacje mię między sobą sobą łącznie łącznie z ofertą ofertą cenową cenową. Klient umieszcza wybrany towar (towary) w koszyku i dalej przeglą przegląda ofertę ofertę. Przed zł złoŜeniem zamó zamówienia klient przeglą przegląda koszyk dla zorientowania się się, czy łączna łączna kwota do zapł zapłaty jest do zaakceptowania. Ewentualnie klient usuwa pewne towary z koszyka. Klient skł składa zamó zamówienie wybierają wybierając formę formę płatnoś atności. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 24/32 8 Scenariusz uŜ uŜycia 2. Klient szukają szukający okreś określonego towaru 1. 2. 3. 4. Klient szuka okreś określonego towaru po nazwie lub typie. Klient oczekuje podania ceny i terminu dostawy. W przypadku niezadowolenia klient oczekuje innej oferty w tym samym typie. Klient skł składa zamó zamówienie lub przechodzi do innej witryny. Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika 25/32 Ŝ Struktura interfejsu Struktura interfejsu okreś określa podstawowe komponenty interfejsu i sposó sposób ich wspó współdział działania dla dostarczenia okreś określonej funkcjonalnoś funkcjonalności dla uŜ uŜytkownikó ytkowników. Sposó Sposób prezentacji: Window Navigation Diagram (WND) Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika 26/32 Ŝ Projekt nawigacji « window» Main Menu « window» Menu A « form» Form A Projektowanie Aplikacji Rozproszonych « window» Menu B zdarzenie / akcja « form» Form B « form» Form C Projektowanie interfejsu u ytkownika Ŝ « report» Report A 27/32 9 Prototypowanie interfejsu Storyboard Prototypowanie HTML Prototypowanie w ję języku docelowym Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika 28/32 Ŝ Storyboard Dane klienta Menu klienta Imi Nazwisko ę DodajKlienta Dodaj klienta Znajd klienta Lista klientów Adres Miejscowo Znajd Klienta ź ź ś Kod poczt. 00-000 ć Nr domu Nr lokalu Ulica DodajKlienta ListaKlientów Znajd klienta ź Imi Nazwisko ę Adres Miejscowo Znajd Klienta ś KlientZnaleziony Kod poczt. 00-000 ć PoprawDaneKlienta Nr domu Nr lokalu Ulica ź Lista klientów Abacki Adam Babacki Bartosz Cabacki Czesław Dane klienta ListaKlientów Imi Adam Znajd Klienta ź PodajDaneKlienta ListaKlientów Projektowanie Aplikacji Rozproszonych Nazwisko Abacki ę Adres Miejscowo Nieznane ś ć Ulica Zapole Kod poczt. 12-345 Nr domu Nr lokalu 13A 13 Projektowanie interfejsu u ytkownika Ŝ 29/32 Prototypowanie w HTML języku docelowym interaktywne szybkie w wykonaniu nie odpowiada obrazowi docelowemu Projektowanie Aplikacji Rozproszonych interaktywne wolniejsze odpowiada obrazowi docelowemu Projektowanie interfejsu u ytkownika Ŝ 30/32 10 Ocena interfejsu ocena heurystyczna ocena zgodnoś zgodności z zasadami min. 3 ekspertó ekspertów przeglą przegląd interfejsu z uŜ uŜytkownikiem ocena interaktywna u uŜ uŜytkownika formalne testowanie uŜ uŜytecznoś yteczności Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 31/32 Literatura Dennis A., Wixom B.H., Tegarden D., Systems Analysis & Design. An ObjectObject-Oriented Approach with UML, UML, John Wiley and Sons, Sons, USA, 2002 Rolf Hennicker, Hennicker, Nora Koch: Modeling the User Interface of Web Applications with UML, UML, http:// www.pst.informatik.uniwww.pst.informatik.uni-muenchen.de /personen/ personen/kochn/pUML2001 kochn/pUML2001--HenHen-Koch.pdf Coad P., Yourdon E.: Projektowanie obiektowe, obiektowe, Oficyna wydawnicza Read Me, Warszawa 1994 Projektowanie Aplikacji Rozproszonych Projektowanie interfejsu u ytkownika Ŝ 32/32 11