V jednej LMS aplikácii sa riešil zvláštny problém. Študent dokončil lekciu, pozrel video aj vyplnil test, ale v reporte pre lektora mal stále progres iba 60 %. Naopak, vedenie firmy tvrdilo, že kurz dokončilo podozrivo veľa používateľov za pár minút.
Na prvý pohľad všetko fungovalo:
Príklad
Obsahový systém nemusí slúžiť iba na ručné publikovanie článkov cez administráciu. Často má aj API rozhranie, cez ktoré si iné systémy čítajú články, stránky, kategórie, tagy, obrázky, kurzy alebo používateľský progres.
Predstavme si CMS, kde redaktor vytvorí článok. Webová stránka si ho následne načíta cez API.…
Príklad
Predstav si spravodajský alebo vzdelávací portál, kde každý používateľ vidí iný obsah podľa svojho profilu, histórie alebo oprávnení.
Bežný návštevník vidí odporúčané články podľa kategórií, ktoré číta najčastejšie. Prihlásený študent vidí odporúčané kurzy podľa absolvovaných lekcií. Premium používateľ vidí platený obsah, zatiaľ čo bežný používateľ len ukážku článku.…
Príklad
Firma migruje starý CMS systém na novú platformu. Na pôvodnom webe bolo 12 000 článkov, obrázky, kategórie, tagy, SEO meta dáta a používateľské komentáre. Obsah sa exportuje zo starej databázy do XML a následne importuje do nového systému.
Na prvý pohľad migrácia prebehla úspešne. Články sa zobrazujú, obrázky existujú, URL adresy fungujú.…
Príklad
Predstav si portál s online kurzami alebo streamovaciu službu. Používateľ si kúpi mesačné predplatné cez platobnú bránu, napríklad Stripe, GoPay alebo PayPal. Po úspešnej platbe sa mu automaticky odomkne platený obsah.
Na prvý pohľad ide len o „zaplať a získaj prístup“. V praxi však ide o kombináciu:
Príklad
Používateľ môže do systému nahrávať rôzne súbory:
Na prvý pohľad ide o jednoduchú funkcionalitu:
„Vyber súbor → Nahrať.“
V praxi je upload jedným z najrizikovejších miest aplikácie.
Stačí:
a aplikácia môže:
Príklad
Predstavme si portál, ktorý spája redakčný systém a vzdelávaciu platformu.
Používateľ si môže nastaviť, že chce dostávať upozornenia, keď:
Na prvý pohľad ide o jednoduchú vec: systém má poslať e-mail, push notifikáciu alebo zobraziť upozornenie v aplikácii.…
Pridanie komentárov pod články, videá alebo lekcie vyzerá na prvý pohľad jednoducho. V praxi je to však kombinácia formulárov, práv používateľov, notifikácií, moderovania, bezpečnosti a výkonu.
Predstav si portál s online kurzami. Používateľ pridá komentár pod lekciu:
„Video sa mi nedá prehrať od 15:30.“
Lektor dostane notifikáciu, odpovie na komentár a administrátor neskôr nevhodný komentár zmaže.…
Príklad
Predstav si spravodajský portál alebo LMS systém, kde sa články, obrázky, videá a štýly načítavajú cez CDN sieť. Redaktor upraví titulný obrázok článku alebo opraví chybu v texte, ale časť používateľov stále vidí starú verziu obsahu. Iní používatelia už vidia novú verziu. Ďalší majú rozbitý layout, pretože sa načítal nový CSS súbor, ale starý JavaScript zostal v cache.…
Príklad
Predstavme si vzdelávací portál, ktorý má na začiatku iba niekoľko kurzov, desiatky lekcií a pár stoviek používateľov.
Po čase sa však obsah rozrastie:
Príklad
Predstav si portál s článkami (napr. blog, spravodaj alebo LMS). Redaktor vytvorí článok „Ako testovať API“.
Vyplní:
Na prvý pohľad všetko vyzerá správne.…
Príklad
Predstav si portál (napr. spravodajský web alebo LMS), ktorý:
Používateľ vidí obsah „ako keby bol náš“, ale v skutočnosti:
Príklad
Na portáli s článkami má redaktor možnosť vložiť do obsahu obrázky, videá z externých služieb (napr. YouTube) a podcasty ako audio prehrávače.
Používateľ si otvorí článok a očakáva, že:
V praxi sa však často stáva, že:
Tester teda netestuje len „či tam niečo je“, ale celý životný cyklus multimédia – od nahratia až po prehranie u používateľa.…
Príklad
Pracuješ na redakčnom systéme, kde sú minimálne tri roly: autor (redaktor), editor a admin.
Autor môže vytvoriť článok a uložiť ho ako draft. Editor ho môže upraviť a schváliť na publikovanie.
Problém nastane v praxi:
Zrazu nejde len o UI, ale o reálne porušenie procesu a bezpečnosti.…
Príklad
Redakčný systém umožňuje autorovi pripraviť článok dopredu a nastaviť publikovanie napr. na pondelok o 08:00. Redaktor článok schváli v piatok, nastaví dátum a čas publikovania a očakáva, že sa článok v pondelok ráno automaticky zobrazí na webe bez ďalšieho zásahu.
V praxi sa tu netestuje len „či sa to zobrazí“, ale celý mechanizmus: uloženie času, časové pásma, plánovač (CRON), cachovanie a aj správanie pri zmene alebo zlyhaní.…
Príklad
Predstav si e-shop, ktorý podporuje slovenčinu, češtinu a angličtinu. Používateľ si prepne jazyk na nemčinu, ktorú systém oficiálne nepodporuje.
Namiesto fallbacku na angličtinu sa mu zobrazí mix jazykov: menu je po slovensky, produkty po česky a chybové hlášky v angličtine.
Výsledok? Nedôvera, chaos a zvýšené riziko, že používateľ odíde bez nákupu.…
Príklad
Na prvý pohľad vyzerá vyhľadávanie v obsahovom systéme jednoducho. Používateľ zadá slovo, systém niečo nájde a zobrazí výsledky. V praxi sa však práve tu často láme dôvera v celý produkt.
Predstav si redakčný portál alebo firemný knowledge base systém. Autor pridá článok s názvom „Zmena fakturačných údajov“, označí ho tagmi fakturácia, profil, zákazník a zaradí do kategórie Pomoc.…
Príklad
Predstav si redakčný systém, v ktorom editor upraví už publikovaný článok. Pri úprave omylom prepíše dôležitý odsek, zmení titulok a odstráni interný odkaz. Na prvý pohľad je všetko uložené správne, ale po zverejnení si tím všimne, že článok má horší význam, chýbajú v ňom dôležité informácie a prepadla sa aj návštevnosť z vyhľadávania.…
Príklad
Predstav si redakčný systém, kde autor napíše článok a odošle ho na schválenie. Editor ho upraví a nastaví publikovanie.
Na prvý pohľad všetko funguje.
Lenže:
Príklad
Predstav si redaktora, ktorý pripraví článok, uloží ho ako draft a plánuje publikovanie na ráno.
Ráno sa článok zobrazí na webe — ale bez obrázkov, so starou verziou textu a bez SEO titulku.
Výsledok:
CMS nie je len „editor textu“.…
