Přejít k navigační liště

Zdroják » JavaScript » Tvorba moderního e-shopu: plánování administrace

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

Články JavaScript

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ší.

Nálepky:

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

Subscribe
Upozornit na
guest
19 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
J.

Nechcem brať autorovi chuť do písania, ale aký je zmysel takéhoto tutoriálu, autor nám tu zobrazuje výcucy zo zdrojových kódov nejakého virtuálneho eshop projektu v štýle „pozrite, takto by sme urobili toto a takto zasa toto“. Každý eshop je iný, každá biznis požiadavka sa odlišne premietne do doménového modelu a operácii nad ním. Každý aspoň trocha vyspelý programátorský tím si takéto analýzy a proof of concepty vie naprogramovať sám a na stotisíc iných spôsobov. Tutoriál sa dá napísať na konkrétnu tému ale nie radiť niekomu cez tutoriál ako spraviť production ready eshop. Programátorskej lame to nepomôže a inteligentný programmer si takéto veci vie urobiť aj sám. Skúste napísať niečo užitočné ohľadom eshop témy napríklad ohľadom payment mechanizmov (to ma len tak napadlo ako prvé, whatever ….)

Martin Hassman

Váš pohled je ryze binární, možná proto ten smysl nevidíte. Obor hodnot kvality programátorů není diskrétní s dvěma stavy (lama, profesionál), nýbrž spojitý a možná dokonce definovaný otevřeným intervalem, kde ty krajní hodnoty neexistují a najdeme maximálně tak hodnoty limitně se jim blížící. Věřím, že nemalé podmnožině z tohoto oboru hodnot může tenhle seriál něco užitečného nabídnout. A proto zde vychází.

vidya

tento tutorial nie je o e-shope.

Roman Antl

Já v tomhle vidím rozhodně smysl.
Já programuji již dlouhou dobu, ale rozhodně o sobě neříkám, že vím všechno. Rád čtu takovéto články, které mi dají širší rozhled. Podotknou mi i nápady a lepší řešení. Je to jenom o tom, co si čtenář z tohohle vezme nebo ne. Je to čístě individuální a nikdy nevíte komu to pomůže a komu ne.

Mario

Rozhodne to zmysel má, pre ľudí čo programovali eshopy v iných jazykoch, napr.: PHP + jQuery je tu pre drtivú väčšinu ľudí pekný príklad na porovnanie v Node.js + Angular. Každý si v tom nájde niečo, čo ho posunie ďalej a tí čo nie, nech napíšu kľudne svoj vlasný článok na zdroják, ja budem len rád :)

koleso

Ja ako totalny zaciatocnik tiez nie som velmi spokojny s formou tutorialu. Ale kazdopadne som zan vdacny lebo som sa aspon dozvedel ze node existuje a dalsi projekt by som v nom rad spravil. Ale ako vravim budem musiet prestudovat plno anglickych tutorialov lebo z tohto som nedokazal vstrebat ine informacie ako tie ze node existuje a da sa pouzit na rest api

Tomáš

Jednoznačně souhlasím s Romanem. Smysl seriálu tu vidím a může otevřít oči v mnoha věcech i trochu zaběhlým programátorům. Může se samozřejmě najít čtenář, který o článek nemá naprosto žádný zájem, ale věřím, že mnoho čtenářů se o tento seriál zajímají.

napalm

Chtěl bych pokračovat v tom, co jsem napsal na Twitter zdrojáku: https://twitter.com/kixorz/status/302572477605900288

Jedná se o to, že si myslím, že Node.js je jako technologie nevhodný pro tento typ projektu a to hned z několika důvodů, které se zde pokusím uvést.

1) http://nodejs.org/ vznikl jako projekt pro real-time aplikace. V čem přesně jsou e-shopy realtime aplikacemi? Já osobně tedy e-shop za realtime aplikaci nepovažuji. Realtime aplikace jsou pro mě aplikace, které zpracovávají a prezentují eventy přicházející do systému. Uživatele e-shopu nezajímá co si kupují ostatní uživatelé a stejně tak nepotřebuje v reálném čase dostávat jakékoliv updaty. Jediná funkce v e-shopu, která je realtime je chat se zákaznickou podporou, jelikož tam putují eventy (zprávy).

2) Zvolená technologie je extrémně nepřátelská pro vyhledávače, jelikož renderuje templaty na klientovi. Z vyhledávačů přihází do e-shopů hodně provozu a tímhle jsou efektivně vyřazené. Viz: view-source:http://shrouded-brook-3499.herokuapp.com/mobil/iphone-4-32gb-cerny Dvojí templatování pro server / klienta je naprosto zbytečná práce navíc.

Pokud bych vyvíjel mobilní e-shop, tak tam by se o vhodnosti nasazení Node.js dalo ještě uvažovat. Jedná se o to, že při přístupu přes mobilní síť je každý HTTP požadavek velmi pomalý. Speciálně, když přistupujete přes HTTPS, což by pro e-shop měl být standard. Tento problém by Node.js, při jeho správném použití (jako socketového serveru) efektivně eliminoval, jelikož klient by se serverem držel pouze jediné spojení, které by nezavíral a všechny příkazy do shopu by posílal tímto spojením a content by stahoval zvlášť z jiného serveru nebo CDN.

Mimo Node.js – pro ukládání košíku bych rozhodně nepoužíval lokální storage ani cookie s daty, ale pouze cookie s id košíku nebo nekonečné session na serveru. Košík podle mého názoru patří vždy na server (kvůli dolování dat apod), e-shopy ukládající košík lokálně jsou mimořádně iritující. Navíc odpadá vámi uvedený push na klienta v případě, že byl produkt vyřazen.

Radim Daniel Pánek

Ano souhlasím. Appky jsem psal dlouhá léta v PHP, nyní mám již cca 3 postavené na NodeJS a AngularJS a ten rozdíl je znát v různých ohledech. Například testování v JS je úplně jiné kafe než v PHP. Tento i ten předchozí seriál mi dává smysl a přeji hodně energie. Rád se nechám poučit a vytvořím si vlastní obrázek.

petersirka

1. node.js – tak to si dobrú hlúposť napísal, najradšej mám takéto reči. To je ako rozprávať o sexe a nikdy ho nemať, však?
2. ja som podobného názoru, ale to sa tu už dávnejšie rozoberalo a preto treba počkať na výsledok, možno zmeníme názor – človek nikdy nevie.

Clary

Osobně nevnímám seriál jako „Tvoříme dokonalý eshop a jako technologii jsme náhodou zvolili Node.js“, ale jako „Na příkladu eshopu vám ukáži co je možné dělat s Node.js, Angularem a featurami HTML5“. Úvahy na téma jestli je eshop dobrou ukázkovou aplikací mi příjdou zcela zcestné. Kdyby se programoval blog, budou tytéž výhrady vůči blogu, kdyby se programovalo něco jiného, řada webových vývojářů by to nemohla srovnat s něčím co už někdy dělali. (Například mě by se líbil v Angularu a Node napsaná LiveInput, ale kdo z vás ví, co ta aplikace vlastně dělá?)

Kolemjdoucí

Rozhodně parádní seriál!
Nic bych neměnil.

J

Tak znova a zkracene, protoze nejaky retard na webu a webu neumi udelat formular …

Je to ptakovina, protoze NIKDO soudnej si neporidi shop, na kterym by musel aminovat objednavky nebo zbozi, tak maximalne garazista. Podstatny je napojeni do systemu zakaznika, a ne nejaky klikatka na webu, to nikoho nedojme.

vaclav.sir

Nikdo u vás nikdy nebude nakupovat kvůli tomu, že nemusíte najímat brigádníka na plnění dat. Naopak o obchodu nebo odchodu může rozhodnout právě provedení těch „klikátek“.

Daniel Steigerwald

Musím říct, že jsem doposud tak kvalitní seriál na českém internetu nečetl. Jakube, klobouk dolů :)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.