Projektowanie Graficznych Interfejsów Użytkownika. Robert Szmurło

Transkrypt

1 Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło 1

2 Proces wytwarzania oprogramowania. Czyli trochę inżynierii oprogramowania ale z perspektywy tworzenia interfejsów użytkownika. 2

3 Tradycyjny proces wytwarzania oprogram. 3

4 Spiralny proces wytwarzania oprogramowania Projekt Ewaluacja Implementacja 4

5 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany na Użytkowniku 2) Model Centered Design Projekt Oparty na Modelach Projekt Ewaluacja Implementacja 5

6 User Centered Design (UCD) 1) Analiza projektu/użytkowników/zadań Projekt 2) Szkice projektu 3) Papierowy prototyp 8 7 4) Testy wewnętrzne (z użytkownikiem) 1 5) Prototyp komputerowy 6) Ewaluacja heurystyczna 7) Analiza raportu ewaluacji i korekta projektu 10 6 Ewaluacja Implementacja 8) Projekt architektury, projekt szczegółowy realizacji interfejsu 9) Implementacja I iteracji 10) Testy z użytkownikami 6

7 Projekt systemu Projekt GUI Projekt podzielimy na 5 kategorii, które będą realizowane różnych etapach procesu: A) Projekt pojęciowy (analiza (1)) wyodrębnienie podstawowych koncepcji systemu jak np. obiektów, relacji i uogólnień. B) Projekt funkcjonalny (semantyczny (2)) zdefiniowanie operacji na wszystkich obiektach oraz danych wejściowych i wyjściowych. C) Projekt sekwencyjny (syntaktyczny (2)) definiuje kolejność operacji wprowadzania danych wejściowych i wyjściowych (np. przez użytkownika do systemu). Przykładem sekwencji jest scenariusz przypadku użycia. Projekt syntaktyczny elementów wyjściowych uwzględnia strukturalne rozmieszczenie elementów wyświetlanych oraz ich zmiany. D) Projekt wizualny (3) definiuje wizualną reprezentację obiektów za pomocą widoków, projekt okien, kolejność ekranów - storyboards, E) Projekt leksykalny (8) czasem określany jako projekt integrujący ze sprzętem, określa w jaki sposób i z jakimi rzeczywistymi prymitywami sprzętowymi połączone są elementy syntaktyczne. 7

8 Projekt pojęciowy (A) Etap Odkrywania / Analizy: 1) określ klasy użytkowników (aktorów) 2) określ cele użytkowników (zadania, oczekiwania) 3) przeanalizuj aktualnie wykonywane czynności użytkownika 4) zbuduj projekt przypadków użycia 8

9 Poznaj Użytkowników (A) Kluczowe w UCD: Określ charakterystykę docelowej grupy użytkowników, która będzie wpływała na wymagania. Między innymi określ: poziom wykształcenia możliwości fizyczne (np.: niepełnosprawni) ogólne doświadczenie komputerowe umiejętności (szybkie pisanie, czytanie) doświadczenie związane z dziedziną pracy doświadczenie z podobnymi aplikacjami środowisko pracy i pozostałe elementy kulturowe zależności i wzorce komunikacyjne Wymagani dotyczące szkolenia (czy duża rotacja pracowników) wiek, płeć, kulturę 9

10 Projekt pojęciowy (A) Etap Odkrywania / Analizy: 1) określ klasy użytkowników (aktorów) 2) określ cele użytkowników (co musi być zrobione, wymagania, zazwyczaj zakres obowiązków w firmie) 3) przeanalizuj aktualnie wykonywane czynności użytkownika 4) zbuduj projekt przypadków użycia 10

11 Cele użytkowników (A) CEL! - czyli co robi (ma robić) zwykły użytkownik w przedsiębiorstwie, jakie mają być jego zadania. << Podstawowe zagadnienie etapu analizy! Używamy tutaj specjalnie słowa cel, gdyż każde zadanie powinno kończyć się osiągnięciem ściśle określonego celu. (Kryterium sukcesu w testach.) Jak robić analizę? Rozmowy z 'przyszłymi' użytkownikami Bezpośrednia obserwacja aktualnie wykonywanej pracy. Zagrożenia: Powtarzanie złych wzorców. Zignorowanie pozytywnych aspektów aktualnych procedur. Dla każdego zadania udokumentuj zalezności: Co musi być zrobione aby umożliwić zrobienie czegoś innego? Od jakich innych czynności zależy dane zadanie? Jakich informacji potrzebuje użytkownik aby wykonać zadanie? 11

12 Projekt pojęciowy (A) Etap Odkrywania / Analizy: 1) określ klasy użytkowników (aktorów) 2) określ cele użytkowników (oczekiwania) 3) przeanalizuj aktualnie wykonywane czynności użytkownika (stwórz model procesów biznesowych przedsiębiorstwa) 4) zbuduj projekt przypadków użycia W najlepszym przypadku może być to: Diagram czynności 12

13 Aktualnie wykonywane czynności (A) Przedstaw czynności wykonywane w ramach poszczególnych zadań (celów) w formie procesu biznesowego w przedsiębiorstwie: tak jak wygląda obecnie lub jak powinien wyglądać po wdrożeniu systemu Podczas projektowania koncentruj się na procesie biznesowym, a nie na systemie. Używaj jak najmniejszej liczby rzeczowników. Dokumentację możesz wykonać na podstawie: opisu procesów otrzymanych od użytkownika, obserwacji aktualnie wykonywanych czynności. Jakość scenariuszy: Powinno być: Pracownik 13

14 Projekt pojęciowy (A) Etap Odkrywania / Analizy: 1) określ klasy użytkowników (aktorów) 2) określ cele użytkowników (oczekiwania) 3) przeanalizuj aktualnie wykonywane czynności użytkownika 4) zbuduj projekt przypadków użycia (które stają się podstawą formalnej specyfikacji wymagań; przypadki użycia w pierszej wersji mogą być celami, z punktu 2., które mogą być osiągniete przy wsparciu systemu informatycznego oraz złożonymi czynnościami z punktu 3.) 14

15 Projekt funkcjonalny (B) Projekt funkcjonalny (semantyczny) zdefiniowanie operacji na wszystkich obiektach oraz danych wejściowych i wyjściowych. 1) Obiekty Użytkownika - określ obiekty/elementy/pojęcia na których wykonuje operacje użytkownik i system (słownik pojęć) 2) Przegląd Zadań (Scenariusze) - określ które czynności wykonuje system a które użytkownik 3) Okna i widoki Abstrakcyjne - jakie informacje musi widzieć użytkownik aby ukończyć zadanie poszczególne zadania (związane z konkretnymi przypadkami użycia) oraz jakie dane powinny być prezentowane do przedstawiania konkretnego obiektu 4) Przepływ Zadań (Sekwencje) - sprecyzuj dokładnie interakcję użytkownika z systemem analogia do scenariuszy przypadku użycia 5) Stany Obiektów - co dzieje się danymi obiektami w trakcie interakcji z użytkownikiem analogia do diagramów stanów obiektów 15

16 Projekt funkcjonalny (B) Projekt funkcjonalny (semantyczny) zdefiniowanie operacji na wszystkich obiektach oraz danych wejściowych i wyjściowych. 1) Obiekty Użytkownika - określ obiekty którymi operuje użytkownik 2) Przegląd Zadań - określ jakie czynności wykonuje system a jakie użytkownik 3) Okna i widoki Abstrakcyjne - jakie informacje musi widzieć użytkownik aby ukończyć zadanie 4) Przepływ Zadań - sprecyzuj dokładnie interakcję użytkownika z systemem 5) Stany Obiektów - co dzieje się danymi obiektami w trakcie interakcji z użytkownikiem 16

17 Projekt funkcjonalny Obiekty użytkownika (B) 1) Wyodrębnij obiekty zazwyczaj są to rzeczowniki z diagramu zawierającego cele użytkowników 2) Możesz posłużyć się specjalną tabelą wskazując na przykład wzajemne zależności, w celu wyselekcojonowania kluczowych obiektów (ważne w iteracjach) np.: konkretne obiekty, osoby, dokumenty, użytkownicy, obiekty abstrakcyjne 3) Zdefiniuj jednoznaczne i zrozumiałe dla użytkownika nazwy obiektów (w niektórych metodologiach nazywa się to słownikiem pojęciowym). 4) Uporządkuj obiekty w modelu uwzględniając ich definicje, atrybuty, operacje oraz relacje w postaci diagramu klas. 17

18 Obiekty użytkownika W początkowych etapach projekt zawiera zazwyczaj same nazwy klas i relacje między nimi. W trakcie tworzenia projektu pojęciowego klasy powinniśmy uzupełniać o atrybuty i metody. Atrybuty są cechami danych obiektów. Metody są operacjami, które możemy na danych obiektach wykonać. np. Pracownik rezerwuje stolik. 18

19 Jak tworzyć model obiektów użytkownika? (B) Obiekt 1) Utwórz diagram klas. Atrybuty 2) Dodaj obiekty, wraz z atrybutami i operacjami. Operacje 3) Utwórz definicje. Relacja (kompozycja składa się z) 4) Określ zależności (relacje). Liczebność 6) Sukcesywnie dodawaj wszystkie obiekty włącznie z aktorami o których musi wiedzieć system 5) Uzupełnij informację o liczebności 7) Operacje na klasach określamy najczęściej za pomocą czasowników z projektu pojęciowego. 19

20 Jak tworzyć model obiektów użytkownika? (B) Dla zależności wiele do wielu zaleca się określenie innego obiektu zwanego obiektem łączącym Najczęściej wykorzystywane są dotychczasowo istniejące w firmie formularze, dokumenty papierowe. 20

21 Projekt funkcjonalny (B) 1) Obiekty Użytkownika - określ obiekty którymi operuje użytkownik 2) Przegląd Zadań (Scenariusze) - określ jakie czynności wykonuje system a jakie użytkownik 3) Okna i widoki Abstrakcyjne - jakie informacje musi widzieć użytkownik aby ukończyć zadanie 4) Przepływ Zadań - sprecyzuj dokładnie interakcję użytkownika z systemem 5) Stany Obiektów - co dzieje się danymi obiektami w trakcie interakcji z użytkownikiem 21

22 Projekt funkcjonalny Przegląd zadań (B) Przegląd Zadań (Scenariusze) - określ które czynności wykonuje system, a które użytkownik. Na etapie zaczyna się określenie doświadczenia / interakcji użytkownika z systemem. Po raz pierwszy pojawia się system. Definicja: wysokiego poziomu opis określający strukturę funkcjonalności (ogólnie sekwencji aktywności oraz punktów decyzyjnych), którą system udostępnia dla użytkownika w celu zrealizowania intencji. Punktem startowym modelu jest odwzorowanie aktualnych procesów w instytucji użytkownika, które wykonaliśmy w projekcie pojęciowym (czasami nazywanym modelem biznesowym) 22

23 Przegląd zadań Jednoznacznie określamy kto jest odpowiedzialny za wykonanie danej czynności. Stąd nazwa procedury: przegląd zadań. Jest to często nazywane scenariuszem przypadku użycia. Diagram czynności. Staraj się używać jak najwięcej (samych?) wyodrębnionych obiektów użytkownika (czyli zdefiniowanych klas) 23

24 Diagram czynności Przykład 2 (B) Przykład aplikacji typu FlashCard. 24

25 Projekt funkcjonalny (B) Projekt funkcjonalny (semantyczny) zdefiniowanie operacji na wszystkich obiektach oraz danych wejściowych i wyjściowych. 1) Obiekty Użytkownika - określ obiekty/elementy/pojęcia którymi operuje użytkownik 2) Przegląd Zadań - określ jakie czynności wykonuje system a jakie użytkownik 3) Okna i widoki Abstrakcyjne - jakie informacje musi widzieć użytkownik aby ukończyć zadanie 4) Przepływ Zadań - sprecyzuj dokładnie interakcję użytkownika z systemem 5) Stany Obiektów - co dzieje się danymi obiektami w trakcie interakcji z użytkownikiem 25

26 Projekt funkcjon. Okna i widoki abstrakcyjne Okna i widoki Abstrakcyjne Definicja 1.: Struktura funkcjonalna interfejsu użytkownika. Definicja 2.: niezależna od implementacji reprezentacja tego co musi widzieć użytkownik do zakończenia zadania w postaci hierarchicznej struktury elementów widocznych na ekranie. Abstrakcyjny model interfejsu użytkownika tworzymy wykorzystując model obiektów użytkownika (diagram klas) oraz przegląd zadań (diagram sekwencji z podziału zadań). Mapowanie funkcjonalne obiektów użytkownika na UI. Motywacja: cel: określenie minimalnych informacji z poszczególnych obiektów, które musi widzieć użytkownik aby ukończyć zadanie oraz jaka w danym kroku musi być udostępniona funkcjonalność. Ideą okien i widoków abstrakcyjnych jest możliwość skoncentrowania się na treści oraz funkcjonalności odseparowanej od prezentacji. W widokach abstrakcyjnych nie interesuje nas jak, ale CO? będzie zaprezentowane. 26

27 Widoki i okna abstrakc. z obiektów użytkownika 1. Widoki abstrakcyjne są elementami, które nie mogą pojawiać samodzielnie. Zawsze są one częścią innych widoków lub są częścią okien. Widoki abstrakcyjne tworzymy zazwyczaj dla każdego obiektu użytkownika, który pojawia się w fazie analizy. Analiza Użytkownicy nie pracują na obiektach ale na ich widokach, czyli ich graficznej reprezentacji. 2. Okna abstrakcyjne są samodzielnymi elementami, które pojawiają się użytkownikowi. Okna abstrakcyjne są elementami które pojawiają się w scenariuszach. Okna abstrakcyjne zbudowane są zazwyczaj z widoków abstrakcyjnych. Projekt Abstrakcyjny <<widok>> WidokProduktu <<widok>> WidokZamówienia 27

28 Widoki abstrakcyjne połączone z obiektami? 1) Każdy widok powinien być związany z jednym lub kilkoma obiektami. W widoku określamy jakie komendy mogą być wywołane na danym obiekcie, które elementy są niezbędne do przedstawienia w celu realizacji jakichś powiązanych z widokiem zadań. 2) Widoki mogą być zbudowane z innych widoków. (Patrz poniższy diagram.) 3) Poniższy diagram przedstawia strukturę jednego okna startowego Telehandlowca wraz z powiązaniami do obiektów (relacja zależności). 28

29 Jak tworzyć widoki abstrakcyjne? (B) Zależność, który aktor używa widoku Widok sklepu składa się z widoku magazynu. EAN może być brany z innej klasy, z której składa się Produkt, np. ProductInfo Zależność, który obiekt prezentuje 29

30 Widoki i okna abstrakc. z podziału zadań Kolejnym typem powstawania okien abstrakcyjnych są wszystkie rzeczowniki z przeglądu zadań, które stanowią elementy interfejsu użytkownika: System wyświetla [okno logowania]. Użytkownik wprowadza [login] i [hasło] oraz wybiera opcję [OK]. System wyświetla [stronę startową użytkownika]. Analiza Projekt Abstrakcyjny 30

31 Projekt sekwencyjny (C) Definiuje kolejność operacji wprowadzania danych wejściowych i wyjściowych. 1) Przepływ Zadań - sprecyzuj dokładnie interakcję użytkownika z systemem 2) Stany Obiektów - co dzieje się danymi obiektami w trakcie interakcji z użytkownikiem 31

32 Projekt sekwencyjny (C) Definiuje kolejność operacji wprowadzania danych wejściowych i wyjściowych. 1) Przepływ Zadań - sprecyzuj dokładnie interakcję użytkownika z systemem 2) Stany Obiektów - co dzieje się danymi obiektami w trakcie interakcji z użytkownikiem 32

33 Przepływ zadań W diagramie przepływu zadań tworzymy szczegółowy projekt interakcji użytkownika systemu z poszczególnymi oknami oraz widokami. Motywacja: Dokumentacja ta będzie służyć do implementacji prototypu oraz gotowego systemu Dokumentacja będzie dodatkowo służyć do definiowania automatycznych testów interfejsu użytkownika. Dokumentacja ta będzie pomocna w Help Desku w przydziale osób odpowiedzialnych za usunięcie usterki. Wykorzystujemy diagram sekwencji! 33

34 Przykład Przegląd zadań (scenariusz): System wyświetla [okno logowania]. Użytkownik wprowadza [login] i [hasło] oraz wybiera opcję [OK]. System wyświetla [stronę startową użytkownika]. Projekt abstrakcyjny UI: 34

35 Projekt abstrakcyjny - dynamika Posiadając projekt sekwencyjny możemy rozwinąć nasz model abstrakcyjny o diagram dynamiki, która opisuje nawigacje między oknami. W diagramie nawigacji reprezentujemy przejścia między oknami (a nie widokami). Możemy zaznaczyć za pomocą jakiej opcji poszczególna nawigacja następuje. Nawigację oznacza się za pomocą stereotypu: <<navigate>> Projekt nawigacji między stronami przydaje się najczęściej w przypadku aplikacji internetowych. W przypadku wzorca architektonicznego Front Controller otrzymujemy gotową konfigurację. 35

36 Projekt nawigacji w Eclipse dla JSF Zintegrowane narzędzia programistyczne pozwalają na wizualne projektowanie nawigacji pomiędzy oknami. Poniżej przykład pluginu do edycji pliku konfiguracyjnego dla Java Server Faces w narzędziu Eclipse. identyfikator reguły nawigacji identyfikator strony 36

37 Projekt sekwencyjny (C) Definiuje kolejność operacji wprowadzania danych wejściowych i wyjściowych. 1) Przepływ Zadań - sprecyzuj dokładnie interakcję użytkownika z systemem 2) Stany Obiektów - co dzieje się z danymi obiektami w trakcie interakcji z użytkownikiem 37

38 Stany obiektów Model stanów obiektów wykorzystujemy bezpośrednio przy projektowaniu wizualnej reprezentacji stanu obiektu. Etap ten jest związany z zaleceniem projektowym dotyczącym wyraźnej reprezentacji poszczególnych stanów. 38

39 Projekt wizualny (D) Zgodność z projektem abstrakcyjnym Wszystkie elementy i decyzje podjęte w fazie projektu abstrakcyjnego powinny mieć swój odpowiednik w projekcie wizualnym. Nie powinno się robić żadnych rozszerzeń. Czytelność reprezentowanych obiektów Obiekty, wyodrębnione w fazie abstrakcyjnej powinny być w czytelny sposób reprezentowane dla użytkownika. Obiekty powinny być łatwo rozpoznawalne przez użytkownika na wszystkich etapach procesu używania systemu. W jasny i czytelny sposób powinny być reprezentowane aktualne stany obiektów oraz ich zmiany. Zgodność i czytelność mają bezpośredni wpływ na użyteczność systemu. 39

40 Projekt wizualny Trzy poziomy (D) Poszczególne widoki Prezentacja pojedynczych obiektów Model obiektów, Środowisko Okna prezentacji Układy, interakcje Widoki abstrakcyjne, sekwencje, stany, platforma, środowisko Całkowity odbiór użytkownika Weryfikacja zgodności i czytelności Prototypowanie, testy zespołowe (in-house) 40

41 Projekt wizualny Identyfikacja (D) Pojedyncze obiekt użytkownika pojawiają się w wiele razy w różnych widokach z różnymi liczebnościami oraz z różnymi możliwościami zajęcia powierzchni ekranu. Każdy obiekt musi być identyfikowalny w całym systemie. Obiekty Różne reprezentacje wizualne obiektów 1,2,3 Obiekt 1 Okno E1 Widok 2A Obiekt 2 Widok 3A Obiekt 3 Obiekt 2 Obiekt 3 Okno F1 Widok 2B Obiekt 2 W1A Obiekt 1 W1A Obiekt 1 Widok 1B Obiekt 1 Okno G1 Widok 2C Obiekt 2 Widok 1C Obiekt 1 Widok 3B Obiekt 3 W1A Obiekt 1 W1A Obiekt 1 W1A Obiekt 1 41

42 Identyfikacja obiektów (D) Przeanalizujmy interfejs sklepu internetowego wyodrębniając z niego odpowiednie widoki. Okno sklepu internetowego, które jest złożone z szeregu widoków. 42

43 Podział na widoki (D) 43

44 Widok: Logo serwisu (D) 44

45 Widok: Menu główne (D) 45

46 Widok: Reklama (D) 46

47 Widok: Panel Wyszukiwania (D) 47

48 Widok: Panelu Ofert z zagnieżdżonymi widokami Pojedynczych Ofert (D) 48

49 Widok: Reklamy Tematyczne (D) 49

50 Projekt abstrakcyjny dla przykładu (D) stm sklep.benchmark.pl «Widok» Logo «Widok» Reklama PanelWyszukiwaniaProduktu << okno>> «Widok» GłównySklepu «Widok» MenuGlowne + czyzalogowany: boolean loginzalogowanyuzytkownik: String konfiguratorpc() : void Kontakt() : void Przewodnik() : void Serwis() : void Sterowniki() : void stronaglowna() : void top10() : void T ransportplatnosciraty() : void Wsparcie() : void «Widok» PanelOfert «Widok» OfertyDnia OfertaDnia z informacją jakie pola muszą być pokazane w widoku. - kierunek: int liczbaofert: int «Widok» ReklamyTematyczne «Widok» Oferta Dla przykładu udokumentowane elementy funkcjonalne MenuGlownego. «Widok» OfertaDnia cena: String obrazek: Im age opisproduktu: String + pokazszczegoly() : void «Widok» ReklamaTematyczna 50

51 Projekt wizualny Całkowity odbiór (D) Całkowity odbiór aplikacji przez użytkownika musi uwzględniać: odpowiednie diagramy sekwencji, być zgodnym ze scenariuszami przypadków użycia, o ile były stworzone w wymaganiach, o ie to możliwe pozwalać na interakcję (prototypy), uwzględniać możliwość występowania kilku wersji do wyboru przez użytkownika, Jest realizowany za pomocą: scenopisów (np. storyborads ) dokumenty tekstowe prezentacja OpenOffice Impress lub PowerPoint itp. prototypów 51

52 Storyboard (D) 52

53 Storyboard - Przykład 2 (D) 53

54 ui Projekt leksykalny «www» ZamowienieBiletu Projekt leksykalny cm dzatwi erdz cm danuluj (from Projekt w izualny) (from Projekt w i zual ny) «trace» (from Projekt w i zualny) «trace» «navigate» «instantiate» Screen2 «GUIAction» AkcjaWalidacji WalidacjaDanych Czy poprawna? T ak «trace» Screen1 Nie Cel: mapowanie elementów interfejsu graficznego z elementami architektury systemu: akcje, kontrolki stosowane dla odpowiednich elementów graficznych. Wykonujemy praktycznie w dużych zespołach programistycznych, aby przekazać wytyczne dla programistów. 54

55 Projekt leksykalny Akcje (E) ui Proj ekt leksykalny «www» ZamowienieBiletu cm dzatwierdz cm danuluj (from Projekt w izualny) (from Projekt w izualny) «trace» (from P rojekt w izualny) «trace» «navigate» «instantiate» Screen2 «GUIAction» Akcj awalidacj i Walidacj adanych Czy poprawna? T ak «trace» Screen1 Nie 55

56 Projekt leksykalny Akcje (E) cd User Interface p o ka z dostaw y.lista Model «a cti o n» :Dostawa.Lista.Akcj a P o rt1 L i sta Do sta w (fro m L o g i ca l Mo d e l ) ::Do sta w a.l i sta.a kcja + e xe cu te () : vo i d IM o d e l Do d a j E d ytu j Dru ku j Za twi e rd z p o ka z dodaj «a cti o n» Dostawa.Lista.Akcja e xe cu te () : vo i d + p o ka z Dostawa.Pozycj a.usun Dostawa.Dodaj Do sta wca Ni e T ak K u ri e r p o ka z Da ta P o zycj e u su n «a cti o n» :Dostawa.Dodaj.Akcj a Do d a j Usu ń E d ytu j «a cti o n» :Dostawa.Dodaj.Akcj a Za ch o wa j ::Do sta w a.do d a j.a kcja + e xe cu te () : vo i d ::Do sta w a.do d a j.a kcja + e xe cu te () : vo i d Anuluj «a cti o n» za ch o wa j Dostawa.Dodaj.Akcja + e xe cu te () : vo i d p o ka z 56

57 Projekt leksykalny implementacja (E) ui Proj ekt wizualny DropDownList «www» DateTimePicker ZamowienieBiletu M iejsce i da ta wylo tu: cbo M ie jscewyl otu d twylo t M ie jsce i d ata do ce lo wa: cbo M ie jscece l d tcel L iczb a p rzesia de k: cbo P rzesia dki M o żliwość an ulo wan ia rezerwa cj i: ch ka nu lowa ni ere ze rwacji CheckBox K a rta Fo rm a p łatn ości: G oto wka cb ok la sa K l asa bile tu: cm dzatwierd z cm da n ulu j «www» ZamowienieBiletuAutobusowego ZamowineieBiletuKolej owego T ypo po ciąg u: P rzele we K lim a tyza cja cbo T ypp o cia gu ZamowienieBiletuLotniczego Jed ze ni e: cb owyzywien ie 57

58 Interakcja Dziękuję za uwagę. Chcemy być coraz lepsi! Jeżeli coś cię zainteresowało napisz a: Jeżeli coś cię bardzo znudziło napisz a: Jeżeli zauważyłeś błąd napisz a: 58