Programovali sme netradičnú webstránku o virtuálnych behoch s množstvom internej funkcionality. Tento článok vám predstaví zákulisia, prepojenia a špecifiká jej programovania, ktoré bežný človek neuvidí.
K napísaniu tohto článku ma inšpirovala diskusia so support centrom jedného použitého pluginu, v ktorom som pri kódovaní webky našiel bug. Tá odpoveď znela takto:
Aby sme si vysvetlili čo vnímaju programátori z Crocoblock ako komplikované, vysvetlím najprv o čom táto webka je a neskôr vysvetlím ako sme túto štruktúru dosiahli.
Extrémne komplikovaná štruktúra webstránky
Stránka www.DigitalRunAndBike.com je webstránka o virtuálnych aktivitách, ktoré sa v čase koronavírusu dajú robiť individuálne. Píšem aktivitách, lebo z pôvodne jedného druhu aktivít – behu – sa prešlo aj na bicykel a plán je rozširovať portfólio aktivít aj ďalej. Nie je jediná svojho druhu na svete, lebo podobných stránok sa pri koróne vyrojilo veľa, predsa len má niektoré špecifiká.
Zákaznícka zóna
Jej základom je zákaznícka zóna pre individuálnych športovcov. Zákazník, resp. športovec má možnosť zakúpiť si účasť na jednej, alebo viacerých virtuálnych trasách. Zakúpením účasti sa mu automaticky vytvára konto, v rámci ktorého do zakúpených virtuálnych trás nahráva svoje aktivity. To znamená, že športovec ide vo svojom vlastnom meste, kde býva sám behať a odbehne, napríklad, 5km. Tento svoj výkon nahrá do svojej virtuálnej trasy. Ak chodí behať každý deň, za týždeň takýchto aktivít na svojej trase nabehá spolu 7x5km = 35 km. Pri splnení všetkých podmienok (dokladovanie individuálnych behov) a absolvovaní celej dĺžky virtuálnej trasy (napríklad maratónskej vzdialenosti 42km) športovec dostane symbolickú medailu za svoj výkon.
V priebehu plnenia svojej virtuálnej trasy sa mu zobrazujú rôzne zaujímavosti, ktoré má na svojej virtuálnej trase. Sú to akési checkpointy, teda body, cez ktoré postupne prechádza, a ktoré mu odhaľujú krásu miesta, cez ktoré virtuálne beží.
Na pozadí stránky beží charitatívna aktivita, v ktorej organizátori sľubujú, že za každú zakúpenú trasu vysadia jeden strom. Pri kúpe virtuálnej trasy má zákazník možnosť sa rozhodnúť, v ktorej časti Slovenska (západné, stredné, východné) sa má “jeho” strom vysadiť.
Bonusy
Aby to celé nebolo také jednoduché, tak jednotlivé virtuálne trasy sa otvárajú a zatvárajú v určených dátumoch, robia sa rozsiahle štatistiky ohľadom mužov, žien, jednotlivých trás, rôzne Top10, počty vysadených stromov v jednotlivých regiónoch apod.
Ako sme túto štruktúru vystavali
Mohlo by sa zdať, že takto špecifickú stránku nie je možné urobiť inak než kódovaním na mieru. Opak je pravdou, okrem niektorých špecifických prvkov, ktoré sme dorábali, je celá postavená na štandardných systémoch, ktoré ponúka systém wordpress. Samozrejme ale so špecifickými pluginmi a na základe dôkladnej znalosti útrob WordPressu.
Membership vs Eshop
Zo začiatku sa zdalo, že najlepší prístup k uchopeniu zákazníckej zóny bude nejaký membership plugin, ktorý upravíme na naše potreby. Ukázalo sa, že pluginy ponúkajúce subscription, alebo membership možnosti sú veľmi obmedzené v tom, že k ich hlbokým funkcionalitám neexistuje žiadna dokumentácia a support zo strany vývojárov pluginov je dosť mizerný. Preto sme sa po zisťovaní možností rozhodli použiť klasický eshopový systém woocommerce a používať zakúpené produkty ako formu membershipu.
Elementor a JetEngine
Každému nalogovanému účastníkovi sa zobrazuje možnosť prezerať si vlastné virtuálne trasy, ich štatistiky a do nich formulárom zadávať individuálne aktivity. Samozrejme, každá aktivita musí byť prepojená s danou trasou. WordPress ako taký neponúka moc možností na vlastné post types, takže bolo treba siahnuť po nejakom systéme, ktorý by vedel nielen urobiť custom post types, ale aj relácie medzi nimi a to všetko pri napojení na užívateľské formuláre na front-ende. Celé sme to vyriešili cez JetEngine s niektorými jeho doplnkami. JetEngine funguje na zakladnej platforme Elementoru, takze vysledkom bol systém postavený na Elementor Pro a JetEngine.
Ruky od wordpressového oleja
Samé o sebe to však toto spojenie neriešilo podmienené zobrazovanie checkpointov na danej trase. Pri checkpointoch ešte s rozlíšením na druh aktivity. Inými slovami, checkpoint sa mohol zobrazovať pri behu na inom kilometri ako napriklad pri bicyklovaní. Aktivity aj checkpointy boli samostatné custom post types. Tá mágia okolo nich sa odohrávala v custom metódach nakódovaných v PHP vo functions.php. A my sme sa museli ponoriť do hlbón wordpressového motroa. Elementor aj JetEngine majú obrovské možnosti práce so shortcodmi a to dokonca s rozšírením na argumenty shortcodov. Takže, podstatná časť výstupov z nakódených metód bola shortcodmi presúvaná do frontendu, kde sa podmienenou logikou zobrazovali tam, kde bolo treba.
Checkpointy sa dali ďalej rozširovať a bola pripravená možnosť na každom checkpointe zobrazovať reklamné zobrazenia (sponzorov) súvisiace s daným miestom. Táto funkcionalita však ostala predbežne nevyužitá a pripravená na budúcnosť.
Admin rozhranie pre organizátorov
Woocommerce aj wordpres ponúkajú nejakú základnú analytiku a štatistiku, ktorá ale pochopiteľne nemala nič spoločné s na mieru kódovanými vecami na webke. Organizátori potrebovali vedieť koľko stromov kde sadiť, koľko mužov a žien sa v ktorej virtuálnej trati nachádza, aký je stav pri ukončení trasy, kvoli zasielaniu finišérskych medailí, top bežcov v každej trase apod. To všetko sa dalo robiť len dotazmi na databázu a programovaním v PHP.
Ďalšími výzvami, ktoré sa postupne objavovali bolo importovanie firemných športovcov, súťaženie medzi oddeleniami firiem a ich samostatné štatistiky, rozšírené potreby na GDPR, archivovanie dosiahnutých výkonov a iné.
Samozrejmosťou je, že administrátori majú v rukách kompetnú správu checkpointov, užívateľov, produktov čiže virtuálnych trás a s tým spojených objednávok, prehľad o aktivitách jednotlivých športovcov a veci s tým súvisiace. A to všetko vo veľmi userfriendly prostredí wordpresu.
Odhalené rezervy
Odhalený bug
Tento článok som začal tým, že sa objavil bug v JetEngine plugine . Trvalo asi týždeň, kým sa ho vývojárom pluginu podarilo vyriešiť. Objaviť niečo fatálne a mimo našej kompetencie to vyriešiť, keď na tom stojí celý systém je, mierne povedané, stresujúce. My sme na to čas mali. Mali sme pripravené aj náhradné riešenie, ale viem si predstaviť, že za iných okolností by to mohol byť trochu stres.
Nevýhoda komplikovaného systému
Komplikované systémy majú tú nevýhodu, že sa vyvíjajú. Preto niektoré rozhodnutia, ktoré človek urobí na začiatku sa v neskorších štádiách môžu ukázať ako obmedzujúce. V našom prípade sa takto ukázalo zaznamenávanie atribútu “pohlavie” v objednávkach zákazníkov, ktoré by bolo treba vyriešiť inak a lepšie. Prax totiž ukázala, že v takomto nastavení si zákazník môže (omylom) zvoliť rôzne pohlavie pri rôznych objednávkach. To v konečnom dôsledku vedie k drobnej nekonzistentnosti vo výsledných štatistikách. Prerábať kvôli tomu celý systém ale nemalo zmysel. Takže sa všetky následné dynamické prvky neskôr trochu komplikovali o ošetrenie tohto špecifika objednávok.
UI/UX
Takisto sa ukázalo ako málo prioritné považovať za základnú platformu mobil, nie web. Analytika používateľského správania ukázala (čiastočne podľa očakávaní), že športovci stránku navštvujú v drvivej väčšine z mobilov. Za daných okolností by stálo za zváženie či by nebolo lepšie postaviť celý vývoj buď ako appku, alebo primárne na mobily a až ako sekundárne na desktopy/tablety.
Záver
Sfunkčniť tento web bola výzva, ktoré máme radi. Ak máte nejakú podobnú, sme tu pre vás.
