• 270 likes • 460 Views
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Projektowanie interfejsu użytkownika (2) Projektowanie nawigacji. Projektowanie nawigacji - podstawowe zasady. Zapobieganie błędom odpowiednie oznaczanie komend i akcji ograniczanie wyboru
E N D
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Projektowanie interfejsu użytkownika (2)Projektowanie nawigacji
Projektowanie nawigacji - podstawowe zasady • Zapobieganie błędom • odpowiednie oznaczanie komend i akcji • ograniczanie wyboru • nie udostępnianie komend, które nie mogą być wydane • żądanie potwierdzenia przed wykonaniem operacji, które nie mogą być cofnięte • Ułatwienie odtworzenia stanu po błędzie • Komenda undo/redo - ile poziomów • Użycie jednolitego porządku gramatycznego • porządek obiekt-akcja • porządek akcja-obiekt Projektowanie interfejsu użytkownika (2)
Projektowanie nawigacji - rodzaje sterowania • Język komend (np. DOS, SQL) • duża elastyczność • konieczność nauczenia się składni • duża podatność na błędy • odmiana - język naturalny (np. asystent MS Office) • Menu • raczej szerokie i płytkie niż wąskie i głębokie • psychologiczne ograniczenie liczby komend (do 8) • skróty klawiszowe • grupowanie wg elementów (Plik, Tabela, Okno) i akcji interfejsowych (Edycja, Wstaw, Format) • Bezpośrednia manipulacja • nie wszyskie operacje są intuicyjne • różne odmiany operacji przez klawisze kontrolne Projektowanie interfejsu użytkownika (2)
Typy menu • Pasek menu (menu bar) - menu główne • Menu opuszczane (drop-down menu) • Menu wyskakujące (pop-up menu) - menu lokalne • Menu zakładkowe (tab menu) • Przyciski (push buttons) • Pasek przycisków (tool bar) • Mapa interaktywna (image map) Projektowanie interfejsu użytkownika (2)
Pasek menu (menu bar) • Główne menu aplikacji - lista komend na górze ekranu, zawsze pokazywana, • Zalecana taka sama organizacja jak w innych aplikacjach dla tego samego systemu operacyjnego • Elementy menu - zawsze jedno słowo • Elementy menu prowadzą zawsze do menu opuszczanych, nigdy nie wykonują operacji Projektowanie interfejsu użytkownika (2)
Menu opuszczane (drop-down menu) • Stosowane jako menu drugiego poziomu pod menu głównym lub z menu lokalnego - lista komend umieszczonych jedna pod drugą • Elementy menu mają nazwy często składające się z 2, 3 słów • Grupować logicznie po kilka komend na liście • Elementy menu prowadzą do innych menu, do dialogów lub do wykonania komendy Projektowanie interfejsu użytkownika (2)
Menu wyskakujące(pop-up menu) • Menu lokalne, pojawia się po kliknięciu myszą, zależy od miejsca kliknięcia, znika po wyborze • Raczej dla doświadczonych użytkowników • Duplikuje komendy z menu głównego • Zawiera tylko komendy odnoszące się do wybranego elementu na ekranie Projektowanie interfejsu użytkownika (2)
Menu zakładkowe(tab menu) • Stosowane w układzie wielostronicowym, przełącza całą zawartość okna lub ramki • Elementy menu muszą być krótkie tak, by wszystkie zakładki zmieściły się w jednym wierszu (maks. 2 wiersze) Projektowanie interfejsu użytkownika (2)
Przyciski(push buttons) • Grupa do kilku przycisków umieszczonych w uporządkowany sposób (w jednym rzędzie lub jednej kolumnie), stosowana w oknach dialogowych • Krótkie nazwy elementów menu • Stosuje się dodatkowe ikony ułatwiające lokalizację i zrozumienie znaczenia przycisku • Rzadko stosuje się same ikony • Elementy menu wiodą do innego dialogu lub do wykonania operacji Projektowanie interfejsu użytkownika (2)
Pasek przycisków(tool bar) • Grupa wielu małych przycisków tego samego kształtu umieszczonych jeden obok drugiego lub jeden nad drugim, cały czas widoczna na ekranie • Elementy menu najczęściej oznaczane tylko ikoną - wówczas objaśnienie pojawia się przy najechaniu myszą. • Stosować intuicyjnie zrozumiałe i łatwe do zapamiętania ikony. • Grupować przyciski. • Przyciski wiodą do dialogów lub do wykonania operacji (często stosowane). Projektowanie interfejsu użytkownika (2)
Mapa interaktywna(image map) • Obraz graficzny, którego pewne obszary są przypisane do komend lub innych menu. • Stosować tylko wówczas, gdy obraz dodaje znaczenia dla menu • Obraz powinien pokazywać, które jego fragmenty są interaktywne • Stosować objaśnienia przy najechaniu myszą. Projektowanie interfejsu użytkownika (2)
Komunikaty • Powinny być jasne, zwięzłe i kompletne (sprzeczne wymagania) • Powinny być gramatycznie poprawne i wolne od żargonu i skrótów (tłumaczenia) • Pytania powinny być pozytywne, a nie negatywne, np.: • "Czy na pewno nie chcesz kontynuować?" (tak/nie) • "Czy na pewno chcesz przerwać operację?" (tak/nie) Projektowanie interfejsu użytkownika (2)
Rodzaje komunikatów • Komunikaty błędów • Żądania potwierdzenia • Powiadomienia • Komunikaty o opóźnieniach • Objaśnienia • Podpowiedzi • Pomoc Projektowanie interfejsu użytkownika (2)
Komunikaty błędów • Informują użytkownika o tym, że próbował wykonać nieprawidłową operację • Zawsze wyjaśniać powód wystąpienia błędu • Sugerować poprawny sposób postępowania Projektowanie interfejsu użytkownika (2)
Żądania potwierdzenia • Wyświetlane wówczas, gdy dalsze wykonywanie operacji wymaga potwierdzenia użytkownika (np. operacja nie może zostać cofnięta) • Zawsze wyjaśniać powód komunikatu • Odpowiedzi OK/Cancel, gdy istnieje zalecany sposób postępowania • Odpowiedzi Tak/Nie, gdy obie odpowiedzi są równoprawne • Unikać mieszania Tak/Nie - OK/Cancel Projektowanie interfejsu użytkownika (2)
Powiadomienia • Wyświetlane wówczas, gdy żądana operacja została zakończona • Rzadko stosowane, raczej do długo trwających operacji • Zalecana możliwość wyłączenia takiego komunikatu Projektowanie interfejsu użytkownika (2)
Komunikaty o opóźnieniach • Wyświetlane wówczas, gdy żądana operacja jest długotrwała (więcej niż 7 sekund) • Najczęściej w formie ikony klepsydry (zmiana wskaźnika myszy) lub paska postępu • Wskazana możliwość przerwania długotrwałej operacji Projektowanie interfejsu użytkownika (2)
Objaśnienia • Krótkie komunikaty wyjaśniające działanie elemenu menu, pojawiające się przy najechaniu na dany element myszą • Muszą być krótkie (2-3 wyrazy), by użytkownik zdążył je przeczytać Projektowanie interfejsu użytkownika (2)
Podpowiedzi • Komunikaty wyświetlane przy stosowaniu języka komend, podpowiadające poprawne możliwości składniowe • Muszą być zgodne ze składnią języka komend • Muszą pokazywać jedynie poprawne możliwości • Mogą zawierać jedynie kilka możliwości Projektowanie interfejsu użytkownika (2)
Pomoc • Dodatkowa informacja wyjaśniajaca znaczenie poszczególnych komponentów systemu i sposób ich użycia • Powinna być w każdym systemie • Powinna być zorganizowana poprzez spis treści i indeks lub wyszukiwanie słów kluczowych • Powinna być wrażliwa na kontekst wywołania Projektowanie interfejsu użytkownika (2)
Przykłady komunikatów (1) Błąd w numerze telefonu Podaj poprawny numer telefonu. Numer telefonu jest błędny. OK Cancel Sugerowanie poprawnej akcji przed stwierdzeniembłędu może wprowadzać użytkownika w zakłopotanie Projektowanie interfejsu użytkownika (2)
Przykłady komunikatów (2) Błąd w numerze telefonu Numer telefonu jest błędny. Podaj poprawny numer telefonu. OK Cancel Stwierdzenie błędu powinno poprzedzaćsugerowanie poprawnej akcji Projektowanie interfejsu użytkownika (2)
Przykłady komunikatów (3) Błąd w numerze telefonu Numer kierunkowy jest błędny. Podaj poprawny numer kierunkowy. OK Cancel Problem powinien zostać objaśniony tak szczegółowo,jak to jest tylko możliwe Projektowanie interfejsu użytkownika (2)
Przykłady komunikatów (4) Błąd w numerze telefonu Nie rozpoznano numeru kierunkowego. Proszę podaj inny numer kierunkowy. OK Cancel Komunikat powinien być uprzejmy Projektowanie interfejsu użytkownika (2)
Przykłady komunikatów (5) Błąd w numerze telefonu (1234) Nie rozpoznano numeru kierunkowego. Proszę podaj inny numer kierunkowy. OK Cancel Podanie numeru błędu ułatwia odnalezienie wyjaśnienia w pomocy Projektowanie interfejsu użytkownika (2)
Dokumentacja projektu nawigacji • Diagramy nawigacji okien (WND) • Rzeczywiste przypadki użycia • Przypadki użycia definiowane w analizie są wystarczające dla zrozumienia wymaganej funkcjonalności • Rzeczywiste przypadki użycia pokazują kroki, jakie użytkownik przechodzi w kontakcie z systemem • Wymaganie - wszystkie zdarzenia muszą być opisane w terminologii interfejsu użytkownika. Projektowanie interfejsu użytkownika (2)
Literatura • Dennis A., Wixom B.H., Tegarden D., Systems Analysis & Design. An Object-Oriented Approach with UML, John Wiley and Sons, USA, 2002 Projektowanie interfejsu użytkownika (2)