Jak zapewne pamiętacie z poprzedniego artykułu, w którym opisywałem proces badawczy, pojawiło się w nim zdanie: „System do gromadzenia danych musi wspierać badacza na każdym z etapów projektu”. Niemniej zanim wsparcie systemowe może się rozpocząć, należy bezwzględnie przejść przez fazę planowania, w której skład wchodzą takie etapy jak: przygotowanie planu badania, dobór techniki i próby, konceptualizacja, operacjonalizacja itp.
Zdecydowanie odradzam koncepcję, w której od razu siadamy do komputera i próbujemy zmaterializować pomysły, które mamy w głowie - taki proces zawsze podlega wielokrotnym modyfikacjom i niepotrzebnie będziemy wykonywać podwójną pracę. Moment, w którym należy sięgnąć do aplikacji umożliwiającej projektowanie kwestionariusza, powinien być zbieżny z momentem powstania „na papierze” ostatecznej treści pytań wraz z pełną logiką tj. regułami przejść, warunkami logicznymi, ustaloną kolejnością pytań czy bloków itp. Oczywiście, na etapie pilotażu mogą lub wręcz powinny pojawić się ewentualne zmiany i poprawki, ale ich liczba będzie zdecydowanie mniejsza.
Piszę o tym aspekcie już na samym początku, gdyż uważam, że dobry projekt badawczy musi cechować się również starannością wykonania. Brak dbałości o konwencje nazewnicze pytań, chaotyczne opisy i komentarze oraz nie do końca przemyślana logika ankiety na pewno nie uniemożliwi nam realizacji projektu, ale zdecydowanie utrudni sięgnięcie do niego po czasie, po raz kolejny. Jest jeszcze jeden ważny element wynikający z powyższego zdania, mianowicie budując ankietę, system w tle od razu tworzy strukturę danych wynikowych (zapisując ją w bazie danych). Chyba nie muszę dodawać, że niedbale przygotowana ankieta oznaczać będzie kiepską postać zbioru wynikowego. Mam na myśli takie elementy jak: nazwy zmiennych, etykiety, braki danych, format itp. Warto o tym pamiętać, gdyż nakład pracy z tym związany na początku procesu badawczego, jest wielokrotnie mniejszy niż na jego końcu. Zagadnienie powstawania zbioru wynikowego i naszych możliwości wpływania na ten element już na etapie projektowania kwestionariusza jest tematem ciekawym acz złożonym. Z tego powodu poświęcę mu osobny artykuł w przyszłości.
Jak widać po temacie artykułu, tym razem chciałbym skupić się na procesie budowania elektronicznej postaci kwestionariusza, oczywiście z wykorzystaniem narzędzia PS QUAESTIO PRO. Jest to system on-premis, umożliwiający konstruowanie ankiet i w czasie rzeczywistym publikowanie ich np. na serwerze WWW. Program umożliwia projektowanie praktycznie dowolnych rodzajów pytań wraz z elementami logiki przejść i wypełnień. Co ważne, bazując na interfejsie graficznym. Nie jest bynajmniej moim celem przygotowanie opisu poszczególnych funkcjonalności programu, bo o tym możecie poczytać w podręczniku użytkownika lub zjawić się na stosownym kursie prowadzonym przez firmę Predictive Solutions. W tym artykule postaram się przedstawić wam elementy, których nie będzie widać na pierwszy rzut oka, a na pewno prędzej czy później zetkniecie się z nimi w swojej pracy.
Przede wszystkim największą sztuką jest umiejętne przeniesienie treści pytania z „wersji papierowej” do programu. Zwrot „wersja papierowa” jest w tym przypadku umowny, bo przecież mam raczej na myśli wersję przygotowaną w programie Word, OpenOffice czy też dowolnym innym edytorze tekstu. Chodzi o fakt, że tak przygotowana treść nie musi podlegać żadnym zasadom badawczym, ani wchodzić w interakcję z pozostałymi pytaniami. Innymi słowy, papier wszystko przyjmie. W moim przypadku najlepiej sprawdza się koncepcja dążenia do maksymalizacji prostoty wypełniania. Pamiętajmy, że dla badacza, po setnym przeczytaniu treści danego pytania wszystko zaczyna być łatwe i klarowne, natomiast respondent będzie widział kwestionariusz jeden jedyny raz. Jeżeli damy mu, choć jeden maleńki powód do powstania wątpliwości przy udzielaniu odpowiedzi to znaczy, że już przegraliśmy walkę o jakość wyników. Zdecydowanie nie wolno do tego dopuścić. Dobrą praktyką w takie sytuacji jest pokazanie kwestionariusza komuś, kto widzi go po raz pierwszy i dodatkowo nie jest zorientowany w tematyce badawczej. Możecie być pewni, że niektóre uwagi i spostrzeżenia mocno Was zaskoczą i spowodują zupełnie inne spojrzenie na treść danego pytania.
Checkboxy
Oczywiście pod pojęciem łatwego wypełniania kryje się znacznie więcej elementów, które możemy stosownie modyfikować na etapie projektowania elektronicznej postaci ankiety. Przykładowo poniższe pytanie:
Co do zasady autorowi pytania zależało na tym, aby respondent wskazał wszystkie aktywności, które podejmował podczas okresu studiowania. Czy w takim razie, analogicznego efektu nie osiągniemy stosując poniższą postać tego samego pytania?
Jak widać, udzielenie odpowiedzi w drugim przypadku sprowadza się do zaznaczenia tylko tych aktywności, których respondent się podejmował.
Nie będę w tym momencie rozkładał pytania na czynniki pierwsze i analizował każdego z nich z osobna, gdyż nie jest moim celem uczenie jak konstruować pytania. Chciałbym przede wszystkim zwrócić uwagę na element prostoty, gdyż bardzo często jest on marginalizowany lub całkowicie pomijany przez badacza. Im łatwiejsza w percepcji postać ankiety, tym większa szansa na to, że dany respondent nie tylko w całości wypełni przygotowany kwestionariusz, ale nie będzie unikał kolejnych badań w przyszłości.
Pomijanie pytań szczegółowych
Przytoczę jeszcze jeden przykład, w którym proces upraszczania będzie miał zupełnie inny charakter.
Przykładowe pytanie:
W tym przypadku mamy do czynienia tak naprawdę z dwoma pytaniami jednocześnie. Po pierwsze, respondent wskazuje wszystkie powody, dla których rozpoczął dany kierunek, a po drugie musi wybrać ten najważniejszy. Niestety czeka na niego przynajmniej kilka pułapek. Po pierwsze, co jeśli pomyli kolumny i zaznaczy je odwrotnie? Po drugie, może wskazać tylko jeden powód podjęcia kierunku studiów. W takim przypadku przestaje mieć sens dodatkowe pytanie o najważniejszy. Specjalnie nie wskazuję tu elementów związanych z tzw. błędnym wypełnianiem czyli intencyjnym lub przypadkowym niestosowaniem się do poleceń zawartych w kwestionariuszu. Temat ten postaram się szerzej omówić w innym artykule, gdyż system oferuje w tym zakresie sporo dodatkowych możliwości kontroli.
Oczywiście sposobów na optymalizację powyższego pytania jest przynajmniej kilka i nie będę się upierał przy konieczności zastosowania tej lub innej opcji. Ważne, aby w jak największym stopniu poznać możliwości PS QUAESTIO PRO i w pełni z nich korzystać. Moja propozycja to rozbicie pytania na dwa osobne. Pierwsze zawierać będzie tylko pytanie o powody wyboru, jak poniżej:
Natomiast drugie z nich prosi o podanie najważniejszego powodu, ale tylko w odniesieniu do odpowiedzi wskazanych przez respondenta w pierwszym pytaniu.
Ostatnim elementem, który pozostaje nam „do obsłużenia” jest sytuacja, w której respondent zaznaczy tylko jedną odpowiedź w pierwszym pytaniu. W takim przypadku z jednej strony nie należy wyświetlać pytania zawierającego prośbę o wskazanie najważniejszego powodu, ale z drugiej (dla badacza znaczniej ważniejszej) koniecznie należy zadbać o to, aby w zbiorze wynikowym pojawiła się stosowna odpowiedź. Mimo, iż respondent nie wskazał najważniejszego powodu, to w domyśle będzie nią odpowiedź z pytania poprzedzającego. Jak tego dokonać? Proponuję następujące rozwiązanie. Zaczniemy od umieszczenia w kwestionariuszu specjalnego obiektu IFBlock znajdującego się w sekcji Condition :
Obiekty tego typu umożliwiają warunkowe prezentowanie zestawów pytań. W naszym przypadku warunkiem, dla którego będzie pojawiało się pytanie o najważniejszy powód, jest zaznaczenie tylko jednej odpowiedzi w pytaniu o powody wyboru danego kierunku studiów. Dla ułatwienia przyjmijmy kodowe oznaczenia obu pytań:
- p2 - Co zdecydowało, że wybrał/a Pan/Pani dany kierunek studiów?
- p3 - Proszę wskazać najważniejszy powód
Wystarczy w tym momencie wskazać pytanie p2 i przypisać mu warunek includes at last (zaznaczono co najmniej) i wprowadzić wartość 2, jak na rysunku poniżej:
Od tego momentu pytanie p3 nie zostanie wyświetlone żadnemu respondentowi, który zaznaczył tylko jedną odpowiedź w pytaniu p2. Ostatnim elementem pozostaje automatyczne wstawienie odpowiedzi na pytanie p3 wszystkim respondentom, dla których zadziałała powyższa instrukcja warunkowa. Aby tego dokonać, należy umieścić dodatkowy obiekt Else, który wykona się zawsze kiedy podstawowy warunek IFBlock nie zostanie spełniony. Innymi słowy jest to swego rodzaju dopełnienie warunku bazowego pozwalające np. wprowadzić dodatkowe pytanie alternatywne, lub niestandardowy komunikat itp. W naszym przypadku posłużymy się obiektem Set Response:
Dzięki niemu badacz ma możliwość uzupełniania odpowiedzi dla dowolnego pytania, które jest pomijane przez respondenta (nie jest mu wyświetlane). Najczęściej wykorzystuje się tego typu obiekty dla pytań pomijanych przez reguły przejść, np. wprowadzając automatycznie jako odpowiedź na pytanie kategorię nie dotyczy. Ponieważ w naszym przypadku chcemy, aby do pytania p3 została przepisana automatycznie odpowiedź zaznaczona w pytaniu p2, to modyfikujemy uprzednio wstawiony obiekt Set Response jak na rysunku poniżej:
Jak zapewne zauważyliście, należy jedynie w polu Build a response umieścić nazwę pytania p2. Teraz wystarczy wykonać kilka testowych wypełnień, aby upewnić się czy zbudowany przez nas wspólnie fragment ankiety działa prawidłowo. Schemat graficzny powinien wyglądać następująco:
Dzięki temu eliminujemy wszystkie opisane przeze mnie wcześniej problemy, a jednocześnie znacznie zwiększamy przejrzystość kwestionariusza. Z moich obserwacji wynika, że podczas projektowania nie należy za wszelką cenę próbować odwzorowywać identycznego układu poszczególnych pytań, tylko skupić się na merytorycznym przeniesieniu treści i intencji badacza.
Grupowanie pytań na skali
Czasem proste triki, wykorzystujące w niestandardowy sposób poszczególne funkcje programu, pozwalają uzyskać bardzo ciekawe efekty końcowe. Przykładowo:
Tutaj wykorzystanie funkcji grupowania pytań oraz tworzenia Sublist pozwala na uzyskanie efektu tzw. „dyferencjału semantycznego” czyli pytania na skali, gdzie respondenci muszą dokonać oceny danego zjawiska wskazując natężenie dwóch przeciwnych określeń.
Standardowo program pozwala na umieszczanie odpowiedzi w wierszach lub kolumnach, ale opis każdej z kategorii znajduje się po prawej stronie checkboxa tj.
W związku z tym musimy delikatnie zmodyfikować nasze pytanie. Wystarczy, że wszystkie odpowiedzi zaznaczymy i zgrupujemy za pomocą funkcji Group into Sublist, jednocześnie w sekcji Presentation ustawiając opcję Orientation na Rows (wiersze).
Jeżeli chcemy, aby liczba pytań bazujących na skali dyferencjału była większa, można dodatkowo na zakończenie zgrupować je na jednej stronie uzyskując efekt jaki zaprezentowałem na początku rozdziału.
Wyświetlanie wcześniejszych odpowiedzi
Innym prostym, acz ciekawym przykładem może być potrzeba wyświetlenia odpowiedzi, które respondent zaznaczył w dwóch poprzednich pytaniach.
Przykładowo możemy zapytać respondenta o jego ulubioną kawę, prezentując listę większości dostępnych marek na rynku. Następnie prosimy o wskazanie tych marek, o których respondent kiedykolwiek słyszał. Oba pytania posiadają identyczną kafeterię odpowiedzi. Na koniec zadajemy pytanie, które zawiera tylko te marki kaw, które zostały uprzednio wybrane, prosząc o wskazanie tych, które kiedykolwiek kupował. Wyświetlenie tylko zanzaczonych odpowiedzi z jednego, poprzedzającego pytania, jest stosunkowo proste i bazuje na standardowej funkcji Filter: Chosen znajdującej się w sekcji Responses.
Efekt użycia powyższej opcji jest widoczny na poniższym zrzucie.
Aby możliwe było wyświetlenie zaznaczonych kategorii z większej liczby pytań należy dodatkowo wprowadzić zapis jak na rysunku poniżej:
Gdzie p1 i p2 są nazwami pytań.
Komunikaty o błędach
Ostatnim już przykładem, który przedstawię w niniejszym artykule, jest sposób na dodatkowe zabezpieczenie się przez „lenistwem” respondenta. Załóżmy, że planujemy zadać pytanie o nazwę województwa, z którego pochodzi ankietowany. Przykładowo:
Proszę wskazać nazwę województwa:
dolnośląskie
kujawsko-pomorskie
lubelskie
lubuskie
łódzkie
małopolskie
mazowieckie
opolskie
podkarpackie
podlaskie
pomorskie
śląskie
świętokrzyskie
warmińsko-mazurskie
wielkopolskie
zachodniopomorskie
Ponieważ lista kategorii jest dość długa, to proponuję zamiast klasycznych checkboxów zastosować listę rozwijalną (dropdown box). Niestety w takim przypadku pierwsza z dostępnych kategorii stanie się domyślną i będzie automatycznie wyświetlana w oknie do zaznaczenia.
Nie muszę chyba pisać, że nieuważny respondent nie dokona modyfikacji i pozostawi wartość domyślną, co niestety spowoduje wprowadzenie błędnej odpowiedzi. Pewnym rozwiązaniem jest wstawienie na początku listy kategorii dodatkowej wartości i ustawienie dla niej statusu brak danych (Missing).
Dzięki temu z jednej strony bardziej przykuwamy uwagę osoby udzielającej odpowiedzi, a z drugiej, nawet jeśli kategoria trafi do zbioru wynikowego to zostanie oznaczona jako brak danych. Nie mniej jest to rozwiązanie nie do końca spełniające swoje zadanie i należałoby dodatkowo się zabezpieczyć. Dlatego proponuję, prostą sztuczkę. Wystarczy, że posłużymy się po raz kolejny opcją Group into Sublist uprzednio zaznaczając wszystkie dostępne kategorie. Następnie modyfikujemy domyślną nazwę listy na < wybierz >
W efekcie, domyślną wartością wyświetlaną w pytaniu jest nazwa listy czyli < wybierz > . Ponieważ nie jest to odpowiedź, to podczas próby przejścia do kolejnego pytania otrzymujemy stosowny komunikat:
Podsumowanie
Jak widać na powyższych przykładach, istnieje wiele ciekawych możliwości niestandardowego użycia gotowych funkcji programu. Jest to ważne zwłaszcza tam, gdzie badacz nie dysponuje umiejętnościami programistycznymi i korzystanie ze środowiska graficznego jakie oferuje PS QUAESTIO PRO jest dla niego zdecydowanie lepszym rozwiązaniem.
Oczywiście zdarzają się sytuacje, gdy z przyczyn od nas niezależnych będziemy zmuszeni do identycznego odwzorowania układu wszystkich pytań z wersji „papierowej” (bo np. wymaga od nas tego klient), a my nie wiemy jak taki efekt osiągnąć. Każdy program oparty o interfejs graficzny posiada skończoną liczbę opcji i prędzej czy później pojawi się potrzeba, której nie będzie można „wyklikać”.
Receptą na ograniczenia funkcjonalne jest otwarte środowisko programistyczne Professional, które jest dostępne w PS QUAESTIO PRO jako dodatkowy moduł. Dzięki niemu za pomocą języka skryptowego będziemy w stanie zaprojektować dowolną ankietę. Dodatkowo istnieje możliwość przygotowywania skryptów zarządzających, tj. takich, które automatyzują procesy np. pobierania danych o respondentach i przekazywania ich do projektu badawczego. Możemy również budować automaty raportujące dla wielu odbiorców jednocześnie. Dodatkową zaletą tego rozwiązania jest możliwość przygotowywania gotowych skryptów/wizardów, które badacz może wykorzystać w programie Author (użyty w omawianych przykładach). Aplikacja będzie automatycznie korzystać z tak przygotowanej funkcjonalności.
Mam nadzieję, że ta garść porad pozowli Wam inaczej spojrzeć, na niektóre obszary swojej pracy i ponownie przemyśleć sposób działania. Jeżeli uda się Wam choć trochę usprawnić swoje zadania i poprawić efekt końcowy, to uznam, że mój cel został osiągnięty.