Odgrzebany projekt: generator quizów do Moodle sprzed ery LLM

W 2020 roku nagrałam krótki film, w którym pokazywałam, jak można przyspieszyć i uprościć tworzenie quizów na platformę Moodle. Każdy, kto tworzył kursy e-learningowe, wie, że przygotowanie pytań jest jednym z najbardziej czasochłonnych etapów pracy. Najczęściej najpierw zapisujemy treść pytań w edytorze tekstu, a potem ręcznie kopiujemy je lub przepisujemy do formularzy w Moodle.

Z czasem zaczęłam się zastanawiać, czy ten proces naprawdę musi wyglądać w ten sposób. Skoro pytania i tak powstają w Wordzie, naturalnym krokiem wydawało się ich bezpośrednie wyeksportowanie do formatu Moodle XML, który można następnie zaimportować do quizu. Właśnie z tej potrzeby powstało proste narzędzie oparte na makrach w Wordzie, wyposażone w dodatkową wstążkę ułatwiającą tworzenie najczęściej używanych typów pytań.

W nagraniu pokazywałam cały proces na żywo: od przygotowania przykładowych pytań, przez użycie własnej wstążki, aż po zapis pliku XML i jego import do Moodle. Dziś, patrząc na ten projekt z perspektywy czasu i zupełnie innego krajobrazu technologicznego, widzę zarówno jego zalety, jak i bardzo wyraźne ograniczenia. I właśnie o tym — o tym, co działało, czego brakowało i dlaczego takie narzędzia rzadko stają się standardem — chcę napisać kilka słów.

Jak działało moje narzędzie?

Na rysunku pokazano fragment dokumentu Word, który pełnił rolę „interfejsu użytkownika” narzędzia. Logika generowania pytań opierała się na rozróżnianiu stylów zdefiniowanych w edytorze tekstu. W przypadku pytań typu prawda/fałsz odpowiedź była kodowana poprzez zastosowanie odpowiedniego stylu: zdania zapisane stylem zielonym interpretowane były jako odpowiedź prawdziwa, a stylem brązowym — jako fałszywa. Parser tekstu nie analizował koloru jako takiego, lecz nazwę stylu, co oznaczało, że użytkownik mógł dowolnie modyfikować jego wygląd, pod warunkiem zachowania pierwotnej nazwy zdefiniowanej w skrypcie.

Rysunek

Jeszcze jedna decyzja projektowa, która okazała się kluczowa

Jednym z elementów, z których do dziś jestem szczególnie zadowolona, było powiązanie struktury dokumentu Word ze strukturą kategorii pytań w Moodle. Tytuł wykładu wpisany w nagłówku dokumentu nie pełnił wyłącznie funkcji opisowej — był również automatycznie odczytywany podczas eksportu i wykorzystywany do tworzenia odpowiedniej kategorii pytań w pliku Moodle XML.

Dzięki temu pytania nie trafiały do wspólnej, niestrukturyzowanej puli, lecz były od razu porządkowane według tematów wykładów. W praktyce znacząco ułatwiało to późniejsze zarządzanie bankiem pytań, ponowne wykorzystanie materiałów oraz przygotowywanie różnych wariantów testów i egzaminów. Było to proste rozwiązanie, ale dobrze oddające zasadę, że automatyzacja powinna wspierać nie tylko szybkość pracy, lecz także jej organizację.

Programowanie przed erą modeli językowych

Warto przy tym pamiętać, w jakim kontekście technologiczno-narzędziowym powstawał ten projekt. Był to czas, w którym programowanie — zwłaszcza w niszowych technologiach takich jak VBA — opierało się głównie na dokumentacji producenta, forach dyskusyjnych i pojedynczych odpowiedziach na Stack Overflow. Nie było narzędzi, które potrafiłyby podpowiadać gotowe fragmenty kodu, wyjaśniać błędy czy sugerować alternatywne rozwiązania w sposób interaktywny.

W praktyce oznaczało to długie godziny spędzone na poszukiwaniu odpowiednich funkcji, testowaniu ich w różnych konfiguracjach oraz metodzie prób i błędów. Część rozwiązań działała tylko w określonych wersjach pakietu Office, inne wymagały obejść, które dziś nazwalibyśmy technicznym kompromisem. Programowanie miało wówczas znacznie bardziej „manualny” charakter — a wiele decyzji projektowych zapadało na podstawie tego, co w ogóle dało się uruchomić, a nie tego, co byłoby idealne.

Ograniczenia i rzeczy, które pozostały nierozwiązane

Narzędzie od początku miało też wyraźne ograniczenia. Zaimplementowałam jedynie sześć najczęściej używanych typów pytań, co było świadomą decyzją wynikającą z realnych potrzeb dydaktycznych, ale także z rosnącej złożoności pozostałych formatów. Największym problemem okazała się obsługa obrazów w pytaniach. Choć specyfikacja Moodle XML dopuszcza osadzanie grafik (np. poprzez kodowanie binarne), próby automatycznego przekształcania i zapisu obrazów z poziomu VBA okazały się niestabilne i trudne do opanowania w praktyce.

Pojawiły się również ograniczenia stricte techniczne związane z samym zapisem plików XML. W trakcie testów okazało się, że przy dłuższych nazwach plików — zwłaszcza zawierających spacje — mechanizm zapisu w VBA po prostu nie działał i plik nie był tworzony w ogóle. Nie był to problem po stronie Moodle ani parsera XML, lecz efekt specyfiki środowiska Worda i używanych funkcji zapisu. W rezultacie konieczne było stosowanie bardzo krótkich nazw plików, bez spacji, jako praktycznego obejścia tego ograniczenia.

Tego typu problemy były typowe dla pracy z makrami VBA, gdzie zachowanie funkcji zależało nie tylko od kodu, ale także od wersji pakietu Office i systemu operacyjnego.

Zamiast podsumowania

Impulsem do stworzenia własnego narzędzia był istniejący wcześniej projekt oparty na makrach Worda, który umożliwiał eksport pytań do Moodle XML. Rozwiązanie to przestało jednak działać wraz z nowszymi wersjami pakietu Office, co w praktyce uniemożliwiało jego dalsze wykorzystanie. Własna implementacja była więc próbą odtworzenia tej idei w realiach ówczesnego środowiska technologicznego.

Choć projekt powstał kilka lat temu i był odpowiedzią na bardzo konkretne potrzeby dydaktyczne, do dziś okazuje się użyteczny w praktyce. Nadal korzystam z tego narzędzia, zwłaszcza w sytuacjach, gdy trzeba szybko przygotować większą liczbę pytań testowych w uporządkowanej formie. Jego największą zaletą pozostaje prostota oraz fakt, że pozwala pracować w środowisku, które dla wielu wykładowców jest naturalne — w edytorze tekstu.

Narzędzie było wykorzystywane również przez jednego z profesorów, z którym współpracowałam, szczególnie w okresie intensywnego przejścia na egzaminy online w 2020 roku. Wówczas możliwość szybkiego zakodowania kilkudziesięciu pytań w różnych wariantach — bez ręcznego wprowadzania ich do systemu — okazała się istotnym wsparciem organizacyjnym. Nie była to sytuacja wyjątkowa technologicznie, lecz bardzo konkretna odpowiedź na presję czasu i skali, z jaką mierzyło się wówczas wielu nauczycieli akademickich.

Patrząc z dzisiejszej perspektywy, ten projekt nie jest ani zapowiedzią „produktu”, ani punktem wyjścia do dalszego rozwoju narzędzia. Jest raczej przykładem lokalnej automatyzacji, która dobrze spełniła swoją rolę w określonym kontekście organizacyjnym i technologicznym. I być może właśnie w tym tkwi jego największa wartość — w pokazaniu, że skuteczne wsparcie pracy dydaktycznej nie zawsze wymaga rozbudowanych platform, lecz czasem po prostu dobrze dopasowanego rozwiązania „tu i teraz”.

Postscriptum

Już po napisaniu tego tekstu próbowałam przygotowywać podobne pliki quizów z pomocą modeli językowych. Ku mojemu zaskoczeniu, nie było to wcale prostsze. Kolejne wersje generowanego XML-a często nie działały poprawnie — brakowało w nich wymaganych elementów, pojawiały się niespójności w formatach liczb lub błędy w naliczaniu procentów za odpowiedzi, które uniemożliwiały import do Moodle.

W tym kontekście stary skrypt oparty na makrach Worda okazał się rozwiązaniem bardziej niezawodnym: nie dlatego, że był „inteligentny”, lecz dlatego, że był jednoznaczny i zgodny ze specyfikacją. To doświadczenie dobrze pokazuje, że generatywna AI nie zawsze zastępuje narzędzia proceduralne — czasem raczej je uzupełnia, a czasem po prostu przegrywa z dobrze zaprojektowaną automatyzacją.