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

Podobne dokumenty