Makiety interfejsu (Mockups)-

ekrany użytkownika podczas konkretyzowania

Źródło: M. Bartyzel; „Oprogramowanie szyte na miarę”, Helion 2012

Na jakiej podstawie programista zazwyczaj poznaje, że aplikacja działa poprawnie? Na podstawie pomyślnego wykonania testów. Po czym użytkownik¹ zazwyczaj poznaje, że aplikacja działa poprawnie? Po tym, że ekrany wyglądają i reagują w oczekiwany sposób. Interfejs (w domyśle mam tu na myśli graficzny interfejs użytkownika) jest najczęściej jedyną częścią systemu, której użytkownik jest w pełni świadomy. Posługiwanie się w trakcie konkretyzowania szkicami ekranów pomaga w miarę szybko dojść do porozumienia. Przykładowy szkic ekranów użytkownika znajduje się na rysunku 5.11.

Rysunek 5.11. Szkic ekranów użytkownika

Zauważ, że przedstawione na rysunku ekrany nie zawierają zbyt wielu detali. Celem szkicowania ekranów jest rozmowa z użytkownikiem i wyodrębnienie oraz skonkretyzowanie wymagań, a nie szczegółowe zaprojektowanie wyglądu aplikacji.

Celem szkicowania ekranów jest konwersacja z użytkownikiem i wy­odrębnienie oraz skonkretyzowanie wymagań, a nie szczegółowe zaprojektowanie wyglądu aplikacji.

Z powyższych względów na ekranach umieszczaj tylko te rzeczy, które mają związek z logiką działania systemu i wymaganiami funk­cjonalnymi, a zatem:

1. Prostokąty oznaczające ekrany wraz z nazwami ekranów.

2. Prostokąty oznaczające pola, w których użytkownik wpisuje jakieś dane².

3. Napisy z podkreśleniem oznaczające elementy akcji (można tam kliknąć i coś się stanie).

4. Strzałki przejścia pomiędzy ekranami wraz z podpisem wskazującym, w wyniku jakiego zdarzenia następuje dane przejście.

Każdy z wymienionych elementów z łatwością odnajdziesz na rysunku 5.11.

Cykl pracy z ekranami użytkownika

Szkic ekranów powstaje stopniowo w trakcie rozmowy. W tabeli 5.7 znajdziesz poszczególne etapy rozmowy na temat portalu internetowego, natomiast na rysunku 5.12 kolejne fazy ekranów użytkownika, powstających w trakcie tej rozmowy.

Zauważ, że zadawane przez programistą pytania były zwyczaj­nymi pytaniami konkretyzującymi. Rysowanie ekranów stanowi przede wszystkim medium komunikacyjne i pomaga skonkretyzować uwagę na funkcjonalności aplikacji

Etap	Programista	Użytkownik	Komentarz
			Zauważ, że programista odwołuje się do tego, co użytkownik widzi - w końcu rysujemy ekrany.
1	Wyobraź sobie, że siadasz przed komputerem i zaczynasz pracę w tym systemie. Którą stronę widzisz jako pierwszą?	—	Programista celowo używa również czasu teraźniejszego, co stawia użytkownika w akcji działania. Programista pyta, jaką stronę użytkownik widzi. Nawiązuje tu do konkretnej technologii, która jest zazwyczaj wcześniej wiadoma. Przy aplikacjach desktopowych można by zapytać, które okno użytkownik widzi.
	—	Logowanie.	—
	Dobrze. Co możesz na niej
	zrobić?		Ogólne pytanie, a zatem ogólna odpowiedź.
2	—	Zalogować się?
	Miałem na myśli: co możesz
	tam wpisać?	Nazwę użytkownika oraz hasło.	Konkretne pytanie, konkretna odpowiedź.

Etap	Programista	Użytkownik	Komentarz
3	Czy coś jeszcze możesz wpisać albo kliknąć?	—	—
	—	Przycisk „Zaloguj”.
	Gdy wciśniesz przycisk „Zaloguj” i login i hasło są prawidłowe, to którą stronę teraz widzisz?		Programista kieruje użytkownika w stronę typowego scenariusza. Scenariusz z błędną nazwą użytkownika lub hasłem będzie omówiony w dalszej kolejności.
	—	Główną.	—
A	Nie rozumiem. Czy chodzi o główną stronę systemu?	—	—
		Nie, o główną stronę dla mojego konta. Coś takiego jak Pulpit albo Panel główny.	Niemal wszystkie aplikacje webowe oferują zapamiętywanie danych uwierzytelniających. W związku z tym wystarczy wpisać nazwę portalu, aby znaleźć się w widoku swojego konta (nie trzeba „się logować”). Spowodowa to, że wielu użytkowników nie czyni rozróżnieni; między częścią publiczną a częścią prywatną portalu.

Etap	Programista	Użytkownik	Komentarz
3	Czy cos jeszcze możesz wpisać albo kliknąć?	—	—
	—	Przycisk „Zaloguj”.	—
	Gdy wciśniesz przycisk „Zaloguj” i login i hasło są prawidłowe, to którą stronę teraz widzisz?		Programista kieruje użytkownika w stronę typowego scenariusza. Scenariusz z błędną nazwą użytkownika lub hasłem będzie omówiony w dalszej kolejności.
	—	Główną.	—
A	Nie rozumiem. Czy chodzi o główną stronę systemu?	—	—
		Nie, o główną stronę dla mojego konta. Coś takiego jak Pulpit albo Panel główny.	Niemal wszystkie aplikacje webowe oferują zapamiętywanie danych uwierzytelniających. W związku z tym wystarczy wpisać nazwę portalu, aby znaleźć się w widoku swojego konta (nie trzeba „się logować”). Spowodowało to, że wielu użytkowników nie czyni rozróżnieni; między częścią publiczną a częścią prywatną portalu.

Etap 1

Rysunek 5.12. Fazy powstawania ekranów użytkownika

Z perspektywy użytkownika korzystanie z tej techniki wiąże się z następującymi korzyściami:

1. Użytkownik sam wymyśla, jak będzie pracował z aplikacją.

2. W trakcie rozmowy używamy języka ekranów zrozumiałego dla użytkownika.

3. Po wdrożeniu systemu czas nauki jest krótszy, gdyż użytkownik zna ideę jego działania.

Z perspektywy programisty korzyści są następujące:

1. Programista nie musi wymyślać logiki działania interfejsu i pracy z aplikacją, gdyż jest ona efektem rozmowy.

2. Łatwiej zaplanować i oszacować prace, gdy znany jest kształt ekranów.

Podsumowując sposób pracy z ekranami, warto dodać kilka ważnych spraw, o których powinieneś pamiętać:

• Rysuj razem z użytkownikiem — wspólne rysowanie buduje zaangażowanie; ludzie są bardziej przywiązani do rzeczy, które stworzą sami, niż do tych, które są im narzucone z góry.

• Ekran to kontrakt — użytkownicy bardzo przywiązują się do narysowanych ekranów, z tego względu ekrany szkicujemy, zamiast je projektować, projektowanie ekranów to zupełnie inny etap prac; mimo wszystko do naszkicowanych ekranów warto dodać podpis Rysunek przedstawia szkic interfejsu użytkownika, a nie docelowy jego kształt.

• Ostrożnie z detalami — nie przeładowuj szkiców niepotrzebnymi szczegółami; na tym etapie nie mają one zbyt dużego znaczenia.

Narzędzia

Zdecydowanie odradzam tworzenie ekranów w środowiskach programistycznych, które to umożliwiają np.: NetBeans, Visual Studio itp. Po pierwsze, te narzędzia przeznaczone są do tworzenia „prawdziwych” formularzy dla działającej aplikacji i służą do implementowania interfejsu, a nie do jego szkicowania. Przekłada się to bezpośrednio na czas przygotowywania ekranów, który jest zbyt długi, aby tworzyć je podczas rozmowy z użytkownikiem. Po drugie, ekrany są identyczne z tymi w działającej aplikacji, co spowoduje, że użytkownik będzie spodziewał się dokładnie takiego samego ekranu w końcowym produkcie. Po trzecie, w trakcie zbierania wymagań użytkownicy często zmieniają zdanie, a modyfikowanie ekranów w tych narzędziach jest czasochłonne. Środowiska programistyczne wkraczają do akcji, gdy interfejs użytkownika jest już (przynajmniej w większej części) rozpoznany.

Nie zachęcam również do korzystania z projektanta ekranów użytkownika dostępnego (w chwili pisania tej książki) w narzędziu Enterprise Architect. Liczba kliknięć, które należy wykonać, aby stworzyć dobrze wyglądające ekrany, jest wprost niewiarygodna. Praca z ekranami użytkownika podczas sesji zbierania wymagań trwa w tym narzędziu zdecydowanie zbyt długo.

Czy zatem cokolwiek mogę polecić? Jak najbardziej! Zdecydowanie polecam narzędzia do tworzenia makiet interfejsu (ang. mockups). W tabeli 5.8 wymieniam kilka użytecznych.

Tabela 5.8. Narzędzia do tworzenia makiet interfejsu użytkownika

Narzędzie	Informacje
	• płatne: 79$
	• dostpna wersja demonstracyjna o ograniczonych
Balsamiq Mockups	funkcjonalnociach
	• wersje online oraz desktop
	• http://www.balsamia.com
	• darmowe
	• tylko wersja desktop
Pencil	• czasem uciążliwe w użytkowaniu przy ekranach
	zawierających kilka kontrolek
	• http://pencil.evoius.vn
	• darmowe
Lumzy	• tylko wersja online
	• http://lumzv.com

Ograniczenia stosowania ekranów użytkownika

Ekrany użytkownika doskonale sprawdzają się wszędzie tam, gdzie system ma graficzny interfejs użytkownika. Nie sprawdzą się zatem tam, gdzie nie ma interfejsu graficznego, np.:

1. sterowniki urządzeń,

2. usługi webowe (ang. web service),

3. aplikacje konsolowe.

W wymienionych przypadkach jedynymi narzędziami rozmowy będą: podstawowy algorytm konkretyzowania, technika skrzynki oraz odręczne rysunki odwzorowujące ideę omawianego zagadnienia.

Ekrany użytkownika w trakcie prac programistycznych

Opracowane ekrany użytkownika stanowią bardzo dużą pomoc dla zespołu programistycznego. Gdy zostanie Ci przydzielone zadanie, możesz wydrukować szkic ekranów, a następnie zacząć zastanawiać się nad pytaniami:

• Z jakimi usługami powinny być powiązane poszczególne ekrany?

• Skąd pobrać dane do zaprezentowania na poszczególnych ekranach?

• Jakie informacje powinny być przekazywane pomiędzy ekranami?

Na wydruku nanieś szczegóły implementacyjne. Przykład pokazany jest na rysunku 5.13.

Takie uszczegółowienie ekranów sprawi, że zanim zabierzesz się do programowania, najpierw zaplanujesz swoje prace. Wynikającą z tego korzyścią jest chociażby lepsze oszacowanie czasu wykonywania zadań.

---

1. Słów „klient” i „użytkownik” często używam wymiennie. Choć to kompletnie inne odpowiedzialności, to przy omawianych zagadnieniach nie potrzeba wprowadzać między nimi rozróżnienia.

   ↩

2. Inputy, tekstfildy — jeśli używać nowomowy programistycznej.↩