Zajęcia są we wtorki. Grupa nr 1 zaczyna zajęcia o 12:15, sala G-1-03. Grupa nr 2 o 14:00, sala G-1-09. Zapraszam również na konsultacje (pokój C-2-29 lub online, terminy w USOSwebie).
W trakcie semestru można mieć co najwyżej dwie nieusprawiedliwione nieobecności.
Oceny z ćwiczeń wystawiane są na podstawie:
Listę ocen cząstkowych oraz przydzielone tematy i daty referatów można znaleźć w pliku pub.txt.
Projekty realizowane są w zespołach złożonych z 3-4 osób, pracuje się nad nimi przez cały semestr. Ważna jest nie tyle otrzymana na końcu implementacja GUI, co zaznajomienie Państwa z procesem projektowym i koniecznością komunikowania się z nie-programistami (np. z klientem, który u Was zamówił stworzenie aplikacji — musicie mu przedstawić zrozumiały dla niego wstępny projekt GUI, jeśli to zawalicie zrezygnuje z Waszych usług i pójdzie do konkurencji).
Sprawozdania z poszczególnych części projektu oddawane są poprzez Pegaza w formacie PDF. Należy je wysyłać najpóźniej w poniedziałek, tak abym mógł się z nimi zapoznać przed wtorkowymi zajęciami. Spóźnienia będą powodować obniżenie oceny.
Terminy:
Pierwsze z kolokwiów odbędzie się 25 listopada, a drugie 13 stycznia (i będzie wymagać przeprowadzenia analizy komputerowego prototypu UI przygotowanego przez któryś inny zespół projektowy).
W tym roku tematem referatów są aplikacje wspomagające tworzenie szkiców projektowanego GUI. Szkice dzielą się na szkice zgrubne (ang. wireframe) i szkice wysokiej wierności (ang. mockup) — można wybrać aplikację obsługującą tylko jeden z tych dwóch rodzajów.
Teoretycznie, szkice można rysować w dowolnym programie do tworzenia grafiki, np. GIMP-ie lub Photoshopie. W praktyce byłoby to bardzo niewygodne, używa się więc specjalizowanych narzędzi. Na rynku jest ich wiele i często pojawiają się nowe. Część z tych narzędzi pozwala tworzyć szkice interaktywne, w których np. kliknięcie w przycisk może powodować przejście do innego okna / ekranu.
Mockupy można też tworzyć przy pomocy IDE zawierającego wizualny edytor GUI (w dzisiejszych czasach wszystkie poważne IDE go mają). W takim edytorze powinno dać się łatwo utworzyć wszystkie okna, z których projektowana aplikacja będzie korzystać i równie łatwo je poprawić, jeśli po ich obejrzeniu okaże się, że konieczne są zmiany ich wyglądu.
Referat należy przygotować w formie rzutnikowej prezentacji. Oprócz slajdów można również pokazać omawiane narzędzie w działaniu — takie demonstracje są czasem znacznie czytelniejsze niż pokazywanie na slajdach nieruchomych zrzutów ekranu.
Prezentacje nie powinny przekraczać 15 minut. 2-3 minuty z zarezerwowanego czasu zajmie rozstawianie laptopa i odpowiadanie na pytania z sali.
Najważniejszą częścią zajęć jest wykonanie projektu zespołowego. W ramach tego projektu należy zaprojektować, zaimplementować i ocenić interfejs użytkownika (tylko interfejs, a nie całą aplikację korzystającą z bazy danych lub połączeń sieciowych — te funkcje aplikacji należy zasymulować). Projektowanie interfejsów użytkownika jest procesem iteracyjnym, tak więc interfejs zostanie wykonany trzykrotnie, za każdym razem z większą precyzją — jako projekt, prototyp i końcowa wersja. Aby mieć czas na wykonanie trzech iteracji należy zacząć jak najwcześniej i pracować systematycznie przez cały semestr.
Zespoły projektowe powinny składać się z 3-4 osób. Temat wybrany do realizacji nie jest narzucony z góry, ale musi spełniać pewne warunki:
Musi mieć znaczący interfejs użytkownika. Program do odtwarzania plików wideo nie jest tu wystarczający, ale już interfejs pozwalający przeglądać takie pliki, organizować je w kolekcje itp. ma szanse na akceptację.
Interfejs musi być interaktywny. Statyczna strona WWW, nawet bardzo rozbudowana, nie będzie przyjęta, ale na przykład sklep internetowy z koszykiem i wyszukiwaniem produktów już tak.
Preferowane są projekty oryginalne. Można oczywiście zrobić interfejs do aplikacji typu album fotograficzny, ale jest ich już bardzo wiele.
Projekt może być związany z innym aktualnie wykonywanym. Można również zbudować znaczący interfejs użytkownika do programu wykonywanego na zaliczenie innego przedmiotu.
Większość projektów będzie zapewne albo w postaci aplikacji desktopowych albo internetowych, ale dopuszczalne są także inne interfejsy (telefon). Proszę wybrać takie narzędzia, które są już dobrze poznane, przynajmniej przez część zespołu. Tworzenie dużego projektu nie jest najlepszym momentem na naukę nowych języków i / lub bibliotek. Można wybrać dowolne narzędzie dostępne na uczelni lub możliwe do legalnego zainstalowania.
Krytycznie ważna uwaga: aplikacja musi być uruchamialna w pracowni, w której odbywają się zajęcia. Opracowany na etapie 5 komputerowy prototyp UI będzie testowany przez osoby z pozostałych zespołów, nie można więc przygotować tego prototypu w formie, na przykład, aplikacji na iPhone’a. Jej uruchamianie nie może też być bardziej skomplikowane niż „otwórz w przeglądarce zapisany na tablicy URL, ściągnij i rozpakuj archiwum z aplikacją, dwukliknij w sklep.exe”.
Kilka przykładowych tematów:
Pierwszą rzeczą, którą musicie Państwo oddać, jest zarys projektu (około jednej strony A4) zawierający:
Opis problemu jaki ma być rozwiązany. Jakie cele użytkownik może tu osiągnąć, jakie przeszkody napotkać?
Uwaga: to ma być problem użytkownika. „Strony będą musiały zmieniać layout w zależności od tego, czy są wyświetlane w przeglądarce działającej na telefonie, czy też na pececie z wielkim monitorem” to problem programisty, a nie użytkownika.
Docelowy użytkownik. Proszę pamiętać, że interfejs nie ma być przeznaczony dla jego autorów. Należy też pamiętać, że zapewne inaczej będzie wyglądał interfejs programu do nauki angielskiego dla małych dzieci, a inaczej dla maturzystów.
Rozwiązanie. Jak zamierzają Państwo rozwiązać postawiony sobie problem? Przedstawione tu rozwiązanie nie jest zobowiązujące, ale stanowi punkt wyjścia dla projektu, oraz daje możliwość oceny czy taki projekt jest wystarczający na projekt zespołowy.
Narzędzia jakie będą użyte.
Odniesienia do innych rozwiązań. Zapewne już ktoś taki problem próbował rozwiązać. Jak to zrobił? Jakie wady ma takie rozwiązanie, co można zrobić lepiej?
Lista członków zespołu.
Kolejnym etapem projektu zespołowego jest wykonanie analizy użytkowników i zadań.
Analiza użytkowników: należy opisać najważniejsze cechy potencjalnych użytkowników zgodnie z zasadami podanymi na wykładzie. Cechy należy określić dla każdej klasy użytkowników (wybrać dla każdej klasy przykładowego przedstawiciela).
Proszę wykazać zdrowy rozsądek przy definiowaniu klas, do których będą należeć przykładowi użytkownicy. Klasy muszą się czymś różnić z punktu widzenia analizowanego problemu. Na przykład, jeśli rozważamy automat do sprzedaży biletów w autobusie, to podział użytkowników na kobiety i mężczyzn raczej nie ma znaczenia. Podział na miejscowych już zaznajomionych z automatem, przyjezdnych z innych miast i zagranicznych gości nie znających języka polskiego byłby znacznie bardziej sensowny.
Analiza zadań: należy określić zadania, jakie są związane z problemem rozwiązywanym przez proponowany projekt oraz odpowiedzieć na pytania związane z zadaniami podane na wykładzie. Proszę pomyśleć także o innych pytaniach, które mogą być istotne w tym konkretnym projekcie. Należy określić i opisać co najmniej 6 zadań. Jeśli w danym projekcie nie można znaleźć tylu zadań to należy zastanowić się na bardziej szczegółowym podziałem, sytuacjami wyjątkowymi, itp. Jeśli zadań jest ciągle za mało, to najprawdopodobniej problem jest zbyt prosty.
Uwaga: celem zadania nie może być „chcę się zalogować, a następnie przejść z ekranu głównego przez ekran kategorii do ekranu wybranego produktu i kliknąć w ikonkę koszyka”. Nie wolno nic pisać o ekranach, ikonach, polach tekstowych, bo na razie nie istnieje jeszcze nawet wstępny projekt interfejsu (powstanie dopiero na etapie 3). Poprawnie sformułowanym zadaniem mogłoby być „chcę kupić w sklepie określony, dobrze mi znany produkt”.
Aby zebrać informacje o użytkownikach należy przeprowadzić wywiady z co najmniej trzema przedstawicielami potencjalnych użytkowników (co najmniej jeden z każdej klasy, jeśli jest kilka klas potencjalnych użytkowników). Jeśli możliwa jest obserwacja użytkowników w rzeczywistym środowisku to także należy ją wykonać. Opisując te działanie proszę nie pisać opowiadań, ale jedynie swoje wnioski, uzasadniając je przeprowadzonymi wywiadami (i obserwacją).
Proszę nie podawać nazwisk osób z którymi przeprowadzono wywiady!
Sprawozdanie z tej części pracy powinno mieć 2-3 strony i zawierać następujące elementy:
Tytuł projektu.
Krótkie przypomnienie problemu (jedno zdanie).
Opis użytkowników (krótki opis każdej klasy użytkowników, wybranych przedstawicieli, uzasadnienie).
Zadania. Opis każdego zadania powinien zawierać:
Cel do osiągnięcia w danym zadaniu.
Warunki wstępne, wymagania przed wykonaniem zadania.
Potencjalne wyjątki.
Podzadania (jeśli są).
Kolejnym etapem projektu zespołowego jest wykonanie pierwszych szkiców projektu interfejsu. W tym etapie należy opracować i przygotować następujące elementy:
Wstępny projekt interfejsu. W oparciu o analizę zadań należy opracować wstępny projekt interfejsu. Powinien składać się z jednego lub kilku szkiców okien, okienek dialogowych, menu i innych elementów pozwalających użytkownikowi wykonywać te zadania.
Scenariusze użycia. Dla 2-3 najważniejszych zadań należy opisać konkretne scenariusze. Dla przykładu w programie pocztowym może wystąpić zadanie „wysłanie e-maila”, scenariusz takiego zadania może wyglądać na przykład tak: „starsza osoba włącza komputer, aby napisać e-maila do znajomych…”. Proszę postarać się, aby scenariusze były jak najbardziej realistyczne. Dobrze byłoby oprzeć się na przeprowadzonej wcześniej analizie użytkowników i wywiadach z użytkownikami.
Storyboardy. Dla każdego scenariusza przygotowanego w tym etapie należy opisać jak może on być zrealizowany w tym projekcie interfejsu. Proszę naszkicować jak wyglądałby przebieg działań użytkownika wykonującego dane zadanie. Te opisy będą wykorzystywane w późniejszym etapie.
Proszę spróbować przemyśleć więcej niż jeden możliwy projekt interfejsu. Będzie można wtedy wybrać najlepiej pasujący do problemu.
Przy rysowaniu szkiców proszę nie skupiać się na szczegółach, wyglądzie ikon, układzie elementów, rozmiarach. Na tym etapie proszę skupić się na tym, jak interfejs będzie się komunikował z użytkownikiem i jak będzie można w nim wykonać zadania przewidziane / odkryte na etapie analizy zadań.
Zamiast szkicować ołówkiem na kartce można użyć jednej z wielu aplikacji służących do tworzenia szkiców bądź mockupów UI. Proszę wybrać taką, która pozwala wyeksportować stworzony projekt w formie plików PNG lub JPEG.
Sprawozdanie z tej części pracy powinno zawierać następujące elementy:
Tytuł projektu.
Wstępny projekt interfejsu. Może być w wersji plików graficznych lub zdjęć ręcznych rysunków, ewentualnie zeskanowanych rysunków. Proszę zwrócić uwagę na czytelność zdjęć.
Scenariusze i storyboardy. Oprócz opisu proszę także dostarczyć rysunki z etapu storyboard w postaci plików graficznych, skanów lub zdjęć.
Kolejnym etapem projektu zespołowego jest wykonanie pierwszego z serii prototypów. W tej części należy wykonać i przetestować prototyp niskiej wierności — papierowy. Wykonany w tym etapie prototyp może wykorzystać opracowane w poprzedniej części scenariusze, wstępne projekty i storyboardy. Opracowany przez Państwa prototyp powinien pozwalać na „wykonanie” w nim co najmniej trzech scenariuszy. Mogą to być albo scenariusze z części 3, albo nowe, na przykład obejmujące najtrudniejsze lub najbardziej skomplikowane zadania. Wykonany przez każdy zespół prototyp będzie testowany na ćwiczeniach. W związku z tym należy opracować i przygotować następujące elementy:
Prototyp papierowy. Należy narysować wszystkie elementy interfejsu, włączając w to elementy dynamiczne. Znaczną część elementów mają Państwo już przygotowaną w poprzedniej części projektu zespołowego.
Zadania dla użytkownika. Na paskach papieru, małych karteczkach należy napisać zadania dla użytkownika. Powinny to być te zadania, dla których maja Państwo zrealizowane scenariusze. Zadania powinny być sformułowane krótko, np. „wyślij maila”, „znajdź książkę danego autora”, itp., oczywiście zależnie od tego do czego służy dany interfejs. Zadania powinny być krótkie i nie zawierać żadnych informacji jak je wykonać, to należy do użytkownika.
Informacje dla testujących interfejs. Należy przygotować krótki opis interfejsu przeznaczony dla użytkowników go testujących. Opis powinien zawierać podstawowe informacje o problemie jaki rozwiązuje dany interfejs, zadaniach, itp. Można wykorzystać opis przygotowany w części 1.
Proszę ponadto wybrać osobę, która będzie w czasie testowania pełnić rolę „komputera”, czyli wykonywać operacje na papierowym interfejsie. Pozostałe osoby z zespołu powinny pełnić funkcję obserwatorów notując uwagi i problemy użytkowników. Ewentualnie mogą Państwo wymieniać się rolą „komputera” w trakcie prowadzenia testów na kolejnych użytkownikach.
Testując interfejs na użytkowniku należy wykonać następujące kroki:
Przekazać użytkownikowi podstawowe informacje o aplikacji — tu należy wykorzystać opis przygotowany jako informacja dla testujących (powyżej).
Dać użytkownikowi zadanie (pasek papieru lub karteczka).
Obserwować, robić notatki, zwracać uwagę na problemy jakie ma użytkownik.
Osoba pełniąca rolę komputera nie powinna komentować działań użytkownika ani mu pomagać, komputer tego nie robi.
Uwagi dla użytkowników:
Proszę nie starać się stwarzać problemów na siłę, na przykład szukać opcji „Zapisz” wszędzie z wyjątkiem menu „Plik”, nie o to tu chodzi.
Proszę starać się myśleć na głos, to pomoże obserwującym zauważyć problemy.
Sprawozdanie z tej części pracy powinno zawierać następujące elementy:
Tytuł projektu.
Zdjęcia / skany prototypu. Jeśli nie maja Państwo dostępu do skanera, to można to zastąpić zrobieniem zdjęć cyfrowych, należy zwrócić uwagę na czytelność zdjęć.
Opis i zadania jakie dali Państwo użytkownikom.
Obserwacje. Nie muszą to być ładnie napisane akapity, ale po prostu nieco uporządkowane surowe notatki z obserwacji.
Przedostatni etap projektu to wykonanie prototypu komputerowego. Im lepiej i staranniej wykonają Państwo prototyp, tym mniej pracy będzie do wykonania przy finalnej implementacji interfejsu.
Stworzony prototyp musi dać się uruchomić na komputerach w pracowni. Jeśli projektowana aplikacja przeznaczona jest dla telefonów komórkowych, automatów sprzedających bilety itp. urządzeń, to trzeba takie urządzenie symulować na komputerze.
Prototyp komputerowy powinien charakteryzować się kilkoma cechami:
Wysoka wierność wizualna elementów. W przeciwieństwie do prototypu papierowego, gdzie rozmiary i kształty elementów były mało istotne, w prototypie komputerowym należy zachować wysoką jakość wizualną co do rozmiaru okien, kolorów, czcionek, rozmieszczenia elementów.
Umiarkowana wierność w zakresie i działaniu. Jeśli chodzi o zakres prototypu to na tym etapie jako minimum musi być w stanie obsługiwać te zadania użytkownika, które obsługiwał prototyp papierowy, i dla których pisali Państwo scenariusze. W sensie działania można jeszcze nie obsługiwać bardziej złożonych zachowań (np. przeciągnij i upuść).
Niska wierność aplikacyjna. Na tym etapie nie musi jeszcze działać (czy też być w przekonujący sposób symulowana) faktyczna aplikacja, której dotyczy interfejs. Nie ma potrzeby pisania całego kodu.
Na tym etapie realizacji proszę się jeszcze nie przejmować takimi elementami jak:
Działanie na różnych platformach, czy w różnych przeglądarkach — mogą Państwo zademonstrować projekt w takiej, w której działa najlepiej.
Przeskalowywanie zawartości okien przy zmianie ich rozmiaru — można ustalić rozmiar i nie ruszać go w trakcie demonstracji.
Obsługa błędów — interfejs nie powinien się zawieszać czy resetować komputera, ale też nie musi sobie radzić konstruktywnie z każdym pomysłem użytkownika.
Wykonany przez Państwa prototyp posłuży do wykonania analizy heurystycznej. Będzie ona wykonywana na ćwiczeniach przez co najmniej 2 osoby z innych zespołów. W związku z tym muszą Państwo dostarczyć prototyp w postaci pozwalającej na uruchomienie go na komputerach w pracowni. Preferowane postacie to: plik wykonywalny (Windows, Linux), plik HTML, plik JAR zawierający aplikację Javy. Jeśli Państwa prototyp jest w innym formacie proszę o wcześniejsze sprawdzenie czy będzie go można uruchomić w czasie ćwiczeń i / lub kontakt z prowadzącym ćwiczenia kilka dni przed zajęciami.
Co należy przygotować:
Prototyp: wystarczy adres URL, pod którym dostępny jest prototyp, w miarę możliwości w postaci jednego pliku ZIP.
Instrukcja uruchomienia (platforma, przeglądarka, co użytkownik jeszcze musi wiedzieć).
Informacja dla użytkownika (ta z części 4, którą dali Państwo użytkownikom przy testowaniu prototypu papierowego będzie OK).
Nie trzeba pisać sprawozdania z procesu implementacji tego prototypu. Prototyp będzie oceniany przez prowadzącego podczas ćwiczeń. W związku z tym brak prototypu na zajęciach skutkuje uzyskaniem 0 punktów.
Prototyp komputerowy z poprzedniego etapu należy rozbudować i poprawić tak, aby otrzymać pełną implementację interfejsu, a następnie publicznie zademonstrować jego działanie. Każdy zespół będzie miał 10 minut na zaprezentowanie swojej aplikacji, a następnie pozostałe osoby będą miały możliwość wyrażenia opinii (konstruktywnej!), uwag, rad i wszystkiego co mogłoby poprawić jakość i funkcjonalność interfejsu.
Ta wersja implementacji powinna zawierać zarówno interfejs, jak i aplikację, dla której jest przeznaczony; wszystkie niezaimplementowane elementy aplikacji powinny być symulowane w sposób umożliwiający pracę z nią (np. komentarze wpisywane przez użytkowników forum dyskusyjnego można trzymać w pamięci operacyjnej jako listę, a nie w bazie SQL).
W trakcie prezentacji każdy zespół powinien krótko omówić cel i założenia swojego projektu, docelową grupę użytkowników, przedstawić całość interfejsu na przykładach (wykorzystując na przykład wcześniejsze scenariusze), odpowiedzieć na ewentualne pytania dotyczące założeń, wyboru narzędzi, itp.
Ta część także będzie oceniana na zajęciach: oceniana będzie przede wszystkim implementacja, jednak sposób prezentacji także ma wpływ na końcową ocenę. W szczególności choć trudno jest pokazać dobrze bardzo zły projekt, to, niestety, bardzo łatwo jest źle przedstawić dobry projekt.