Příloha č. 1 – Specifikace požadavků
Úvod Členění minimálních požadavků včetně názvů jednotlivých kapitol a nižších řádů včetně jejich číslování musí dodavatel ve své nabídce zachovat. Nebude-li nabídka dodavatele splňovat všechny zadavatelem stanovené požadavky, bude dle § 76 odst. 1 zákona vyřazena a dodavatel následně vyloučen z účasti v zadávacím řízení. Zadavatel upozorňuje, že pokud je v požadavcích použit obchodní název některých výrobků nebo dodávek, případně jiná označení či vyobrazení mající vztah ke konkrétnímu dodavateli, jedná se pouze o ilustrativní příklady vhodných řešení. Zadavatel umožňuje pro plnění veřejné zakázky použití jiných, kvalitativně a technicky obdobných řešení za současného splnění požadovaného účelu a minimálních technických požadavků.
Počet uživatelů redakčního systému (CMS) Zadavatel požaduje poskytnutí veškerých nezbytných licencí k řádnému plnění předmětu smlouvy. Zhotovitel specifikuje název, počet, rozsah a licenční podmínky ke všem nutným licencím v příloze smlouvy, a to včetně odůvodnění zvolené licenční nabídky, dále pak uvede licenční politiku, pravidla pro přidělení a případně změny v počtu licencí, typy a verze licencí. Licenční politika nesmí nijak omezovat současnou práci různých uživatelů. Počet uživatelů (editorů): 51.
1. Požadavky na Nový web 1.1. Rozvoj 1.1.1. Možnost funkčního a grafického rozvoje dle požadavků (na míru). 1.2. Responsivní design 1.2.1. Design stránky bude reagovat na změny velikosti výstupního zobrazovacího zařízení; podle velikosti displeje bude docházet k přerovnávání obsahových prvků tak, aby byla zachována jejich nadefinovaná priorita; některé prvky mohou být zcela odstraněny, pokud v zařízení s menší zobrazovací plochou nemají smysl. 1.2.2. Prototyp webové prezentace ČTÚ obsahuje návrh rozložení stránek pro dva typy zobrazovacích zařízení: malé, s nízkým rozlišením, zpravidla do 6 cm šířky displeje (mobilní telefony, PDA, tablety, phablety), a pro větší obrazovky se šířkou displeje nad 16 cm. Velikosti mezi budou doplněny buď pouze zmenšováním prvků větší varianty, nebo přidáním 1-2 breakpointů, které by definovaly jiné přeuspořádání obsahu (nepředpokládají se zásadní obsahové či funkční změny). 1.2.3. Typ zařízení bude detekován a pomocí databáze zařízení (existují volně dostupné) se určí příslušná šířka; podle šířky a typu zařízení pak server zobrazí příslušný CSS soubor. 1.2.4. Změny designu a funkcí v responsivní webové prezentaci ČTÚ nebudou vázány pouze na šířku displeje, systém musí na základě rozpoznání zařízení pro něj upravovat další vlastnosti webu (např. kontrast jednotlivých HTML elementů na zařízení s nižším rozlišením). 1.2.5. Dodávány vždy budou pouze ty kódy, které dané zařízení nutně potřebuje, to znamená, že se vždy pošle pouze odpovídající kód pro dané zařízení (to platí pro veškerá data, které server na zařízení odesílá (například obrázky, CSS, javascript ad.). Stránka 1 z 12
1.3. Jazykové verze 1.3.1. Nový web bude dostupný ve dvou jazykových verzích, v české a anglické; anglická verze bude fungovat jako samostatný web, který bude kopírovat českou verzi pouze, co se týče layoutu a designu. 1.4. Přístupnost 1.4.1. Web bude splňovat pravidla přístupnosti, která jsou dostupná na adrese http://www.pravidlapristupnosti.cz; to platí i pro obsah, který je generovaný automaticky či prostřednictvím redaktora (např. přes wysiwyg editor). 1.4.2. Ve zdrojovém kódu budou prvky seřazeny podle priorit, které odpovídají řazení v mobilní verzi a zároveň odpovídají pravidlům přístupnosti (skryté kotvy umožňující přeskočit navigaci v hlasových čtečkách a jiných zařízeních pro nevidomé apod.). 1.5. Wireframy 1.5.1. Zadavatel zpřístupňuje sadu 11 prototypů nejběžnějších stránek (wireframů). Pro vytváření nových stránek bude možné používat šablony přinejmenším v rozsahu těchto navržených prototypů. V šablonách budou definovány HTML elementy v optimalizovaném rozložení na dané typové stránce při respektování dalších požadavků dle této dokumentace. Wireframy jsou přístupné na adrese http://hcenvy.axshare.com/ (heslo pro přístup: „ctu213-14“). 1.6. Grafické styly pro formátování obsahu 1.6.1. Dodavatel připraví grafické styly pro formátování obsahu ve vazbě na poskytnuté wireframy: odstavce; podnadpisy minimálně čtyř úrovní; seznamy s odrážkami, číslované seznamy, včetně zanořených podseznamů; tabulky, včetně stylů pro hlavičkové buňky (styl pro tabulky se připraví s mřížkou (rámečky buněk) a bez ní); odkazy, včetně stavů visited, active, focus a hover; citace (blockquote); obrázky a videa ve stránce – bez popisků, s popisky, plovoucí vpravo, vlevo i neplovoucí. Každý obrázek musí umožňovat i odkaz na větší verzi, která se otevírá pomocí javascriptového lightboxu, ve kterém je možný i přechod na zvětšené verze dalších obrázků na stránce, tedy funkcionalita jakési galerie. 1.7. (X)HTML 1.7.1. Zdrojový kód stránek (HTML šablony) musí být validní podle některého z platných doporučení konsorcia W3C a co nejúspornější a efektivní, bez zbytečných tabulek pro layout a dalších nadbytečných značek; budou důsledně využívány čistě strukturální a sémantické (X)HTML značky kombinované s kaskádovými styly v externím souboru; v externích souborech budou uloženy případné skripty v jazyce JavaScript. 1.7.2. V kódu nesmí chybět správné vyznačení znakové sady dokumentu a vyznačení jazyka obsahu stránek atributy u značky . 1.7.3. Verze (X)HTML normy bude zvolena tak, aby bylo možné efektivně dosáhnout validního kódu, a to zvláště s ohledem na charakter uživatelsky editovatelných vstupů, např. za použití WYSIWYG editoru. 1.7.4. Pro kontrolu validity se využije validátor W3C (http://validator.w3.org/unicorn/ nebo http://validator.w3.org/). 1.7.5. Řazení obsahu v kódu stránek: Obsah v kódu stránek bude v jednotlivých šablonách seřazený s ohledem na důležitost jednotlivých bloků: 1.7.5.1 nejvyšší priorita:
Stránka 2 z 12
stručná hlavička s názvem webu a sloganem, odkaz na přeskočení navigace, hlavní navigace, hlavní nadpis, obsah stránky;
1.7.5.2 nižší priorita: patičková navigace, patička webu (Copyright apod.). 1.8. Kaskádové styly (CSS) 1.8.1. Kaskádové styly v externích souborech budou použity jako výhradní způsob pro definici layoutu webu i jeho formátování. 1.8.2. K webu budou připojeny i separátní kaskádové styly sloužící pro tisk stránek, které zajistí tisk pouze těch informací, které jsou pro tisk vhodné, a zamezí tisku např. vyhledávacího formuláře, rozsáhlé navigace, vyhledávání apod.; tiskové styly umožní bezproblémový tisk na běžné formáty papíru. 1.8.3. Soubory s kaskádovými styly budou mít vhodně nastavené HTTP hlavičky, aby bylo umožněno jejich cacheování prohlížečem, a byla tak využita výhoda rychlejšího načítání stránek. 1.9. Sémantika 1.9.1. Pro správné strukturování textů budou využity sémantické značky, jedná se zvláště o tyto značky: a) Nadpisy: h1 - h6, Nadpis h1 na stránce uveden právě a pouze jeden, b) Seznamy číslované, c) nečíslované, d) definiční: ul, ol, dl, e) Odstavce: p. 1.8
Formuláře 1.8.5 Formuláře budou v maximální možné míře využívat technologie jQuery (nebo jQueryMobile). 1.8.6 Pro popisky formulářů se použije značka label s atributem for, jehož hodnota se rovná hodnotě atributu id souvisejícího formulářového prvku. 1.8.7
Do polí pro zadání e-mailové adresy bude předvyplněn znak zavináče.
1.8.8 Uživatel nesmí být nucen vyplňovat přesný formát vstupního údaje, bude mu ponechána volnost a umožněno vkládat libovolný formát (např. telefonního čísla). Eventuálně v nápovědě může být ukázán doporučený tvar. 1.8.9 Žádné z polí ve formuláři nesmí být nadbytečné; při minimálním počtu je pravděpodobnější, že je uživatel vyplní.1 1.8.10 Delší formuláře je nutné rozdělit do více stran (kroků) s grafickým vyznačením absolvovaných a následujících kroků. 1.8.11 U formulářů s větším počtem polí budou sdruženy související prvky do svisle orientovaných skupin – fieldsetů. 1.8.12 Formulář nebude rozdělován do více sloupců. 1.8.13 Uživateli budou ukazována jen relevantní pole v závislosti na tom, co již zadal. Nerelevantní pole budou skryta.
1
Doporučený nejvyšší počet polí u jednoho formuláře je 10.
Stránka 3 z 12
1.8.14 Místo zašednutí (disablování) budou formulářová pole rovněž skrývána. 1.8.15 Budou nastaveny pravděpodobné výchozí hodnoty (např. předvolací čísla +420 u telefonů apod.) 1.8.16 Pro malý počet možností bude použito radio buttonu místo selectu. 1.8.17 Pokud v prvku <select> jsou na začátku uvedeny nejčastěji vybírané volby, je třeba zajistit, aby i bez posouvání stránky bylo vidět vizuální ukončení seznamu nejčastějších voleb. 1.8.18 Tlačítko pro odeslání formuláře musí být srozumitelně pojmenované. U formuláře by nemělo být více tlačítek, např. reset a submit. Je-li bezpodmínečně nutné mít více tlačítek, je třeba jasně odlišit primární. 1.8.19 Tlačítko pro uvedení formuláře do výchozího stavu (reset) bude užíváno jen minimálně, a to v jasně odůvodněných případech. 1.8.20 Je nutné zabránit dvojitému odeslání formuláře tam, kde to může způsobit problémy (registrace, diskuse). Dvojitému odeslání bude zabráněno tak, že se tlačítko pro odeslání formuláře po stisknutí nahradí prvkem znázorňujícím probíhající odesílání, čímž se znemožní kliknutí na tlačítko podruhé. Je třeba zamezit znovuodeslání formuláře po znovunačtení stránky (např. po stisknutí klávesy F5, tlačítko aktualizovat apod.). 1.8.21 O výsledku odeslání je uživatel informován pomocí potvrzovací hlášky nebo děkovací stránky. Potvrzovací hlášky budou dostatečně zvýrazněné a jasně odlišené od zbytku stránky i chybových hlášek. Chybové hlášky budou formulovány přátelsky až omluvně. 1.8.22 Uživatel bude varován před opuštěním stránky v tom případě, že by tím přišel o data zadaná do formuláře. 1.8.23 Vzhled posuvníků (u okna prohlížeče nebo formulářových prvků) nebude měněn a bude ponechán ve stylu vykresleném operačním systémem. 1.8.24 Možnost použití základních funkcí prohlížeče, např. tlačítka Zpět, kontextového menu prohlížeče, adresního řádku nebude omezena. 1.8.25 Formuláře, na jejichž výsledky má smysl odkazovat (např. vyhledávání), budou odesílány metodou GET. 1.8.26 Formulář bude kontrolován při odeslání ještě v prohlížeči pomocí javascriptu. V případě chyby nesmí být uživatel nucen vracet se zpět. 1.8.27 V případě chyby se ponechávají všechna pole formuláře tak, jak je uživatel vyplnil. 1.8.28 O případných chybách bude uživatel informován co nejblíže u daného formulářového pole. 1.8.29 Nápověda u formulářů 1.8.29.1 Výslovně bude označeno každé povinné pole. 1.8.29.2 Povinná pole budou zřetelně označena např. hvězdičkou (*) s odlišnou barvou. Označení musí být v blízkosti formuláře vysvětleno. Na celém webu je nutné dodržet stejný typ označení povinných polí; v případě formulářů obsahujících pouze povinné položky lze tuto skutečnost uvést na začátku formuláře a jednotlivá pole neoznačovat. 1.8.29.3 Pokud je nutné uvádět nápovědu, bude napsána přímo k jednotlivým polím. 1.8.29.4 Pokud je delší nápověda na samostatné stránce, bude otevřena do nového okna.
Stránka 4 z 12
1.8.29.5 Po zpracování odeslaných dat metodou POST bude uživatel nasměrován na výslednou stránku.2 1.8.29.6 Pokud je v prvku <select> možné vybrat více možností současně, bude vysvětleno jak. 1.9
URL 1.9.5
Tvar URL
1.9.5.1 Z hlediska budování zpětných odkazů a všeobecné použitelnosti webu bude URL důležitých stránek co nejkratší, tj. cca do 60-70 znaků včetně doménového jména. 1.9.5.2 Pro oddělení klíčových slov v URL budou použity výhradně znaky lomítko nebo pomlčka (spojovník). 1.9.5.3 V URL nebudou používány znaky, které se obtížně diktují nebo jejichž poloha na klávesnici není všeobecně známá, např. _, & apod. 1.9.5.4 V URL nebude použita diakritika. 1.9.5.5 V URL složky nebude název výchozího souboru, tzn. správně je http://www.ctu.cz/, nikoli např. http://www.ctu.cz/index.php. 1.9.5.6 V URL nebude přípona souboru, nikoli http://www.ctu.cz/kontakt.php.
tzn.
správně
je
http://www.ctu.cz/kontakt,
1.9.5.7 Nebude kolidovat obdobné URL souboru a složky, tj. např. URL http://www.ctu.cz/ochrana-spotrebitele a http://www.ctu.cz/ochranaspotrebitele musí vést na tutéž stránku, přičemž jedna varianta je výchozí a druhá je na ni ideálně přesměrována pomocí serverového přesměrování (301). 1.9.5.8 Verze URL bez www na začátku (např. http://ctu.cz/kontakt) budou přesměrovány pomocí serverové hlášky 301 na varianty s www (např. http://www.ctu.cz/kontakt). 1.9.6
Struktura URL
1.9.6.1 URL nebude odrážet hierarchickou strukturu webu. 1.9.6.2 Použijí se tvary URL, které obsahují vhodné klíčové slovo a jsou co nejkratší např. http://www.ctu.cz/kontakty/e-podatelna/. 1.9.7
Odstraněné stránky a změna URL
1.9.7.1 Stránka se přesunula na jinou adresu. V případě, kdy se stránka přesune na jinou adresu, bude nastaveno přesměrování pomocí HTTP kódu 301 z původní adresy na novou. 1.9.7.2 Existuje adekvátní náhrada/y původní stránky. V případě, kdy existuje adekvátní náhrada/y původní stránky, se původní stránka s původním obsahem ponechá na původní adrese; do její horní části se velmi zřetelně vloží upozornění, že daný obsah již neplatí, a odkazy na stránku/y s adekvátní náhradou.
2
Dodržení tohoto pravidla je důležité proto, aby mohl uživatel i nadále používat bez problémů tlačítko Zpět. Pokud na stránce vyvolané metodou POST není přesměrování, ptá se prohlížeč uživatele při návratu na tuto stránku, jestli má znovu odeslat formulářová data, čemuž uživatel nerozumí a může ho to zmást. Pokud navíc zvolí odeslání dat, formulář se odešle na server podruhé, což může způsobit duplicitní komentáře, registrace apod. Předem vysvětlete, co se stane s odeslanými údaji, a zdůvodněte méně obvyklá formulářová pole.
Stránka 5 z 12
1.9.7.3 V případě, kdy je stránka zrušena bez náhrady, se vrátí stavový kód 404 a vhodná 404 stránka s upozorněním, že stránka byla zrušena (nebo nikdy neexistovala), a se základní navigací webu. 1.10
Indexace webu vyhledávači 1.10.5 Jednoznačnost URL 1.10.5.1 Jedné URL bude vždy odpovídat právě jedna obsahová stránka. 1.10.5.2 Interní odkazy na úvodní stránku webu budou směřovat na kořenový adresář domény (/), nikoliv jmenovitě na výchozí dokument (např. index.html). 1.10.5.3 Pro výchozí (implicitní) variantu dynamické stránky se nebude používat URL bez parametrů, ani URL s implicitními hodnotami parametrů. 1.10.5.4 V URL nebude jako parametr zahrnut identifikátor session. 1.10.6 Unikátní obsah 1.10.6.1 Každá stránka bude mít metadata unikátní v rámci celého webu (obsah prvku title a meta description); prvek title je povinný, a bude na každé stránce (a na každé s jiným obsahem), meta description povinné není, a pokud není možné zajistit, aby bylo na každé stránce jedinečné, může být, pokud to bude vhodnější, zcela vynechán. 1.10.6.2 Hlavní obsah stránky bude tvořit většinu jejího obsahu; naopak ty části obsahu, které se opakují na více stránkách webu (navigace, záhlaví, upoutávky v krajních sloupcích apod.), budou tvořit pouze menší část stránky. 1.10.6.3 Na stránkách se nebudou objevovat samotné nadpisy uvozující bloky, ve kterých aktuálně není žádný obsah; grafický návrh musí být v tomto směru dostatečně pružný. 1.10.7 Meta Title 1.10.7.1 Administrátor webu bude mít možnost značku title libovolně upravovat. 1.10.7.2 Pokud nebude nastaveno jinak, bude se meta title implicitně generovat podle nadpisu h1 dané stránky; za oddělující značkou „ | “ bude následovat název webu; struktura meta title bude vypadat následovně „Název stránky | Název webu“. 1.10.7.3 Všechny stránky webu budou mít unikátní titulek dobře vystihující obsah dané stránky. 1.10.7.4 Fráze použitá v titulku nebude příliš obecná a bude zvolena také na základě analýzy klíčových slov tak, aby byla použita fráze s vysokou hledaností. 1.10.7.5 Délka Meta Title nebude přesahovat cca 65 znaků. 1.10.7.6 V Meta Title se budou v minimální míře používat velká písmena (kapitálky). 1.10.8 Přístupnost pro roboty 1.10.8.1 Nový web (zejména jeho navigace) bude v minimální míře závislý na aktivovaných cookies ani na Javascriptu a technologii Flash; pokud web tyto technologie bude využívat, bude nabízet odpovídající alternativu uživatelům, kteří tyto funkce nemají nainstalované nebo povolené (což platí i pro roboty vyhledávačů). 1.10.8.2 Odkazy a navigace indexovatelných stránek budou řešeny výhradně HTML značkou
. 1.10.8.3 Zabránění indexace testovacích verzí např. pomocí nastavení souboru robots.txt; zákaz indexace bude odstraněn po spuštění na ostrou verzi. 1.10.8.4 Tisková verze nesmí být indexovatelná.
Stránka 6 z 12
1.11
Chybová stránka 404
1.11.5 URL bez platného obsahu musí vracet stavový kód (http hlavičku) 404. Platí to nejen o URL, která ukazují na neexistující soubor, ale také pro URL existujícího souboru s neexistujícími parametry; nesmí docházet např. k situaci, kdy URL s neplatným parametrem zobrazí prázdný výpis z databáze nebo chybovou hlášku databáze. 1.11.6 Chybová stránka bude stejného grafického provedení jako ostatní stránky webu (včetně základní navigace). 1.11.7 Chybová stránka bude srozumitelně informovat, že se stala chyba a co ji způsobilo (neplatný odkaz, překlep uživatele, chyba serveru apod.), případně bude doporučovat další postup (kontrola správného zadání adresy, nabídka přechodu na úvodní stránku webu nebo jiné obvykle navštěvované stránky, doporučení použití dalších prvků webu – hlavní navigace, mapy webu, kontaktní údaje na správce webu). 1.11.8 Číslo chyby nebude uvedeno vůbec, nebo bude mít pouze nízkou vizuální prioritu. 1.11.9 Chybová stránka bude obsahovat pouze minimum typických prvků webu přítomných na všech stránkách. 1.11.10 Chybová stránka bude automaticky (bez přičinění uživatele) informovat správce webu, který může v případě potřeby opravit chybný odkaz uvnitř webu. 1.11.11 V rámci Google Analytics bude nastaven alert, který bude informovat o počtu zobrazených chybových stránek nad určitou mez. 1.12
RSS
1.12.5 Prostřednictvím RSS bude dostupný všechen pravidelně publikovaný obsah webu; tím je myšlen dynamický obsah, který je pravidelně v různých intervalech na webu publikován (například: oznámení, vydaná opatření, ale také i pro diskusi ve Veřejných konzultací – aby bylo možno sledovat příspěvky); samostatné RSS nemusejí mít stránky, které mají obsah statický, tj. nijak zásadně se nemění (například Rada ČTU). 1.12.6 RSS zdroj bude dostupný odkazem vždy na stránce, jejímuž obsahu odpovídá; zároveň bude unikátní pro danou stránku (případně pro tematickou sekci), aby bylo možné sledovat pouze daný obsah. 1.12.7 Na stránce „Přehled RSS“ bude přehled všech RSS z celého webu (všechny jednotlivé kanály). 1.12.8 Jeden samostatný RSS kanál bude věnovaný oznámením na Elektronické úřední desce. 1.12.9 Zároveň bude zřízen jeden samotný RSS kanál, který odkazuje na všechny změny na webu, které byly provedeny (nerozlišuje se dynamický ani statický obsah). 1.13
Google Analytics
1.13.5 Google Analytics bude implementován prostřednictvím nástroje Google tag manager. 1.14
Sitemap
1.14.5 Mapa webu bude umístěna do kořenové složky Nového webu, tedy na URL http://www.ctu.cz/sitemap.xml. 1.14.6 V souboru robots.txt bude uvedena informace o tom, že na Novém webu existuje Sitemap soubor, a to pomocí instrukce „Sitemap: http://www.ctu.cz/sitemap.xml“.
Stránka 7 z 12
1.14.7 Formát Sitemap souboru: XML Sitemap formát je standardní XML soubor. Podrobnější informace najdete na webu http://www.sitemaps.org/protocol.php, základní podoba souboru vypadá následovně (volitelné značky jsou vyznačeny kurzívou, sekce se v dokumentu opakuje pro každou stránku webu):
http://www.example.com/ 2008-09-01 daily <priority>0.5
1.15 Navigace a vyhledávání 1.15.5 Navigaci webu tvoří jednak horizontální menu, pomocné menu a pak také vyhledávání, které je doplňkovou funkcí, pomocí které se mohou uživatelé na webu pohybovat. 1.15.6 Hlavní horizontální navigace je výsuvná. Po najetí myší na položku se zobrazí panel s nabídkou podsekcí. Na malých displejích tato navigace není a návštěvníci se pohybují pomocí lokální navigace. 1.15.7 V patičce stránky jsou některé odkazy zduplikovány. Předpokládáme totiž, že je právě zde budou uživatelé hledat. A dále jsou zde odkazy na stránky, které nejsou důležité pro cílovou skupinu, ale na webu být musí. 1.15.8 Lokální navigace. 1.15.8.1 Navigace na stránkách je umístěna přímo v obsahu stránky. V ideálním případě je reprezentována přímo samotným obsahem (například stránka Ochrana spotřebitele), častěji pak formou rozcestníku vedoucího na další obsah v dané sekci. Pokud je obsah tvořen dalšími podsekcemi, je odkaz na něj nadpisem, podstránky jsou pak vypsány v seznamu. Tematicky příbuzný obsah tvoří další formu navigace napříč obsahem, která zachycuje vztahy v něm. 1.15.9 Drobečková navigace 1.15.9.1 Drobečková navigace (breadcrumb) umožňuje jednak snadno zjistit, kde ve struktuře webu se návštěvník nachází, jednak snadný přechod na stránky ve vyšší úrovni hierarchie webu. Bude mít podobu lineárního seznamu odkazů oddělených obvykle znakem >, např.: Úvodní stránka > Hlavní kategorie > Podkategorie > Detail 1.15.9.2 Drobečková navigace se vyskytuje ve všech variantách zobrazení webu. 1.15.10 Vyhledávání 1.15.10.1 Na Novém webu bude implementována funkce běžného i pokročilého vyhledávání (využití logických operátorů, hledání podle dalších atributů – stáří dokumentu, sekce, apod.) Stránka 8 z 12
1.15.10.2 Do vyhledávacího formuláře bude za použitím nástrojů jQuery a AJAX implementována interaktivní nabídka nejčastěji hledaných frází a klíčových slov (podobně jako při vyhledávání v Googlu) 1.15.10.3 Formuláře (INPUT) s vyhledávacími frázemi budou serveru odesílány metodou GET, aby na výsledky vyhledávání bylo možné odkazovat.
2. Požadavky na redakční systém / CMS (Content Management System) 2.1. Pokud nebude CMS řešen přímo webovou službou ale na klientských počítačích instalovaným softwarem, zajistí dodavatel dálkový přístup k redakčnímu systému přes webové rozhraní, a to bez podstatného omezení funkcí. 2.2. Možnost rozšíření CMS dle požadavků (na míru). 2.3. Záplatování případných chyb a aktualizace CMS. 2.4. Záruka vývoje platformy CMS. 2.5. Odborné poradenství při správě Nového webu. 2.6. Statistiky. 2.7. Možnost změny designu webu bez nákladů na přepracování obsahu - obsah je na šabloně (podobě) stránek nezávislý. 2.8. Integrovaná optimalizace pro vyhledávače. 2.9. CMS bude uživatelsky přívětivý a komplexní: 2.9.1. S jednoduchým a intuitivním administračním rozhraním: bez nepotřebných funkcí a navržené tak, aby nejčastěji používané funkce byly nejrychleji přístupné. 2.9.2. Rozšířitelný: nízkonákladové provádění změn a aktualizací v návaznosti na potřeby ČTÚ. 2.9.3. Interoperabilní: podpora pro externí analytické nástroje, exporty a importy obsahu apod. 2.9.4. Umožňující víceúrovňové přidělování práv uživatelům. 2.10. Administrační rozhraní pro správu webu bude umožňovat jednoduchou a rychlou správu jednotlivých stránek a sekcí a ovládání všech funkcionalit předpokládaných touto přílohou. 2.11. Variabilní obsahové bloky: administrační systém (CMS) musí umožňovat na jednotlivé stránky libovolně vkládat následující typické obsahové bloky: 2.11.1. Knihovna souborů: umožní vložit 1 nebo více souborů s volitelnou mírou zobrazování detailu (ikonka typu souboru, jméno souboru, název odkazu, datum/čas vložení, velikost). 2.11.2. Knihovna obrázků: podmnožina předchozího – měla by umět zobrazovat rozklikávací náhledy v různém rozlišení – využitelné např. pro stránky Rady ČTÚ. 2.11.3. Typ oznámení: dynamicky generovaný obsah boxu, který zobrazuje proměnlivý výstup z databáze. Možnost určit počet položek, jejich řazení apod. 2.11.4. Diskusní fórum: možnost vložit na stránku moderovatelnou diskusi vč. připojování příloh (např. u veřejných konzultací) - zobrazení vloženého příspěvku podléhá schválení administrátorem. 2.11.5. Kalendář: umožní vizuálně zobrazit časový úsek průběhu nějaké události (například trvání veřejné konzultace, začátek účinnosti nového rozhodnutí apod.). 2.11.6. Anketa: možnost vložení hlasovací komponenty. 2.11.7. HTML: dává možnost kamkoliv do šablony umístit jakýkoliv HTML kód.
Stránka 9 z 12
2.11.8. Související obsah: obsahový blok, který odkazuje na jinou část webu, která je tematicky příbuzná. Proces by měl být co nejvíce automatizován, například za pomoci štítkování obsahu (labeling) administrátory. 2.12. Reálný WYSIWYG editor, tzn. výstup stránky (zobrazení pro koncového uživatele) bude vypadat stejně jako v editačním rozhraní. 2.13. WYSIWYG editor bude produkovat na web takový obsah, který splní pravidla přístupnosti podle vyhlášky o přístupnosti č. 64/2008 Sb. 2.14. Hlavním nástrojem pro tvorbu a editaci jednotlivých stránek bude WYSIWYG editor3, tzn. výstup stránky (zobrazení pro koncového uživatele bude vypadat stejně jako v editačním rozhraní), umožňující zejména: 2.14.1. Vkládání a kopírování textu z formátovaných dokumentů tak, aby bylo zachováno formátování při dodržení požadavků na validitu dokumentu. 2.14.2. Jednoduchou manipulaci s obrázky s nastavením všech obvyklých atributů (např. pozicování, alternativní text apod.). 2.14.3. Přikládání souborů a správu katalogu vložených souborů. 2.14.4. Vytváření tabulek. 2.15. Přepnutím z WYSIWYG editoru do HTML získá administrátor přístup ke zdrojovému kódu a může jej bez omezení editovat. 2.16. Pro vytváření nových stránek by mělo být možné používat šablony přinejmenším v rozsahu navržených wireframes (každá wireframe bude mít odpovídající šablonu). 2.17. Administrační rozhraní bude umožňovat víceúrovňové přidělování přístupových práv jednotlivým administrátorům, přinejmenším v rozsahu: 2.17.1. Správce webu – neomezený přístup ke všem sekcím a stránkám, k šablonám, galeriím a dalším elementům. Vytváří další uživatelské přístupy a přiděluje jim příslušná oprávnění. Vytváří nové sekce, stránky. 2.17.2. Editor sekce – neomezený přístup pouze do svěřené části webu vymezené buď hloubkou zanoření v informační architektuře, nebo typem obsahu, který je dotyčnému zpřístupněn. Může v rámci svěřeného přístupu vytvářet nové stránky. 2.17.3. Referent – má buď právo změny a zápisu, nebo jen změny k úzce vymezenému typu obsahu (např. může pouze editovat obsah stránky a vyměňovat přiložené soubory, ale nemůže vytvářet nové stránky nebo dokonce sekce). 2.18. Všechny aktivity prováděné administrátory budou protokolovány tak, aby z protokolu bylo zřejmé, kdo, kdy, z jaké IP adresy a co na webu učinil. 2.19. Provedené změny v obsahu stránek budou reverzibilní alespoň do té míry, že změny provedené v době mezi pořízením záloh celého webu (předpokládá se zálohování na denní bázi) bude možné jednoduše vrátit zpět, např. formou správy verzí. 2.20. Záznamy provedených změn: administrační rozhraní přidaných/upravených stránek na zadané e-mailové adresy.
3
http://cs.wikipedia.org/wiki/WYSIWYG
Stránka 10 z 12
automaticky
posílá
soupis
2.21. Moduly: administrační rozhraní bude umožňovat přidat na stránku variabilní obsahové bloky popsané v bodě 2.11; bude umožněno na stránku vložit více stejných či různých obsahových bloků a každému přiřazovat příslušné vlastnosti (škálovatelnost modulů).
3. Technická specifikace a požadavky na Zákaznickou podporu 3.1. Webový server v konfiguraci, která zajistí vytížení CPU a obsazení paměti RAM na úrovni max. 60 % (měřeno pro pětiminutový průměr). 3.2. Nesdílený diskový prostor. 3.3. Připojení k síti Internet s rychlostí min. 100 Mb/s. 3.4. Webhosting bez limitu přenesených dat. 3.5. Zajištění dohledu (vytížení zdrojů serveru (CPU, RAM, HDD), konektivita, rychlost download/upload (max. 5 min. průměry), dostupnost jednotlivých služeb atd.) a správy serveru v režimu 24/7/365. 3.6. Instalace nových aplikací. 3.7. Zajištění bezpečnosti webového serveru, ochrana před napadením z Internetu (updaty SW, IDS apod.). 3.8. Zajištění zálohování kompletního webu (kód, databáze, konfigurace) v intervalu max. 2 hodiny (inkrementální/rozdílová), provádění denních úplných záloh s historií záloh min. po dobu 60 dnů; zajištění přístupu k zálohám. 3.9. Zajištění dostupnosti Nového webu minimálně 99,95% (měřeno za kalendářní měsíc); dodavatel zajistí report z monitoringu dostupnosti minimálně 1 x měsíčně. Do tohoto parametru se nezapočítávají plánované odstávky. Tyto budou oznámeny nejméně 5 pracovních dní předem. Plánované odstávky budou probíhat výlučně v nočních hodinách (22-07 h). 3.10. Optimalizace a testování spolehlivosti serveru pro zajištění nepřetržitého provozu webu, instalace a konfigurace serveru, instalace a pravidelná aktualizace SW. Dodavatel zajistí a navrhne vhodnou ochranu před kybernetickými útoky. 3.11. Neomezený počet domén 2. řádu, aliasů a subdomén. 3.12. Serverové statistiky o přístupech a návštěvnosti (s historií min. 12 měsíců). 3.13. Dálkově přístupné serverové statistiky - vytížení zdrojů serveru (CPU, RAM, HDD), konektivita, rychlost download/upload (max. 5 min. průměry), dostupnost jednotlivých služeb atd. zatížení CPU, RAM a HDD s historií po dobu 12 měsíců. 3.14. Zajištění reportů o bezpečnostních incidentech s historií 12 měsíců. 3.15. Servisní zásah: Režim
Incident kat. A
Incident kat. B
Běžná odezva (zjištění příčin) od nahlášení max. do
1 hod
2 hod
Doba odstranění od nahlášení max. do
3 hod
10 hod
Stránka 11 z 12
3.15.1. Incidentem kategorie „A“ se rozumí stav, kdy je server s hostovaným Novým webem zcela nedostupný. 3.15.2. Incidentem kategorie „B“ se rozumí stav, kdy web běží v nouzovém režimu, zobrazuje jen statickou stránku informující o chybě a odhadované době nutné k jejímu odstranění. 3.15.3. Termín pro odstranění incidentu kategorie „A“ je splněn i tehdy, pokud je v dané době možné incident překlasifikovat na kategorii „B“. 3.16. Zajištění Help Desk (vč. manuálu k HelpDesku) v režimu 24/7/365. 3.17. Dostupnost webu z adresního prostoru IPv4 a IPv6. 3.18. Podpora protokolů SSL, FTP, FTPS.
Stránka 12 z 12
