Technická specifikace
Příloha č. 03 Výzvy k podání nabídek (stane se přílohou č. 1 uzavřené Smlouvy o dílo)
Technická specifikace
pro zpracování nového webu UHK
Obsah
2. Požadavky na zpracování webu 4
2.1.1 Předpokládané role uživatelů (univerzitní web) 5
2.2.1 Hierarchická struktura 7
2.3 Informační architektura, prototyp 8
2.3.1 Předpokládané typy stránek (univerzitní web) 9
2.3.2 Předpokládané prvky na homepage (univerzitní web) 9
2.6 Použitelnost a přístupnost 12
3. Požadavky na redakční systém 13
3.13 Spolupráce s interními systémy 21
5.1 Současný stav webové prezentace UHK 24
5.2 Základní údaje z Google Analytics 25
1. Hlavní rámcové cíle
Tato specifikace se týká kompletního vytvoření celouniverzitní veřejné webové prezentace, dále jen
„univerzitní web“, a zároveň vytvoření webové prezentace pro uchazeče, dále jen „web pro uchazeče“. To zahrnuje mj. úvodní analýzy a výzkum, vytvoření hierarchické struktury, grafické zpracování, responzivní šablony, restrukturalizaci a přesun obsahu, implementaci redakčního systému vč. napojení na interní systémy. Dále po dobu 5 let od předání kompletního díla i aktualizace softwaru a řešení bezpečnostních incidentů a havárií.
„Zhotovitel“ značí v této specifikaci odpovědnou osobu na straně zhotovitele. „Objednatel“ značí v této specifikaci odpovědnou osobu na straně objednatele.
Univerzitní web i web pro uchazeče musí splňovat následující hlavní cíle:
• 1_01 mít vizuálně atraktivní a moderní formu, ale ne na úkor přehlednosti a použitelnosti
• 1_02 mít logickou intuitivní hierarchickou strukturu s přiměřeným zanořením a bez duplicit, položky první úrovně by měly být zhruba rovnocenné svou váhou a významem
• 1_03 respektovat vizuální styl univerzity, jehož podmínky jsou zveřejněny zde: xxxxx://xxx.xxx.xx/xx-XX/Xxxxxxxx?XxxxxxxxXXx00000, zejména barvy, symboly a fonty; pozn.: od 1.9.2017 pouze 4 fakulty bez FSP / ÚSP
• 1_04 vhodně implementovat responzivní design, optimalizace pro malé (mobily, tablety) i velké displeje (širokoúhlé monitory), mobile-first přístup, optimalizace pro dotykové displeje
• 1_05 respektovat publikování informací prostřednictvím dalších zdrojů (Facebook, Youtube, různé samostatné weby univerzitní i externí) a vhodným způsobem začlenit na web
• 1_06 moderně a zároveň přehledně prezentovat poslední novinky, pozvánky a grafické upoutávky
• 1_07 weby budou implementovány v open source redakčním systému, případně lze i v proprietárním řešení, ale v tom případě požadujeme přístup ke zdrojovému kódu z důvodu budoucí údržby a rozvoje vlastními silami, a to včetně dokumentace
• 1_08 budou dodržovat v maximální možné míře pravidla pro použitelnost a přístupnost
• 1_09 použitelnost bude otestována ve fázi zpracování interaktivního prototypu, grafického návrhu a hotových šablon webu, aby se ověřila správnost příslušných návrhů
• 1_10 budou optimalizovat výkon, umožňovat funkční vyhledávání nad různými typy obsahu z více zdrojů
• 1_11 redakční systém bude bezpečně a efektivně spolupracovat s interními systémy vč. dokumentového úložiště a interního LDAP řešení
• 1_12 instance redakčního systému bude shodná pro univerzitní web i web pro uchazeče, na webu pro uchazeče bude možné zobrazovat vybraný obsah z univerzitního webu
• 1_13 návrh a následná implementace musí respektovat strukturu univerzity, tj. celouniverzitní obsah („uzel UHK“) a obsah samostatných součástí, tj. čtyř fakult (uzly „FF“,
„FIM“, „PdF“, „PřF“)
Univerzitní web musí dále splňovat následující hlavní cíle:
• 1_14 představit UHK jako důstojnou, prestižní ale zároveň moderní instituci, která je atraktivní pro uchazeče o studium a absolventy a perspektivní pro potenciální partnery
• 1_15 přehledně prezentovat informace pro rozdílné role uživatelů (viz 2.1 Úvodní studie a 2.1.1 Předpokládané role uživatelů), mimo jiné také upozornit na úspěchy univerzity (úspěšné studenty a absolventy), propagovat vědu a výzkum a mezinárodní vztahy
• 1_16 grafika webu bude zahrnovat modifikace pro každou fakultu dle vizuálního stylu
Web pro uchazeče musí dále splňovat následující hlavní cíle:
• 1_17 vhodně oslovit věkovou skupinu uchazečů 17-20 let (web pro uchazeče)
• 1_18 fungovat jako atraktivní ale přehledný informační rozcestník (např. xxxx://xxxxx.xx, xxxx://xxxxxxxxxx.xx/, xxxx://xxxxxx.xxx.xx/)
2. Požadavky na zpracování webu
Konkrétní požadavky na zpracování webu jsou rozepsány níže v příslušných sekcích dle tématu / fáze zpracování. Pozn.: Konkrétní požadavky lze se souhlasem objednatele upravit, pokud zhotovitel nabídne kvalitativně srovnatelnou nebo lepší variantu zpracování požadovaného. Předmětem smlouvy pak bude tato upravená specifikace. O tom, zda je řešení kvalitativně srovnatelné či lepší, rozhoduje v případě neshody výhradně objednatel, který nemusí zhotoviteli zdůvodňovat zvolená kritéria posouzení variant. Stejně tak tam, kde specifikace nechává požadavkům otevřený prostor pro „vhodnost“ či „dostatečnost“, o tom co vhodné / dostatečné je či není rozhoduje objednatel. Veškeré požadavky ke zpracování v této specifikaci jsou kladeny na zhotovitele, pokud není explicitně uvedeno jinak. Výrazem pouze „web“ se myslí oba dva zpracovávané weby, tj. univerzitní web i web pro uchazeče, pokud není specifikováno jinak.
Časová posloupnost požadavků (a souvisejících výstupů práce zhotovitele) daná touto specifikací není závazná, pokud zhotovitel navrhne posloupnost vhodnější. Nicméně vždy platí, že další navazující výstupy budou vycházet ze závěrů a výstupů předchozích, tj. zejména veškeré provedené analýzy budou vhodným způsobem využity při zpracovávání díla a budou mít reálný přínos pro celé dílo. Co se týče posloupnosti a termínů jednotlivých prací a výstupů, závazný je v tomto ohledu materiál „Harmonogram prací“ (příloha č. 2 Smlouvy o dílo).
Veškeré aspekty webu, které nejsou explicitně popsány v této specifikaci, budou řešeny způsobem obvyklým, a to s ohledem na zaměření a rozsah webu.
2.1 Úvodní studie
• 2.1_01 bude provedena analýza hlavních cílů, potřeb a požadavků objednatele na základě osobní konzultace a dodaných materiálů, naše představa byla specifikována v sekci 1 Hlavní rámcové cíle
o 2.1_01_a pokud závěry analýzy budou v rozporu s požadavky v sekci 1 Hlavní rámcové cíle, zhotovitel předá písemný návrh na změnu specifikace, a to formou dodatku ke smlouvě, který bude podléhat schválení ze strany objednatele (bez jeho souhlasu nadále platí touto specifikací stanovené cíle a požadavky)
• 2.1_02 ve spolupráci s objednatelem budou definovány hodnoty univerzity, komunikační strategie, marketingová strategie, obsahová strategie atp., po konečném schválení ze strany objednatele zhotovitel tyto závěry použije jako další východiska při tvorbě webu, web bude demonstrovat hodnoty univerzity a komunikovat benefity především pro primární, ale i pro sekundární podporované role uživatelů (viz 2.1.1 Předpokládané role uživatelů)
• 2.1_03 bude provedena analýza rolí uživatelů, pro které je nutné web primárně optimalizovat a dalších podporovaných rolí uživatelů, jejich cíle a potřeby, naše úvodní představa je naznačena v sekci 2.1.1 Předpokládané role uživatelů
• 2.1_04 bude proveden uživatelský výzkum pro primární podporované role uživatelů, a to takového rozsahu a za použití takových metod, aby se maximálně odpovědně stanovily
odpovědi na otázky „čeho chtějí uživatelé dosáhnout?“, „co vnímají jako důležité?“, „jaký benefit pro sebe očekávají?“, „jaké mají obavy?“ atp.
o 2.1_04_a metodologie bude obsahovat počet účastníků u každé zvolené metody
o 2.1_04_b závěry z tohoto testování budou vhodně využity při tvorbě webu
o 2.1_04_c pokud některé závěry na základě tohoto uživatelského výzkumu budou v rozporu s požadavky na web kladenými v této specifikaci, zhotovitel předá písemný návrh na změnu specifikace, a to formou dodatku ke smlouvě, který bude podléhat schválení ze strany objednatele
• 2.1_05 bude provedena konkurenční analýza – analýza konkurenčních českých řešení, metodologie bude obsahovat seznam analyzovaných konkurentů
• 2.1_06 pro veškeré požadavky, které zahrnují zpracování dat a informací, analýzu a/nebo výzkum, platí, že minimálně metodologii a závěry zpracuje zhotovitel písemně a předá objednateli elektronicky, na vyžádání objednatele doplní či vysvětlí požadované části dodaných materiálů
• 2.1_07 v případě, že zhotovitel v rámci výběrového řízení zpracoval soutěžní grafický návrh, který byl kladně přijat komisí, bude u všech návrhů dle této specifikace usilovat o maximální strukturální, vizuální a příp. i funkční podobnost s daným soutěžním návrhem
o 2.1_07_a soutěžní grafický návrh tak bude použit jako „koncept“ pro grafický návrh řešení a všech návrhů mu předcházejících
o 2.1_07_b zároveň ale tato podobnost nebude vynucena na úkor závěrů ze sekce
2.1 Úvodní studie a dalších relevantních sekcí, které budou respektovány především
o 2.1_07_c soutěžní grafický návrh bude tedy dále doplněn a příp. i upraven dle provedených prací, závěrů a výstupů dle této specifikace
2.1.1 Předpokládané role uživatelů (univerzitní web)
primární podporované role:
o uchazeči o studium – potřeba zaujmout
o potenciální partneři pro spolupráci – firmy, střední školy, oblast vědy a výzkumu sekundární podporované role:
o absolventi – podpořit spojení s univerzitou, aby ji chtěli podporovat
o média, novináři – tiskové zprávy, PR
o odborná komunita
o další veřejnost
tyto role by měly být přesměrovány na intranet:
o studenti
o zaměstnanci
o přijatí uchazeči
v anglické verzi webu především:
o zahraniční uchazeči o studium
o incoming students (ještě bude diskutováno, zda nepřesunout do intranetu)
o zahraniční vysokoškolské instituce (mobility, věda a výzkum)
Pozn. pro web pro uchazeče předpokládáme primární podporovanou roli „uchazeč o studium“.
2.2 Obsah a struktura
• 2.2_01 bude zpracována obsahová a strukturální analýza vč. klasifikační analýzy klíčových slov, na základě obsahu na současném webu objednatele a závěrů z 2.1 Úvodní studie
o 2.2_01_a analýza bude provedena zvlášť pro univerzitní web, pro fakultní weby v rámci univerzitního, web pro uchazeče a pro anglickou verzi univerzitního webu
• 2.2_02 bude provedena důkladná revize struktury a obsahu a plán restrukturalizace, aktualizací a změn stávajícího obsahu (rozhodně tedy ne přesun 1:1) a zpracování nového obsahu, při respektování rámcového plánu viz „Harmonogram prací“, podle plánu pak zpracování obsahu bude realizováno, a to:
o 2.2_02 _a s ohledem na závěry analýzy uživatelských rolí, uživatelského výzkumu, konkurenční analýzy a obsahové a strukturální analýzy
o 2.2_02 _b s ohledem na definované hodnoty univerzity, komunikační strategii, marketingovou strategii, obsahovou strategii atp.
o 2.2_02 _c s ohledem na povinně zveřejňované údaje a další specifika veřejných institucí
o 2.2_02 _d při vhodné součinnosti s objednatelem
o 2.2_02 _e s cílem zeštíhlení / redukce a zpřehlednění webu z obsahového hlediska
o 2.2_02 _f s cílem zkvalitnění tohoto obsahu i způsobu jeho prezentace
o 2.2_02 _g s cílem odstranění nedostatků současného webu (jako např. prázdné či poloprázdné stránky, neaktuální informace, duplicity)
o 2.2_02_h bude zpracováno samostatně avšak ve vzájemné souvislosti a návaznosti v rámci následujících celků: univerzitní web, fakultní weby v rámci univerzitního, web pro uchazeče a anglická verze univerzitního webu
o 2.2_02_i u aktualit, událostí a/nebo pozvánek budou navrženy vhodné kategorie (např. Kultura, Sport, Věda a výzkum, Naše úspěchy,...), na základě kterých pak bude možné tyto položky filtrovat, zobrazovat štítek s tématem atp. dle navržené implementace
o 2.2_02 _j dále upravuje příloha „Harmonogram prací“ smlouvy o dílo
• 2.2_03 bude zpracován návrh hlavní hierarchické struktury (mapy webu) v souladu s předchozím bodem
o 2.2_03_a návrh předpokládáme ve čtyřech modifikacích: pro univerzitní web, pro fakultní weby v rámci univerzitního, pro web pro uchazeče a pro anglickou verzi univerzitního webu
o 2.2_03_b návrh bude respektovat strukturu univerzity, tj. hlavní uzly (zobrazované jako homepage) by měly být UHK a její 4 součásti (FF, FIM, PdF, PřF), potom první úrovní hierarchické struktury se myslí základní kategorizace obsahových položek každého z hlavních uzlů, tj. položky hlavní navigační lišty
o 2.2_03_c návrh hierarchické struktury bude kompletován min. do druhé úrovně, při zpracování obsahu a implementaci bude počítáno s rozšířením struktury dle potřeby
o 2.2_03_d je nutná vhodnost kategorizace obsahu vzhledem k zavedeným zvyklostem v rámci českých univerzitních webů, dále vzhledem k logice uspořádání, a také vzhledem k samotnému obsahu UHK
o 2.2_03_e dále viz 2.2.1 Hierarchická struktura
• 2.2_04 související strategie a návrhy (a následně i redakční systém) budou umět řešit položky s přesahem do intranetu (napojení na intranet viz 3.13 Spolupráce s interními systémy), tj. předpokládáme existenci sekcí webu, jednotlivých stránek a dokumentových úložišť, které:
o 2.2_04_a jednoznačně spadají do veřejného webu, budou řešeny v rámci této specifikace zhotovitelem
o 2.2_04_b jednoznačně spadají do intranetu, budou řešeny objednatelem
o 2.2_04_c položky, jejichž zařazení není jednoznačné – obecně v rámci veřejného webu by měly být prezentovány propagační a obecné informace, s odkazem do
intranetu pro např. aktuální nabídky pro studenty, návody, termíny, přihlášky, formuláře a administrativní záležitosti, podrobné podmínky,...
• 2.2_05 v případě, že zhotovitel v rámci výběrového řízení zpracoval hierarchickou strukturu, která byla kladně přijata komisí, bude u návrhů hierarchické struktury dle této specifikace usilovat o maximální podobnost s daným soutěžním návrhem
o 2.1_07_a soutěžní návrh struktury tak bude použit jako „koncept“ pro návrh struktury dle této specifikace
o 2.1_07_b zároveň ale tato podobnost nebude vynucena na úkor závěrů ze sekce
2.1 Úvodní studie, této sekce (2.2 Obsah a struktura) a dalších relevantních sekcí
o 2.1_07_c soutěžní návrh struktury bude tedy dále doplněn a příp. i upraven dle provedených prací, závěrů a výstupů dle této specifikace
• 2.2_06 co se týče anglické verze univerzitního webu, požadujeme zúženou verzi české verze, po vzoru xxxx://xxx.xxx.xx/xx/, tj. jiná hierarchická struktura než v české verzi
o 2.2_06_a homepage bude univerzitní i jednotlivé fakultní jako v případě české verze (tj. hlavní uzly budou UHK a její 4 fakulty)
o 2.2_06_b anglická verze webu bude zahrnovat informace pro „incoming students“ na celouniverzitní úrovni, v případě existence informací na univerzitní a fakultní úrovni viz 2.2.1 Hierarchická struktura.
Hierarchickou strukturou se myslí primární hierarchická organizace stránek celého webu, tj. mapa webu, hlavní navigace atp. V rámci univerzitního webu na základě naší rámcové představy navrhujeme (ale nutně nevyžadujeme v případě návrhu vhodnějšího řešení) tato pravidla:
1. První úroveň celouniverzitní a fakultní struktury
• fakultní struktura se odvíjí od struktury celouniverzitní (např. analogicky Kontakty, Studium, Fakulty -> Katedry, ...)
• fakultní struktura 1. úrovně bude shodná pro všechny fakulty
2. Druhá úroveň fakultní struktury bude obsahovat:
• položky shodné pro všechny fakulty
• položky povinné (např. Organizační struktura, Studijní obory,..)
• položky nepovinné, pokud za fakultu není tematicky odpovídající obsah (např. Praxe a stáže, Doktorandi, Kurzy a školení, ...)
• položky jedinečné pro danou fakultu (např. FIM/Telegraf, PDF/Pedagogické dny, FF/Xxxxxxxx knihovna, ...)
Nelze, aby se jedna informace spravovala v systému na více místech, tj. vznik duplicit. V případě existence položky na obou úrovních (celouniverzitní i fakultní) bude zvolena vhodná strategie pro správu obsahu, např.
• ze stránky na fakultní úrovni může být přesměrováno na stránku univerzitní úrovně
• ze stránky na univerzitní úrovni může vést rozcestník na jednotlivé stránky na fakultních úrovních
Informace se tedy nebudou uchovávat duplicitně, ale budou vhodně provázány, přesměrovány atp. podle konkrétních potřeb a zvolené obsahové strategie. To samé platí pro vztah univerzitního webu a webu pro uchazeče, na webu pro uchazeče bude možné zobrazovat obsah z univerzitního webu.
2.3 Informační architektura, prototyp
• 2.3_01 na základě závěrů ze sekce 2.1 Úvodní studie a 2.2 Obsah a struktura bude navržena nová informační architektura, rozepsaná detailněji v následujících bodech
• 2.3_02 bude zpracován návrh wireframe (drátěný model, rozmístění prvků na stránce) minimálně pro následující typy stránek:
o 2.3_02_a návrh pro hlavní homepage univerzitního webu (1)
o 2.3_02_b návrh pro běžnou stránku univerzitního webu (1)
o 2.3_02_c návrhy pro homepage všech fakult v rámci univerzitního webu (5)
o 2.3_02_d návrhy pro běžnou stránku všech fakult v rámci univerzitního webu (5)
o 2.3_02_e návrh pro homepage webu pro uchazeče (1)
o 2.3_02_f návrh pro běžnou stránku webu pro uchazeče (1)
o 2.3_02_g modifikace návrhu pro základní identifikované typy stránek, které jsou výstupem předchozích prací, dle dohody s objednatelem
• 2.3_03 návrhy wireframe dále musí splňovat následující:
o 2.3_03_a volba a uspořádání jednotlivých obsahových, navigačních a vizuálních prvků musí mít opodstatnění a vycházet z předchozích závěrů a výstupů, naše rámcová úvodní představa je naznačena v sekci 2.3.2 Předpokládané prvky na homepage
o 2.3_03_b budou provedeny ve třech responzivních provedeních, pro malou (360 x 640), střední (1366 x 768) a velkou obrazovku (1920 x 1080), u všech nutné počítat s možným dotykovým displejem
o 2.3_03_c požadujeme zobrazování první hierarchické úrovně jako „hlavní menu“ a druhé hierarchické úrovně jako tzv. „lokální menu“, s možností rozkliknutí na další úrovně, přičemž cesta k aktuální stránce bude rozkliknutá defaultně a aktuální stránka v seznamu bude graficky odlišena a nebude se chovat jako odkaz
o 2.3_03_d bude vhodně začleňovat kromě hlavní hierarchické struktury také další navigační schémata
o 2.3_03_e hierarchická struktura a další navigační schémata budou dohromady tvořit přehlednou a intuitivní navigaci pro všechny podporované role uživatelů a zároveň se nebudou zcela vymykat běžné praxi dalších vysokých škol, především co se týče členění první úrovně hierarchické struktury a používaného názvosloví
o 2.3_03_f návrhy budou vhodně okomentovány tak, aby byla zjevná alespoň základní motivace a/nebo odůvodnění k volbě zobrazovaných prvků, jejich uspořádání a priorit umístění
• 2.3_04 návrhy wireframe budou doplněny o další řešené prvky informační architektury, tam kde komentáře k wireframům nejsou postačující, jako např.
o 2.3_04 _a identifikace významných obsahových prvků, jejichž umístění a zobrazení bude třeba věnovat speciální pozornost, např. Studijní programy, Kontaktní osoby, Personální obsazení, Události, Pozvánky na tyto události, Aktuality atp.
o 2.3_04 _b identifikace jednotlivých typů stránek (resp. šablony) kromě těch základních viz 2.3_02, naše rámcová úvodní představa (nikoliv kompletní) je naznačena v sekci 2.3.1 Předpokládané typy stránek
• 2.3_05 wireframe bude po schválení rozpracován na formu interaktivního prototypu webu, který bude odrážet navrhovaný interakční design
• 2.3_06 ve všech návrzích bude kladen důraz na přehlednost, účelnost, snadnou a intuitivní orientaci uživatele v rozumném množství navigačních lišt
• 2.3_07 některé strukturální a později i grafické prvky mohou být ovlivněny specifickými požadavky ze sekce 3 Požadavky na redakční systém, kam byly pro ucelenost v rámci specifikace zařazeny, dále u návrhů vyžadujeme následující specifika:
o 2.3_07_a na homepage konkrétní fakulty už nebudou dominovat odkazy na ostatní fakulty
o 2.3_07_b vhodná implementace odkazu návrat na homepage, např. přes proklik loga, a to jak na celouniverzitní, tak i fakultní
o 2.3_07_c návrh a následná implementace musí respektovat strukturu univerzity, tj. celouniverzitní obsah („uzel UHK“) a obsah samostatných součástí, tj. čtyř fakult (uzly „FF“, „FIM“, „PdF“, „PřF“)
• 2.3_08 zhotovitel provede testování použitelnosti jím navrženého rozhraní (ve formě interaktivního prototypu) pro reprezentativní skupinu uživatelů, aby se ověřila správnost dosavadních návrhů
o 2.3_08_a je vyžadována účast objednatele při testování
o 2.3_08_b testování bude rámcově probíhat dle metodologie naznačené v knize Nenuťte uživatele přemýšlet / Xxxxx Xxxx
o 2.3_08_c testované uživatele a základní technické zázemí pro testování zajistí objednatel
o 2.3_08_d pokud má zhotovitel specifické požadavky na zařízení, které není objednatel schopen zajistit, zajistí toto zařízení zhotovitel, a zároveň poskytne objednateli informace k metodologii testování s tímto zařízením
o 2.3_08_e po testování zhotovitel zpracuje a poskytne objednateli písemné vyhodnocení výsledků, na základě toho navrhne plán změn dosavadních návrhů a po schválení objednatelem zapracuje do stávajících návrhů
o 2.3_08_f pokud testování odhalilo zásadní chyby a/nebo velké množství chyb, dle zhodnocení objednatele, provede zhotovitel druhou iteraci testování použitelnosti opravených návrhů
2.3.1 Předpokládané typy stránek (univerzitní web)
• homepage – univerzitní a všech součástí (tj. hlavní uzly)
• běžná stránka – podpora všech běžných typů obsahu jako např. formátovaný text (vč. obrázků, tabulek,odkazů,...), obrázková galerie, příbuzné stránky, přiložené soubory,...
• přehled aktualit a jednotlivá aktualita
• přehled událostí (kalendář) a jednotlivá událost
• profilová karta zaměstnance – vč. jména, titulů, pracovní zařazení, email, telefon,... (data budou poskytnuta z intranetu, zde jen zobrazení)
• rozcestník budov s mapou, jednotlivé budovy a pracoviště
• katalogová stránka a položka – na principu přehledu záznamů s možností překliknutí na detail konkrétního záznamu (např. publikace nakladatelství, studijní obory, různé seznamy spravované vlastním intranetovým řešením – viz 3.13 Spolupráce s interními systémy )
• ...
2.3.2 Předpokládané prvky na homepage (univerzitní web)
• logo a název univerzity
• posuvník / slider / carousel grafických upoutávek nebo alternativní způsob prezentace graficky zpracovaných informací
• přepínání české a anglické verze
• první úroveň hierarchické navigace (max 8 položek)
• odkazy na fakulty (4 položky)
• odkazy na další samostatné weby jako např. web pro uchazeče, intranet atp., s možností grafických i textových odkazů
• odkaz na Facebook a Youtube (případně jinak řešená integrace dalších zdrojů)
• vyhledávací pole, případně rozlišení např. hledání osob a dokumentů
• krátký úvodní odstavec a volitelně foto
• min. 2 novinky (xxxxxx, krátký text, každá volitelně s fotem nebo bez)
• min. 2 pozvánky na události (nadpis, krátký text, datum konání)
• aktuální a nejbližší události, minimálně v současný den a následující – ve formě kalendáře nebo jiný přehledný způsob
2.4 Grafický návrh
• 2.4_01 grafický návrh musí odpovídat objednatelem odsouhlasenému drátěnému modelu, interaktivnímu prototypu a východiskům z úvodní studie, dále viz požadavek 2.1_07 o vztahu k soutěžnímu grafickému návrhu
• 2.4_02 grafický návrh bude v maximální možné míře usilovat o
o 2.4_02_a vizuální atraktivitu, poutavost, přívětivost
o 2.4_02_b začlenění originálního nápadu či příběhu
o 2.4_02_c vyvolání žádoucího dojmu, tj. a) u univerzitního webu představit UHK jako důstojnou, prestižní ale zároveň moderní instituci, která je atraktivní pro uchazeče o studium a perspektivní pro potenciální partnery a b) u webu pro uchazeče zejména oslovit věkovou skupinu 17-20 let (viz sekce 1 Hlavní rámcové cíle)
o 2.4_02_d dodržení základních pravidel pro použitelná webová rozhraní, tj. přehlednost a smysluplnost (dále také viz kapitola 2.6 Použitelnost a přístupnost)
o 2.4_02_e responzivitu, tj. vhodné přizpůsobení pro daný rozměr obrazovky
• 2.4_03 grafický návrh musí být v souladu s vizuálním stylem univerzity a vhodně aplikovat symboly a barvy pro ustavení identity a odlišení fakult, a to při zachování maximální použitelnosti (např. dodržení doporučeného kontrastu, vyhnutí se zbytečnému opakování a vizuálnímu šumu, dále viz kapitola 2.6 Použitelnost a přístupnost)
• 2.4_04 požadujeme následující grafické návrhy:
o 2.4_04_a graf. návrh pro hlavní homepage univerzitního webu (1)
o 2.4_04_b graf. návrh pro běžnou stránku univerzitního webu (1)
o 2.4_04_c graf. návrhy pro homepage všech součástí univerzitního webu (5)
o 2.4_04_d graf. návrhy pro běžné stránky všech součástí univerzitního webu (5)
o 2.4_04_e graf. návrh pro homepage webu pro uchazeče (1)
o 2.4_04_f graf. návrh pro běžnou stránku webu pro uchazeče (1)
o 2.4_04_g modifikace grafických návrhu pro základní identifikované typy stránek, které jsou výstupem předchozích prací, dle dohody s objednatelem
• 2.4_05 zhotovitel dodá objednateli všechny požadované návrhy
o 2.4_05_a ve třech responzivních provedeních, pro malou (360 x 640), střední (1366 x 768) a velkou obrazovku (1920 x 1080), u všech nutné počítat s možným dotykovým displejem
o 2.4_05_b v souborovém formátu výchozího vrstveného PSD a výstupního PNG
• 2.4_06 součástí dodání grafických návrhů pro web budou grafické šablony pro zobrazování grafických upoutávek / úvodníků / obrázkových posuvníků (dle grafického návrhu webu)
o 2.4_06_a s rozměry přesně odpovídajícími grafickému návrhu webu
o 2.4_06_b v souborovém formátu výchozího vrstveného PSD a výstupního PNG
o 2.4_06_c ve stylu konzistentním s celkovým stylem grafických návrhů
o 2.4_06_d min. 2 varianty, každá v provedení celouniverzitním a pro každou fakultu
• 2.4_07 grafické návrhy budou dále splňovat následující:
o 2.4_07_a budou v rámci jednotlivých homepage moderně a zároveň přehledně prezentovat příslušné poslední novinky, pozvánky a grafické upoutávky
o 2.4_07_b pro zobrazení událostí požadujeme kalendář akcí v rámcové podobě a funkčním zpracování viz xxxx://xxx.xxxx.xx/ (dále specifikováno v části 3.5 Aktuality a události)
o 2.4_07_c v grafických návrzích pro běžné stránky webu bude vidět grafické zpracování nejběžněji používaných prvků, jmenovitě: nadpisy až do 3. úrovně, odstavce, citace, seznamy, tabulky, odkazy, obrázky zarovnané v textu, fotogalerii, výpis složek a souborů
o 2.4_07_d v grafických návrzích bude naznačeno grafické odlišení aktuální sekce v navigaci a grafické odlišení textového a obrázkového odkazu při interakci uživatele (hover)
o 2.4_07_e v rámci grafických návrhů bude řešeno speciální strukturální a grafické zpracování významných obsahových prvků, které budou definovány v rámci úvodní studie (také viz 2.3_04 _a)
o 2.4_07_f pokud bude pro návrh použit slider, carousel nebo jiný grafický prvek zabírající velkou část obrazovky, bude použit pouze na homepage nebo jiných speciálních stránkách, ne už na běžných stránkách (příp. bude redukován, obecně nebude omezovat přístup k obsahu)
o 2.4_07_g pokud bude web obsahovat kromě obsahového bloku také pozadí, tak toto pozadí nebude graficky výrazné tak, aby rušilo při prohlížení a čtení webu
• 2.4_08 provedení testování použitelnosti navrženého grafického návrhu, obdobně viz předchozí kapitola 2.3 Informační architektura, prototyp
• 2.4_09 ve grafickém a následném zpracování nebudou opomenuty chybové stránky 403, 404 a 500, které pak bude vhodně implementovat redakční systém
2.5 Kódové zpracování
• 2.5_01 na základě odsouhlasených grafických návrhů budou zpracovány šablony validní v HTML5 a CSS3 (dle xxxxx://xxxxxxxxx.x0.xxx), analogicky strukturou i stylem budou vytvořeny šablony pro zbývající typy stránek, které v předchozím kroku nebyly zpracovány
• 2.5_02 šablony (a následně celý web) budou vhodně implementovat responzivní design, tj. optimalizovat vzhled a použitelnost pro obrazovky s nejpoužívanějšími rozlišeními obrazovky a přijatelně se zobrazovat a fungovat na všech ostatních obrazovkách s libovolným rozlišením
• 2.5_03 požadován je přístup Mobile-first a Progressive enhancement (postupné vylepšování)
• 2.5_04 nejpoužívanější rozlišení obrazovky jsou definované zde: 1920 x 1080, 1600 x 900, 1440 x 900, 1366 x 768, 1280 x 800, 1280 x 1024, 768 x 1024, 360 x 640
• 2.5_05 zejména v nižších rozlišeních bude kód dále optimalizován pro dotykové displeje, tj. interakce nebude vyžadovat kurzor myši, navigační prvky budou dostatečně velké, vhodné rozvržení obsahu (ne rozbalené menu před samotným obsahem) apod.
• 2.5_06 šablony (a následně celý web) budou optimalizovat vzhled a použitelnost pro nejpoužívanější prohlížeče a přijatelně se zobrazovat a fungovat ve všech ostatních prohlížečích
• 2.5_07 nejpoužívanější prohlížeče jsou definované zde: Chrome, Firefox, MSIE 11, Chrome Mobile, Edge, WebKit Mobile, Opera, Safari, Android Browser, Safari Mobile
• 2.5_08 požadavky na kvalitní kód – čistý, strukturovaný, znovupoužitelný – efektivní definice selektorů, sdružování souvisejících definic na jedno místo, vhodně využitá dědičnost atp.
• 2.5_09 veškeré styly (CSS) a skripty (JS, tj. JavaScript a jeho knihovny) budou definovány v externích souborech, ne inline definice, styly nebudou přidávany primárně přes skripty pokud k tomu nebude oprávněný důvod (dynamické zobrazení)
• 2.5_10 sémanticky správné použití strukturních elementů HTML5, použití strukturovaných dat tam, kde je to vhodné (xxxxxx.xxx, mikroformáty, RDFa nebo JSON-LD)
• 2.5_11 grid system použitý pro responzivní design bude v CSS stylech transparentně definován, v případě použití externího řešení bude definován jeho zdroj, použití box modelu s definicí box-sizing: border-box pro prohlížeče, které ho správně implementují
• 2.5_12 veškerý kód (HTML, CSS i JS), fonty, ikony a jiné komponenty převzaté z externího zdroje (např. frameworky, UI kity aj.) budou ve zdrojovém kódu / adresáři také transparentně označeny
• 2.5_13 šablony (a následně celý web) budou optimalizovat vzhled a použitelnost také pro čtečky a tisk (tj. bude obsahovat tiskový styl pro tiskový výstup)
• 2.5_14 šablony budou otestovány na reprezentativním vzorku reálných zařízení s různými rozlišeními a na základě tohoto testování zhotovitel ověří jejich správné zobrazovaní, zjištěné chyby zobrazení je povinen řešit a šablony opravit
2.6 Použitelnost a přístupnost
• 2.6_01 vizuální podoba webu nesmí výrazněji omezovat použitelnost a přístupnost
• 2.6_02 web bude v maximální možné míře vyhovovat požadavkům Vyhlášky o přístupnosti (64/2008 Sb.) a doporučení Web Content Accessiblity Guidelines 2.0 na úrovni A a AA, zejména:
o 1.1.1 netextový obsah (až na výjimky) má textovou alternativu
o 1.3.1 až 1.3.3 obsah prezentovatelný bez ztráty informací
o 1.4.1 barva není jediným nositelem informace
o 1.4.3 dodržení minimálního kontrastu
o 2.1.1 a 2.1.2 veškerá funkčnost je dosažitelná pomocí klávesnice
o 2.2.1 a 2.2.2 možnost zastavit, skrýt nebo jinak ovlivnit pohybující se obsah
o 2.3.1 web nebude obsahovat blikající prvky
o 2.4.1 až 2.4.4 navigační mechanismy, odkazy s kontextem
o 3.2.1 až 3.2.4 předvídatelnost, konzistentní navigace a identifikace
o 3.3.1 až 3.3.4 popisky vstupních polí, opravy a prevence chyb ve formulářích
o 4.1.1 a 4.1.2 nevynechávání koncových značek, správné zanořování, ID jsou unikátní
• 2.6_03 web se bude správně a shodně zobrazovat v nejpoužívanějších prohlížečích (definovaných výše v sekci 2.5 Kódové zpracování), u méně používaných prohlížečů jsou možné mírné grafické odchylky, které nebrání běžnému prohlížení a používání webu
• 2.6_04 u webu budou dodrženy obecně platné zásady pro design, specifické zásady pro web design a pro použitelnost uživatelských rozhraní, zejména:
o 2.6_04_a vhodné použití barev, grafiky, ikonek,.. (v souladu s vizuálním stylem UHK)
o 2.6_04_b ustavení vizuální hierarchie, vhodná aplikace kontrastů a zdůraznění (které budou funkční i bez interakce uživatele)
o 2.6_04_c čistý design a vhodně použitý prázdný prostor, eliminace rušivého vizuálního šumu a „přeplácanosti“
o 2.6_04_d přehledný layout a rozmístění prvků na stránce
o 2.6_04_e použití smyslupných navigačních schémat
o 2.6_04_f vhodná organizace, kategorizace a hierarchie obsahu
o 2.6_04_g správná aplikace Gestalt principů (blízkost a podobnost), shlukování, seskupování, opakování, tam kde je to vhodné
o 2.6_04_h použití vrstvení a postupného odhalování informací, tam kde je to vhodné
o 2.6_04_i jednoduché a intuitivní použití navigace
o 2.6_04_j vhodné navigační indikátory (drobečková navigace)
o 2.6_04_k snadno přístupné a použitelné vyhledávání
o 2.6_04_l strukturální konzistence (layout, umístění prvků)
o 2.6_04_m funkční konzistence (chování navigace, odlišení externích odkazů)
o 2.6_04_n vizuální konzistence (sjednocení, vyváženost)
o 2.6_04_o dodržení čitelnosti textů napříč celým webem ve všech responzivních variantách
• 2.6_05 tlačítko Zpět bude v nejpoužívanějších prohlížečích bezchybně fungovat
3. Požadavky na redakční systém
Základní požadavky na redakční systém jsou následující:
• 3_01 Redakční systém bude implementován jako jedna instance pro celý univerzitní web (tj. včetně fakultních webů a anglické verze) i pro web pro uchazeče (viz také 2.2.1 Hierarchická struktura).
• 3_02 Systém bude poskytovat standardní funkce dnešních redakčních systémů
• 3_03 Systém bude funkční, použitelný, optimalizovaný pro snadnou obsluhu systému a stejně jako celý web bude responzivní a funkční minimálně v nejpoužívanějších prohlížečích
• 3_04 Systém bude realizovat bezpečná a optimalizovaná připojení na interní systémy, ze kterých bude nutné automatizovaně stahovat data. Vzhledem k potřebě realizovat vyhledávání i nad takto importovaným obsahem může být vhodné umístění dat v mezi- úložišti, dle dohody s objednatelem.
• 3_05 Preferujeme open source redakční systém, případně lze i proprietární řešení, ale v tom případě požadujeme přístup ke zdrojovému kódu z důvodu budoucí údržby a rozvoje vlastními silami, a to včetně dokumentace
Výrazem pouze „web“ se myslí oba dva zpracovávané weby, tj. univerzitní web i web pro uchazeče, vč. anglické verze, pokud není specifikováno jinak.
Funkce na webových stránkách, tj. pro uživatele / návštěvníky, jsou označeny [web], funkce v administračním rozhraní webu, tj. pro redaktory, jsou označeny [red]. Takto označené funkce [admin] by měly být dostupné pouze pro administrátorský účet správce. Obecně účet správce ([admin]) bude tzv. „superuser“ účet v rámci celého redakčního systému, bude tedy mít k dispozici veškeré funkce, které redakční systém nabízí (včetně těch pro [red]).
Konkrétní požadavky na redakční systém jsou rozepsány níže v příslušných sekcích dle tématu. Opět platí jako viz výše, že požadavky lze se souhlasem objednatele do jisté míry upravit, pokud zhotovitel nabídne kvalitativně srovnatelnou nebo lepší variantu zpracování požadovaného. O tom, zda je řešení kvalitativně srovnatelné či lepší, rozhoduje v případě neshody výhradně objednatel.
3.1 Stránky a rozhraní
• stránky v redakčním systému (resp. v administračním rozhraní) budou zobrazeny pomocí klasické rozklikávací hierarchie stránek, s rychlými volbami pro jejich základní správu (nová stránka, upravit stránku,..) [admin] [red]
• stránky a konkrétní rychlé volby se budou zobrazovat pouze těm redaktorům, kteří budou mít příslušná práva [red]
• možnost editace obsahu a metadat stránky, pokud má redaktor příslušná práva [red]
• možnost vytvoření nové stránky, smazání stránky, přesun stránky, klonování stránky, přesměrování, zkrácená URL stránky (URL aliasy) [admin]
• možnost změny URL stránky (při změně názvu), zároveň možnost snadného nastavení přesměrování z původní URL na novou (URL aliasy) [admin]
• zároveň zhotovitel zajistí nastavení přesměrování (redirect) ze současného webu, stačí u cca 50-ti nejfrekventovaněji navštěvovaných stránek a zároveň těch stránek, které mají v současném systému nastavenou zkrácenou URL, jako např. xxx.xxx.xx/xxx nebo xxx.xxx.xx/xxxxxx atp., ale primárně tak, aby stávající pozice webu UHK ve vyhledávání na Google a Seznam zůstala zachována
• každé jedinečné zobrazení (stránka) na webu bude mít svoji jednoznačně určenou URL
• „pěkné“ URL, v URL se nebude zobrazovat ID stránky, ID souboru a další technické parametry, využívá jen malá písmena bez diakritiky, číslice, pomlčky (spojovník), tečky a lomítka
• verzování stránek a možnost uložit stránku jako neveřejný koncept (i zpětně, tj. půjde již zveřejněnou stránku opět odveřejnit), který se nebude zobrazovat v navigaci a nebude se zobrazovat ve výsledcích vyhledávání [web], k tomu dále možnost definovat, zda bude přístupná přes přímý odkaz (tj. pouze těm, kteří znají URL) nebo nebude dostupná ani tak [red]
• ve výpisech, seznamech, přehledech, tabulkách atp. bude dle konkrétní potřeby aplikována možnost řazení a filtrování dle vhodných parametrů [web], redakční systém bude umožňovat nastavení těchto funkcí [admin]
• hierarchická struktura na webu se bude tvořit automaticky ze zveřejněných položek v redakčním systému, speciální položky (novinky, události,..) se budou na webu zobrazovat dle jednoznačně stanovených pravidel [web], které dle možností návrhu bude možné modifikovat [admin]
• drobečková navigace se bude tvořit automaticky na základě pozice v hierarchii, jednotlivé položky budou klikatelné odkazy kromě té poslední (aktuální stránka) [web]
• v redakčním systému bude možné libovolnou stránku nastavit tak, aby se při aktivaci odkazu na tuto stránku uživateli zobrazil obsah jiné (v redakčním systému vybrané) stránky (tj. ne klasické přesměrování – uživatel zůstává v hierarchické struktuře na stejném místě), zároveň zachování možnosti klasického přesměrování na stránku v jiném místě struktury [admin]
• možnost tvorby „archivů“ v rámci redakčního systému, tj. přesunu stránek pod neveřejného rodiče, v rámci kterého se položky nebudou zobrazovat na webu a budou vyloučeny z vyhledávání [red], ale nebudou smazány ze systému, a to ani automaticky po uplynutí určité doby
• návštěvníkům webu se nebude na stránce zobrazovat informace o tom, kdo a kdy stránku naposledy změnil a jiné provozní či nežádoucí informace [web]
• navigace (ani jiný obsahový prvek) se na stránce nebude duplikovat z důvodu automatizace či nepromyšlenosti návrhu (např. rozcestník odkazů v obsahové části a ty samé položky v lokálním menu) [web]
3.2 Šablony
• šablony pro stránky budou odpovídat schváleným wireframům, prototypům a grafickým návrhům, nedojde ke ztrátě souladu se schválenými závěry a strategiemi
• šablona pro běžnou stránku bude podporovat vkládání veškerých základních typů obsahu (vč. fotogalerie, souborů, seznamu odkazů,..) [red] na webu se pak příslušná obsahová sekce zobrazí pouze, pokud tato stránka bude obsah mít [web]
• každá šablona a každé vyplňované pole šablony v administračním rozhraní bude mít krátký popisek (k čemu slouží, jak se bude zobrazovat, pokyny pro vyplnění,..) [red], tento popisek bude možné upravovat [admin]
• podpora SEO prvků (Title, Description, ALT u obrázků), možnost odlišit krátký název (zobrazení v navigaci) a delší název (pro zobrazení jako nadpis h1 a title – musí být jedinečný pro každou stránku, systém neumožní duplicity) [red]
• kde to bude vhodné, tj. u ne tak často používaných výplňových polí v administraci, bude použito podmíněné zobrazování polí (tj. např. nejprve checkbox, zda chce redaktor vložit fotogalerii, teprve po zaškrtnutí se objeví pole s popiskem pro vkládání fotografií atp.) [red]
• kompletní správa šablon – vytvoření, editace, duplikování [admin]
• při editaci šablon musí být ošetřeno riziko smazání dat při smazání pole s obsahem – systém poskytne upozornění a potvrzení volby [admin]
• při mazání šablon musí být ošetřeno riziko smazání dat při smazání stránek s danou šablonou – systém poskytne upozornění s počtem používaných stránek, šablonu nebude možné smazat, dokud existují záznamy s danou šablonou [admin]
3.3 Wysiwyg editor
• editor bude implementovat standardní funkce, jejichž použití bude analogické jako ve standardně používaných aplikacích jako např. MS Word (seznamy, tabulky, odkazy, nadpisy, obrázky, zarovnání, odsazení,...) [red], styl všech těchto standardních prvků bude podřízen celkovému stylu webu [web], tj. font, výchozí velikost textu, barvy použité v tabulkách atp. (to neznamená, že zarovnání vpravo nebude fungovat proto, že na celém webu se preferuje zarovnání do bloku apod. – explicitně nastavené formátování nabízené editorem bude funkční)
• odkazy bude možné vést na stránku v rámci webu, externí URL, dokument, email,..., bude možné nastavit otevření ve stávajícím nebo novém okně [red]
• odkazy budou odlišeny od běžného textu, konzistentně napříč celým webem (v rámci stejných obsahových a tematických bloků / uzlů) [web]
• bude možné přidat či odebrat jednotlivé funkce (ikonky) z editoru, nejlépe globálně i na úrovni pouze vybraných rolí [admin], pokud ne, je nutná konfigurace na základě požadavků objednatele – např. pro redaktory nechceme funkci barva písma, výběr fontu nebo emotikony (v souladu s předchozím bodem, aby styl zůstal jednotný), naopak chceme vložení kotev [red], pro roli správce naopak všechny možnosti vč. zobrazení zdrojového kódu a možnost editace ve zdrojovém kódu [admin]
• bude mít aktivní filtr, který ve svém výchozím nastavení nepovolí vkládání skriptů, stylů a dalších nevhodných HTML elementů (jako např. kompletních stylů při kopírování textu z jiného webu), zároveň ale nebude znemožňovat vkládání standardně zformátovaného textu např. z MS Word (nelze, aby redaktoři museli vkládat obsah z Poznámkového bloku, jako to musí dělat nyní) [red]
• bude možné nastavit povolené a zakázané HTML tagy, nejlépe globálně i na úrovni pouze vybraných rolí [admin], pokud ne, je nutná konfigurace na základě požadavků objednatele (zhotovitel je povinen upozornit objednatele na možná rizika zvolené konfigurace)
• bude obsahovat fungující pravopisnou kontrolu s automatickou nebo alespoň manuálně nastavitelnou lokalizací CZ/EN [red]
3.4 Obrázky a média
• možnost centrální správy obrázků a fotografií v galerii médií, media manageru nebo podobném (nebo jinak implementovaná možnost využití obrázků na další stránce kromě té původní), zároveň možnost navázání obrázků pouze na konkrétní stránku [red]
• u vkládání jednotlivých obrázků
o možnost nastavení maximální nahrávané velikosti obrázku [admin], při překročení systém nabídne automatické zmenšení [red]
o komprese při zmenšování a jiné manipulaci s obrázky bude nastavitelná [admin], nepřipadá v úvahu automatická vysoká komprese
o při vkládání na stránku možnost základních úprav obrázku jako ořez, změna velikosti (originál v galerii médií zůstane nezměněn, nová verze bude do galerie přidána) [red]
o možnost odkazu na větší (tj. původní) verzi obrázku nebo URL [red]
o na menších monitorech responzivní chování (zmenšení dle dostupné šířky) [web] – nelze např. aby se pro mobilní zařízení stahoval obrázek s rozlišením mnohonásobně větším, než je toto zařízení schopno zobrazit
o možnost vložení popisku pro ALT a TITLE, výchozí hodnota pro TITLE shodná jako pro ALT (např. formou předem zaškrtnutého checkboxu nebo předvyplnění) [red]
• možnost fotogalerie (např. lightbox, příp. slideshow) u každé stránky webu (případně datově bezztrátová možnost změny šablony stránky na šablonu podporující vložení fotogalerie), hromadné vkládání obrázků, tj. ne nutnost vkládání po jednom jako nyní [red]
• fotogalerie bude výkonnostně optimalizována, tj. zobrazení pomocí miniatur, až po interakci uživatele zobrazení velké verze, dále viz sekce o výkonu [web]
• vkládání videí do textu, možnost nastavení výchozí velikosti [red], na menších monitorech responzivní chování (zmenšení dle dostupné šířky) [web]
• možnost zobrazování vlastního obsahu ze souboru html/xml, vloženého přes rozhraní systému nebo přímo do souborového systému [admin], jako např. virtuální prohlídka
• v případě umístění pro obrázky v šabloně vymezených přesnou velikostí bude zachován poměr stran obrázku s možností volby úpravy obrázku (ořez, vyplnění barvou,..) [red]
• možnost vložení seznamu odkazů na stránku (nemyslí se v rámci Wysiwyg editoru, ale jako speciální druh obsahu)
o kompletní správa odkazů v seznamu [red]
o zobrazení v souladu s vizuálním stylem [web]
o možnost výběru varianty odkazů včetně náhledu (nahrání obrázku) a bez [red], podle toho se pak bude aplikovat styl zobrazování na webu [web]
o speciální použití pro homepage, na které se bude zobrazovat jen návrhem omezený počet odkazů (pokud to návrh umožňuje, tento počet půjde změnit [admin]), konkrétní odkazy bude možná přesně definovat [red], na konci seznamu bude odkaz na kompletní výpis odkazů uložený v rámci dané homepage [web], možnost nastavení pořadí odkazů (manuální, autom. podle abecedy / data vložení,..), tj. bude možné určit které se zobrazí primárně a které až po rozkliknutí [admin]
3.5 Aktuality a události
• výchozí řazení v administračním rozhraní podle data vložení sestupně [red], řazení na webu dle návrhu, ale logicky a přehledně (je nutné, aby byly především vidět události, které se budou aktuálně konat, ale i nově vložené pozvánky) [web]
• bude možné vložit aktuality s doprovodnou fotografií (zobrazena ve formě náhledu), i bez (pouze textová) [red], layout webu musí podporovat jejich libovolné kombinace [web]
• při prokliku na aktualitu / událost z homepage se uživatel dostane do rozhraní přehledu aktualit / událostí s detailem zvolené události [web]
• bude vhodně použito stránkování při větším počtu aktualit / událostí [web], max. počet položek na jednu stránku bude možné nastavit [admin]
• dle strukturální a obsahové analýzy budou aktuality a události vhodně kategorizovány tematicky a dle hlavních „uzlů“ (UHK, FF, FIM, PdF, PřF), redakční systém bude umožňovat zařazení do jedné a více kategorií [red] a na webu bude zobrazovat vhodné grafické odlišení (např. různě barevný štítek s kategorií, přičemž je potřeba respektovat vizuální styl, resp. barvy fakult) a bude nabízet funkci filtrování dle těchto kategorií [web]
• kategorie pro aktuality a události bude možné spravovat – přidávat, odebírat a editovat jak textovou část, tak i případné barevné odlišení [admin]
• možnost zvolit omezenou dobu zveřejnění OD-DO, přesnost na minuty [red]
• možnost zvolit předřazení novinky ve výpisu [red] a grafické odlišení / zvýraznění takové novinky, ale v souladu s celkovým stylem webu [web]
• pokud to bude vhodné (na základě strukturálního a grafického návrhu), bude systém automaticky odveřejňovat pozvánky na události následující den po době konání
• u posuvníku / slideru / carouselu grafických upoutávek nebo jiné alternativní formy zobrazení, která bude použita pro grafické upoutávky (dle návrhu):
o upoutávka bude mít možnost vložení nadpisu a textu [red]
o upoutávku bude možné realizovat s celoklikacím odkazem na stránku v rámci webu, s odkazem na externí URL i bez odkazu [red]
• aktuality a pozvánky na události bude možné odebírat pomocí RSS [web]
• web bude umět na vybraných stránkách zobrazovat aktuální články z jiných webů pomocí RSS [web], bude možné definovat kategorie, počet atp. [admin]
• u kalendáře událostí na hlavní straně musí být vidět i bez interakce uživatele, které dny je nějaká akce, možnost snadného překliknutí na akce v daný den (viz xxxx://xxx.xxxx.xx/), dle vhodnosti také znázornění příslušnosti akce k fakultě / celé univerzitě pomocí barevného odlišení dle vizuálního stylu [web]
3.6 Vyhledávání
• fulltextové vyhledávání v rámci celého webu [web]
o integrace Google vyhledávání nebo výkonnostně srovnatelné vlastní vyhledávání s funkcí našeptávání
o integrace vyhledávání dokumentů z dokumentového úložiště (viz 3.12 Dokumenty)
o speciální zohlednění k vyhledávání osob, zobrazení „profilové karty“ s kontaktem
o dle návrhu možnost oddělení vyhledávání osob a dokumentů od webového obsahu
• po prvním načtení homepage UHK získá focus vyhledávací pole [web]
• redaktoři budou mít v administračním rozhraní alternativní možnosti přístupu ke stránkám (kromě klasické rozklikávací hierarchie stránek) [red]
o bude možné vyhledávání / filtrování všech stránek dle základních parametrů (fulltextově název, autor, intervalem datum změny, datum vytvoření,..) vč. možnosti vypsání všech stránek pod zvoleným rodičem (tj. např. i seznam všech stránek určité fakulty nebo všech stránek anglické verze atp.)
o výpis výsledků vyhledávání (resp. stránky) bude možné řadit podle základních parametrů (opět název, autor, datum změny, datum vytvoření,..)
o jednotlivé stránky ve výpisu výsledků bude možné jedním proklikem editovat (rychlé volby obdobně jako u rozklikávací hierarchie stránek)
o bude možné nastavit, které sloupce budou zobrazené pro výsledky vyhledávání, pokud ne, je nutná konfigurace na základě požadavků objednatele
o každý redaktor bude mít možnost označit libovolné množství stránek, ke kterým pak bude mít přístup ve formě snadno přístupných „rychlých odkazů“ (bookmarks / shortcuts)
• administrační rozhraní pro redaktory bude přehledné a nebude obsahovat pro ně zcela nepotřebné či matoucí funkce, ani funkce na které nemají práva [red]
3.7 Formuláře
• odlišení správy formulářů [admin] a přístupu k datům získaných z formulářů [red]
• možnost tvorby formulářů, klonování (duplikovat existující formulář) a editace [admin]
• k dispozici bude použitelný editor formulářů, výběr standardních formulářových prvků, možnost vkládání příloh, výběru z definovaného seznamu položek nebo z existujících stránek pod určeným rodičem [admin]
• možnost nastavení odeslání emailu odesílateli formuláře při odeslání [admin]
• možnost nastavení odeslání emailu do emailové schránky (či více schránek), zadané v administraci (pro každý formulář zvlášť) při odeslání [admin]
• správa dat získaných z formulářů (evidence přihlášených), možnost konfigurovatelného exportu do csv / xls [red]
• vhodné zobrazení na webu (min. možnost dvousloupcového layoutu a responzivní – změna na jeden sloupec v menších šířkách) [web]
• možnost formuláře u každé stránky webu (případně bezztrátová možnost změny šablony stránky na šablonu podporující vložení formuláře) [admin]
• funkcionalita formulářů bude zhotovitelem ověřena na přesunu existujících formulářů ze současného webu (viz 2.2 Obsah a struktura)
• systém bude umožňovat řešení katalogového výpisu s možností zaškrtnutí a následné objednávky (xxxxx://xxx.xxx.xx/xx-XX/XXX/Xxxxxxxxx-xxxxxxxxxx/Xxxxxxxxxxx- knihovna/Nakladatelstvi-Gaudeamus/nabidka-publikaci/Prodej-publikaci#UHK-Article) – možnost třídění položek, vyhledávání, zaškrtnout více kusů, zachovat možnost poznámky při objednávání, způsob dodání (vyzvednutí v knihovně nebo poštou), možnost definovat
povinná pole při objednávání, design přehledu jako eshop, zobrazení náhledu, dle vhodnosti možnost podbarvení podle fakult, pro které byla publikace vydána
3.8 Uživatelé, role, práva
• bezpečné, výkonnostně optimalizované připojení na interní LDAP řešení (pro přihlašování redaktorů, napojení na dokumentové úložiště bez mezikroku dalšího ověřování,...), bude ale možné také vytváření lokálních uživatelských účtů [admin]
• přihlašování uživatelů redakčního systému bude splňovat bezpečnostní standardy (SSL, salt do hesla, ukládat hesla jako hash, ...)
• práva jednotlivých uživatelských účtů budou řešena standardně pomocí rolí, na úrovni rolí budou definována konkrétní práva
• administrátorský účet (tj. [admin]) bude tzv. „superuser“ účet v rámci celého redakčního systému, bude tedy mít k dispozici veškeré funkce, které redakční systém nabízí, prostřednictvím tohoto účtu bude možné na straně objednatele realizovat obsluhu všech rutinních požadavků, jako např. kompletní správa stránek, formulářů, uživatelů, práv [admin]
• role bude možné vytvářet, editovat, mazat, klonovat / duplikovat (při vytváření nové role), role bude možné uživatelům přiřadit, změnit i odebrat [admin]
• práva bude možné definovat podle hierarchie stránek, podle způsobu manipulace se stránkami (právo na přidání, mazání, editaci, přesun), podle šablony stránky, odlišení práva zveřejňovat a práva jen uložit jako neveřejný koncept, právo na správu dokumentů atp. – práva bude možné logicky kombinovat, tj. např. právo na správu dokumentů jen v určené části hierarchické struktury stránek, nebo právo mazání jen na definovaný typ stránky (např. aktuality, ne obsahové stránky)
• výchozí nastavení redaktorů a jejich práv proběhne v součinnosti s objednavatelem
• ve výchozím nastavení (které bude možné změnit [admin]) nebude redaktorům umožněno stránky vytvářet, mazat a přesouvat, pouze editovat (viz 3.1 Stránky a rozhraní)
• redaktorům se v administračním rozhraní nebudou zobrazovat stránky, které nemohou editovat (až na výjimky, např. když je potřeba zobrazit needitovatelného rodiče pro přístup ke stránkám, které již redaktor editovat může) [red]
3.9 Multijazyčnost
• administrační rozhraní bude kompletně lokalizováno do češtiny, s možností přepnutí do angličtiny (a zapamatování volby u konkrétního redaktora) [red]
• struktura webu v anglické verzi nebude shodná se strukturou ve verzi české – obvyklá implementace, kdy každá stránka má verzi českou a anglickou, tedy není vhodná
• autodetekce jazykové verze - pro uživatele s internetovým připojením v ČR se automaticky při zadání domény načte česká jazyková mutace; pro uživatele s internetovým připojením mimo ČR se automaticky při zadání domény načte anglická jazyková mutace [web]
• v rámci anglické verze bude možné nastavovat práva stejně jako v případě české [admin]
3.10 Výkon, bezpečnost
• redakční systém bude výkonnostně optimalizován, jak pro návštěvníky (tj. webové stránky) [web] i pro redaktory a správce (tj. administrační rozhraní systému) [red]
• bude optimalizován jak obecně (běžné postupy, obecně platné), tak i podmíněně dle schopností zobrazovacího zařízení a rychlosti internetového připojení (tj. nelze např. načítání obrázku v HD rozlišení pro mobilní telefon na datovém připojení) [web] [red]
• systém bude schopen bez výraznějších výkonnostních problémů a časových prodlev obsloužit vyšší počet návštěvníků, než který odpovídá dostupným datům z Google Analytics (viz 5.2 Základní údaje z Google Analytics)
• běžným uživatelům se nebudou zobrazovat technická chybová hlášení [web]
• naopak pro správce bude systém poskytovat přehledné logy / záznamy o chybách (kdo, kdy, na jaké stránce, popis chyby...) a ideálně i základní statistiky o návštěvnosti stránek [admin]
• redakční systém a celé webové stránky budou v maximální možné míře odolné vůči útokům z vnějšku, ochrana před standardními typy útoků
• kódování znaků napříč celým webem bude v UTF-8 (včetně skriptů atp.)
• web bude mít vhodnou faviconu dle vizuálního stylu [web], lze použít tu na stávajícím webu
• použití a vynucení HTTPS protokolu vč. vhodného certifikátu pro celý web, nejen přihlášení [web], hodnocení hlaviček minimálně v kategorii A dle xxxxx://xxxxxxxxxxx.xxxxxxx.xxx/.
• ukládaná citlivá data budou dostatečně dobře šifrována
• jakákoli změna provedená v redakčním systému se na webu projeví okamžitě nebo se zpožděním max. 5s [web]
• dostupnost a rychlost webu bude možné průběžně monitorovat [admin]
• na webu bude standardně fungovat chybové zobrazení 403, 404 a 500 [web]
• rozhraní pro editaci stránky pro redaktory nebude obsahovat možnosti, které by potenciálně mohly narušit funkčnost a konzistenci celého systému nebo jeho části [red], tyto možnosti bude možné upravit pomocí rolí a práv uživatelů [admin], pokud ne, je nutná konzultace a konfigurace na základě požadavků objednatele
• možnost kompletního zálohování, automatického pravidelného i okamžitého [admin]
• možnost rychlé obnovy ze zálohy do stavu před havárií / napadnutím [admin]
• přechodem na další verzi systému nebude zásadně ovlivněno fungování a zobrazování webu, budou zachovány vlastní úpravy systému (tj. moduly, další přidaná logika, styly atp.), tedy jádro systému by mělo být zcela odděleno od vlastních úprav a „nadstaveb“ systému
• web poběží pouze na jedné veřejně dostupné doméně, a to xxx.xxx.xx, testovací verze webu bude mít přístup robotů zakázán v robots.txt
• web bude obsahovat standardní sitemap.xml a bude odkázána v souboru robots.txt
• jedna stránka bude mít vždy jedno URL, za duplicitní se považují i ta URL, která jsou současně dostupná a) s WWW a bez WWW; b) s lomítkem a bez lomítka na konci URL; c) na protokolech HTTPS i HTTP
• při změně URL stránky systém vytvoří přesměrování ze staré URL na novou pomocí kódu 301, tato přesměrování je možné v rámci systému spravovat a přesměrování manuálně přidávat, upravovat, mazat,.. [admin]
• web bude technologicky postaven tak, aby roboti vyhledávačů mohli bez problému zaindexovat jeho obsah
• web bude optimalizován pro vyhledávače (zejm. Google, Seznam) a stávající pozice webu UHK ve vyhledávání na Google a Seznam zůstane při přesunu na nové řešení zachována
3.11 Podpora, dokumentace
• možnost standardizovaného exportu obsahových článků, aktualit a všech dalších typů obsahu vč. uživatelů a jejich práv (a to jak možnost exportu jednotlivého záznamu, výběru záznamů dle selektorů a hromadného exportu všech záznamů daného typu) ve formátu CSV [admin]
• na web bude nasazeno Google Analytics, dle dohody s objednatelem bude buď použito současné sledovací číslo nebo nové, výchozí konfiguraci provede zhotovitel minimálně v tomto rozsahu: měřící kódy pro traffic, vyloučený vlastní traffic, nasazené alerty pro zásadní poklesy, interní vyhledávání, měření akcí, které nemění URL
• přesně pro dodanou verzi redakčního systému bude dodán manuál v elektronické podobě
o ve formátu editovatelném ve standardně používaných editorech (např. DOC/DOCX)
o verze pro administrátora (dokumentace) a verze pro běžné redaktory (návod)
o manuál bude přehledný, názorný a kompletní
o rozsahem bude pokrývat minimálně veškerou požadovanou funkcionalitu popsanou v rámci této technické specifikace
o bude obsahovat relevantní screenshoty a výřezy obrazovky
o budou zohledněny zásadní odlišnosti mezi prohlížeči
• pokud se jedná o open source systém, lze vynechat dokumentaci k částem, které jsou popsané dostatečně v rámci veřejně dostupné dokumentace k systému (nelze vynechat části, které byly jakkoliv ovlivněny zásahem zhotovitele do standardní podoby systému)
• dokumentace pro administrátora bude obsahovat (nejlépe v samostatném materiálu) také technickou dokumentaci o způsobu instalace a konfigurace aplikačních částí a popis postupů, co všechno je třeba spravovat/prověřovat z pohledu administrátora serveru
• bude poskytnuto odborné školení na základě dodaného manuálu (resp. dokumentace), opět ve dvou variantách – pro administrátora a pro běžné redaktory (každé jednou), zahrnující všechny zásadní informace a praktickou ukázku s možností vyzkoušení a dotazů
• zabezpečenou písemnou formou komunikace budou předány veškeré přihlašovací údaje k systému a k případným navázaným službám zástupci na straně objednatele
3.12 Dokumenty
• fyzické uložení a správa dokumentů (resp. souborů) bude realizováno na vlastním interním řešení – dokumentovém úložišti (dále jen DMS)
o DMS bude podporovat souborový systém, ve kterém budou veřejné a interní dokumenty umístěny centrálně z důvodu vyhledávání všech dokumentů (interních i veřejných) pro interní uživatele na jednom místě
o na úrovni DMS bude realizováno omezení souborových přípon, přístupová práva a další bezpečnostní omezení
o v DMS na úrovni jednotlivých složek bude definováno, jaká metadata (sloupce v případě tabulkového výpisu) se budou u souborů spravovat a zobrazovat na webu, bude určeno několik typů obsahu dokumentů a u každého bude jiná množina metadat (například materiály na úřední desce s vyznačením účinnosti a platnosti, studijní materiály s definicí studijního předmětu)
o připojením bez ověření (tj. read-only) bude umožněn přístup k veřejným složkám a souborům, resp. jejich výpis včetně metadat a možností stažení, s indikací o existenci dalších interních složek a souborů [web]
o integrovaně v rámci veřejného webu tedy nebude umožněna správa dokumentů
o pro přístup ke správě dokumentů bude potřeba autentizace uživatele pomocí interního LDAP řešení v rámci intranetu, kde každý pracovník dle své pracovní pozice bude moci spravovat složky, ke kterým je oprávněn [red]
• redakční systém bude umožňovat funkční, bezpečné a optimalizované připojení na DMS, ke kterému budou objednatelem poskytnuty veškeré potřebné údaje, připravené funkce, databázové tabulky atp. dle dohody
o pokud budou k dané stránce přiřazené složky a soubory, redaktor uvidí v administračním rozhraní editace této stránky hierarchickou strukturu těchto složek a souborů, přímo v rozhraní redakčním systému (read-only přístup bez ověření), opět s indikací případných dalších interních složek/souborů [red]
o redaktor bude mít v rámci editace stránky možnost připojit se kontextově do rozhraní DMS (ve stylu „iframe“, tj. okno v okně), jeho práva budou ověřena pomocí interního LDAP, a tak bude moci z prostředí redakčního systému spravovat složky a soubory v DMS [red]
o jedním kliknutím se bude moci redaktor přesunout do plné verze DMS, se snadnou možností návratu zpět do redakčního systému (na to samé místo, tj. do editace dané stránky, ke které v DMS spravoval soubory) [red]
o správa bude zahrnovat běžné funkce jako vložení dokumentu, odstranění dokumentu, aktualizace dokumentu (DMS bude podporovat verzování souborů, odkaz na dokument zůstane při aktualizaci dokumentu stejný) – to vše přes DMS
o pokud by se realizace „iframe“ řešení ukázala jako nevhodná, lze alternativně realizovat správu dokumentů přímo přesměrováním na plnou verzi DMS, kde se redaktorovi po návratu do redakčního systému zobrazovaný seznam dokumentů aktualizuje dle změn, které provedl v DMS [red]
• propojení s DMS bude realizovatelné v rámci vhodně implementovaných funkcí redakčního systému, tj. nebudou nutné nestandardní zásahy do systému, které by měly za následek obtížný přechod na novou verzi systému apod.
• zobrazení na webu bude realizováno v podobě výpisu hierarchie složek a souborů, tabulkový či jiný přehledný layout, soubory budou vizuálně odlišeny ikonkou dle typu souboru, výpis bude obsahovat metadata dle typu obsahu úložiště, specifikována v DMS na úrovni každé složky [web, red]
• v rámci zobrazení hierarchie složek a souborů je nutné zobrazení vizuálního indikátoru u složek, zda obsahuje nějaké další složky a/nebo soubory [web, red]
• v rámci hierarchie složek a souborů bude možné zvolit řazení dle všech zobrazovaných sloupců [web, red], dále bude možné nastavit filtrování a vyhledávání (preferujeme u každého výpisu, případně dle dohody stačí jen u Úřední desky) [admin]
• na existenci interních složek a souborů bude vizuálně upozorněno v relevantní části hierarchie, interakcí s tímto indikátorem bude realizováno přesměrování intranetového uživatele na příslušné úložiště v rámci DMS a zpřístupněno po přihlášení a ověření pomocí LDAP a následné autorizaci, pokud je do úložiště omezený přístup [web]
• soubor, který lze zobrazit přímo v prohlížeči (JPG, PNG, PDF,..), se zobrazí v prohlížeči místo zahájení stahování souboru (při interakci uživatele s odkazem na soubor, preferujeme přes proklik na název souboru), a to pokud nejde výslovně o odkaz na stažení souboru, které bude ve výpisu souborů také zahrnut, preferujeme formou ikonky
• každé jedinečné zobrazení (výchozí adresář, „otevřená“ složka v adresáři, konkrétní soubor) na webu bude mít svoji jednoznačně určenou URL, na kterou se lze odkazovat
• Úřední desce, jako speciálnímu typu obsahu (viz univerzitní úřední deska xxxxx://xxx.xxx.xx/xx-XX/XXX/Xxxxxx-xxxxx/Xxxxxx-xxxxx-xxxxxxxxxx, analogicky částečně fakultní) bude věnována zvláštní péče ohledně vhodnosti zobrazení a interaktivnosti, oproti standardnímu výpisu složek a souborů bude obecně zobrazovat více metadat
• V úřední desce u složek a souborů v sekci „Řídící akty“ dále požadujeme
o vizuální odlišení platných a neplatných předpisů [web], na základě příslušné zaškrtávací volby u příslušného souboru v DMS
o zobrazování odkazu na nový platný předpis u všech předchozích předpisů, které tento nový zneplatňuje [web], na základě příslušných dat v DMS
3.13 Spolupráce s interními systémy
• systém bude umět realizovat bezpečná a optimalizovaná připojení na interní systémy, ze kterých bude nutné automatizovaně stahovat data, resp. systém musí umět integrovat data z intranetových aplikací, a to formou databázových pohledů, procedur či funkcí (MSSQL)
• příklad integrace přes databázovou funkci – k dispozici bude funkce
„getPracovniciPracoviste '02420', 'EN'“, kde výstupem bude seznam pracovníků Katedry informatiky a kvantitativních metod FIM seřazený automaticky dle požadavků katedry, s anglickými názvy pracovních pozic
• web i redakční systém budou umožňovat vyhledávání i nad takto importovaným obsahem, proto může být vhodné umístění dat v „mezi-úložišti“, tj. import do databázových tabulek v rámci redakčního systému, konkrétní implementace záleží na zhotoviteli, nicméně aktualizace takových dat musí proběhnout minimálně každou hodinu, synchronizaci dat ze
svých interních systémů do mezi-úložiště zajistí objednatel (lze upravit dle konkrétních typů importovaného obsahu dle důležitosti pro optimalizaci výkonu)
• systém bude umožňovat specifikovat relevantní parametry, nutnost ošetření bezpečnosti - pouze pro hlavního správce, možnost filtrování a řazení na výstupu [admin]
• funkce integrace dat z interních systémů bude realizovatelná v rámci vhodně implementovaných funkcí redakčního systému, tj. nebudou nutné nestandardní zásahy do systému, které by měly za následek obtížný přechod na novou verzi systému apod.
• zároveň bude tato funkčnost ověřena zhotovitelem na realizaci požadovaných propojení, a to v rozsahu současného webu, jmenovitě např.
o seznam pracovníků oddělení
o správa údajů v seznamech - veřejné soutěže a výběrová řízení; oznámení o habilitacích a jmenovacích řízeních; oznámení o obhajobách; personální výběrová řízení a soutěže; veřejné zakázky; nedoručitelné písemnosti; seznam ESF programů a projektů; evidence VaV činnosti; mapy budov; publikace nakladatelství Gaudeamus;
o přípravné a jiné kurzy IDV
o praxe, stáže, workshopy, nabídky práce a brigád
o studijní programy a obory
• možnost vkládání vlastních skriptů pro napojení na webové služby (STAG,..), nutnost ošetření bezpečnosti - pouze pro hlavního správce [admin]
• funkcionalita vkládání vlastních skriptů bude zhotovitelem ověřena na realizaci existujících napojení, tj. na základě obsahu současného webu
• systém bude umožňovat zpřístupnění obsahu na úrovni databáze či jinou podobnou formou jako jsou webové služby, XML, JSON atp. (struktura menu, obsahové články, aktuality, pozvánky,...) pro účely upozorňování na nový obsah v rámci vlastního intranetového řešení
• v případě obsahu s přesahem do intranetu (viz 2.2 Obsah a struktura)
o na úrovni celého uzlu v hierarchii – v rámci nadřazeného lokálního menu bude zobrazen vhodný indikátor, upozorňující na existující interní obsah
o na úrovni jedné celé stránky – v rámci lokálního menu, kde je stránka umístěna, bude zobrazen indikátor, upozorňující na existující interní obsah
o na úrovni části stránky – v rámci lokálního menu u názvu stránky a zároveň na konci samotné stránky bude zobrazen indikátor, upozorňující na existující interní obsah
o v rámci výpisu složek a souborů z DMS – analogicky, na úrovni složky kde existují interní podsložky / soubory, bude zobrazen indikátor
4. Podpora po předání
Součástí zakázky dle Xxxxxxx o dílo jsou po dobu 5-ti let od předání kompletního díla aktualizace softwaru a řešení bezpečnostních incidentů a havárií. Konkrétně požadujeme následující:
• aktualizace dodaného redakčního systému (a případně navázaných modulů, pokud to bude nutné pro jejich další bezchybné fungování), a to na každou „major“ verzi, min. 1 ročně
• řešení bezpečnostních incidentů a havárií, dle závažnosti:
o incidenty a havárie, které brání běžnému užívání díla (např. uživatel není schopen na webu získat požadované informace nebo dokončit konverzní akci – konkrétně např. přihláška pro uchazeče, informace o studijních oborech, kontakty atp.) a/nebo poškozují dobré jméno a pověst univerzity - požadujeme řešit ihned bez zbytečných prodlení, alespoň částečnou nápravu zjednat nejdéle do 2 hodin od nahlášení incidentu, úplnou nápravu nejdéle do 12-ti hodin od nahlášení incidentu
o incidenty a havárie, které výrazně ztěžují běžné užívání díla (např. uživateli je ztížen přístup k informacím nebo požadované konverzní akci), ale nepoškozují dobré jméno a pověst univerzity v takové míře – požadujeme řešit bez zbytečných prodlení, alespoň částečnou nápravu zjednat nejdéle do 12-ti hodin od nahlášení incidentu, úplnou nápravu nejdéle do 3 pracovních dní od nahlášení incidentu
o incidenty a havárie, které ztěžují běžné užívání díla pouze lokálně nebo v malé míře, přičemž se nejedná o klíčové funkce webu nebo obsah zobrazovaný na hlavní stránce – požadujeme řešit bez zbytečných prodlení, alespoň částečnou nápravu zjednat nejdéle do 48 hodin od nahlášení incidentu, úplnou nápravu nejdéle do 7 pracovních dní od nahlášení incidentu
5. Doplňující materiály
Jako doplnění této technické specifikace lze zhotoviteli poskytnout následující:
• vzhled a obsah současného webu: xxxxx://xxx.xxx.xx/
• struktura současného webu: xxxxx://xxx.xxx.xx/xx-XX/XXX/xxxxxx-xxxx/Xxxx-xxxxxxx
• manuál vizuálního stylu a související soubory
• analýza současného obsahu (stránek a souborů) UHK – XLS s jednotlivými záznamy, kategorizace dle fakult a kategorií, id, název, cesta, datum a autor poslední editace (nyní existuje verze z 11/2016)
• export stránek a souborů dle dohody (omezený export dat pro účely analýzy obsahu, ne export kompletního existujícího obsahu)
• analýza přispívajících redaktorů na UHK
• analýza webů českých a zahraničních univerzit
• studie intranetu – otázky spolupráce s veřejným webem
• povinně zveřejňované údaje
5.1 Současný stav webové prezentace UHK
Současné webové stránky jsou kombinací upraveného CMS Kentico (verze 7) a vlastního intranetu a souborového úložiště. Intranet vč. souborového úložiště jsou v jazyce .NET a databázi MSSQL, soubory jsou ukládány jako BLOB v databázi. Uživatelské účty (tj. zaměstnanci i studenti – cca 21 100) se synchronizují s LDAP, podle toho je umožněn přístup k určitým stránkám / souborům. Redaktoři (cca 120) mají navíc role v Kenticu. Prostřednictvím SQL dotazů se také realizuje import z dalších databází interních systémů.
Přibližný počet záznamů v systému:
• 14 800 položek v dokumentovém úložišti (údaje z 4/2017)
o 900 root adresářů
o 3 000 dalších složek
o 10 900 souborů
• 8 200 položek v CMS_Document v systému Kentico (údaje z 11/2016)
o 4 100 stránek české verze
▪ 1 600 obsahových stránek
▪ 1 500 novinek a událostí
▪ 1 000 stránek pod katedrami
o 1 600 stránek anglické verze
o 1 000 obrázkových souborů
o 700 neobsahových položek jako např. systémová menu nebo přesměrování
o 800 stránek Portálu cestovního ruchu (bude převeden do jiného systému)
• 90 vlastních MSSQL tabulek (mimo Kentico) - implementace intranetu (údaje z 3/2017), např:
o překlady – 1000 položek
o praxe a stáže – 800 položek
o konzultační hodiny – 500 položek
o profilové fotky – 350 položek
o workshopy – 300 položek
o mobility – 300 položek
o publikace nakladatelství – 300 položek
o studijní obory – 200 položek
• cca 120 uživatelů s právy redaktora
o práva jsou specifikována rolemi, primární rozdělení každého redaktora je na uzel UHK nebo konkrétní fakulty, výjimkou jsou superredaktoři (přístup k veškerému obsahu, ale ne práva hlavního administrátora / správce)
o hlavní redaktoři (za každou fakultu 1 a více) – mají práva na celý uzel (UHK nebo konkrétní fakulty) včetně správy dokumentů
o práva oborových redaktorů jsou dále specifikována přesným vymezením části hierarchie, volitelně přístup k dokumentům
Hrubý nástin kategorií obsahu na současném webu, zde uvedený jen pro základní představu, je následující (z 11/2016):
o Studium (435 stránek, 1 134 souborů)
o Věda a výzkum, zahraničí, mezinárodní spolupráce (388 stránek, 1 451 souborů)
o Pracoviště, oddělení, ústavy – např. IDV, Gaudeamus, Knihovna,.. (266 stránek, 244 souborů)
o CIT, Budovy a Technicko-provozní úsek (142 stránek, 243 souborů)
o Ostatní obsahové stránky - O fakultě, Absolventi, Praxe,… (240 stránek, 411 souborů)
o Úřední deska (54 stránek, 3 523 souborů)
o Novinky a události (1 501 stránek, 8 souborů)
o Katedry, oddělení v případě ÚSP (982 stránek, 795 souborů)
o Anglická verze, v rámci toho „International students“
o Portál cestovního ruchu (xxxxx://xxx.xxx.xx/xx-XX/xxxxxx-xxxxxxxxxx-xxxxx/Xxxxxx) *
o Intranetový obsah *
* Rozsah nového webu, v porovnání se současným webem, bude primárně zmenšen o interní obsah, který se přesune do intranetu, a o Portál cestovního ruchu, toto zajistí objednatel.
5.2 Základní údaje z Google Analytics
návštěvnost za posledních 12 měsíců (1.7.2016 – 30.6.2017):
• návštěvy: 1 259 622
• uživatelé: 333 665
• zobrazení stránek: 5 458 428
• počet stránek na 1 návštěvu: 4,33
• průměrná doba návštěvy: 00:04:10
• míra okamžitého opuštění: 44,26 %
• procento nových návštěv: 24,94 %
akvizice za posledních 12 měsíců (1.7.2016 – 30.6.2017):
• organic search (774 303 návštěv)
• direct (304 823 návštěv)
• referral (128 563 návštěv)
• social (51 798 návštěv)
návštěvnost ve vytíženém měsíci (únor 2017):
• návštěvy: 129 295
• uživatelé: 52 095
• zobrazení stránek: 619 012
• počet stránek na 1 návštěvu: 4,79
• průměrná doba návštěvy: 00:04:42
• míra okamžitého opuštění: 41,95 %
• procento nových návštěv: 26,91 %
návštěvnost ve vytíženém dni (27.2.2017):
• návštěvy: 6 892
• uživatelé: 5 147
• zobrazení stránek: 34 488
• počet stránek na 1 návštěvu: 5,00
• průměrná doba návštěvy: 00:05:13
• míra okamžitého opuštění: 37,22 %
• procento nových návštěv: 28,69 %