in2studyfinder dla TYPO3

Kandydaci na studia oczekują wyszukiwarki, a nie broszury PDF

Uczelnie z 50 do 300 kierunkami studiów stają przed konkretnym problemem: kandydaci chcą filtrować, a nie przewijać. Szukają według rodzaju dyplomu, wydziału, formy studiów i lokalizacji, jednocześnie. in2studyfinder od in2code rozwiązuje dokładnie to w obrębie TYPO3. Rozszerzenie zostało opracowane specjalnie dla środowiska uczelnianego i odwzorowuje złożoną strukturę licencjat, magisterium, studia dzienne, zaoczne, dualne i dokształcające w jednej masce filtrującej. Ponad 20 niemieckojęzycznych uczelni używa rozszerzenia produkcyjnie.

Dla zespołów webowych uczelni, które dotychczas pielęgnowały informacje o kierunkach studiów przez statyczne strony lub własne rozwiązania, przejście na in2studyfinder jest znacznym zyskiem efektywności. Zamiast tworzyć osobną podstronę dla każdego nowego kierunku, redaktorzy pielęgnują rekord w backendzie, a rozszerzenie automatycznie generuje widok listy, stronę szczegółową i funkcję filtrowania. Na uczelni zawodowej z 80 kierunkami oszczędza to szacunkowo 40 godzin pierwszej konfiguracji w porównaniu z ręczną strukturą stron.

Typowe scenariusze zastosowań sięgają od katalogu kierunków do przeglądu akredytacji

Standardowy scenariusz to centralna wyszukiwarka kierunków na stronie głównej uczelni. Kandydaci trafiają na stronę, wybierają wydział, dyplom i formę studiów i natychmiast otrzymują przefiltrowaną listę. Kliknięcie prowadzi do strony szczegółowej z planem modułów, warunkami przyjęcia, terminami rekrutacji i osobami kontaktowymi. Na uczelni zawodowej z 80 kierunkami zmniejsza to liczbę odsłon do uzyskania żądanej informacji z średnio 6 do 2.

Drugi scenariusz: wyszukiwanie ponad lokalizacjami u uczelni z wieloma kampusami. Uniwersytet z lokalizacjami w trzech miastach pokazuje wszystkie kierunki w jednym widoku i pozwala filtrować według kampusu. Informacja o lokalizacji jest pielęgnowana jako własna relacja, a nie jako tekst, co gwarantuje spójne filtrowanie.

Trzeci scenariusz: przeglądy akredytacji dla zapewnienia jakości. Polskie uczelnie podlegają kontroli Polskiej Komisji Akredytacyjnej i muszą wykazać, które kierunki są akredytowane i do kiedy. in2studyfinder może odwzorować te metadane jako pola niestandardowe i wyświetlać je w widoku listy, co dział akredytacji wykorzystuje jako podstawę pracy. Eksport danych kierunków jako CSV lub PDF dodatkowo umożliwia przekazanie do PKA lub innych zewnętrznych instytucji.

Architektura techniczna opiera się na rekordach Extbase z konfigurowalnymi relacjami

in2studyfinder to rozszerzenie Extbase/Fluid od in2code, niemieckiego dostawcy usług TYPO3 stojącego za powermail i in2publish. Kierunki studiów są zapisywane jako rekordy domenowe we własnej tabeli. Każdy rekord zawiera pola obowiązkowe jak tytuł, rodzaj dyplomu, regulaminowy czas studiów, punkty ECTS i wydział oraz pola opcjonalne dla progu punktowego, opłat za studia, statusu akredytacji i linku rekrutacyjnego.

Filtrowanie w frontendzie działa przez żądania AJAX, dzięki czemu strona nie jest przeładowywana przy filtrowaniu. Znacznie poprawia to doświadczenie użytkownika, szczególnie na urządzeniach mobilnych. Konfiguracja filtrów jest sterowana przez TypoScript: które pola są wyświetlane jako filtry, jakie sortowanie obowiązuje i ile wyników pokazuje się na stronę.

Szablony są oparte na Fluid i można je nadpisać w sitepackage. Rozszerzenie dostarcza standardowe szablony, które dla większości uczelni działają jako punkt startowy. Dla uczelni z własnym corporate designem Gosign dostosowuje szablony i integruje je w istniejący sitepackage, dzięki czemu strony kierunków pasują wizualnie bez przerw do całego serwisu.

Częste problemy dotyczą jakości danych, wydajności i wielojęzyczności

Największy problem przy wdrożeniu to jakość danych. Informacje o kierunkach studiów istnieją na uczelniach często w trzech do pięciu różnych systemach: USOS, własne bazy danych wydziałów, broszury PDF i ręcznie pielęgnowane teksty strony. Zanim in2studyfinder będzie mógł działać produkcyjnie, te źródła muszą zostać skonsolidowane. Gosign wspiera ten proces strukturalnym szablonem importu, który wydziały wypełniają, a my automatycznie importujemy do TYPO3.

Drugi problem: wydajność przy dużych ilościach danych. Uczelnie z ponad 200 kierunkami i złożonymi relacjami (wydział, lokalizacja, forma studiów, język) mogą doświadczać opóźnień w filtrowaniu AJAX, jeśli zapytania do bazy danych nie są zoptymalizowane. Indeksy na relacjach i poprawnie skonfigurowany cache w TypoScript rozwiązują problem zwykle w pełni. Dodatkowo pomaga rozgrzewanie cache po każdej zmianie danych, aby pierwszy odwiedzający po aktualizacji nie zobaczył wolnej strony.

Trzeci problem: wielojęzyczność. Międzynarodowe uczelnie z anglojęzycznymi kierunkami potrzebują spójnego tłumaczenia masek filtrów, kategorii i stron szczegółowych. in2studyfinder wykorzystuje framework tłumaczeń TYPO3, ale konfiguracja języków fallback i nakładek tłumaczeń musi być starannie dostosowana do wymagań uczelni. Szczególnie przy kierunkach oferowanych tylko w jednym języku (np. polski licencjat, ale anglojęzyczne magisterium) zachowanie fallbacku musi być tak skonfigurowane, żeby filtrowanie działało specyficznie językowo i nie dawało mylących wyników.

Czwarty problem, który Gosign regularnie widzi w projektach uczelnianych: nazwy kierunków zmieniające się z biegiem lat. “Informatyka stosowana” staje się “inżynierią danych”, ale zachowuje ten sam URL szczegółowy. Rozszerzenie musi być skonfigurowane tak, aby zmiany nazw nie tworzyły broken linków, a stare URL-e były przekierowywane na aktualną stronę.

TYPO3 v12 jest wspierane, kompatybilność z v13 zależy od planu wydań in2code

in2code aktywnie pielęgnuje in2studyfinder i regularnie dostarcza aktualizacje. Aktualna wersja obsługuje TYPO3 v11 i v12. Ponieważ in2code to komercyjny dostawca usług TYPO3 z długoterminową strategią produktową, kompatybilność z v13 jest oczekiwana, ale jeszcze nie oficjalnie wydana. Przy upgrade z v10 lub v11 na v12 breaking changes dotyczą przede wszystkim konfiguracji TypoScript (nowa składnia SiteSet) i ewentualnych własnych ViewHelperów w szablonach. Struktura bazy danych pozostaje stabilna, dzięki czemu migracja danych zwykle nie jest potrzebna.