Projektowanie interfejsu użytkownika (2) Projektowanie nawigacji

1. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Projektowanie interfejsu użytkownika (2)Projektowanie nawigacji

2. 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)

3. 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)

4. 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)

5. 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)

6. 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)

7. 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)

8. 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)

9. 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)

10. 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)

11. 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)

12. 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)

13. Rodzaje komunikatów • Komunikaty błędów • Żądania potwierdzenia • Powiadomienia • Komunikaty o opóźnieniach • Objaśnienia • Podpowiedzi • Pomoc Projektowanie interfejsu użytkownika (2)

14. 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)

15. Żą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)

16. 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)

17. 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)

18. 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)

19. 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)

20. 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)

21. 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)

22. 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)

23. 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)

24. 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)

25. 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)

26. 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)

27. 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)