Transcript Projektowanie interfejsu użytkownika (1)

Jarosław Kuchta
Dokumentacja i Jakość Oprogramowania
Projektowanie interfejsu
użytkownika (1)
[email protected]
[email protected]
Charakterystyki użytkowników



Nazwa użytkownika
Cel korzystania z systemu
Klasyfikacja




Dodatkowe cechy




wiek
poziom wykształcenia
zastrzeżenia
Krytyczne czynniki powodzenia



przynależność organizacyjna
doświadczenie i umiejętności
uprawnienia decyzyjne
potrzeby i możliwości
preferencje i uprzedzenia
Scenariusze zadań
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
2/27
Podstawowe zasady projektowania
interfejsu użytkownika






Wygląd – interfejs powinien być podzielony na różne obszary przeznaczone
do różnych celów.
Uświadamianie zawartości – interfejs powinien uświadamiać użytkownika,
w którym miejscu się znajduje i co oznaczają prezentowane informacje.
Estetyka – interfejs powinien zapewniać równowagę pomiędzy ilością
prezentowanej informacji a jej atrakcyjnością wizualną.
Doświadczenie użytkownika – interfejs powinien uwzględniać zarówno
łatwość nauki dla początkujących jak i łatwość użycia dla doświadczonych
użytkowników.
Spójność – interfejs powinien być spójny dla ułatwienia użytkownikowi
przewidywania skutków podejmowanych przez niego działań.
Minimalizacja wysiłku – interfejs powinien ułatwiać działania użytkownika,
tak by ilość kroków wiodących do osiągnięcia celu była jak najmniejsza.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
3/27
Podział interfejsu na obszary
Obszar nawigacji
przeglądarki
Obszar nawigacji
strony
Obszar nawigacji
strony
Dokumentacja i Jakość
Oprogramowania
Obszar nawigacji
strony
Obszar informacyjny strony
Projektowanie interfejsu użytkownika (1)
Obszar statusu
przeglądarki
4/27
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ą potrzebne do realizacji określonego
przeznaczenia.
Obszary informacyjne powinny być uszeregowane w
kolejności przetwarzania tej informacji przez
użytkownika (z góry w dół, od lewej do prawej).
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
5/27
Zasady uświadamiania
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ą pokazywane cały czas na
ekranie, to powinny być pokazywane przy najechaniu
na przycisk wskaźnikem myszy.
Przyciski odpowiedzi na oknach komunikatów powinny
być łatwo interpretowane w kontekście treści
komunikatu.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
6/27
Zasady uświadamiania
zawartości (2)





Forma informacji na sąsiadujących obszarach powinna być różna
(np. tekst-grafika, różne czcionki). Rozróżnianie kolorem nie jest
wystarczające.
Jeśli informacje na sąsiadujących obszarach są podobne w
formie, to muszą być oddzielone dodatkowym elementem (np.
linią).
Każde 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.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
7/27
Zasady estetyki (1)



Interfejs użytkownika 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ących, 10% dla zaawansowanych).
Należy unikać tworzenia formularzy lub raportów
dużych, zawierających ponad 50 pól danych. Formularz
lub raport powinien zawierać tylko informacje, które
mogą być jednorazowo przetworzone przez człowieka.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
8/27
Zasady estetyki (2)




Tekst główny powinien być prezentowany czcionką 810 punktową. Na formularzach powinna być używana
czcionka bezszeryfowa, na raportach – czcionka
szeryfowa.
Należy unikać stosowania więcej niż dwóch różnych
czcionek. Stanowczo trzeba unikać czcionek
ozdobnych, lecz trudnych do czytania.
Stosowane kolory powinny być stonowane
(kontrastowe zwracają uwagę, lecz są męczące dla oka).
Kolor nie może być jedynym wyróżnikiem informacji.
Interfejs użytkownika nie może ukrywać informacji
przed osobami cierpiącymi na daltonizm.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
9/27
Doświadczenie użytkownika (1)





Interfejs użytkownika powinien być łatwy do nauczenia się
posługiwania się nim przez początkujących użytkowników.
Interfejs użytkownika powinien ułatwiać i przyspieszać
wykonywanie działań przez zaawansowanych użytkowników.
Menu powinno składać się nie więcej niż z trzech poziomów w
przypadku menu głównego 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 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 logicznie pogrupowane oraz by
częściej używane funkcje były w pewien sposób wyróżnione.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
10/27
Doświadczenie użytkownika (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ła ona konfigurację pasków narzędziowych, w tym
umieszczanie na paskach przycisków wiodących do wszystkich
funkcji aplikacji, również tych rzadziej wykorzystywanych.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
11/27
Doświadczenie użytkownika (3)



Wskazane jest, aby bardziej złożona aplikacja prezentowała
swoje możliwości za pomocą podpowiedzi. Jeśli podpowiedzi te
zajmują istotnie dużo miejsca na ekranie, to aplikacja powinna
umożliwić wyłączenie podpowiedzi i włączenie ich ponownie na
żądanie.
Aplikacja powinna umożliwiać szybki dostęp do funkcji za
pomocą skrótów klawiszowych. W przypadku bardziej złożonej
aplikacji wskazane jest zapewnienie możliwości definiowania
własnych skrótów klawiszowych.
Aplikacja powinna mieć system pomocy ekranowej wyjaśniającej
podstawowe mechanizmy zastosowane w aplikacji i wyjaśniającej
sposób wykorzystania tych mechanizmów.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
12/27
Spójność



Interfejs użytkownika powinien być spójny dla
zapewnienia przewidywalności podejmowanych działań
przez użytkownika.
Wszystkie formularze i raporty w aplikacji powinny być
zaprojektowane w jednolity sposób, tzn. z użyciem
jednolitego aparatu pojęciowego (terminologii) i z
zastosowaniem jednolitej formy (takiego samego
układu, czcionek i kolorów) oraz sposobu nawigacji.
Interfejs użytkownika aplikacji powinien być spójny z
innymi aplikacjami z tej samej dziedziny zastosowania
wykorzystywanymi w określonym systemie
operacyjnym.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
13/27
Minimalizacja wysiłku




Interfejs użytkownika powinien ułatwiać
użytkownikowi wykorzystanie funkcji aplikacji tak, aby
wysiłek użytkownika była jak najmniejszy.
Zaleca się, aby ilość kliknięć myszą wiodących poprzez
menu lub przyciski narzędziowe do każdej funkcji nie
przekraczała trzech.
W przypadku funkcji wielokrotnie wykorzystywanych
zaleca się zastosowanie mechanizmu powtarzania
funkcji lub grupowania przedmiotów działania funkcji.
W przypadku bardziej złożonych aplikacji zaleca się
zastosowanie mechanizmu umożliwiającego łączenie
wielu różnych funkcji w jedną.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
14/27
Proces projektowania interfejsu
użytkownika
Opracowanie
scenariuszy użycia
Projektowanie
struktury
interfejsu
Ocena
interfejsu
Prototypowanie
projektu
interfejsu
Dokumentacja i Jakość
Oprogramowania
Projektowanie
standardów
interfejsu
Projektowanie interfejsu użytkownika (1)
15/27
Scenariusz użycia




Scenariusz użycia jest opisem podstawowych
kroków, które musi przejść użytkownik dla
osią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, lecz dwa lub trzy najczęściej
realizowane.
Sposób prezentacji: opis tekstowy
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
16/27
Scenariusz użycia
1.Klient przeglądający ofertę
1.
2.
3.
4.
5.
Klient przegląda ofertę szukając interesujących go towarów w
określonej kategorii
Klient przegląda podstawowe informacje dla kilku towarów.
Porównuje informacje między sobą łącznie z ofertą cenową.
Klient umieszcza wybrany towar (towary) w koszyku i dalej
przegląda ofertę.
Przed złożeniem zamówienia klient przegląda koszyk dla
zorientowania się, czy łączna kwota do zapłaty jest do
zaakceptowania. Ewentualnie klient usuwa pewne towary z
koszyka.
Klient składa zamówienie wybierając formę płatności.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
17/27
Scenariusz użycia
2. Klient szukający określonego towaru
1.
2.
3.
4.
Klient szuka 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łada zamówienie lub przechodzi do
innej witryny.
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
18/27
Struktura interfejsu


Struktura interfejsu określa podstawowe
komponenty interfejsu i sposób ich
współdziałania dla dostarczenia określonej
funkcjonalności dla użytkowników.
Sposób prezentacji: Window Navigation
Diagram (WND)
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
19/27
Window Navigation Diagram
(WND)
« window»
Main Menu
« window»
Menu A
« form»
Form A
Dokumentacja i Jakość
Oprogramowania
« window»
Menu B
« form»
Form B
« form»
Form C
Projektowanie interfejsu użytkownika (1)
« report»
Report A
20/27
Standardy interfejsu (1)



Standardy interfejsu są do podstawowe elementy
projektowe, które są wspólne dla wielu ekranów,
formularzy i raportów w systemie.
Tworzy się repozytorium elementów, które będą
wykorzystywane przy prototypowaniu i
projektowaniu interfejsu
Ustala się nazwy elementów, ich znaczenie i
formę (nazwę prezentowaną dla użytkownika,
ikonę)
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
21/27
Standardy interfejsu (2)





Metafory interfejsu (np. koszyk na zakupy)
Obiekty interfejsowe - klasy głównych komponentów
interfejsu (np. Formularz zamówienia)
Akcje interfejsowe - działania wiodące użytkownika
przez interfejs (np. Zamówienie-nowe, Zamówieniezmiana, Zamówienie-anuluj)
Ikony interfejsowe (zgodność ze standardami,
czytelność, zrozumiałość)
Szablony interfejsowe - wygląd głównych okien,
formularzy, raportów
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
22/27
Prototypowanie interfejsu



Storyboard
Prototypowanie HTML
Prototypowanie w języku docelowym
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
23/27
Storyboard
Dane klienta
Menu klienta
Imię
Nazwisko
DodajKlienta
Dodaj klienta
Znajdź klienta
Lista klientów
Adres
Miejscowość
ZnajdźKlienta
Ulica
Kod
poczt.
00-000
Nr domu Nr lokalu
DodajKlienta
ListaKlientów
Znajdź klienta
Imię
Nazwisko
Adres
Miejscowość
ZnajdźKlienta
Ulica
KlientZnaleziony
Kod
poczt.
00-000
Nr domu Nr lokalu
Lista klientów
Abacki Adam
Babacki Bartosz
Cabacki Czesław
Dane klienta
ListaKlientów
Imię
Adam
ZnajdźKlienta
PodajDaneKlienta
ListaKlientów
Dokumentacja i Jakość
Oprogramowania
PoprawDaneKlienta
Nazwisko
Abacki
Adres
Miejscowość
Nieznane
Kod
poczt.
12-345
Ulica
Zapole
Nr domu Nr lokalu
13A
13
Projektowanie interfejsu użytkownika (1)
24/27
Prototypowanie w

HTML




interaktywne
szybkie w wykonaniu
nie odpowiada obrazowi
docelowemu
Dokumentacja i Jakość
Oprogramowania
języku docelowym



interaktywne
wolniejsze
odpowiada obrazowi
docelowemu
Projektowanie interfejsu użytkownika (1)
25/27
Ocena interfejsu

ocena heurystyczna
ocena zgodności z zasadami
 min. 3 ekspertów




przegląd interfejsu z użytkownikiem
ocena interaktywna u użytkownika
formalne testowanie użyteczności
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
26/27
Literatura



Dennis A., Wixom B.H., Tegarden D., Systems
Analysis & Design. An Object-Oriented Approach
with UML, John Wiley and Sons, USA, 2002
Rolf Hennicker, Nora Koch: Modeling the User
Interface of Web Applications with UML, http://
www.pst.informatik.uni-muenchen.de
/personen/kochn/pUML2001-Hen-Koch.pdf
Coad P., Yourdon E.: Projektowanie obiektowe,
Oficyna wydawnicza Read Me, Warszawa 1994
Dokumentacja i Jakość
Oprogramowania
Projektowanie interfejsu użytkownika (1)
27/27