RAPORT ZBIORCZY Z PODŁĄCZANIA I TESTOWANIA USŁUG NA PLATFORMIE ELA-ENT

Transkrypt

1 Projekt badawczy rozwojowy Nr R pt.: Protokoły i prototyp platformy umożliwiające działanie elektronicznego rynku usług, z uwzględnieniem osób zagrożonych wykluczeniem z rynku pracy finansowany przez MNiSzW; od 2 marca 2007 do 1 marca dr Dariusz Mikułowski mgr Marek Faderewski RAPORT ZBIORCZY Z PODŁĄCZANIA I TESTOWANIA USŁUG NA PLATFORMIE ELA-ENT Siedlce Warszawa, 2010 r.

2 Spis treści 1. WSTĘP ZGŁASZANIE PROPOZYCJI USŁUG PROGRAMOWANIE I INSTALACJA USŁUG W SYSTEMIE ELA-ENT 8 4. TESTOWANIE URUCHOMIONYCH USŁUG UWAGI OGÓLNE REJESTRACJA DODANIE OFERTY W USŁUDZE WYSZUKANIE OFERTY I ZAWARCIE UMOWY Z WYKONAWCĄ PODSUMOWANIE ZAŁĄCZNIKI dr Dariusz Mikułowski, mgr Marek Faderewski 2

3 1. Wstęp W niniejszym raporcie zostanie przedstawiony przebieg procesu opisywania, podłączania i testowania usług do prototypowej platformy realizującej elektroniczny rynek usług ELA-enT. Instalowanie nowej usługi na platformie przebiegało w czterech następujących etapach: 1. Zgłaszanie propozycji usługi a po jej akceptacji wprowadzanie do systemu jej opisu przez użytkownika (jednego z przyszłych potencjalnych wykonawców takiej usługi). 2. Programowanie usługi na podstawie opisu wprowadzonego do systemu w etapie jej zgłaszania i opisywania. 3. Podłączanie zaprogramowanej usługi do systemu. 4. Testowanie uruchomionej usługi przez jej potencjalnych użytkowników. Należy nadmienić, że wymienione etapy nie były realizowane oddzielnie dla wszystkich usług w określonych przedziałach czasowych. Uruchamianie każdej z usług dzieliło się na te etapy, przy czym dla różnych usług różne etapy były realizowane w różnym czasie. Dotyczą więc one raczej każdej pojedynczej usługi podłączanej do systemu a nie wszystkich usług łącznie. W ciągu całego procesu instalowania usług zostało uruchomionych łącznie 74 usługi. Proces opisywania, implementacji, podłączania i uruchamiania usług był realizowany od kwietnia 2007 do lutego W kolejnych podrozdziałach niniejszego raportu zostanie przedstawiony przebieg każdego z wymienionych etapów. W każdym z podrozdziałów zostaną przedstawione również wnioski oraz uwagi, jakie nasunęły się autorom podczas przebiegu każdej z części opisywania, uruchamiania i testowania usług. dr Dariusz Mikułowski, mgr Marek Faderewski 3

4 2. Zgłaszanie propozycji usług Pierwszym etapem instalowania nowych usług na zaprogramowanej prototypowej wersji platformy ELA-enT było zgłaszanie opisów usług przez potencjalnych usługodawców oraz klientów. Polegało ono na utworzeniu odpowiednio skonstruowanego opisu usługi. Proces opisywania usług rozpoczął się w kwietniu 2007 a opisy ostatnich usług zostały wprowadzone w grudniu W początkowej fazie, opisy nowych usług były wykonywane przez członków grupy realizującej system. Pierwsze 9 opisów usług zostało wprowadzonych przez wykonawców platformy ELA-enT po bezpośrednich konsultacjach z osobami, które mogły się stać usługodawcami a które posiadały wiedzę dotyczącą odpowiednich dziedzin. Następnie zostały utworzone dwa zespoły opisująco-testujące. Koordynatorami pierwszego z tych zespołów byli: Joanna Królak-Werwińska i Włodzimierz Suski a także Marek Faderewski. Jego członkami były osoby niepełnosprawne i pełnosprawne wskazane przez Fundację Matematyków i Informatyków Niepełnosprawnych Ruchowo. Osoby pracujące w tym zespole wprowadziły do systemu 25 opisów usług. Drugi (pracujący równolegle) zespół opisująco-testujący był koordynowany przez Dariusza Mikułowskiego. Członkowie tego zespołu byli rekrutowani niezależnie z pośród osób niepełnosprawnych i pełnosprawnych. Osoby pracujące w tym zespole wprowadziły do systemu 16 opisów usług. We sierpniu 2009 zostały utworzone dwa kolejne zespoły opisująco-testujące. Pierwszy z nich był koordynowany przez Marka Faderewskiego, Jego członkami były w większości osoby wskazywane przez FMiINR. Drugi zespół opisująco-testujący był koordynowany przez Dariusza Mikułowskiego. Osoby pracujące w ramach tych zespołów wprowadziły do systemu kolejnych 24 opisów usług, przy czym każdy zespół wprowadził po 12 opisów. W ten sposób zostały opisane łącznie 74 usługi, które zostały następnie zaprogramowane i uruchomione. Celem wprowadzenia opisów usług było umożliwienie programistom zaimplementowania na ich podstawie formularzy dla usługodawcy zgłaszającego ofertę danej usługi oraz dla klienta chcącego wyszukać i doprowadzić do zawarcia kontraktu dotyczącego jej wykonania. Dlatego wymagania, co do tych opisów musiały być na tyle silne, aby spełniły one swoje zadanie. Chodziło o to, aby opisy były możliwie jak najbardziej precyzyjne, jasne i sparametryzowane w taki sposób, by programiści mogli z nich skorzystać i zaprojektować na ich podstawie formularze przeznaczone dla klientów oraz usługodawców. W celu ułatwienia wprowadzania do systemu możliwie najbardziej precyzyjnych opisów usług, w momencie utworzenia pierwszych zespołów opisująco-testujących opracowano formularz, przy pomocy którego opisy były wprowadzane do systemu. Propozycja wyglądu i zawartości tego formularza została zgłoszona przez grupę uczestników projektu związaną z FMiINR. Następnie była ona uzupełniona i dostosowana do wymagań programistów, którzy na podstawie opisów dr Dariusz Mikułowski, mgr Marek Faderewski 4

5 wprowadzanych do tego formularza mieli programować nowe usługi. Z tego powodu, niektóre informacje umieszczone w formularzu do zgłaszania usług nie były wykorzystywane przez programistów i w ostatecznej jego wersji, dla ułatwienia pracy opisujących, zostały zablokowane do wpisywania. Inne elementy tego formularza zostały do niego dodane przez koordynatorów zespołów w celu wymuszenia bardziej precyzyjnego formułowania opisów. Formularz ten zawierał takie elementy jak: 1. Klasyfikacja usługi - w tej części formularza opisujący podawał proponowaną kategorię, w jakiej powinna się znaleźć opisywana usługa. 2. Odbiorcy usługi - w tej części formularza opisujący określał grupę potencjalnych odbiorców / klientów dla swojej usługi np. osoby niepełnosprawne. 3. Miejsce świadczenia usługi - w tej części opisujący określał, na jakim obszarze może być prowadzona działalność związana z wykonywaną usługą. 4. Czas świadczenia usługi - w tej części opisujący określał przedziały czasowe wykonywania usługi. 5. Sposób świadczenia usługi - ta część formularza zawierała opis sposobu działania usługi. 6. Cennik (sposób/algorytm wyliczania ceny) - w tej części formularza opisujący określał sposoby obliczania ceny, jakie powinny być stosowane w opisywanej usłudze oraz podawał przykładowe ceny. 7. Zawarcie umowy - w tej części opisujący określał, jakie rodzaje umów (umowy zlecenie, o dzieło itp.) mogą być stosowane dla opisywanej usługi. Ponieważ takie elementy jak odbiorcy usługi, czas i miejsce jej świadczenia są informacjami charakterystycznymi dla konkretnych ofert, zostały one zablokowane do wpisywania. Najistotniejszymi elementami opisu usługi branymi pod uwagę przez programistów były: sposób świadczenia usługi oraz sposób wyliczania ceny. Sekcja Sposób świadczenia usługi składała się z następujących elementów: Opis usługi - który zawierał wyjaśnienie przeznaczenia danej usługi np. celem usługi jest zapewnienie wykwalifikowanej kadry trenerskiej osobom indywidualnym w różnych dyscyplinach sportowych. Zarówno zdrowi jak i niepełnosprawni dorośli oraz dzieci mogą pod okiem profesjonalisty bezpiecznie uprawiać ulubioną dyscyplinę sportową na różnych poziomach zaawansowania. Dodatkowe wymogi - który zawierał wymagania, jakie musi spełnić klient, aby usługa mogła być wykonana. Cechy usługi - które zawierały opis elementów formularza przeznaczonego dla usługodawcy zgłaszającego swoją ofertę oraz klienta poszukującego danej usługi. np. nazwa cechy: dr Dariusz Mikułowski, mgr Marek Faderewski 5

6 dyscyplina sportowa, wartości: badminton, sporty walki, gimnastyka. użycie: (obowiązkowe pola wyboru w formularzu dla usługodawcy, lista wyboru w formularzu dla klienta). Taki sposób opisania cech usługi pozwalał programistom na dość dokładne zaprojektowanie formularzy przeznaczonych dla zgłaszającego ofertę usługi, formularza dla klienta wyszukującego oferty oraz obowiązkowych elementów, jakie powinny się znaleźć w umowie dotyczącej wykonania usługi danego typu. Sekcja cennik w formularzu do opisywania usług służyła do wprowadzenia opisu wyliczania ceny oraz przykładowych jej wartości np.: Godzina lekcyjna: 36 PLN, rabaty: za zamówienie więcej niż 15 godzin 5 %, narzuty: brak. Drugim elementem systemu pomocnym przy wprowadzaniu opisów usług było forum internetowe, które zostało uruchomione na portalu platformy ELA-enT. Służyło ono do bieżącego i szybkiego wymieniania informacji pomiędzy opisującymi usługi a koordynatorami grup opisująco-testujących. Po opublikowaniu formularza do tworzenia opisów usług oraz uruchomieniu forum, rozpoczął się etap wprowadzania opisów usług. Przebiegał on w następujący sposób: Osoba opisująca wprowadzała do formularza propozycję opisu usługi. Wprowadzony opis był weryfikowany przez koordynatora a uwagi były publikowane na forum. Po zapoznaniu się z tymi uwagami osoba opisująca dokonywała poprawek w opisie swojej usługi i umieszczała informację o tym fakcie na forum. Poprawiony opis był po raz kolejny weryfikowany przez koordynatora. Proces opisywania danej usługi trwał aż do chwili, gdy jej opis został uznany przez koordynatora za wystarczający i pełny. Gotowy opis usługi był przekazywany programistom, którzy na jego podstawie projektowali odpowiednie elementy formularzy interfejsów użytkownika (projektowali formularze klienta oraz implementowali formularze usługodawcy) a także część funkcjonalną usługi. Zaprojektowane formularze klienta były wprowadzane do ontologii systemu, na podstawie której Manager Zadań automatycznie generował formularze wyszukiwania i kreator zawierania umowy. Jak okazało się już podczas wprowadzania pierwszych opisów usług, precyzyjne określanie cech usługi oraz sposobów, w jaki ma być ona zaimplementowana sprawiły duże trudności osobom opisującym. Ponieważ opisującymi były często osoby, które nie miały wielkiego doświadczenia w obsłudze komputera, Większość z nich miała trudności ze zrozumieniem potrzeby wprowadzania opisów w kategoriach cech, ich wartości oraz przeznaczenia. Taki sposób opisu był konieczny, ponieważ pozwalał na zaprojektowanie odpowiednich elementów formularzy takich jak pola edycyjne, przyciski opcji, listy itd. Opisujący mieli również duże problemy z podzieleniem dr Dariusz Mikułowski, mgr Marek Faderewski 6

7 informacji charakteryzujących ich usługę na poszczególne cechy tak, aby dało się na ich podstawie zaprogramować odpowiednie formularze. Wielu opisujących wprowadzało swoje opisy w taki sposób jakby publikowali tylko jedną (swoją własną) konkretną ofertę. Tymczasem wymaganiem stawianym przez koordynatorów było to, aby opisujący uogólnił swój opis na tyle, by po jego zaprogramowaniu w formie usługi można było dodawać możliwie jak najszersze spektrum ofert danej usługi. Jedną z przyczyn takiego stanu mogło być to, iż w formularzu istniały sekcje, które nie były przeznaczone do wypełniania a które były mylące dla wprowadzających opisy. Kolejnym problemem podczas wprowadzania opisów usług było to, że dość często zdarzało się, iż prawie kompletny opis usługi umieszczony w formularzu był tracony przez opisującego. Taka sytuacja była spowodowana niestabilną pracą serwera, zamknięciem się przeglądarki lub nie zatwierdzeniem całości wykonywanych operacji przez naciśnięcie przycisku Zapisz, który znajdował się na samym końcu formularza. Ponadto, komunikat o błędnie wprowadzonych danych lub ich pomyślnym zapisaniu był umieszczony w trudnym do odnalezienia miejscu, szczególnie dla osób niewidomych. Dlatego też koordynatorzy doradzali opisującym, aby redagowali oni kompletny opis cech usługi w pliku tekstowym a następnie wstawiali go do formularza w jednym kroku. Do formularza dodano także opcję tryb dla niewidomych, której włączenie powodowało, iż informacje o poprawnym zapisaniu danych lub błędach popełnionych podczas ich wprowadzania pojawiały się w formie wyskakujących okienek (alertów) w przeglądarce. Ta możliwość została pochwalona przez niewidomych użytkowników gdyż znacznie ułatwiła im pracę. dr Dariusz Mikułowski, mgr Marek Faderewski 7

8 3. Programowanie i instalacja usług w systemie ELA-enT Proces programowania usług w systemie ELA-enT rozpoczął się bezpośrednio po przygotowaniu pierwszych opisów usług tzn. około czerwca 2007 r. Pierwsze dwie usługi (Korepetycje i Zespół muzyczny) zostały zaimplementowane przez Grzegorza Terlikowskiego a były uruchomione na przełomie lipca i sierpnia 2007 roku. Usługi te stanowiły wzorzec dla pozostałych programistów, którymi było 15-stu studentów informatyki Akademii Podlaskiej w Siedlcach. Programowanie każdej nowej usługi przebiegało w następujących krokach: 1. Programista wybierał z pośród zatwierdzonych opisów usług opis usługi, którą chce zaprogramować. Następnie zgłaszał swój wybór administratorowi systemu (M. Faderewskiemu). 2. Następnie rozpoczynał się proces programowania, który zazwyczaj trwał około 2-3 tygodnie. Po tym etapie powstawała aplikacja oraz tzw. ontologia dla usługi. W tej ontologii zebrane były wszystkie cechy usługi wraz możliwymi dla nich wartościami. Każda cecha posiadała również opisy swoich dodatkowych właściwości takich jak: czy cecha ma być kryterium przy wyszukiwaniu przez klienta, Czy cecha jest obowiązkowa do wypełnienia w formularzach dodawania i wyszukiwania ofert, według jakiego wzorca ma być ona walidowana, itd. 3. Programista przekazywał administratorowi ontologię dla swojej usługi, która następnie była wprowadzana do słownika usług systemu ELA-enT. Aplikacja słownika usług została zrealizowana przez M. Faderewskiego. Początkowo opisy ontologii usług wprowadzane były do słownika przez M. Faderewskiego (19 ontologii). Pozostałe (55 ontologii) wprowadził do słownika M. Stępniak. Wprowadzenie każdej z ontologii zajmowało ok. 2-3 dni, przy czym w niektórych ontologiach konieczne było nanoszenie korekt. 4. Dla zaimplementowanej aplikacji na serwerze projektu ( administrator tworzył niezbędne katalogi oraz elementy konfiguracji. Następnie programista instalował swoją aplikację na serwerze projektu i dostrajał ją w celu zapewnienia jej poprawnego działania w systemie. 5. Po podłączeniu usługa przechodziła wewnętrzny test poprawności działania przeprowadzany przez zespół ELA-enT. Błędy i nieprawidłowości wykryte w czasie tego testu były na bieżąco poprawiane przez programistę. Na platformie zaprogramowano i uruchomiono łącznie 74 usługi. Zaimplementowane, uruchomione i wstępnie przetestowane usługi przechodziły następnie do fazy testowania przez przyszłych użytkowników. dr Dariusz Mikułowski, mgr Marek Faderewski 8

9 4. Testowanie uruchomionych usług Pierwsze testy platformy ELA-enT zostały przeprowadzone na przełomie 2007 i 2008 roku. Testowane były wówczas dwie prototypowe usługi: korepetycje i zespół muzyczny. Wzięło w nich udział sześciu testerów, wśród których były 4 osoby niepełnosprawne (dwie niewidome i dwie słabowidzące) oraz dwie osoby pełnosprawne. Uwagi zebrane w trakcie tych testów zostały umieszczone w raportach a następnie były uwzględnione podczas dalszych prac nad samym systemem oraz kolejnymi programowanymi usługami. Drugi etap testowania został przeprowadzony w okresie od sierpnia 2009 do lutego 2010 r. Z pośród 74 uruchomionych w systemie usług zostały przeprowadzone testy 40 usług. Testowanie, podobnie jak tworzenie opisów usług było koordynowane przez koordynatorów (M. Faderewskiego i D. Mikułowskiego). Każdy z koordynatorów nadzorował testowanie 20 usług. 15 z nich zostało przetestowanych wirtualnie (zawierane umowy oraz konta użytkowników były fikcyjne) natomiast 5 było testowanych w formie in vivo (doszło do zawarcia prawdziwych umów, które następnie zostały zrealizowane przez usługodawców). W celu ułatwienia procesu testowania koordynatorzy opracowali instrukcję (stanowi ona załącznik do niniejszego raportu), która w szczegółowy sposób omawiała kolejne kroki procesu testowania nie omawiając jednak testowania jakiejś konkretnej usługi. Wirtualne testowanie platformy przez każdą osobę testującą przebiegało w następujących krokach: 1. Osoba testująca zapoznawała się z instrukcją testowania platformy. 2. Osoba testująca testowała jedną usługę jako usługodawca oraz tę samą usługę jako klient. W trakcie testowania jako usługodawca testujący dodawał swoją ofertę poprzez wypełnienie odpowiedniego formularza w aplikacji danej usługi. Następnie korzystając z formularza wyszukiwania odpowiedniego dla tej usługi, odnajdywał dodaną ofertę i przechodził przez proces kreowania kontraktu. W tym procesie testujący najpierw ustalał szczegóły kontraktu, a następnie go podpisywał. Po jego utworzeniu kontrakt był automatycznie wysyłany przez system do wykonawcy (usługodawcy). W kolejnym kroku należało podpisać otrzymany kontrakt jako usługodawca i wytworzyć rachunek, który otrzyma zamawiający (usługobiorca). 3. Osoba testująca testowała 3 inne usługi tylko jako zamawiający. W tym celu musiała ona wyszukać oferty trzech usług wskazanych przez koordynatora i doprowadzić do zawarcia umów z odnalezionymi usługodawcami. 4. Po przeprowadzeniu testu osoba testująca opracowywała raport, w którym zbierała wszystkie uwagi, sugestie i spostrzeżenia, jakie nasunęły się jej w czasie całego procesu. dr Dariusz Mikułowski, mgr Marek Faderewski 9

10 W celu ułatwienia sporządzania raportów przez testujących koordynatorzy opracowali szablon dokumentu raportu (stanowi on załącznik do niniejszego opracowania), który otrzymywał każdy testujący. Sporządzenie raportu przez testującego polegało zatem na wypełnieniu formularza raportu, w którym na podstawie przebiegu czynności związanych z testowaniem platformy musiał się on odnieść do zawartych tam pytań, podpowiedzi i wskazówek. W II etapie testów wzięły udział 33 osoby, wśród których było 21 osób niepełnosprawnych oraz 12 osób pełnosprawnych. Osoby niepełnosprawne stanowiły zatem ponad 60 % testerów, wśród których większość stanowiły osoby z dysfunkcją wzroku (ponad 70 %). Poniżej przedstawiono wykresy, które charakteryzują struktury poszczególnych grup testujących. Podział testerów sprawni/niepełnosprawni 36% Podział testerów niepełnosprawnych wg. niepełnosprawności 27% 27% 64% 46% Niepełnosprawni Pełnosprawni Niewidomy Słabowidzący Inni Wykres 1. Podział testerów. Testy prowadzone były najczęściej w systemie operacyjnym Windows XP (ponad 80 %). Kilka osób wykonało test używając systemu Windows Vista. Niektórzy użyli również innych systemów, takich jak: Windows Millenium, Windows 7, Linux Debian czy MacOS. Przeglądarką najczęściej używaną podczas testów był Internet Explorer (24 razy). Nieco mniej razy używana była Mozilla FireFox (11 razy). Testerzy wykorzystywali także mniej popularne przeglądarki takie jak: Google Chrome, Wyzo, Opera, Safari, Avant Browser czy tekstową przeglądarkę Lynx znaną z systemu Linux. Poniższe wykresy przedstawiają dokładny podział wykorzystanych systemów operacyjnych. oraz przeglądarek internetowych. Ilość użyć IE FF Google Chrome Wyzo Avant Opera Safari Windows XP Windows Vista Windows Me Windows 7 Debian Mac OS Lynx Ilość użyć Wykres 2. Podział wg użytych systemów operacyjnych i przeglądarek internetowych. dr Dariusz Mikułowski, mgr Marek Faderewski 10

11 Wśród osób z dysfunkcją wzroku wykorzystywane było również specjalistyczne oprogramowanie powiększająco-udźwiękawiające. Spośród osób, które używały takiego oprogramowania (12 testujących) najczęściej używany był program Jaws oraz Supernowa. Osoby niewidome i słabowidzące wykorzystywały także darmowy program mówiący NVDA oraz programy Window-Eyes i Hal Uwagi ogólne W raportach opisujących testowanie platformy ELA-enT osoby testujące zgłosiły wiele uwag ogólnych dotyczących jej funkcjonowania, wyglądu oraz problemów, jakie wystąpiły w czasie jej użytkowania. Najczęściej zgłaszanym problemem był zdaniem testujących zły dobór kolorów, czcionek, nieczytelność stron portalu zarówno w interfejsie klienta jak i usługodawcy. Wskazywali oni na to, iż wiele elementów formularzy posiada szare, nieodróżniające się kolory oraz niezbyt wyróżniającą się czcionkę. Uwaga ta była szczególnie eksponowana przez słabowidzących użytkowników platformy. Ten problem został zgłoszony przez 24 osoby testujące (ponad 70 %). Inne zastrzeżenia dotyczące również wyglądu portalu ale tym razem sugerujące zmiany układu menu po stronie usługodawcy oraz klienta pozwalające na lepsze wyeksponowanie niektórych opcji zostały zgłoszone przez 6 osób testujących. Innym, często występującym problemem było pojawianie się angielskich komunikatów oraz występowanie słów angielskich w opisach elementów formularzy a także treści kontraktów i rachunków. Uwaga ta została zgłoszona przez 15 osób testujących (około 45 %). Osoby testujące wskazały także na występowanie błędów ortograficznych, gramatycznych i literowych, które pojawiały się w interfejsach usługodawców m.in. takich usług jak: Skanowanie książek czy Pranie i prasowanie. Błędy tego rodzaju występowały częściej w interfejsach usługodawców, które były programowane przez różnych programistów. Nie zawsze implementowali oni swoje formularze na tyle starannie, aby wyeliminować z nich angielskie komunikaty i słowa oraz błędy w nazwach elementów takich jak: pola formularzy, etykiety, podpowiedzi itp. Pochwała idei powstania samej platformy oraz sugestia jej wdrożenia Została wyrażona przez 14 osób (ponad 40 % testujących). Podkreślali oni, że prawdziwe uruchomienie takiego portalu byłoby bardzo pomocne w szczególności dla osób niepełnosprawnych, które mogłyby za jej pomocą znajdować zatrudnienie oraz korzystać z wielu różnych potrzebnych im usług. W tych uwagach został również pochwalony pomysł użycia elektronicznego podpisu, chociaż jeden z testujących zasugerował jego usunięcie. 11 osób testujących uznało, iż problemem dla nich było częste pojawianie się wyskakujących okienek z informacją o błędnych certyfikatach. Jego rozwiązaniem byłoby zakupienie dr Dariusz Mikułowski, mgr Marek Faderewski 11

12 i zastosowanie kwalifikowanego certyfikatu dla serwera platformy. Często zgłaszaną sugestią była również propozycja wprowadzenia systemu wspólnego logowania się zarówno klientów jak i usługodawców. Została ona zgłoszona przez 10 osób testujących (około 30 %). Dziewięć osób zaproponowało także dodanie opisu korzystania z platformy na głównej stronie a nie umieszczenie go w niezbyt wyeksponowanym systemie pomocy. Kilka osób testujących krytykowało nieporządek w generowanych umowach i rachunkach. W przeciwieństwie do nich, dwie osoby uznały umowy i rachunki za czytelne i przejrzyste. Kilka osób testujących wskazywało na wolną lub nie stabilną pracę serwera oraz na bardzo długi czas wyszukiwania usług. Tego rodzaju błędy były spowodowane faktem, iż bardzo często podczas testowania jednych usług, inne w tym samym czasie były podłączane do systemu. Z tych powodów serwer platformy był zatrzymywany i uruchamiany w czasie pracy testujących, co powodowało, iż nie mogli oni wykonywać swoich czynności lub tracili wprowadzane dane. Ciekawszymi pomysłami dotyczącymi funkcjonowania platformy były: Sugestia dodania funkcji wysyłania informacji lub SMS o kontraktach otrzymanych przez klienta lub usługodawcę - zgłoszona przez 7 osób. Sugestia podłączenia do systemu słownika nazw własnych - zgłoszona przez jedną osobę. Propozycja utworzenia 24-godzinnego systemu pomocy (tzw. helpdesk) - zgłoszona przez jedną osobę. Sugestia dodania systemu oceny usług - zgłoszona przez dwie osoby. Propozycja dodania funkcji pozwalającej na negocjowanie kontraktu - zgłoszona przez 6 osób. Sugestia dodania możliwości wysłania wiadomości lub umożliwienia nawiązania kontaktu z usługodawcą przed zawarciem kontraktu - zgłoszona przez 5 osób. Sugestia podłączenia do systemu możliwości wykonywania elektronicznych płatności - zgłoszona przez jedną osobę. Pozostałymi sporadycznie zgłaszanymi problemami i propozycjami dotyczącymi ogólnego funkcjonowania platformy były: Sugestia wprowadzenia kategorii lub uporządkowania alfabetycznego serwerów usług - zgłoszona przez pięciu testujących. Sugestia dodania wszędzie gdzie jest to możliwe w atrybutach z określonymi wartościami opcji zatytułowanej inne pozwalającej na wpisanie dowolnej wartości - zgłaszana przez pięciu testujących. Sugestia dodania automatycznego lektora odczytującego głosem elementy portalu. dr Dariusz Mikułowski, mgr Marek Faderewski 12

13 Wskazanie na różniące się między sobą (po stronie usługodawcy i po stronie klienta) formaty rachunków i umów dotyczących wykonania tej samej usługi - zgłoszona przez czterech testujących. Wskazanie braku informacji o błędnym wpisaniu danych wyświetlanych w formie wyskakujących okienek. problem zrozumienia podziału na usługodawców i usługobiorców i oddzielenia, jako odrębnych części systemu serwerów usług. Propozycja umieszczenia przed formularzem informacji o tym, które pola są obowiązkowe do wypełnienia. Sugestia utworzenia różnych wersji językowych platformy. Propozycja dodania funkcji przypominania hasła. Problemy z logowaniem się przy pomocy nazwy użytkownika, która zawierała duże litery oraz przy użyciu hasła określanego jako trudne (zawierającego znaki nie alfanumeryczne takie # % +). W raportach dotyczących prawdziwego testowania platformy (in vivo) pojawiły się również uwagi, które nie zostały dostrzeżone podczas sprawdzania (tylko wirtualnie) użycia usług. Były to następujące problemy oraz propozycje: sugestia dodania mechanizmów zapewniających sprawdzenie wiarygodności wykonawców (szczególnie osób niepełnosprawnych) przez klientów zamawiających wykonanie usługi, propozycja dodania do platformy możliwości wycofania się z podpisanego kontraktu (przy zgodzie obu stron możliwość polubownego zerwania umowy), potrzeba konsultacji treści umów i rachunków z prawnikami i specjalistami od prawa skarbowego, sugestia szczególnego wyeksponowania niektórych usług. propozycja dodania możliwości zawarcia umowy poza platformą Rejestracja Każda z osób zgłaszająca nową usługę lub testująca system musiała zarejestrować się poprzez przygotowany w tym celu formularz rejestracyjny ( registration.jsp). Formularz ten jest bardzo rozbudowany i zawiera wiele pól obowiązkowych oraz kilka nieobowiązkowych. Tak duża ilość koniecznych do podania danych niezbędna jest ze względu na automatycznie generowane w systemie dokumenty (umowy i rachunki). W trakcie rejestracji wielu testerów bardzo dobrze oceniło formularz rejestracyjny jak też przebieg całego procesu rejestracji (łącznie z wysłaniem wiadomości z hasłem oraz linkiem aktywacyjnym) około 50 % osób. dr Dariusz Mikułowski, mgr Marek Faderewski 13

14 Kilku osobom (6 testujących) podobał się zastosowany mechanizm automatycznego dopasowywania urzędu skarbowego do wprowadzonego numeru NIP oraz automatyczny dobór banku do wprowadzonego numeru konta. Kilka osób (8) miało zaś problemy z automatycznym dopasowaniem US i/lub konta bankowego. Wynikały one z nieaktualnych baz danych Urzędów Skarbowych oraz banków w Polsce, na podstawie których był programowany formularz rejestracyjny. Niektórzy testerzy zwracali uwagę na to, iż musieli podać za dużo wymaganych danych w formularzu rejestracyjnym. Jednakże jak już wspomniano, taka ilość obowiązkowych danych jest wymagana ze względu na generowane przez system dokumenty. Osoby testujące sygnalizowały także pojedyncze uwagi takie jak: propozycja zamiany sposobu przydzielania hasła polegającego na tym, że system wysyła wiadomość z automatycznie wygenerowanym hasłem, na możliwość samodzielnego jego ustalania przez użytkownika, propozycja utworzenia dwuetapowej rejestracji, osobnej dla klienta i osobnej dla wykonawcy (usługodawcy). Funkcjonalność ta została wprowadzona z powodu pojawienia się takiej konieczności w trakcie testów tzw. in vivo. Zostanie to szerzej opisane w dalszej części niniejszego opracowania, brak regulaminu korzystania z platformy oraz brak informacji, że z systemu mogą korzystać tylko osoby pełnoletnie, pochwała zastosowanego rozwiązania polegającego na użyciu w formularzach pól dzielonych przeznaczonych na wpisywanie takich danych jak np. kod pocztowy czy nip. Kilku testerów zwróciło też uwagę na problemy z nawigacją za pomocą klawiatury oraz nieprawidłowe działanie formularza podczas jego wypełniania przy użyciu specjalistycznego oprogramowania typu screenreader. Uwagi testerów In vivo W usługach testowanych na żywo testerzy zwrócili uwagę na następujące zagadnienia: wymogi rejestracyjne są zbyt rygorystyczne dla zamawiających, gdyż muszą oni podawać taką samą dużą ilość danych jak wykonawcy, a dane te (zamawiających) w większości nie są nigdzie wykorzystywane (chyba, że wystąpiliby w roli wykonawców). Problem ten został rozwiązany w trakcie testów poprzez rozdzielenie rejestracji na rejestrację tylko jako zamawiający gdzie należało podać wyłącznie dane konieczne dla zamawiającego oraz na rejestrację dla wykonawcy gdzie należało podać wszystkie dane. Jeśli użytkownik zarejestrowany, jako zamawiający będzie chciał zaoferować jakąś usługę, wówczas będzie musiał uzupełnić dane w swoim profilu. dr Dariusz Mikułowski, mgr Marek Faderewski 14

15 W trakcie testowania problem ten okazał się na tyle poważny, że zahamował na pewien czas testowanie platformy. Instytucje, które miały zamówić usługi, kategorycznie nie zgodziły się na podanie tak dużej ilości danych, które nie byłyby nigdzie użyte. system eliminuje osoby, które nie posiadają numeru konta bankowego, gdyż to pole jest obowiązkowe, system eliminuje osoby, które nie posiadają nr PESEL, gdyż to pole jest wymagane brak szczegółowego wyjaśnienia tego, po co określono jako wymagane poszczególne dane, które należy podać w procesie rejestracji użytkownika, brak opcji, dzięki której należy wyrazić jawną zgodę na generowanie umów i rachunków, brak w formularzu rejestracyjnym pola na podanie tytułu osoby rejestrującej się (prof., dr, mgr itp.), brak wyjaśnienia, że w przypadku rejestracji instytucji, podawane dane osobowe dotyczą osoby reprezentującej tę instytucję, brak wyjaśnienia, że adres, który należy podać oznacza adres stałego zameldowania Wnioski Po przeanalizowaniu wszystkich uwag zgłoszonych przez osoby testujące platformę a w szczególności formularz rejestracyjny oraz zbadaniu przyczyn powstania niektórych błędów, można dojść do kilku następujących wniosków: Należy usprawnić mechanizm doboru urzędu skarbowego na podstawie numeru NIP. Urząd skarbowy powinien być mianowicie dobierany na podstawie adresu zameldowania, a nie numeru NIP gdyż ten przypisywany jest do urzędu, który go wydał. Gdy dana osoba zmieni miejsce zamieszkania, zmianie ulega również urząd skarbowy, natomiast jej NIP pozostaje niezmieniony. Należy rozważyć wprowadzenie mechanizmu automatycznej aktualizacji baz danych informacji o urzędach skarbowych i bankach. Należy opracować i zamieścić na platformie regulamin korzystania z niej. Należy zmienić pole nr konta bankowego z pola obowiązkowego na nieobowiązkowe, a co za tym idzie we wszystkich usługach należy uwzględnić ten wymóg. Wykonawca, który nie podał numeru konta bankowego nie powinien mieć możliwości akceptowania formy płatności przelew. Należy zweryfikować, czy istnieją w Polsce osoby które nie posiadają nr PESEL, jeśli tak to należy rozważyć wprowadzenie nr PESEL jako pola nieobowiązkowego. Jednakże wówczas trzeba też wyjaśnić pod względem prawnym, czy osoby nieposiadające nr PESEL mogą być wystawcami rachunków. dr Dariusz Mikułowski, mgr Marek Faderewski 15

16 Należy lepiej wyjaśnić użytkownikom, po co zbierane są poszczególne dane na ich temat. Należy dodać opcję, dzięki której użytkownik będzie mógł wyrazić jawną zgodę na generowanie dokumentów z systemu (umowy i rachunki), Należy dodać pole Tytuł pozwalające na wprowadzenie tytułu (naukowego, zawodowego lub formalnego) rejestrującej się osoby. Należy wprowadzić wyjaśnienie, iż adres podawany przy rejestracji jest adresem stałego zameldowania. W przypadku rejestracji instytucji/firmy powinno być także dodane wyjaśnienie, że dane osobowe dotyczą osoby reprezentującej tę instytucję Dodanie oferty w usłudze Kolejnym etapem testowania platformy ELA-enT przez osobę testującą było sprawdzenie działania przydzielonej jej przez koordynatora usługi. Odbywało się ono poprzez dodanie oferty usługi za pośrednictwem interfejsu WWW zaimplementowanego na odpowiednim serwerze usług. W opracowanych po przeprowadzeniu testowania raportach osoby testujące zgłosiły również wiele uwag, problemów i sugestii dotyczących wyglądu, oraz działania poszczególnych serwerów usług. Najczęściej zgłaszanymi problemami występującymi podczas tego etapu testowania platformy były błędy związane z nie prawidłowym merytorycznie doborem poszczególnych elementów formularzy służących do dodawania ofert usług. Osoby testujące zgłaszały brak niektórych elementów tych formularzy, ich nadmiar, złe umiejscowienie lub rodzaj. Część z tych błędów była spowodowana nie dokładnym zastosowaniem się programistów do wskazówek zawartych w opisach usług wprowadzonych do systemu przez opisujących. Część z tych problemów była jednak spowodowana przez samych testujących, którzy we wcześniejszym etapie wprowadzili do systemu niezbyt dokładne i mało precyzyjne opisy swoich usług. Powodem mogło być także to, że wiele usług było testowanych przez inne osoby niż te, które wprowadzały ich opisy. Pomyłki dotyczące złego doboru elementów formularzy zostały zgłoszone przez 21 osób testujących (około 65 %) a wystąpiły one w interfejsach takich usług jak np.: skanowanie książek, czy transport. Pięciu testujących uznało, że interfejs służący do dodawania oferty po stronie usługodawcy jest niedopracowany. Ten problem wystąpił w formularzach takich usług jak: Tłumaczenia czy Ankietowanie. dr Dariusz Mikułowski, mgr Marek Faderewski 16

17 Rysunek 1. Fragment interfejsu usługi Tłumaczenia W raportach dotyczących testowania kilku usług znalazła się także pochwała dobrego merytorycznie doboru elementów w formularzach do zgłaszania ofert. Prawidłowy dobór elementów formularzy został wskazany przez cztery osoby testujące a dotyczył takich usług jak np.: Turystyka młodzieżowa czy Masaż. Innym często sygnalizowanym problemem był także nie prawidłowy sposób obliczania ceny za usługę przez jej aplikację. Wystąpił on w interfejsach takich usług jak np.: Nauka języków, Analiza danych statystycznych, Studio nagrań lektorskich, Wygłaszanie odczytów czy Przepisywanie z audio na tekst. Problem ten został zgłoszony łącznie przez 14 osób testujących. Nieprawidłowe wyliczanie innych wartości takich jak cena netto, podatek czy ubezpieczenia umieszczanych w rachunkach zgłosiły cztery osoby testujące. Często wskazywanym problemem była również mała dostępność kalendarza w interfejsie służącym do dodawania oferty usług. Ta niedogodność była podkreślana szczególnie przez użytkowników niewidomych. Jedną ze zgłaszanych wad kalendarza był mylący dobór nazw statusów opisujących terminy wybrane przez usługodawcę, jako czas jego pracy oraz terminy, w których nie może on wykonywać swojej działalności. Przedziały czasowe, które usługodawca zarezerwował na wykonywanie swojej pracy były oznaczane jako zajęte natomiast przedziały czasowe w których usługodawca nie pracuje - jako wolne. dr Dariusz Mikułowski, mgr Marek Faderewski 17

18 Rysunek 2. Przykład kalendarza tekstowego. Problem mylących nazw opisujących przedziały czasowe został wskazany przez 7 osób testujących, natomiast ogólna mała dostępność i wygląd kalendarza były sygnalizowane przez 12 osób. Trzech testerów zgłosiło także potrzebę dodania do kalendarza legendy, która opisywałaby znaczenie poszczególnych kolorów, jakimi są oznaczane przedziały czasowe. Wśród testujących były też jednak osoby, które pochwaliły wygląd i funkcjonalność kalendarza ze względu na jego estetyczny i ładny graficznie wygląd. Osoby testujące wskazywały także na problemy związane z podpisywaniem i akceptowaniem umów przysłanych przez klientów i wytwarzaniem rachunków za wykonaną usługę. Jednym z elementów, który należałoby dodać do interfejsów usługodawców powinna być możliwość wydrukowania umów i rachunków lub wygenerowania plików pdf z tych dokumentów. Taką sugestię wyraziło 7 osób testujących. Niektórzy testerzy uważali, że umowy zawierają zbyt dużo szczegółowych mało odróżniających się informacji co utrudnia znalezienie przycisku służącego do ich zaakceptowania i przesłania do klienta. Pięć osób testujących zauważyło, że system pozwala na zawarcie umowy z datą wcześniejszą niż wykonanie samej usługi, co oczywiście w systemie informatycznym nie powinno być możliwe. Podczas sprawdzania działania interfejsów do dodawania ofert usług wiele osób testujących miało problemy z sfinalizowaniem dodawania swojej oferty. Były one spowodowane brakiem jawnie napisanej informacji o kolejnych krokach dodawania oferty. Koordynatorzy musieli na bieżąco podpowiadać testującym, jakie czynności powinni wykonać w kolejnych krokach dodawania swojej oferty. Czynności, jakie należy wykonać w celu dodania oferty były opisane w systemie pomocy platformy umieszczonej na portalu edukacyjnym. Jednakże, jak można wnioskować na podstawie zgłaszanych przez testujących uwag, nie wielu z nich skorzystało z tej pomocy. Problem braku informacji o kolejnych krokach procesu dodawania oferty został zgłoszony łącznie przez 9 osób testujących. Ciekawą propozycją związaną z dodawaniem oferty był pomysł zaprogramowania dr Dariusz Mikułowski, mgr Marek Faderewski 18

19 możliwości przerwania wprowadzania oferty i zapamiętania częściowych danych w celu ich późniejszego wykorzystania. Osoby testujące, które przy sprawdzaniu możliwości platformy korzystały z programów odczytu ekranu zgłaszały uwagi dotyczące nawigacji oraz małej czytelności formularzy do dodawania ofert. Czterech testujących zgłosiło problem braku odczytywania etykiet znajdujących się obok pól edycyjnych oraz list wyboru przez screnreader. Podkreślali oni również niewygodę używania tabel, brak informacji wyświetlanych w wyskakujących okienkach oraz elementów takich jak wielopoziomowe nagłówki czy listy ułatwiające nawigację przy pomocy screenreaderów. W raportach dotyczących przebiegu testowania platformy znalazły się także uwagi dotyczące wyglądu oraz szaty graficznej interfejsów dodawania ofert. Sugestia jej poprawy została wyrażona przez trzy osoby testujące a dotyczyła takich usług jak np.: Nauka języków oraz Przepisywanie z audio na tekst. Pochwałę wyglądu interfejsu usługi wyraziło czterech testujących. Innymi funkcjami interfejsów dodawania ofert, które znalazły uznanie były: możliwość wprowadzania różnych wariantów wykonywanych usług przez jednego usługodawcę oraz możliwość precyzowania dodatkowych wymagań, jakie powinien spełnić klient, aby usługa mogła być wykonana. Osoby testujące zgłaszały także problemy techniczne, jakie pojawiły się podczas dodawania ofert na serwerach usług. Były to takie niedogodności jak: utrata wprowadzonych danych oferty spowodowana wyłączeniem się serwera lub jego nie stabilną pracą oraz pojawiające się wyskakujące komunikaty i zamykanie się przeglądarki przy akceptacji kontraktu po stronie usługi. Takie niedogodności pojawiły się w szczególności u osób testujących, które używały przeglądarki Mosilla FireFox. Interesującymi pomysłami zasugerowanymi przez niektórych testujących były: sugestia rozszerzenia usługi o możliwość dodania całej firmy, sugestia dodania pola na wpisanie powodu odrzucenia umowy przez usługodawcę, sugestia dodania listy zamówionych usług przez klientów u usługodawcy. Innymi, sporadycznie występującymi uwagami osób testujących były: sugestia alfabetycznego uporządkowania listy języków, która była częścią formularzy dodawania oferty takich usług jak np.: nauka języków czy nauczanie brajla, sugestia dodania innego miejsca wykonywania usługi prócz usługodawca/klient - zgłoszona przez czterech testujących, problemy z zaakceptowaniem kontraktów po stronie usługodawcy - zgłoszone przez trzech testujących, sugestia usunięcia kalendarza z interfejsu dodawania oferty usługi - zgłoszona w przypadku trzech usług, dr Dariusz Mikułowski, mgr Marek Faderewski 19

20 brak wyszukiwarki zawartych kontraktów w interfejsie usługodawcy - zgłoszony przez trzech testujących, sugestia przesyłania do klienta informacji o cząstkowych cenach za wykonanie usługi - zgłoszona przez trzech testujących, pochwała działania funkcji zatwierdzania kontraktu i tworzenia rachunku - zgłoszona przez trzech testujących, brak informacji o danych zalokowanego użytkownika w interfejsie usługodawcy - zgłoszona przez trzech testujących, sugestia usunięcia w niektórych usługach nie potrzebnego pola zawierającego koszty dojazdu usługodawcy do miejsca pracy, sugestia wprowadzenia szybszego akceptowania i podpisywania kontraktów i rachunków w interfejsie usługodawcy za pomocą tylko jednego przycisku, brak informacji o tym, czy kwoty umieszczane w dokumencie rachunku są kwotami brutto, czy netto. Wnioski Po przeanalizowaniu wszystkich uwag zgłoszonych przez osoby testujące platformę a w szczególności formularze służące do dodawania ofert usług oraz zbadaniu przyczyn powstania niektórych błędów, można dojść do kilku następujących wniosków: Należy w dokładniejszy lub inny sposób tworzyć opisy usług a następnie lepiej programować formularze ofert na podstawie tych opisów. Opisy usług, które były wprowadzane przez samych przyszłych użytkowników były często zbyt mało precyzyjne. Koordynatorzy mieli często trudności ze zobligowaniem opisujących do odpowiedniego sformułowania cech i wartości opisujących usługę. Wynikało to z trudności w przestawieniu się opisujących na bardziej abstrakcyjne myślenie na temat swojej usługi. Z tego powodu programiści nie mogli zaimplementować odpowiednich funkcjonalności interfejsu usługodawcy. Należy zaimplementować dwie wersje kalendarza, z których pierwsza byłaby podobna do graficznej obecnie zaimplementowanej. Ta wersja powinna być przeznaczona dla pełnosprawnych użytkowników. Należy dodać do niej legendę opisującą znaczenie poszczególnych kolorów oraz funkcje ułatwiające nawigację w ramach większych ram czasowych. Druga wersja kalendarza powinna mieć bardziej tekstowy charakter i uproszczony wygląd, który nie sprawiałby problemów użytkownikom niepełnosprawnym wzrokowo. Użytkownik powinien mieć możliwość wybrania, której wersji kalendarza chce używać, poprzez np. konfigurację w swoim profilu. dr Dariusz Mikułowski, mgr Marek Faderewski 20

21 Do interfejsów usługodawców wszystkich usług należy dodać możliwość wydrukowania umów i rachunków i/lub wygenerowania plików pdf z tych dokumentów. Należy zabezpieczyć system przed możliwością zawarcia umowy z datą wcześniejszą niż data wykonania samej usługi. Warto zaimplementować w interfejsach usługodawców możliwość przerwania wprowadzania oferty i zapamiętania częściowych danych. Warto również dodać możliwość informowania klientów i usługodawców drogą SMS-ową lub -ową o otrzymanych umowach i rachunkach. Należy dostosować wygląd interfejsów usług oraz klientów do wymagań dostępności stron internetowych sformułowanych przez organizację W3C w standardach Web Accessibility Initiative WAI) ( Warto rozszerzyć funkcjonalność interfejsu usługi o możliwość dodania oferty jako firmy. Do interfejsu usługodawcy należy dodać pole przeznaczone na wpisanie powodu odrzucenia umowy przez usługodawcę, którego zawartość byłaby przesyłana do klienta. Do interfejsu usługodawcy należy dodać funkcjonalność pozwalającą automatycznie tworzyć listę usług zamówionych przez klientów. W momencie gdy usługodawca zatwierdzi umowę od klienta np. na wykonanie zabiegu masażu, klient ten oraz godzina zabiegu umieszczane są na liście zabiegowej. Do interfejsów usługodawców należy dodać możliwość wyświetlania danych zalogowanego użytkownika. Wszędzie gdzie występuje lista miejsc wykonywania usługi Należy dodać element opisujący inne miejsce wykonywania usługi prócz istniejących tam elementów u usługodawcy oraz u klienta. Należy dodać do interfejsu usługodawcy wyszukiwarkę zgromadzonych przez niego kontraktów. Należy dodać funkcjonalność pozwalającą na przesyłanie do klienta informacji o cząstkowych cenach za wykonanie usługi (szczegółowy cennik). Należy dodać informację o tym, czy kwoty umieszczane w dokumencie rachunku są kwotami brutto, czy netto Wyszukanie oferty i zawarcie umowy z wykonawcą Ten krok testowania platformy był przeprowadzany za pomocą aplikacji klienta ( Polegał on na odszukaniu przez osobę testującą usługi w drzewie kategorii a następnie wypełnieniu formularza do wyszukiwania ofert danej usługi. Po wyszukaniu dr Dariusz Mikułowski, mgr Marek Faderewski 21

22 ofert należało wybrać odpowiadającą klientowi ofertę i zawrzeć umowę na jej wykonanie z wykonawcą tej usługi. Po zatwierdzeniu umowy i wystawieniu rachunku przez wykonawcę należało sprawdzić poprawność treści wygenerowanych przez system dokumentów: umowy podpisanej przez wykonawcę i wystawionego przez niego rachunku. Uwagi testerów Podczas wykonywania sprawdzania działania usług od strony klienta testerzy już na samym początku zwrócili uwagę na nieprawidłowy ich zdaniem dobór kategorii dla usług. Za niezbyt trafnie uporządkowane uznano około 30 % testowanych usług. Jednocześnie w przypadku około 15 % usług testujący orzekli ich umiejscowienie w odpowiednich dla nich kategoriach. Problem ten został dość szybko wyeliminowany przez ponowne przeanalizowanie struktury drzewa kategorii i opracowanie nowego ich podziału. Testujący zasugerowali także dodanie wyszukiwarki usług, która ułatwiłaby odnajdywanie usług w coraz to bardziej rozbudowującej się strukturze kategorii. Wielu testerów pozytywnie oceniło formularze do wyszukiwania ofert, w szczególności za ich precyzję i dokładność (około 40 % testowanych usług). Jednocześnie, wielu testerów zwróciło także uwagę na to, że w formularzach często występuje niepoprawny merytorycznie dobór pól, który nie pasuje do charakteru i przeznaczenia danej usługi (około 40 % testowanych usług). Problem ten zgłoszono na przykład w przypadku usług Ankietowanie, Klinika, Transport, Przepisywanie z audio na tekst, Zespół muzyczny. Przykładowo w formularzu do wyszukiwania ofert usługi zespół muzyczny brakuje pola Zaliczka w którym klient mógłby podać, jakiej wysokości zaliczkę może zapłacić, a usługodawca - jakiej wysokości zaliczki oczekuje. Testerzy uznali również, że podczas wyszukiwania usług są stosowane zbyt rygorystyczne kryteria (np. jest wymagane wypełnienie zbyt dużej liczby obowiązkowych pól) (około 30 % testowanych usług). Mimo wielu podejmowanych prób bardzo często testerom nie udawało się doprowadzić do odnalezienia żadnej oferty. Wynikało to najczęściej z faktu, że w systemie było opublikowanych stosunkowo mało ofert. Testerzy słusznie zasugerowali, aby w przypadku, gdy nie uda się dopasować żadnej oferty, system informował o przyczynach takiego nie dopasowania oraz podawał, jakie kryteria nie zostały spełnione. Wydaje się to ciekawą propozycją ulepszenia mechanizmu wyszukiwania usług. Osoby testujące zgłaszały również następujące uwagi i spostrzeżenia dotyczące działania oraz wyglądu formularzy do wyszukiwania ofert usługodawców: Dobrym rozwiązaniem jest funkcja podświetlania aktualnie edytowanego pola, czy też możliwość wyboru daty z kalendarza obok pola przeznaczonego na wpisanie daty. dr Dariusz Mikułowski, mgr Marek Faderewski 22

23 Rysunek 3. Podświetlenie aktualnie edytowanego pola. Rysunek 4. Kalendarzyk ułatwiający wprowadzenie daty. Sugestia usunięcia części pola przeznaczonego na wprowadzanie sekund w polach służących do określania czasu wykonywania usługi. Sugestia uporządkowania kolejności wyświetlania dni tygodnia na liście Dni pracy. Dni te wyświetlane są obecnie alfabetycznie nie zaś w kolejności chronologicznej. Sugestia usunięcia w formularzach do wyszukiwania ofert dla niektórych usług informacji lokalizacyjnych takich jak województwo czy miejscowość oraz czasowych takich jak godziny świadczenia usługi. W niektórych usługach wydają się one zbędne, ponieważ nie ma znaczenia, skąd będzie pochodził wykonawca usługi. Propozycja dodania wyszukiwarki kodów pocztowych, np. w usłudze Transport polegającej na przewiezieniu przesyłki ze wskazanego adresu do innego miejsca. W formularzu do wyszukiwania takich usług należy podać kody pocztowe miejsc wysyłki i odbioru paczki, których klient nie musi przecież znać. Wyszukiwarka kodów bardzo ułatwiłaby takie zadanie. Sugestia dodania w przypadku kilku usług szczegółowego wyjaśnienia, jakich czynności wykonywanych przez usługodawcę dotyczy całkowita cena za usługę oraz podania klientowi informacji o cząstkowych cenach składających się na cenę całkowitą. W kolejnym kroku testowania interfejsu klienta (po wyszukaniu ofert) testerzy zaproponowali, aby istniała możliwość sortowania znalezionych ofert według różnych kryteriów. Zaproponowano również, aby obok tej listy były pokazywane oferty, które już wygasły tzn. pasują do nich wszystkie kryteria wyszukiwania, poza czasem ich wykonania. Ostatnia uwaga wydaje się uzasadniona, gdyż na podstawie takich ofert klient będzie miał możliwość uzyskania informacji o orientacyjnych cenach za wykonanie danej usługi. Testerzy zgłosili także ciekawą propozycję polegającą na tym, dr Dariusz Mikułowski, mgr Marek Faderewski 23

24 aby wyświetlać klientowi również listę usług, które są powiązane z aktualnie wyszukiwaną. Przykładowo, jeśli klient wyszukuje ofert usługi Wynajem sal na imprezy to można mu również zasugerować skorzystanie z usług Agencja artystyczna, Zespół muzyczny czy Catering. Testerzy (w szczególności posługujący się specjalistycznym oprogramowaniem udźwiękawiającym) krytycznie wypowiedzieli się na temat kalendarza, używanego w usługach, w których należy określić dokładne godziny ich świadczenia. Taka sytuacja miała miejsce np. w przypadku usług korepetycje, aerobik lub masaż - ten problem zgłosiło około 30 % testerów. Kalendarz ten nie jest prawidłowo odczytywany przez oprogramowanie, które umożliwia osobom niewidomym korzystanie z komputera. Wśród testujących były także osoby, którym podobał się właśnie taki kalendarz. Rysunek 5. Kalendarz w aplikacji klienckiej. W trakcie sprawdzania działania kreatora do zawierania umów, w którym można ustalić inne elementy kontraktu, testerzy zasugerowali, aby część pól z formularza wyszukiwania (których wartości są następnie umieszczane w umowie) były ustalane w drugim kroku działania kreatora, bezpośrednio przed wygenerowaniem umowy. W ten sposób będzie można znacznie uprościć sam formularz wyszukiwania. Kolejnym testowanym elementem interfejsu klienta był mechanizm pozwalający na podpisanie wytworzonej umowy, która była następnie automatycznie wysyłana do wykonawcy. Mógł on ją odrzucić lub podpisać. Po ewentualnym rzeczywistym wykonaniu usługi wykonawca mógł wystawić rachunek powiązany z tą umową. Po podpisaniu i wystawieniu rachunku dokumenty przesyłane były automatycznie do klienta. Zadaniem testującego było sprawdzenie wyglądu i zawartości tych dokumentów w zakładce Kontrakty. Po przetestowaniu tej części interfejsu klienta wyrażono następujące uwagi i sugestie: Dobrym i przydatnym elementem interfejsu jest wyszukiwarka kontraktów. Bardzo przydatna jest opcja pozwalająca na wydrukowanie umowy i rachunku bezpośrednio ze strony internetowej. Brak możliwości utworzenia pliku pdf z umowy i rachunku. dr Dariusz Mikułowski, mgr Marek Faderewski 24