Hlavní menu

Nástroje

CourseWare / CoOpravduPotrebujeme

View (print) - Edit page | Recent changes - Page history

Updated 01 February 2008, 12:41 by PremekBrada

Seznam požadavků, které musí portál+courseware portlety splňovat, aby byly prakticky a masově použitelné. Ideálně by se (IMHO [P.Brada]) mělo objevit v nějakém issue tracking systému.

Organizační a systémové

  • Provést analýzu potřeb kateder, studentů, dalších subjektů – použitá řešení, technologie, procesy atd. musí vycházet z potřeb a způsobu práce uživatelů portálu. Tento krok je třeba provést dříve než všechny ostatní.
    • Děje se tak na 30%
  • Systémová podpora provozu a rozvoje – univerzitou garantovaná údržba portálu včetně řešení problémů uživatelů, dostatečné projektové a personální zabezpečení pro rozvoj služeb nabízených portálem (ve shodě s bodem 1 výše).
    • Splněno
  • Snadné oznamování nedostatků a námětů – rozhraní pro zadávání požadavků do RT snadno přístupné přímo na portálu, např. v globální nabídce (tak jako je dostupná Správa, Upravit stránku apod.). Řešení přes diskusní forum na úvodní stránce portálu je nedostačující.
    • Víceméně splněno - RT, fakultní coursemasteři

Portál

  • Garantovaná dostupnost, stabilita a rychlost – dlouhodobé výpadky jako jsou profylakční pátky jsou nepřijatelné, krátkodobé časté výpadky taktéž, funkčnost systému se bude měnit v podobném režimu jako jsou změny IS univerzity (tj. letní odstávka), nikoli za provozu, systém bude mít garantovanou rychlou odezvu (vhodná doba od prokliku k plnému zobrazení stránky je do 2s).
    • Splněno až na rychlost, která je snesitelná ale ne lepší
  • Vytěžování a výměna obsahu – schopnost přes definovaná API a distribuční kanály (viz bod 1) importovat data zadávaná v místě vzniku (katedry) a exportovat data vznikající v portálu, nebo přes portál dostupná, pro lokální použití na jiných webech/aplikacích.
    • Nesplněno, hudba budoucnosti
  • Zálohování obsahu, vratnost změn a správa verzí – možnost obnovit předchozí stav obsahu a v optimálním případě i mít dostupnou historii předchozích verzí obsahu, jak z důvodu ochrany proti ztrátě dat, tak dostupnosti důležitých historických dat. Platí zejména pro textový obsah (typicky informační stránky předmětů), viz požadavek na WebCMS? níže.
    • Splněno na 50% - verze a tudíž "zálohy" jednotlivých textů fungují, na záloze předmětu jako celku se pracuje

pravy dat přes portál* – možnost přes webové rozhraní portálu editovat relevantní data ve STAGu?, INISu? a dalších back-end systémech, jako cesta ke zjednodušení aktualizace dat.

  • Hotovo tak na 5% z pohledu učitele. Pracuje se na STAGu?.

CourseWare

  • Jedoznačná a závazná definice struktury předmětu - definovat názvy stránek, přesné portlety které na nich mají být, a co v nich má být za obsah. Třeba i 3 varianty, ale neměnné.
    • Splněno.
  • Flexibilnější přístup k obsahu – zejména u Courseware, ne jen přes katedry, ale také přes „moje předměty“ (student), „studijní programy“ (student, katedra, fakulta), „organizační hierarchii“ apod.
    • Splněno.
  • Byl by vhodný náhled na přístup k obsahu přes autorizační skupiny – možnost nechat si zobrazit web jako příslušník typické autorizační skupiny jiné, než ve které je aktuální uživatel. Důležité např. pro vyučující, kteří potřebují ověřit, co ze stránek jimi editovaných předmětů je (ne)dostupné studentům těchto předmětů, ostatním studentům, atd.
    • Nesplněno, technicky velmi složité
  • Lepší správa předmětů vyučujícími – jednak snazší možnost definovat přístup k úpravám obsahu (vč. automaticky dle dat o vyučujících – přednášejícím i cvičících – ve STAGu?), za druhé zahrnutí doktorandů do skupiny „zaměstnanci“ pro účely správy obsahu předmětů.
    • Splněno tak na 20% - umí se přidat/ubrat editoři, nic lepšího
  • Zakomponování WebCMS? - velká část obsahu předmětu je strukturovaný text, který by měl být spravovaný přes webový redakční systém, nikoli ukládaný do izolovaných portletů.
    • Nesplněno, ale naučili jsme se s tím žít

Portlety pro CourseWare


Patří do KategorieCourseWare