©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 1 Projektowanie interfejsu użytkownika l Przedstawienie pewnych aspektów projektowania interfejsu użytkownika, które są istotne dla inżynierów oprogramowania

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 2 Cele l Znać uniwersalne zasady projektowania, które powinni uwzględniać inżynierowie odpowiedzialni za projekt interfejsu użytkownika; l Rozpoznawać pięć różnych sposobów interakcji z systemem oprogramowania; l Znać różne sposoby przetwarzania informacji i wiedzieć, kiedy prezentacja graficzna jest właściwa; l Rozumieć pewne podstawowe zasady projektowania wbudowanej w system pomocy dla użytkownika; l Znać atrybuty użyteczności i proste podejścia do oceny interfejsu systemu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 3 Zawartość l Zasady projektowania interfejsu użytkownika l Interakcja z użytkownikiem l Prezentacja informacji l Pomoc dla użytkownika l Ocena interfejsu

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 4 Interfejs użytkownika l Dobry projekt interfejsu użytkownika jest niezbędnym warunkiem prowadzenia systemu. l Interfejs trudny w użyciu w najlepszym wypadku doprowadzi do wielu pomyłek użytkowników. l W najgorszym wypadku użytkownicy po prostu odmówią używania systemu oprogramowania niezależnie od jego funkcjonalności. l Jeśli informacja jest przedstawiona w sposób zagmatwany i mylący, użytkownicy muszą źle rozumieć znaczenie systemu. l Mogą wykonać ciągi poleceń, które uszkodzą dane lub doprowadzą do awarii systemu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 5 Graficzny interfejs użytkownika l Obecnie niemal wszyscy użytkownicy komputerów mają komputer osobisty, który oferuje interfejs graficzny użytkownika (GUI) obsługujący kolorowy ekran o dużej rozdzielczości i interakcje za pomocą myszy i klawiatury.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 6 Właściwości interfejsu graficznego użytkownika WłaściwościOpis OknaWiele okien umożliwia jednoczesne wyświetlanie różnych informacji na ekranie użytkownika. IkonyIkony reprezentują różne rodzaje informacji. W niektórych systemach odpowiadają plikom, a w innych – procesom. MenuPolecenie wybiera się z menu, a nie wpisuje w postaci instrukcji języka poleceń. WskazywanieUrządzenie do wskazywania, takie jak mysz, służą do wyboru z menu i wskazywania potrzebnych elementów w oknie. GrafikaElementy graficzne można połączyć z tekstowymi na tym samym ekranie

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 7 Zalety GUI l Są dość łatwe do nauczenia się i do użytkowania. Użytkownicy bez doświadczeń z komputerami mogą nauczyć się używania interfejsu w ciągu krótkiego szkolenia. l Użytkownik ma kilka ekranów (okien) do interakcji z systemem. Można przejść od jednego zadania do innego bez utraty oglądu informacji przygotowanej w trakcie pierwszego zadania. l Szybka interakcja za pomocą pełnego ekranu daje dostęp do każdego miejsca na ekranie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 8 Projektowanie interfejsu użytkownika l Projektanci oprogramowania i programiści są zwykle kompetentnymi użytkownikami technologii, takich jak klasy biblioteki Swing w Javie albo HTML, które są podstawą implementacji interfejsu użytkownika. l Zbyt rzadko jednak korzystają z tej technologii właściwie i tworzą nieeleganckie, nieodpowiednie i trudne w obsłudze interfejsy użytkownika.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 9 Proces projektowania interfejsu użytkownika Opracuj papierowy prototyp projektu Opracuj papierowy prototyp projektu Zanalizuj i rozpoznaj czynności użytkownika Zanalizuj i rozpoznaj czynności użytkownika Zaimplementuj docelowy interfejs użytkownika Zaimplementuj docelowy interfejs użytkownika Zbuduj dynamiczny prototyp obiektu Zbuduj dynamiczny prototyp obiektu Oceń projekt z użytkownikami Oceń projekt z użytkownikami Zaprojektuj prototyp Zaprojektuj prototyp Wykonywalny prototyp Wykonywalny prototyp Oceń projekt z użytkownikami

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 10 Zasady projektowania interfejsu użytkownika l Projektanci interfejsu użytkownika muszą brać pod uwagę psychiczne i umysłowe zdolności osób używających oprogramowania. l Ludzie mają ograniczoną pamięć krótką i robią błędy zwłaszcza wówczas, gdy muszą obsłużyć dużą ilość informacji lub są pod presją. l Mają różne możliwości psychiczne. l Projektując interfejsy użytkownika, trzeba to wszystko wziąć pod uwagę.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 11 Zasady projektowania interfejsu użytkownika ZasadaOpis Zbliżenie doInterfejs powinien posługiwać się pojęciami i kategoriami wziętymi z użytkownikadoświadczeń osób, które najczęściej będą korzystać z systemu. SpójnośćInterfejs powinien być spójny, tzn. tam, gdzie to jest możliwe, podobne operacje powinny być wykonywane w ten sam sposób. Minimum Użytkownicy nie powinni być zaskakiwani zachowaniem systemu. Niespodzianek MożliwośćInterfejs powinien obejmować mechanizmy, które umożliwiają wycofaniaużytkownikom wycofanie się z błędów. Porady dlaInterfejs powinien przekazywać znaczące informacje zwrotne, gdy użytkownikadochodzi do błędów. Powinien też oferować pomoc, której treść zależy od kontekstu. Rozróżnianieinterfejs powinien oferować udogodnienia do interakcji dostosowane użytkownikówdo różnych rodzajów użytkowników systemu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 12 Omówienie zasad l Z zasady zbliżenia do użytkownika wynika, że użytkownicy nie powinni być zmuszani do adaptowania się do interfejsu, gdyż tak łatwiej jest go zaimplementować. Interfejs powinien posługiwać się kategoriami znanymi użytkownikowi, a obiekty przetwarzane przez system powinny być bezpośrednio związane ze środowiskiem użytkownika. l Zasada spójności interfejsu użytkownika oznacza, że polecenia systemu i menu powinny mieć ten sam format. Parametry poleceń powinny być zawsze przekazywane w ten sam sposób, a przestankowanie poleceń powinno być zawsze takie samo. Spójne interfejsy zmniejszają czas nauki. l Spójność interfejsu w ramach grupy podsystemów jest równie istotna. Jeśli jest to możliwe, w różnych podsystemach polecenia o podobnym znaczeniu powinny być wyrażane w ten sam sposób. Błędy często wynikają z przypisania tym samym kombinacjom klawiszy, takim jak „ctrl-b”, różnych znaczeń w innych podsystemach.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 13 Omówienie zasad Ten poziom spójności nosi nazwę spójności niskiego poziomu. Projektanci interfejsów zawsze powinni starać się go osiągnąć. Czasem jest również potrzebna spójność wyższego poziomu. Może zajść konieczność zapewnienia tych samych operacji (drukowania, kopiowania itd.) na wszystkich rodzajach bytów systemowych. Zasada minimum niespodzianek jest właściwa, ponieważ użytkownicy irytują się, gdy system działa w nieoczekiwany sposób. Zasada możliwości wycofywania jest istotna, ponieważ użytkownicy nie uchronią się przed błędami przy korzystaniu z systemu. Projektant interfejsu powinien minimalizować wystąpienia błędów.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 14 Interakcja z użytkownikiem l Projektant komputerowego interfejsu użytkownika ma do czynienia z dwoma zasadniczymi zagadnieniami: Jak systemowi komputerowemu dostarczyć informacje od użytkownika? Jak przedstawić użytkownikowi informacje od systemu komputerowego? l Spójny interfejs użytkownika musi integrować interakcję użytkownika i prezentację informacji.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 15 Rodzaje interakcji l Działanie bezpośrednie. l Wybór z menu. l Wypełnianie formularza. l Język poleceń. l Język naturalny.

Wady i zalety sposobów interakcji Sposób Główne zalety Główne wady Przykład zastosowań Interakcji BezpośrednieSzybka i intuicyjna Może być trudna do Gry wideo działanieinterakcja implementacji Systemy CAD Łatwe do nauczenia Odpowiednie jedynie wówczas, gdy istnieje graficzne wyobrażenie czynności i obiektów Wybór z menuUmożliwia uniknięcie Zbyt powolny dla doświadczonych Większość błędów użytkownika użytkownikówsystemów ogólnego Wymaga mało pisania Może być skomplikowany, gdy opcji menu jest dużo WypełnianieProste wprowadzenie Zajmuje duży obszar ekranu Zarządzanie magazynem formularzadanych Przetwarzanie kredytów Łatwe do nauczenia dla ludności Język poleceńSolidny i elastyczny Trudny do nauczenia Systemy operacyjne Małe możliwości obsługi Systemy wydobywania błędów informacji bibliotecznych Język naturalnyDostępny dla przypa- Wymaga więcej pisania Systemy rozkładów jazdy dkowych użytkowników Systemy rozpoznające Systemy określania Łatwy do rozszerzenia język naturalny są zawodne informacji WWW

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 17 Direct manipulation advantages l Users feel in control of the computer and are less likely to be intimidated by it l User learning time is relatively short l Users get immediate feedback on their actions so mistakes can be quickly detected and corrected

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 18 Direct manipulation problems l The derivation of an appropriate information space model can be very difficult l Given that users have a large information space, what facilities for navigating around that space should be provided? l Direct manipulation interfaces can be complex to program and make heavy demands on the computer system

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 19 Control panel interface

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 20 Menu systems l Users make a selection from a list of possibilities presented to them by the system l The selection may be made by pointing and clicking with a mouse, using cursor keys or by typing the name of the selection l May make use of simple-to-use terminals such as touchscreens

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 21 Advantages of menu systems l Users need not remember command names as they are always presented with a list of valid commands l Typing effort is minimal l User errors are trapped by the interface l Context-dependent help can be provided. The user’s context is indicated by the current menu selection

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 22 Problems with menu systems l Actions which involve logical conjunction (and) or disjunction (or) are awkward to represent l Menu systems are best suited to presenting a small number of choices. If there are many choices, some menu structuring facility must be used l Experienced users find menus slower than command language

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 23 Form-based interface

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 24 Command interfaces l User types commands to give instructions to the system e.g. UNIX l May be implemented using cheap terminals. l Easy to process using compiler techniques l Commands of arbitrary complexity can be created by command combination l Concise interfaces requiring minimal typing can be created

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 25 Problems with command interfaces l Users have to learn and remember a command language. Command interfaces are therefore unsuitable for occasional users l Users make errors in command. An error detection and recovery system is required l System interaction is through a keyboard so typing ability is required

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 26 Command languages l Often preferred by experienced users because they allow for faster interaction with the system l Not suitable for casual or inexperienced users l May be provided as an alternative to menu commands (keyboard shortcuts). In some cases, a command language interface and a menu-based interface are supported at the same time

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 27 Natural language interfaces l The user types a command in a natural language. Generally, the vocabulary is limited and these systems are confined to specific application domains (e.g. timetable enquiries) l NL processing technology is now good enough to make these interfaces effective for casual users but experienced users find that they require too much typing

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 28 Różne interfejsy użytkownika System operacyjny Graficzny interfejs użytkownika Graficzny interfejs użytkownika Interfejs języka poleceń Interfejs języka poleceń Menedżer GUI Interpreter języka poleceń Interpreter języka poleceń

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 29 Prezentacja informacji l Wszystkie systemy interakcyjne muszą zapewniać sposoby przedstawiania informacji użytkownikom. l Prezentacja informacji może być po prostu bezpośrednim uwidocznieniem danych wejściowych (np. tekstu w procesorze tekstu) lub mieć formę graficzną. l Dobrą praktyką programistyczną jest oddzielenie oprogramowania do prezentacji informacji od samej informacji.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 30 Prezentacja informacji Informacja do wyświetlenia Oprogramowanie prezentacyjne Ekran

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 31 Model MCV interakcji z użytkownikem Stan widoku Metody widoku Stan modelu Metody modelu Stan koordynatora Metody koordynatora Komunikaty o modyfikacji widoku Działania użytkownika Modyfikacje modelu Zapytania i aktualizacje modelu

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 32 Informacje statyczne i dynamiczne l Informacja, która nie zmienia się w trakcie sesji, może być przedstawiona zarówno graficznie, jak i tekstowo. l Prezentacja tekstowa zajmuje mniejszy obszar ekranu, ale nie może być czytana „na pierwszy rzut oka”. l Informacja, która się nie zmienia, powinna być odróżniona od informacji dynamicznej za pomocą innego stylu wyświetlania. l Wszystkie statyczne informacje mogą być wyświetlane na przykład za pomocą jednej czcionki lub uwydatnione za pomocą ustalonego koloru. l Mogą być też zawsze skojarzone z tą samą ikoną.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 33 Sposoby prezentacji informacji l Czy użytkownik potrzebuje dokładnej informacji, czy tylko związków między różnymi wartościami danych? l Jak szybko zmienia się ta informacja? Czy użytkownik musi natychmiast widzieć te zmiany? l Czy użytkownik musi wykonywać pewne działania w odpowiedzi na zmianę informacji? l Czy użytkownik ma oddziaływać na wyświetlaną informację przez interfejs bezpośredniego działania? l Czy wyświetlana informacja jest tekstowa, czy numeryczna? Czy wartości względne są ważne?

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 34 Różne prezentacje informacji Styczeń Luty Marzec Kwiecień Maj Czerwiec Styczeń Luty Marzec Kwiecień Maj Czerwiec Styczeń Luty Marzec Kwiecień Maj Czerwiec

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 35 Tekst czy grafika? l Prezentacja tekstowa zajmuje mniej miejsca niż graficzna. l Dynamicznie zmieniające się informacje numeryczne najlepiej uwidacznia się za pomocą prezentacji graficznej. l Ustawicznie zmieniające się wyświetlacze cyfrowe są mylące, ponieważ szybkie przyswajanie dokładnych informacji jest trudne. l Ciągłe wyświetlacze analogowe umożliwiają zaobserwowanie wartości względnych. l Gdy przedstawia się dokładna informację alfanumeryczną, grafika może służyć do wydobycia danych ukrytych w tle. l Graficzne uwydatnianie może również służyć do zwrócenia uwagi użytkownika na zmiany we fragmentach obrazu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 36 Metody prezentacji dynamicznie zmieniającej się informacji numerycznej Zegar ze wskazówką Diagram kołowy Termometr Pasek poziomy

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 37 Graficzne wyświetlanie danych pokazujące wartości względne Ciśnienie Temperatura

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 38 Tekstowe uwydatnianie informacji alfanumerycznej ! Wybrana przez Ciebie nazwa pliku Jest już używana. Wybierz inną. R. 15 Projektowanie interfejsu użytkownika OKAnuluj

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 39 Przykłady prezentacji graficznych l Informacje meteorologiczne zebrane z kilku źródeł przedstawione na mapie pogody za pomocą izobar i frontów atmosferycznych. l Stan sieci telefonicznej przedstawiony graficznie jako zbiór połączonych węzłów na tablicy w centrum sterowania siecią. l Stan reaktora chemicznego przedstawionego graficznie uwidoczniony jako ciśnienia i temperatury w zbiorze połączonych zbiorników i rur. l Model cząsteczki uwidoczniony i zmieniany w trzech wymiarach za pomocą systemu rzeczywistości wirtualnej. l Zbiór witryn WWW wyświetlony w postaci drzewa hiperbolicznego (Lamping i inni, 1995).

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 40 Kolor w projekcie interfejsu l Za pomocą kolorów można ulepszyć interfejs, pomagając użytkownikom w zrozumieniu i panowaniu nad złożonością. l Łatwo jest jednak nadużyć barw i stworzyć interfejsy użytkownika nieatrakcyjne graficznie i powodujące błędy. l Projektanci interfejsu powinni przyjąć ogólną zasadę, że kolory należy stosować ostrożnie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 41 Jak należy korzystać z kolorów w interfejsach użytkownika? l Ogranicz liczbę stosowanych kolorów i używaj ich ostrożnie. l Zmiany kolorów używaj do oznaczenia zmiany stanu systemu. l Skorzystaj z kodu kolorów, który pomoże użytkownikowi w realizacji zadań. l Korzystaj z kodu kolorów spójnie i rozsądnie. l Uważaj na związki między kolorami.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 42 Pomoc dla użytkownika l Komunikaty generowane przez system w odpowiedzi na działania użytkownika. l System pomocy natychmiastowej. l Dokumentacja dostępna w systemie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 43 Help and message system

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 44 Komunikaty o błędach l Pierwsze wrażenie użytkownika w kontaktach z systemem zależy od komunikatów o błędach systemowych. l Niedoświadczeni użytkownicy rozpoczynają pracę, popełniają błąd i natychmiast muszą zrozumieć komunikat o błędzie. l Projektując komunikaty o błędach należy przewidzieć doświadczenie i przeszłość użytkowników.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 45 Zagadnienia projektowe związane z redakcją komunikatów ZagadnienieOpis KontekstSystem wspomagania użytkownika powinien brać pod uwagę aktualne działania użytkownika i dostosować swoje komunikaty do bieżącego kontekstu. DoświadczenieW miarę zapoznawania się użytkownika z systemem, może on irytować się zbyt długimi „znaczącymi” komunikatami. Początkujący użytkownicy mają jednak trudności ze zrozumieniem krótkich i zwięzłych określeń problemów. System wspomagania użytkownika powinien więc móc wyświetlać oba rodzaje komunikatów, zależnie od stopnia świadomości użytkownika. UmiejętnościKomunikaty powinny być dostosowane do umiejętności użytkownika oraz jego doświadczenia. Komunikaty dla różnych grup użytkowników można wyrazić na różne sposoby zależnie od znanej im terminologii. StylKomunikaty powinny być pozytywne, a nie negatywne. Nigdy nie powinny być złośliwe ani żartobliwe. KulturaO ile możliwe, projektant komunikatów powinien znać kulturę kraju, w którym system będzie sprzedawany. Między Europą, Azją i Ameryką występują rozmaite różnice kulturowe. Komunikat właściwy w jednym kraju może być nie do zaakceptowania w innym.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 46 Ekran do wprowadzania nazwiska pacjenta przez pielęgniarkę Wpisz nazwisko pacjenta i naciśnij OK Kowalski J. OKAnuluj Nazwisko pacjenta

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 47 Komunikaty o błędach napisane w kategoriach systemu i użytkownika ? ? Błąd nr 27 Wprowadzono niewłaściwy Identyfikator pacjenta Błąd nr 27 Wprowadzono niewłaściwy Identyfikator pacjenta OKAnuluj PacjenciPomocPowtórzAnuluj Pacjent Kowalski J. nie jest zarejestrowany Naciśnij przycisk Pacjenci, aby zobaczyć listę zarejestrowanych pacjentów. Naciśnij przycisk Powtórz, aby ponownie wprowadzić nazwisko pacjenta Naciśnij przycisk Pomoc, aby otrzymać więcej informacji Komunikat o błędzieKomunikat będzie zapisany zapisany w kategoriach systemuw kategoriach użytkownika

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 48 Projektowanie systemu pomocy l Gdy użytkownicy otrzymują komunikat o błędzie, którego nie rozumieją, odwołują się do systemu pomocy w poszukiwaniu informacji. Jest to przykład wołanie „Pomóżcie!”, oznaczającego „Pomocy, jestem w kłopotach!”. l Innym rodzajem prośby o pomoc jest pytanie „Pomożecie?”, oznaczające „Potrzebuję informacji”. l Systemy pomocy powinny mieć kilka różnych punktów wejściowych.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 49 Teksty systemu pomocy l Powinny być przygotowane z udziałem specjalistów w dziedzinie zastosowania. l Temat pomocy nie powinien być prostym odwzorowaniem podręcznika użytkownika, ponieważ ludzie inaczej czytają ekran niż kartki papieru. l Tekst, jego układ i style powinny być starannie oznakowane, aby można je było czytać w dość małym oknie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 50 Systemy pomocy l Można implementować jako zbiór powiązanych witryn WWW lub za pomocą uniwersalnego systemu hipertekstowego, który można integrować z programami użytkowymi. l Hierarchię można łatwo przemierzać, wybierając części komunikatu oznaczone jako odsyłacze. l Zaletą systemu WWW jest łatwość implementacji i brak wymagania jakiegokolwiek specjalnego oprogramowania.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 51 Punkty wejściowe do systemu pomocy Sieć tematów pomocy Wejście z programu użytkowego Wejście od góry Wejście z systemu komunikatów o błędach

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 52 Okna systemu pomocy Tematy pomocy Przekazanie listu List można przekazać do innego użytkownika sieci przez naciśnięcie przycisku Przekazywanie w panelu sterowania. System poprosi o podanie nazwy użytkownika lub użytkowników, do których ten list ma być wysłany. więcejnastępnytematy Historia pomocy 1.Poczta 2.Wysyłanie listów 3.Czytanie listów 4.Przekazanie

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 53 Dokumentacja użytkownika l Dokumentacja użytkownika nie jest ściśle częścią projektu interfejsu użytkownika. l Dobrą praktyką jest jednak projektowanie pomocy natychmiastowej w połączeniu z dokumentacją papierową. l Podręczniki systemu powinny obejmować bardziej szczegółową informację niż system pomocy. l Należy je zaprojektować tak, aby mogły z nich korzystać różne klasy użytkowników systemu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 54 Rodzaje dokumentacji wspomagającej użytkownika Recenzenci systemu Recenzenci systemu Administratorzy systemu Administratorzy systemu Początkujący użytkownicy Początkujący użytkownicy Doświadczeni użytkownicy Doświadczeni użytkownicy Administratorzy systemu Administratorzy systemu Opis usług Jak zainstalować system ? Jak zainstalować system ? Początki pracy Opis udogodnień Opis udogodnień Działanie i pielęgnacja Działanie i pielęgnacja Opis funkcjonalny Opis funkcjonalny Podręcznik instalatora Podręcznik instalatora Przewodnik podstawowy Przewodnik podstawowy Podręcznik administratora Podręcznik administratora

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 55 Typy dokumentów l Opis funkcjonalny Należy bardzo krótko opisać usługi oferowane przez system. l Podręcznik instalatora Powinien obejmować szczegółowe informacje o instalacji systemu. l Przewodnik podstawowy Powinien obejmować nieformalne wprowadzenie do systemu, w którym należy przedstawić jego „normalne” użycie. l Podręcznik Powinien zawierać opis udogodnień systemu oraz ich wykorzystywania. l Podręcznik administratora Powinien być dostarczony w wypadku niektórych rodzajów systemu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 56 Ocena interfejsu l Ocena interfejsu to proces szacowania użyteczności interfejsu i sprawdzenia, czy spełnia on wymagania użytkownika. l Powinna więc być częścią normalnego procesu weryfikacji i zatwierdzania systemów oprogramowanych. l Najlepiej jest, aby oceny dokonywano względem specyfikacji użyteczności ustalającej atrybuty użyteczności.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 57 Atrybuty użyteczności AtrybutOpis Łatwość Po jakim czasie nowy użytkownik efektywnie korzysta z systemu? nauczenia SzybkośćW jakim stopniu sprawność systemu odpowiada praktyce pracy działaniaużytkowników? SolidnośćJak system znosi błędy użytkownika? ZdolnośćJak dobrze system radzi sobie z wycofywaniem wyników błędów do do wycofaniaużytkowników? ZdolnośćJak bardzo system jest związany z jednym modelem pracy? do adaptacji

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 58 Sposoby oceny interfejsu użytkownika l Kwestionariusze z pytaniami o to, co o interfejsie myślą jego użytkownicy. l Obserwowanie użytkowników przy pracy z systemem i „głośne myślenie” o tym, jak próbują korzystać z systemu w celu realizacji pewnego zadania. l Krótkie filmy z typowym użyciem systemu. l Umieszczanie w oprogramowaniu kodu, który służy do gromadzenia informacji o najczęściej używanych udogodnieniach systemu i najczęściej występujących błędach.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 59 Główne tezy l Proces projektowania interfejsu użytkownika powinien koncentrować się na użytkowniku. Interfejs powinien porozumiewać się z użytkownikiem za pomocą ich pojęć. Powinien być logiczny i spójny. Powinien zawierać tez udogodnienia pomagające użytkownikom w pracy z systemem i w wycofywaniu się z pomyłek. l Sposoby interakcji z systemem oprogramowanym to m. in. Bezpośrednie działanie, wybór z menu, wypełnianie formularza, języki poleceń i język naturalny. l Informacje należy wyświetlać graficznie, gdy chce się przedstawić trendy i wartości przybliżone. Wyświetlacze cyfrowe powinny być stosowane jedynie wówczas, gdy jest wymagana precyzja. l W interfejsie użytkownika kolory należy używać oszczędnie i spójnie. Projektanci powinni brać pod uwagę, że znacząca liczba osób to daltoniści.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 15Slide 60 Główne tezy l Systemy pomocy powinny oferować dwa rodzaje pomocy: Pomóżcie!, to znaczy „Pomóżcie! Jestem w kłopotach!” i „Pomożecie?”, to znaczy „Pomożecie? Potrzebuję informacji”. l Komunikaty obłędach nie powinny sugerować, że użytkownik jest winny. Powinny za to sugerować, jak naprawić błąd, i dawać odsyłacz do systemu pomocy. l Dokumentacja użytkownika powinna obejmować przewodniki dla początkujących i podręczniki. Należy dostarczyć oddzielenie dokumenty dla administratora. l Specyfikacja systemu powinna zawierać (tam gdzie to jest możliwe) ilościowe wartości atrybutów użyteczności. Proces oceny powinien polegać na weryfikacji systemu względem tych wymagań.