Když jsme v červnu roku 2014 začínali s projektem jednotné platformy pro podporu studia, nikdo z nás netušil, jak rozsáhlý nakonec bude. To, co začalo jako obyčejné přebrání správy nad malou lokální aplikací z katedry kybernetiky, skončilo u komplexního IT řešení na správu výuky pro celou fakultu. Jako horolezci na úpatí Everestu, postavili jsme se čelem problému, který je na fakultě téměř po desetiletí. A jak se ukázalo, zdolat takového obra dá poměrně hodně práce.
Všechno začalo spoluprací s panem doc. Svobodou z katedry kybernetiky. Svým charismatickým přístupem a nadšením na fakultě vždy působil jako vizionář s velmi pragmatickým smyslem pro realizaci, a tak nebylo žádným překvapením, že právě od něj vzešel návrh na studentskou aplikaci pro sledování rozvrhu a termínů – dodnes známou jako akademický portál. Projekt byl těsně před dokončením a vzhledem k celofakultnímu využití aplikace nám připadalo smysluplné ji převzít pod správu SVTI a provozovat centrálně. Do vývoje jsme se tedy zapojili a právě tehdy jsme poprvé začali chápat skutečný rozsah problematiky. Kladli jsme si jedinou otázku – proč je vůbec aplikace, jakou akademický portál je, na fakultě tolik potřeba?
Odhalili jsme, že se na fakultě používá přes 60 různých technických řešení na správu výukových materiálů. Také, že KOS pro studenty poskytuje naprosto nedostačující funkcionalitu, že na fakultě chybí centrální datový výměník, že systémy, které jsou široce využívané napříč několika katedrami, provozuje jeden vývojář, nebo že jiným systémům podpora končí úplně a nemají náhradní řešení. Především jsme ale zjistili, že vlastně nikde není stanoveno, jak to má správně být. Po tom všem nešlo jenom stát opodál a nechat to být. Rozhodli jsme se jednat.
V průběhu téměř dvou let jsme nejen převzali a nadále rozvíjeli akademický portál, ale také stabilizovali a centralizovali správu nad systémem CourseWare, vyvinuli a nasadili celofakultní Moodle, zmigrovali jsme data ze systémů EDUX, KME Moodle, rektorátní Moodle či řady katederních webů natolik, že téměř pozbyly svého uplatnění a celkově jsme přispěli k výraznému zlepšení kvality služeb v oblasti správy výuky jak pro studenty, tak pro vyučující a akademickou obec. Dnes ještě zdaleka nejsme na konci, ale můžeme s klidnou duší hrdě prohlásit, že jsme byli úspěšní.
Protože se v Centru znalostního managementu rádi dělíme o své zkušenosti, rozhodl jsem se napsat o těch zkušenostech, které jsem jako hlavní realizátor projektu za ta léta sám načerpal. Nerad bych Vás ale zatížil náročnou četbou na dlouhé večery, a proto to vezmeme postupně, projekt po projektu. V prvním článku se zaměříme na základní stavební kámen celé platformy – akademický portál (dnes známý jako FELSight).
Od inovací k chaosu a od chaosu k řízení
Pokud jste se s portálem ještě nesetkali, jde o jednoduchou webovou aplikaci na sledování informací o studiu. Můžete v ní sledovat svůj rozvrh, svátky, termíny úloh a testů nebo vyhledávat kontakty na fakultě a procházet databázi předmětů (zaujalo vás to? Mrkněte na naši online prezentaci zde).
To samo o sobě ale nebyl důvod, proč aplikace vznikla. Hlavním problémem bylo, že na fakultě má téměř každý předmět své studijní materiály dostupné na jiném webu, pod jinou adresou a s jiným uživatelským rozhraním a strukturou informací. Studenti si tak museli všechno hlídat sami a často se v tom ztráceli a byli zmatení. Akademický portál představuje řešení – stačí jen v KOSu (univerzitní studijní IS) udržovat databázi odkazů na materiály a v portálu studentům nabízet seznam zapsaných předmětů s odkazem. To se nakonec podařilo, nicméně jak je dnes vidět, zdaleka jsme nezůstali jen u toho.
Obr.1 – jak FELSight pomáhá a co je jeho filozofií? Spokojený student! 🙂
O přínosech a filozofii portálu vám mnohé jistě vypoví uvedený obrázek. Žijeme v době moderních technologií a na technické fakultě je naprosto běžné vyvíjet systémy tzv. od spoda (tj. z lokálního experimentu postupně vytvořit centrální řešení). Velké množství informačních systémů je na denním pořádku. To má své výhody zejména ve velké míře inovace a poměrně dobrému samovolnému pokrytí potřeb uživatelů. Problém nastává až v momentě, kdy je nutné aktivity koordinovat.
Najednou máte před sebou pět různých specifických řešení na jeden problém, nikdo nesrovnával, které řešení je lepší, každý prosazuje to své a doufá, že v souladu s přírodními zákony to špatné samo časem vymře a zůstane jen to dobré. V realitě je koncový uživatel zavalen desítkami systémů a situace je tím horší, s čím více katedrami přichází do styku.
Co s tím? Bojovat můžete v zásadě na dvou frontách – můžete jednotlivé systémy rozebrat, srovnat, vyhodnotit a centralizovat (jako jsme to udělali například s fakultním Moodlem), a nebo vytvoříte mezivrstvu – prostředníka – který se s informacemi popere a předá je koncovému uživateli v přehledné formě a jen tehdy, když je skutečně potřebuje. A právě tuhle roli zastává akademický portál.
Kdepak ty data hnízdo maj?
Největší problém FELSightu (jak jsme akademický portál nakonec pojmenovali) spočíval v úplnosti řešení. Chcete-li budovat centrální přístupový bod do ostatních systémů, musíte minimalizovat potřebu uživatelů pravidelně sledovat data v systémech koncových. Pokud ale nezajistíte dostatečnou spolehlivost a úplnost dodávaných informací, uživatel k tomu bude tak či tak nucen a ve skutečnosti se problém ještě zhorší – k desítkám systémů mu přibude jen další aplikace ke sledování.
Zajistit stoprocentní úplnost ale nebylo v našich silách a museli jsme hledat kompromis. Pokaždé je totiž na začátku uživatel, který data do systému zadává a ten je v tom často velmi kreativní. Pokud bychom například chtěli čerpat termíny testů z fakultního Moodlu, můžeme se ptát na objekty testů ve všech kurzech, ale už například nerozeznáme poznámku v obecném textu někde na nástěnce kurzu. Pokud tedy student nechce testy zmeškat, tak či tak musí Moodle sledovat a pouze na FELSight se spolehnout nemůže.
Kompromisem pro nás znamenalo filozofii aplikace rozvolnit. Sledování termínů jsme zachovali, ale nedokázali jsme garantovat úplnost dat a ponechali tuto zodpovědnost na uživatelích. Řada uživatelů si už nyní termíny někam přepisuje a hlídá – proč to tedy nedělat v našem portálu, kde budou mít polovinu termínů předvyplněných. Díky tomu, že si každý uživatel může svá data ve FELSightu synchronizovat se svým kalendářem a mít je tak neustále po ruce i na svém telefonu, nám to najednou začalo celé opět dávat smysl.
Systémy všech kateder, spojme se
Druhým palčivým problémem realizace byly integrace. Akademický portál čerpá data ze sedmi různých systémů, často vždy v úplně jiném formátu a za odlišným účelem. Navíc jsme museli brát v úvahu, že množství datových zdrojů s časem poroste a řešení tedy musí být univerzální a modulární a řešili jsme tedy nejen v jakém formátu data uchovávat, ale také kdy nad nimi provádět transformace, která data uchovávat a které získávat tzv. on-the-fly, která data generovat dopředu a především odkud a v jakém formátu je brát (často na jednu informaci existovalo i několik možných zdrojů).
Řešení představoval standardní formát informací, tzv. zpráv a k ní korespondující restové API. O každé události uchovávala dostatek potřebných informací a její chování bylo možné rozšiřovat prostřednictvím specifikace jejich typu (dnes například pracujeme s typy jako je test, úloha, zkouška a další). Po řadě iterací a analýz jsme strukturu databáze a formát API rozhraní optimalizovali a zbývalo pouze vyřešit, co a odkud získávat.
Obr. 2 – datový model je nakonec překvapivě jednoduchý. Skutečná výzva je data standardizovat.
Dnes prostřednictvím restového API na KOS čerpáme údaje o rozvrhu, zkouškách či předmětech, RSS čtečkami čerpáme data o akcích ČVUT z kalendáře událostí a naším vlastním API logujeme studijní termíny ze systémů Moodle a CourseWare. Opakovaně jsme ale naráželi na to, že získaná data měla chybný formát, jiné data bylo nutné odfiltrovat a každý systém jsme museli do detailů pochopit, analyzovat, která data schraňuje, jak se do systému zadávají a v jaké formě jsou uchovány.
Co jsem si z toho odnesl? Především poučení, že u integrací je velmi důležité důkladně promyslet standardní datový formát, pečlivě vybrat použité technologie a zapojovat systémy postupně a po malých krůčcích. Sami jsme si od začátku ukousli příliš velký kus koláče najednou a v důsledku toho jsme technologii a databázi několikrát předělávali. Nepodceňte ani monitoring, protože výpadek každého datového zdroje znamená částečný (nebo i úplný) výpadek vaší aplikace a riziko chybného provozu je mnohonásobně vyšší.
Na vzhledu záleží
V době, kdy jsme se do vývoje zapojili v Centru znalostního managementu také my, byla již velká část ze zmíněného v první fázi vývoje a naším úkolem bylo všechno vylepšit, optimalizovat a dotáhnout do konce. V důsledku toho jsme nejen přepisovali aplikaci do úplně jiné technologie a přidali řadu nových funkcí, ale také kompletně přepracovali uživatelské rozhraní.
Obr. 3 – facelift akademického portálu aneb jak jsme k Bootstrapu přešli.
Jaké zkušenosti jsem si odnesl z návrhu uživatelského rozhraní? Nesnažit se všechno vymyslet hned – neskutečné množství problémů vyvstane až při jejich realizaci a je lepší mít několik iterací než jednu velkou úpravu. Také se příliš nevyplatí vymýšlet rádoby chytrá řešení, protože na konci často vůbec nefungují a s jejich realizací je víc problémů než užitku a také především že to, co vám připadá jako jedno tlačítko, může být pro programátora někdy i týden práce a měl by proto být přímou součástí tvůrčího procesu.
Kudy dál?
I přes všechny problémy se nám začátkem letošního roku podařilo aplikaci oficiálně spustit a pomocí naši prezentace rozhlásit mezi studenty fakulty. Počáteční provozní problémy nás lehce zpomalily v růstu uživatelů, ale zatím se zdá, že aplikaci navštěvuje přes 200 lidí denně, což na první dva týdny provozu považujeme za úspěch, ale zdaleka ne cíl. Rádi bychom nyní dostali aplikaci do běžného užívání a na to potřebujeme také pomoc vás – studentů. Pokud se vám líbí, ukažte ji svým známým, napište o ni na sociální sítě a šiřte ji dál. Velké množství uživatelů znamená podporu i pro nás a tedy i snazší cestu při jejím dalším rozvoji.
Ten bychom rádi směřovali i na vyučující a zaměstnance fakulty, aby si prostřednictvím našeho portálu mohli spravovat lépe svou výuku, komunikovali se studenty a organizovali svůj čas. Díky tomu nejen sami získají dobrý informační servis, ale také zlepšíme komunikaci se studenty a zvýšíme pokrytí termínů, které FELSight sdružuje. Naše zkušenosti z portálu navíc dokážeme nyní uplatnit v novém projektu návrhu nové verze KOSu a v souladu s principem vývoje odspoda se zdá, že podobné řešení prosadíme i přímo v něm. To je ale ještě hudba daleké budoucnosti a prozatím budoucnosti také velmi nejisté.
Závěrem bych rád poděkoval všem, kteří se na projektu podíleli. Především panu doc. Svobodovi z katedry kybernetiky, který stál u samotného zrodu aplikace a svými nápady a zkušenostmi její vývoj vždy posouval mílovými kroky kupředu. Také děkuji Ing. Karlu Čemusovi, který vyvinul původní verzi aplikace a v začátcích vývoje nás velmi aktivně podporoval a pomáhal nám s přebráním projektu a děkuji také všem svým kolegům, kteří se na realizaci aplikace podíleli.
A co vy? Jak se vám aplikace líbí? Máte nějaký zajímavý nápad, jak ji rozvíjet dál? Určitě nám o tom dejte vědět. Chceme slyšet váš názor a rádi se budeme vašimi podněty zabývat.
V příštím článku se podíváme na druhý pilíř naší platformy – celofakultní Moodle.