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ů)
- Úvodní analýza pro moderní e-shop 4. 1. 2013
- Návrh uživatelské části e-shopu 11. 1. 2013
- Tvorba uživatelské části e-shopu 18. 1. 2013
- Nákupní košík pomocí HTML5 Web Storage 25. 1. 2013
- Tvorba moderního eshopu: kategorie a parametrické hledání 1. 2. 2013
- Tvorba moderního e-shopu: dokončení uživatelské části 8. 2. 2013
- Tvorba moderního e-shopu: plánování administrace 15. 2. 2013
- Tvorba moderního e-shopu: správa objednávek 22. 2. 2013
- Tvorba moderního e-shopu: nahrávání obrázků k produktu 1. 3. 2013
- Tvorba moderního e-shopu: Bower, Yeoman a Gemnasium 15. 7. 2013
- Tvorba moderního e-shopu: HTML5 drag & drop a kategorie 29. 7. 2013
- Tvorba moderního e-shopu: zpracování chyb 12. 8. 2013
- Tvorba moderního e-shopu: Rich-Text Editing a dokončení administrace 26. 8. 2013
- Autentizace v single-page aplikacích 9. 9. 2013
- Autentizace v single-page aplikacích – serverová část 7. 10. 2013
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:
- Správce zobrazí přehled objednávek.
- Správce zobrazí podrobné informace o konkrétní objednávce.
- Správce zpracuje objednávku (třeba zadá požadavek do skladu, tohle v našem systému neřešíme).
- Správce změní stav objednávky na „expedováno“ (popř. jiný stav) a případně připojí zprávu pro zákazníka.
- 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!
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 ….)
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í.
tento tutorial nie je o e-shope.
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.
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 :)
Díky za názor, autor určitě nemá problém s kritickými ohlasy, naopak, jsou vítané.
K smyslu seriálu. Seriál především navazuje na ten předchozí, který byl zaměřen mnohem více teoreticky. Podle mě by byl ale jeho přínos podstatně nižší bez nějaké praktické ukázky. Je fajn si číst o tom, jak je důležité testovat, jak se dobře pracuje s NoSQL databází ap., ale jakmile chce danou věc člověk použít v reálné aplikaci, tak obvykle naráží na řadu problémů, které v nějaké jednoduché ukázce nejsou řešeny. Já jsem tímto směrem nechtěl jít a raději jsem se snažil prezentovat nějako větší aplikaci, se kterou se většina čtenářů vývojářů už setkala.
Druhá věc je, že ona ukázková aplikace se hodí i do budoucna. Jestliže budu po seriálu psát nějaký další článek pro Zdroják, můžu ho rozdělit na dvě části: první bude teoretická a druhá praktická, kde využiji právě onu aplikaci. Konkrétně vámi zmiňované téma implementace platebních bran je hodně zajímavé i z pohledu Node.js, protože pro něj existuje pár balíčků, se kterými se tyhle věci implementují velmi snadno. Takže po seriálu není problém vydat samostatný článek „Implementace platebních bran v Node.js“ a tam projdu všechny dostupné balíčky a nakonec ukážu implementaci jednoho z nich v daném e-shopu. Čtenář k tomu pak dostane i demo, kde si může věc prakticky vyzkoušet.
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
„Ja ako totalny zaciatocnik tiez nie som velmi spokojny s formou tutorialu“
Napište mi, prosím, co Vám konkrétně na formě nevyhovuje. Není problém formu článků změnit, bohužel pod články k tomuto seriálu je velmi málo komentářů, a bez chybějící zpětné vazby je těžké něco měnit. Než se článek publikuje, obvykle ho dávám minimálně jedné osobě přečíst a na základě toho pak třeba udělám nějaké úpravy před vydáním.
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í.
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.
1) S tím nesouhlasím. Je běžnou praxí, že je technologie třeba původně vymýšlena pro nějaký jiný účel a po čase se ukáže, že se může hodit i někde jinde. Pokud se většiny lidí zeptám, co se jim vybaví pod pojmem Node.js, tak značná část odpoví, že umožní použití JavaScriptu na serveru a tuto funkci plní výborně. Kdo má rád JavaScript jako jazyk (třeba já), tak uvítá možnost, že ho může použít i na straně serveru. Na Node.js je postavena celá řada velkých aplikací, ať už jen mobilních verzí, tak i celé aplikace.
Museli bychom se dále bavit o tom, proč by mělo být použití Node.js pro tuto aplikaci nevhodné? Tedy konkrétní důvody (“raději bych tuhle aplikaci stavěl v PHP, protože v Node.js nejde xyz a v PHP je to mnohem snažší atd.”), bez toho jde pouze o pocit, filozofický názor.
Co se týče použití socket.io na tomto projektu, tak je to především z toho důvodu, aby zde byla praktická ukázka všech tří oblastí, pro které se Node.js dpoporučuje (1. Aplikace s RESTful/JSON API, 2. Single-page aplikace s frameworky jako třeba AngularJS a 3. real-time aplikace). Chtěl jsem jako demo aplikaci vytvořit projekt, který zasahuje do všech tří oblastí, což je v tomto případě splněno.
2) Psal jsem v jednom z komentářů, že shop bude “seo friendly”, že s ním vyhledávače nebudou mít problém. Kdyby shop nešel indexovat, samozřejmě by byl úplně k ničemu. Tomuto tématu se budu věnovat v posledních dílech seriálu a určitě nebude nutné psát další verzi šablon pro vyhledávače. Zase existují už různé Node.js balíčky, které tento problém řeší. Mně naopak přijde velmi vhodné, že byla pro tento seriál vybrána aplikaci, která musí být i indexovaná vyhledávači, protože jsem se setkal s tím, že někdo nechtěl dělat aplikaci na AngularJS kvůli tomu, že potřeboval zindexovat drobnou část stránek a myslel si, že v AngularJS tohle vůbec nepřichází v úvahu a v rámci tohoto seriálu bych mu rád ukázal, že to nemusí být neřešitelný problém. Počkejte do konce seriálu.
3) K použití localStorage. Seriál se věnuje i mnoha jiným oblastem a ukazuje různé možnosti řešení konkrétního problému. Zmiňuji poměrně často v seriálu, jaké jsou možnosti řešení dané záležitosti a není problém je doplnit/zkritizovat pod článkem. LocalStorage je jedno z řešení. Vím, že na základě seriálu se více lidí dozvědělo o věcech, které předem neznali a díky seriálu je pak použili na vlastních projektech. Třeba localStorage pro průběžné ukládání textu při psaní článku (výborné použití), samotné použití frameworku AngularJS a ti, co ho už používali, třeba neznali úplně všechny možnosti použití (třeba ngMockE2E) a seriál jim v tom pomohl.
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.
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.
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á?)
Rozhodně parádní seriál!
Nic bych neměnil.
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.
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“.
Musím říct, že jsem doposud tak kvalitní seriál na českém internetu nečetl. Jakube, klobouk dolů :)
Like this! :-) Díky.