Tvorba moderního e-shopu: plánování administrace

Dnešní, čistě teoretický díl je věnován rozboru jednotlivých sekcí administrace. Mimo jiné se budeme věnovat řešení parametrů produktů a variant, které jsou z pohledu programování e-shopu nejsložitější.

Seriál: E-shop pomocí moderních technologií (15 dílů)

  1. Úvodní analýza pro moderní e-shop 4.1.2013
  2. Návrh uživatelské části e-shopu 11.1.2013
  3. Tvorba uživatelské části e-shopu 18.1.2013
  4. Nákupní košík pomocí HTML5 Web Storage 25.1.2013
  5. Tvorba moderního eshopu: kategorie a parametrické hledání 1.2.2013
  6. Tvorba moderního e-shopu: dokončení uživatelské části 8.2.2013
  7. Tvorba moderního e-shopu: plánování administrace 15.2.2013
  8. Tvorba moderního e-shopu: správa objednávek 22.2.2013
  9. Tvorba moderního e-shopu: nahrávání obrázků k produktu 1.3.2013
  10. Tvorba moderního e-shopu: Bower, Yeoman a Gemnasium 15.7.2013
  11. Tvorba moderního e-shopu: HTML5 drag & drop a kategorie 29.7.2013
  12. Tvorba moderního e-shopu: zpracování chyb 12.8.2013
  13. Tvorba moderního e-shopu: Rich-Text Editing a dokončení administrace 26.8.2013
  14. Autentizace v single-page aplikacích 9.9.2013
  15. Autentizace v single-page aplikacích – serverová část 7.10.2013

V minulém díle jsme dokončili celou uživatelskou část. Ta byla konzultována se zákazníkem, který k ní přidával různé připomínky. Četnými iteracemi jsme došli do fáze, kdy je aktuální podoba e-shopu pro všechny strany výhodná. Zákazník měl možnost e-shop proklikat, a protože jsme použili jako testovací data reálné produkty, má také přesnou představu o tom, jak bude výsledný e-shop fungovat.

Prioritní požadavky a Paretův princip

Vytvoření celého uživatelského rozhraní bylo jednoduché a rychlé, protože jsme vůbec nemuseli programovat serverovou část ani administraci. Běžně praktikovaný postup je totiž přesně opačný. Nejprve se začíná administrací a jednoduchými číselníky a postupně se vytvářejí další a další sekce, které závisí na těch předchozích. Až následně programujeme uživatelskou část, protože v databázi konečně máme data, která potřebujeme. Takovým způsobem dojdeme v naší aplikaci k tomu, že v administraci na konci programujeme správu objednávek a v uživatelské části nákupní proces. Paradoxně zrovna tyto dvě části jsou v obou sekcích ty nejdůležitější.

Každý asi poznal situaci, kdy původní optimistický časový odhad neodpovídal realitě a aplikace se dokončovala na poslední chvíli. Dle různých statistik (třeba The Standish Group Report, 1994) je méně než 10 % projektů dokončeno včas a za dohodnutou cenu. Říká se, že 5 ze 6 softwarových projektů v současné době skončí neúspěšně. To jsou hrůzostrašná čísla. Pokud necháváme ty nejdůležitější věci na konec, znamená to, že je budeme velmi pravděpodobně dokončovat v časové tísni, což rozhodně na jejich kvalitě nepřidá. Není lepší programovat to nejdůležitější na začátku? V rámci seriálu tento postup dodržujeme.

Často se také hovoří o Paretově principu v softwarovém vývoji. Říká, že na 80 % funkcí potřebujeme 20 % času a na zbylých 20 % funkcí zbylých 80 % času. Dokončení projektu prodlužují především neustálé připomínky klienta k představené aplikaci. V již hotové aplikaci se úpravy dělají nesmírně náročně, obzvláště když požadavek na změnu vede i k změně databáze. Musí se pak adekvátně změnit administrace, a to stojí nehorázné množství času.

Postup v této vyvíjené aplikaci umožňuje tento problém výrazně minimalizovat, protože zásahy do šablony jsou mnohem méně časově náročnější než zásahy do existující aplikace. Zatímco běžně začíná programátorská práce návrhem databáze, v našem případě navrhujeme databázi až na konci, kdy přesně víme, jaké schéma databáze potřebujeme.

Správa objednávek

Nejdůležitější sekce v administraci je jednoznačně správa objednávek. Tuto sekci budou správci navštěvovat zdaleka nejčastěji. V souladu s výše uvedeným textem jí udělíme nejvyšší prioritu a budeme se ji věnovat nejdříve.

Nejčastější případ užití (use case) v administraci bude vyřízení objednávky:

  1. Správce zobrazí přehled objednávek.
  2. Správce zobrazí podrobné informace o konkrétní objednávce.
  3. Správce zpracuje objednávku (třeba zadá požadavek do skladu, tohle v našem systému neřešíme).
  4. Správce změní stav objednávky na „expedováno“ (popř. jiný stav) a případně připojí zprávu pro zákazníka.
  5. Správce přejde na zpracování další objednávky.

Z toho vyplývá několik požadavků a nich odvozených návrhů, které pro správu objednávek aplikujeme.

Předně není potřeba dělat žádnou zvláštní úvodní stránku administrace, úvodní stránka bude rovnou správa objednávek. Následně potřebuje mít správce okamžitý přehled o daných objednávkách. V přehledu potřebujeme každou objednávku jednoznačně odlišit podle jejího stavu. Nejjednodušší bude přidělit každému stavu objednávky barvu, kterou danou položku podbarvíme. Zároveň potřebujeme mít výborné prohledávání objednávek. Určitě podle zákazníka (jméno, příjmení, e-mail), nakoupeného produktu (názvu, kódu), čísla objednávky, poznámky, ceny a data uskutečnění nákupu. Můžeme využít parametrické hledání z uživatelské části. V NoSQL databázi bude opět objednávka vč. všech nakoupených produktů jako jeden dokument kolekce, takže vyhledávání i manipulace s ní bude jednoduchá.

Podle úvodní analýzy můžeme očekávat spíše jednotky nových objednávek denně. Správce zajímá hlavně adresa, obsah objednávky a doprava a platba. To není tolik položek, aby nemohly být u jedné objednávky už v přehledu. Budeme však chtít, aby se na jednu obrazovku vešlo minimálně 10 objednávek, takže některé méně důležité informace možná skryjeme JavaScriptem. Správci také necháme možnost změnit stav objednávky už v přehledu. To znamená, že pokud nebude chtít správce měnit samotný obsah objednávky, může vyřizovat objednávky již na úvodní stránce administrace. Do detailu pak přijde tehdy, pokud bude potřebovat k objednávce připojit nějakou zprávu, upravit údaje zákazníka nebo změnit obsah objednávky, dopravu či platbu.

Fakturaci v našem projektu řešit nebudeme. Vzhledem k tomu, že značná část dnešních online fakturačních systémů už má možnost napojení přes API, není problém toto napojení využít a ušetřit si práci při tvorbě vlastního fakturačního systému pro e-shop. Zda se z uživatelské části dotazujeme na vlastní API nebo API nějakého externího systému, je z pohledu programátora celkem jedno.

Správa kategorií a parametrů

Správa kategorií bude trochu jiná než správa ostatních sekcí. Na úvodní stránce budeme totiž zobrazovat kategorie v hierarchii. Kromě toho chceme nechat správci možnost libovolně strukturu měnit, což se nejlépe provede pomocí drag & drop. Dříve se tato funkcionalita řešila pomocí různých js knihoven, nyní je podpora pro drag & drop přímo v HTML5. Podporují ji všechny moderní prohlížeče (IE od verze 10), takže ji můžeme v administraci použít.

V editaci kategorie budeme také přiřazovat layout parametrů, který budeme vytvářet ve vedlejší sekci. Co to znamená? Každý druh produktů má specifické parametry, které u něj potřebujeme vyplňovat. Jiné parametry budou o samotných telefonů a jiné u cestovních nabíječek, některé však budou u obou druhů (třeba rozměry). Pro každý druh takových produktů vytvoříme vlastní layout parametrů. U něj budeme potřebovat evidovat název, seznam daných parametrů a také informaci, zda je chceme zobrazovat i v parametrickém hledání v kategorii v dané uživatelské části. Parametry se totiž budou používat jak pro parametrické hledání, tak v detailu produktu doplní jeho popis.

Potřebujeme tedy ještě sekci, kde budeme spravovat jednotlivé parametry. Ty mohou být dvojího druhu. Buď se u nich bude přímo vyplňovat unikátní hodnota (třeba rozměr či váhu bude mít každý produkt unikátní), ty označíme jako „parametry typu hodnota“. Nebo mohou být složeny z předem daných hodnot (např. barva: červená, modrá, černá ap.) a ty budeme označovat jako „parametry typu číselník“.

Postup bude tedy takový, že nejprve správce nadefinuje parametry, z nich se pak vytvoří layouty pro všechny druhy produktů a ty se poté přiřadí k dané kategorii.

Správa produktů

Sekce s produkty bude navštěvována také velmi často a lze ji považovat za druhou nejdůležitější v celé administraci. V rámci tohoto textu je zařazena až za správou kategorií i parametrů, aby bylo jasné, co si přesně pod pojmy parametry produktů či layouty představit, my ji však budeme dělat ihned po objednávkách.

V přehledu sekce budeme chtít vypisovat základní informace o produktech vč. jednoho obrázku pro rychlou orientaci. Také zde budeme potřebovat pokročilejší vyhledávání. Určitě budeme chtít filtrovat produkty podle kategorie a fráze, která se bude vyhledávat v názvu, perexu a textu produktu. Důležité je také vyhledávání podle kódu jak produktu, tak dané varianty.

K produktu přidáváme atribut” úvodní stránka”, který mají ty produkty, které budou na úvodní stránce. Určitě tedy budeme chtít vyfiltrovat i produkty s tímto atributem a případně ho rovnou z přehledu k produktu přiřadit.

V našem e-shopu neřešíme skladové zásoby (počty ks na skladě), pouze přiřazujeme konkrétní popis dostupnosti (viz dále). Určitě i podle něj budeme chtít produkty filtrovat a jeho nastavení měnit hned z přehledu produktů. A konečně také u produktu určujeme stav aktivní/neaktivní, takže i ten bude určitě kandidátem pro použití filtrování a také musíme umožnit jeho rychlou změnu hned z přehledu sekce.

Podobně jako všechny ostatní sekce i tato nebude obsahovat klasický formulář pro editaci, kam se nahrají všechny hodnoty. Když bude chtít uživatel změnit název, prostě klikne na název a objeví se mu textové pole, které může editovat (inline editace). To platí i pro všechny ostatní položky, i když se místo textového pole může objevit třeba roletkové menu nebo WYSIWYG editor.

Vkládání produktu bude rozděleno do několika částí. V první části se správci objeví formulář, kde vyplní všechny údaje, které se vyplňují vždy u všech produktů. Jde o název, cenu, kód, krátký popisek (perex) a dlouhý text, výrobce, dostupnost, stav (aktivní/neaktivní) a také zařazení do kategorie. Produkt je možné zařadit do více kategorií, jedna však musí být určena jako hlavní.

V druhé části se na základě dané kategorie zobrazí layout s parametry, který byl k dané kategorii přiřazen. Správce zadá hodnoty parametrů, popř. je vybere z multicheckboxu (v případě parametrů typu číselník). Pokud je vybráno více hodnot jednoho parametru (např. barva se vybere červená a černá), vygenerují se varianty produktu, u kterých je možné zadat doplňující údaje.

V detailu produktu bude mít správce možnost přidat k produktu fotografie. Zde si ukážeme několik novinek v oblasti HTML5, především nahrání fotografie jejím přetažením do okna prohlížeče. Fotografie budeme ukládat ve třech formátech: malý (použije se třeba v přehledu sekce produkty), střední (použije se pro kartičky produktů v uživatelské části a v detailu produktu) a originál. Necháme také správce vybrat hlavní fotografii pro daný produkt.

Správa uživatelů

Z úvodní analýzy víme, že počet uživatelů s přístupem do administrace bude v řádech jednotek (v současné chvíli je jich 5). Tři z nich budou mít roli klasických prodavačů a nepotřebují mít přístup nikam jinam než k správě objednávek. Další dva, jeden dlouhodobý zaměstnanec, který se bude starat o databázi produktů, a majitel obchodu, budou mít přístup do zbytku administrace. Budeme tedy potřebovat dvě uživatelské role: prodavač a správce, které se ke konkrétnímu uživateli přiřadí.

Samotná správa uživatelů už bude triviální záležitost. Jde o kolekci uživatelů, u kterých se eviduje jméno, příjmení, e-mail a role.

Správa výrobců a dostupností

Jsou to nejméně důležité části administrace, kam správce zavítá jednou za dlouhou dobu. Půjde o jednoduché dvě sekce, kde má správce možnost vložit libovolný počet položek.

Co dále

Výše uvedený popis je základ e-shopu. Můžeme mít samozřejmě požadavky na další funkce, jako je třeba podpora pro slevové kupóny, statistiky, ap. Tyto sekce jsou ale již doplňky, bez kterých může e-shop bez problémů fungovat. Je proto lepší je přesunout do další iterace mezi požadavky s nižší prioritou.

Nyní máme konkrétní představu o tom, jak bude administrace vypadat, takže nám nic nebrání v tom, abychom ji začali vytvářet. V příštím díle se vrhneme na správu objednávek.

Na tvorbě tohoto článku se díky závěrečnému review podílel i Pavel Lang. Díky!

Komentáře: 19

Přehled komentářů

J. Zmysel
Martin Hassman Re: Zmysel
vidya Re: Zmysel
Roman Antl Re: Zmysel
Mario Re: Zmysel
Jakub Mrozek Re: Zmysel
koleso totalny zaciatocnik v node
Jakub Mrozek Re: totalny zaciatocnik v node
Tomáš
napalm Node.js
Jakub Mrozek Re: Node.js
Radim Daniel Pánek Re: Node.js
petersirka Re: Node.js
Clary Node.js
Kolemjdoucí
J
vaclav.sir Re:
Daniel Steigerwald Kvalita seriálu
Jakub Mrozek Re: Kvalita seriálu
Zdroj: https://www.zdrojak.cz/?p=7074