Funkční požadavky na řešení vycházení z provedené analýzy, V rámci analýzy je zpracována přesná podoba a rozsah funkcí MVP (minimálního produktu). Implementace je provedena na základě analýzy požadavků. Web je implementován s použitím vizuálního stylu, který byl schválen zákazníkem, například s požadavkem: Web je graficky lehký, přehledný, dobře strukturovaný. Stránky nejsou zahlceny obsahem. Obsahově náročné informace obsahují doplňkovou navigaci umožňující rychlou orientaci v komplexním obsahu. Na každé stránce jsou odkazy na sociální sítě. Níže uvádíme příklad funkcí, které náš systém nabízí. Jedná se však pouze o nejdůležitější funkce, náš systém toho nabízí mnohem více a jednotlivé funkce jsou implementovány na základě požadavků každého klienta.

Funkční požadavky na administraci

Uživatelské role a oprávnění

Systém obsahuje uživatelské role

1. Administrátor – vytváří, maže, edituje a blokuje uživatele, edituje obsah
2. Editor – může editovat informace a obsah dle potřeby
3. Další přístupy s oprávněními dle potřeby zákazníka

Administrace obsahu

Je implementovaný editor pro stránky a metadata. 

1. možnost editace ve WYSIWYG a HTML režimu
2. předdefinované styly. Uživatel nemusí řešit, jak má vypadat výsledek
3. min. 3 úrovně nadpisu, fotografie, číslované i nečíslované seznamy
4. zadávání a editace odkazů
5. vkládání videí z YouTube pouze zadáním správného odkazu
6. Je implementováno vkládání souborů – příloh – (typicky PDF, DOCX, XLSX).
7. Je možné přidávat/odebírat/skrývat/zobrazovat obsah
8. Je možné zobrazit si ekvivalentní náhled, jak bude obsah vypadat před zveřejněním na produkční web.
9. Stránky je možné organizovat do sekcí a podsekcí a jednotlivé sekce a podsekce přiřazovat v navigaci. Jednotlivé sekce lze dělit mezi sloupce.

Web má vhodné ikony a favicon pro všechny relevantní platformy. Web neobsahuje odkazy vedoucí na neexistující adresy (HTTP 404). Web nenačítá zdroje (CSS, JS, obrázky, …) z neexistujících adres (HTTP 404). Weby mají nastavený viewport stránky. Používají se správné vstupní prvky (HTML5 input type) podle druhu zadávaných dat. Používají se sémantické elementy HTML5 (header, section, footer, main …). Všechny hlavní šablony jsou testovány W3C validátorem pro identifikaci možných problémů.

Fonty

Při načítání webu nedochází k efektům FOIT (flash of invisible text).

CSS

Weby používají responzivní design. Web se přizpůsobuje vlastnostem a rozměrům výstupního zařízení z hlediska velikosti písma, rozměrů klikacích/dotykových prvků. U mobilních telefonů a tabletů proběhlo přizpůsobení dotykovému ovládání (minimální ergonomické rozměry dotykových prvků, nezávislost na hover stavech). Všechna ID na stránce jsou unikátní.

Javascript

Hlavní obsah webu včetně navigace jsou dostupné i bez JavaScriptu.

Obrázky a video

Videa jsou zajištěna skrze globální CDN řešení (přípustné i YouTube či Vimeo).  Obrázky se poskytují v alternativách dle podpory UA (nejlépe pomocí picture srcset, popř. dynamickou volbou mimetype dle UA). Alternativami jsou myšleny zejména relevantní případy vlastních obrázků:

1. vhodné rozměry obrázku podle výstupního zařízení (malé, velké)
2. vhodné formáty obrázku s přihlédnutím zejména na datovou velikost a charakter  obrazové informace (preferovány moderní formáty SVG, WebP, JPEG 2000, JPEG XR).

Přístupnost

Profil a popisy jsou upraveny pro tiskový výstup pomocí tiskových stylů. Tiskové výstupy jsou optimalizovány tak, aby spořily spotřební materiál uživatele (papír, toner). Jsou respektována Web Content Accessibility Guidelines 2.1 minimálně v úrovni shody A a další doporučení konsorcia W3C ohledně přístupnosti pro uživatele se zdravotním postižením. Všechny obrázky mají alternativní popis. Web je ovladatelný pomocí klávesnice. Používá se značkování WAI-ARIA v souladu s https://www.w3.org/TR/wai-aria-practices/ Web má dostatečný kontrast textu a pozadí – minimálně 4,5:1. Všechny formulářové prvky na webech mají label nebo aria-label.

Rychlost

Web má charakter statického website, tedy vysoká cachovatelnost webu, možnost jednoduše a efektivně umístit do globální CDN / reverzní proxy cache a nebo s minimálními náklady do mnoha POP (points of presence). 

HTML, CSS a JavaScript soubory jsou minifikované. Používá se brotli, popř. gzip komprese. Obrázky jsou optimalizované, včetně uživatelsky nahrávaných. JavaScript se načítá v maximální možné míře pomocí async nebo defer. V relevantních případech (dlouhé výpisy) se používá lazyloading obrázků. Používá se dns-prefetch, popř. preconnect pro důležité assety (zejména obsah nad zlomem) načítané z jiných domén. Assety (statický obsah) mají velmi dlouhou dobu uchovávání v cache (max-age či expires). Invalidace se provádí změnou názvu assetu.

Technické SEO

Není zakázaná indexace veřejného a publikovaného obsahu vyhledávači, pokud toto nevyplývá z explicitního funkčního požadavku. Je nasazen korektní robots.txt. Pro weby existuje relevantní, validní a aktuální sitemap.xml, v případě většího rozsahu (limit 50.000 záznamů nebo 50MB) dělený do více souborů. Sitemaps jsou uvedeny v robots.txt Řešení robotům neblokuje přístup ani neposkytuje rozdílný obsah. Výjimku tvoří roboti, v případě že řešení extrémně přetěžují (zejména známé botnety z Číny, Ruska, …). Na tyto roboty je možné aplikovat přísný rate limiting. Stejný obsah webů není duplicitně přístupný na více URL a na jednom URL není přístupné více stránek. Za různá URL se považují i URL lišící se jen počtem či hodnotami parametrů (“query”). URL webů není zbytečně dlouhé, nemá zbytečné parametry, složky či číselné identifikátory. V URL webů se používají jen malá písmena anglické abecedy, číslice, pomlčky (minus), tečky a lomítka. Title a description stránek webu jsou automaticky generována z nadpisů či obsahu stránky, každá stránka má unikátní title. Je možné definovat vlastní title a description. Na každé veřejné stránce jsou implementovány náhledy pro sociální sítě. Open Graph a Twitter Cards minimálně v rozsahu reprezentativního obrázku. Nad rámec základního HTML obsahuje zdrojový kód stránek i validní sémantické značkování vybraných objektů (události, místa, kontakty apod.) podle specifikace

Schema.org JSON-LD.

Jsou použity validní Google rich snippets pro všechna relevantní data, která web obsahuje a Google podporuje ( Breadcrumb, Course, Event, How-to, Job Posting, Job Training, Logo, FAQ, Article ).

Uživatelské role a oprávnění

Systém obsahuje uživatelské role

1. Administrátor – vytváří, maže, edituje a blokuje uživatele, edituje obsah
2. Editor – může editovat informace a obsah dle potřeby
3. Další přístupy s oprávněními dle potřeby zákazníka

Administrace obsahu

Je implementovaný editor pro stránky a metadata. 

1. možnost editace ve WYSIWYG a HTML režimu
2. předdefinované styly. Uživatel nemusí řešit, jak má vypadat výsledek
3. min. 3 úrovně nadpisu, fotografie, číslované i nečíslované seznamy
4. zadávání a editace odkazů
5. vkládání videí z YouTube pouze zadáním správného odkazu
6. Je implementováno vkládání souborů – příloh – (typicky PDF, DOCX, XLSX).
7. Je možné přidávat/odebírat/skrývat/zobrazovat obsah
8. Je možné zobrazit si ekvivalentní náhled, jak bude obsah vypadat před zveřejněním na produkční web.
9. Stránky je možné organizovat do sekcí a podsekcí a jednotlivé sekce a podsekce přiřazovat v navigaci. Jednotlivé sekce lze dělit mezi sloupce.

Na základě analýzy definujeme obsah webu. Pro prezentaci a propagaci web může obsahovat následující základní stránky prezentující informace (pro e-shop se struktura jiná):

a. Úvodní stránka, rozcestník s odkazy na stránky produktů
b. Produkty a jejich popis.
c. Detailní popis jednotlivých produktů (včetně fotek a videí).
d. Cenové nabídky
e. Všeobecný popis
f. Informace týkající se služeb a produktů klienta
g. Často kladené otázky (FAQ).
h. Kontakty.

Vizuální styl je tvořen s ohledem na cílovou skupinu zákazníka a dle jeho požadavků. Většinou jsou předloženy dvě varianty konceptů vizuálního stylu, schválený koncept vizuálního stylu zapracujeme do uceleného grafického manuálu. Všechny styly jsou navrženy jako responzivní pro všechna rozlišení a použitá zařízení. Grafický manuál – dodá klient, případně zpracuje náš grafik. Značka – logo má definovanou barevnou, jednobarevnou i černobílou variantu pro použití na světlý či tmavý podklad, definice podkladů – kdy použít jakou variantu loga, ochrannou zónu, konstrukční schéma, rozměrová řada, minimální velikost a zakázané varianty. Pravidla pro použití s dalšími logotypy. Zahrnuje definici filozofie značky. Barvy – základní a doplňkové barvy definovány pro digitální použití (RGB, HTML) i tisk (CMYK, Pantone, RAL). Písma – definice primárního a sekundárního řezu písem včetně nadpisů a zvýraznění.

Příklady práce s vybraným písmem, kdy použít který styl.

Aplikace vizuálního stylu

1. Web – pro účel realizace webu
2. E-mailový podpis – HTML šablona

Orientační popis návaznosti s loga s celkovou grafikou pro vytváření dalších aplikací

1. reklamní formáty použité na webu a v kampaních

Řešení umožňuje implementaci webu v anglickém nebo jiném jazyce (není omezen počet jazyků, abeceda, řazení, směr psaní, formáty čísel /např. telefon, PSČ, formátování čísel atp./, měna, fyzikální jednotky, formáty papíru, zvyklosti zápisu data a času včetně používání různých kalendářů a časových pásem). Weby jsou validní podle https://validator.w3.org/i18n-checker/ Používá se HTML atribut lang. Možnost formátu překladů XLIFF, podpora vzdálené lokalizace, připojení překladatelů do aplikace.

Domény

Domény jsou většinou ve správě klienta, můžeme ale nabídnout správu domén, případně nákup nebo registraci domén dle požadavku klientů

DNS

DNS jsou ve správě zákazníka, který umožní nstavení dle požadavků pro vývoj a následný provoz webu.

Webhosting 

V případě potřeby zajistíme hosting pro aplikace  a databáze

Součástí procesu vývoje a deploymentu je verzování databázových schémat a nastavení pro migraci dat nebo zajištění stejného či lepšího efektu, který tento požadavek zajišťuje. Existuje více prostředí (minimálně vývojové, QA a produkční). Vývojovým prostředím je myšleno typicky lokální vývojové prostředí jednotlivého vývojáře či vnitrofiremní vývojové prostředí zhotovitele. QA (Quality Assurance) prostředí je zpřístupněno objednateli pro testování funkčnosti a jedná se o prostředí technologicky velmi blízké produkčnímu prostředí (s menšími nároky na výkon a distribuovatelnost aplikace, pokud toto není předmětem testování). Produkčním prostředím je míněno prostředí veřejně přístupné návštěvníkům a administrátorům webů.

Web je vyřešen tak, aby byl dostupný a dostatečně rychlý ve všech zemích, pro které bude primárně poskytovat obsah, zejména: celá EU nebo dle požadavků klienta. Zhotovitel Web provozuje a poskytuje jeho správu a průběžné aktualizace všech prostředí.

Je dodržována klasifikace požadavků na:

Běžný požadavek – požadavek Objednatele týkající se Provozu, Podpory nebo Údržby, jako jsou žádosti editorů o radu, jak nastavit či používat některé části Díla, běžné technické požadavky, žádosti o Customizaci a jiné podobné požadavky, které nejsou ohlášením Incidentu.  Incident kategorie 3 (drobná závada) – Dílo má vady, které však neomezují jeho funkčnost. Jedná se zejména o vady v zobrazení prvků GUI, jako je posunuté tlačítko, překlepy apod.

Incident kategorie 2 (nekritické závady nikoliv drobné) – Dílo má vady, které částečně omezují jeho funkčnost. Vady se projevují u méně než 20 % návštěvníků webových stránek. Jedná se zejména o vady jako nefunkční administrace, chyby v zobrazení části webových stránek, které způsobují komplikace návštěvníkům webových stránek apod. Vady způsobené Incidentem kategorie 2 lze obejít použitím jiného postupu, např. úpravou obsahu.

Incident kategorie 1 (kritické závady) – Dílo má vady, které způsobují jeho nefunkčnost či nefunkčnost jeho podstatných či kritických částí nebo byla v systému objevena bezpečnostní slabina, kvůli které byl odstaven. Za kritické závady jsou považovány také závady, které by jinak spadaly do kategorie 2, pokud se projevují u více než 20 %návštěvníků webových stránek.

Helpdesk

Zhotovitel vede elektronickou evidenci všech požadavků (HelpDesk), reakcí na ně a způsobů vyřešení po celou dobu trvání smlouvy. V evidenci vede informace o tom, kdy byl vznesen požadavek, kdo jej vznesl, jaký byl jeho obsah, kdo jej vyřizoval, kdy bylo na požadavek reagováno a kdy a jak byl požadavek vyřešen.

Provoz HelpDesku zajišťujeme v režimu 24/7 s historií hlášení Incidentů.

apeedo.com je organizačně, odborně a kapacitně připraveno řešit požadavky a podporu celého řešení. Reakční lhůty a lhůty vyřešení požadavku Je dodržována reakční lhůta (převzetí požadavku a zahájení řešení fyzickým člověkem, ne automatem) a lhůta pro odstranění vady od nahlášení závady.

Reporting

Poskytujeme  minimálně jednou za každé tři měsíce report provozu řešení, nejpozději do 20. dne následujícího měsíce.

Report obsahuje:

– Dostupnost služby v procentech

– Přehled využití servisního okna

– Přehled řešených Incidentů s výsledným stavem

– Hodnoty dosažených SLI / SLO

– Využití kapacity

– Doporučení k opatřením

Zálohování

Veškerá data se zálohují minimálně s denní frekvencí. Je uchováno minimálně 7 posledních denních, 4 poslední týdenní a 12 posledních měsíčních záloh.

Monitoring

Dostupnost webu je měřena monitorovacím nástrojem, na kterém se objednatel se zhotovitelem dohodli včetně metodiky měření, popřípadě nahlášením nedostupnosti objednatelem. Minimální Dostupnost v procentech se vypočítá za každý kalendářní měsíc tak, že celkový počet celých minut, po který byla služba dostupná nebo probíhala plánovaná údržba v servisním okně, se vydělí celkovým počtem minut v měsíci a vynásobí 100. Pokud je mezi samostatnými nedostupnostmi období kratší než 10 minut, považuje se toto celé období za nedostupnost.

Údržba

Všechny použité součásti všech prostředí jsou v rámci servisních oken udržovány v aktuálních verzích podle doporučení zhotovitele/autora součásti. 

V samostatném provozním dokumentu jsou definovány SLI (Service Level Indicators – vyhodnocované metriky) a k nim příslušné SLO (Service Level Objectives – cíle dosahovaných SLI, většinou jako minimální nebo maximální hodnota, popř. rozsah hodnot  typicky za udaný čas). U testování rychlosti pomocí webpagetest.org zahrnuje SLO region a prohlížeč, z jakého je prováděn test. V dokumentu jsou definovány typy sledovaných stránek (např. homepage, landing page, detail programu …) a konkrétní sledovaná URL pro související SLI. Dokument byl odsouhlasen před zahájením fáze 2.

Rozsah SLI

SLO v závorce jsou uvedené minimální hodnoty v okamžiku zadávání VZ, po dohodě může

být zpřísněno v provozním dokumentu.

– Qualys SSL Labs Test Grade (alespoň B)

– Securityheaders.com Grade (alespoň B, běžně dosahujeme A+)

– Mozilla Observatory Grade (alespoň C)

– Dostupnost viz (minimálně 99.5 %)

– Google PageSpeed Insights Score Mobile / Desktop (minimálně 80/80)

– Webpagetest.org TTFB – Time To First Byte (maximálně 350 ms)

– Webpagetest.org FCP – First Contentful Paint (maximálně 1.500 ms)

– Webpagetest.org TTI – Time To Interactive (maximálně 5.500 ms)

– Webpagetest.org TTFB – Time To First Byte (maximálně 350 ms)

– Webpagetest.org FCP – First Contentful Paint (maximálně 1.500 ms)

– Webpagetest.org TTI – Time To Interactive (maximálně 5.500 ms)

apeedo.com je organizačně, odborně a kapacitně připraveno řešit další rozvoj celého řešení po celou dobu trvání smlouvy.

Veškerá dokumentace k projektu je v češtině nebo angličtině. Správnost a úplnost dokumentace je kontrolována a dokumenty jsou aktualizovány  minimálně 1x ročně. Zákazník má k dispozici uspořádané a přehledné výstupy všech provedených analýz.

Technická dokumentace

Popis základní logiky/filosofie produktu. Dokumentace infrastruktury. Seznam externích služeb, závislostí a datových toků (např. Mailchimp, Sentry, DataDog, IS apod.) Dokumentace k zabezpečení (VPN, ukládání hesel, TLS atp) zejména pro účely auditů. Dokumentace typů zasílaných e-mailů a způsobu jejich posílání (SMTP servery či služby a jejich požadavky na DNS záznamy).

Uživatelská a business dokumentace

Existuje uživatelská dokumentace – návod na zadávání a úpravu obsahu. Může odkazovat na dokumentaci použitého CMS (DMS, PIM, atp.). V samostatném dokumentu jsou evidovány vyhodnocované metriky SLI a způsob měření.

Školení

Doporučujeme alespoň jedno hromadné školení obsluhy pro 1-5 editorů zákazníka v rozsahu alespoň 5 hodin.