Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: sonicpp 28. 12. 2020, 13:44:09
-
Zdravím vespolek,
během Svátečních dnů jsem si řekl, že by nebylo na škodu podpořit některé projekty pár drobnými. Minulý týden jsem teda poslal něco málo dvou projektům přes PayPal donate - transakce proběhla přes kartu. Bohužel jsem ale z emailů a z internetového bankovnictví zjistil, že PayPal připsal obě platby stejnému příjemci. Naštěstí jsem měl ještě nacachovanou stránku se samotnou platbou, kde jsem si ověřil (a pro jistotu udělal screenshot), že druhá platba skutečně směřovala jinému příjemci. Čili na webu mi PayPal potvrdil, že platba danému příjemci proběhla v pořádku, ale z emailu vidím, že ta samá platba byla připsána někomu jinému. Bohužel PayPal podpora se tváří, že se nic nestalo a že platby proběhly tak, jak jsem je zadal. Osobně si myslím, že nastala nějaká chyba v jejich systému, kdy jsem ty platby zadal hned po sobě a on je nějak smíchal dohromady.
PayPal každopádně nechce přiznat chybu - mám nějaké páky na to, aby to napravil? Nejsou to nijak závratné částky, ale nelíbí se mi, jak se k tomu staví.
A trochu offtopic - jaké služby používáte pro donate OS projektům? S PayPalem po tomto už končím.
-
Podobny problem melo FORPSI, kdyz vam expiruje >1 domena a vy si v nekolika tabech otevrete prodlouzeni a platbu - nejak tam maj bordel v cookies a vlatne provedete platbu na 1 domenu, vicekrat :-)
Samozrejme to je koncepcni chyba, protoze nejake frameworky jsou napytel, kdyz si stav vedou v cookies, a nemaji ho v URL.
Podobny problem ale je treba i u banky - tusim FIO rovnou zahlasi vadu a odhlasi vas - protoze nesedi sekvencni poradi cookies verzi.
Tohle nevyreklamujes - zadny moloch neprizna vadu, nebo zamestnava indy, kteri nejsou ochotni pripustit novou vadu - znaj jen sve existujici problemy.
-
Zeptej se obou protistran jestli to dorazlo..
-
Zeptej se obou protistran jestli to dorazlo..
Tohle bude hodne blbe vysvetlovani.
Nejlepsim resenim je znovu poslat tomu co to nedorazilo a tomu prvnimu zablahoprat at penize vyuzije na dobrou vec.
-
Pokud to na jejich stránce vypadá ok, tak mají možná jen chybu v emailech.
-
Podobny problem ale je treba i u banky - tusim FIO rovnou zahlasi vadu a odhlasi vas - protoze nesedi sekvencni poradi cookies verzi.
To není bug, ale feature. Pokud byste pracoval na stejném účtu ve dvou oknech paralelně, tak budete klikat do stavu, který už není platný a to může způsobit různé podivuhodné věci (které třeba nechcete). A co se týče peněz, tak "better safe than sorry".
-
Podobny problem ale je treba i u banky - tusim FIO rovnou zahlasi vadu a odhlasi vas - protoze nesedi sekvencni poradi cookies verzi.
To není bug, ale feature. Pokud byste pracoval na stejném účtu ve dvou oknech paralelně, tak budete klikat do stavu, který už není platný a to může způsobit různé podivuhodné věci (které třeba nechcete). A co se týče peněz, tak "better safe than sorry".
Ale on tam zadny evidentni stav neni - typicky use case je, ze chcete zopakovat X transakci (treba platby odvodu, najem, vyplaty), tak se doklikam v historii to obdobi ktere opakuji, ale nesmim otevrit v novych tabech "opakovat transakci" u vsech naraz - musim to delat po jednom - opakovat+k podepsani, opakovat+k podepsani... holt to UX pak trpi, radeji bych si pripravil do tabu co chci opakovat a pak je po jednom upravoval/odesilal a zaviral, nez mit vedle papirek a skrtat co jsem udelal nebo neudelal a musel stridat typ ukolu, protoze to maj napsany blbe.
Nepredpokladam ze to udelali takto umyslne (aka featura), spis to nemaj vychytany nebo je to technologicke omezeni frameworku (a s tim jako integratori nic nenadelaj).
-
To není bug, ale feature. Pokud byste pracoval na stejném účtu ve dvou oknech paralelně, tak budete klikat do stavu, který už není platný a to může způsobit různé podivuhodné věci (které třeba nechcete). A co se týče peněz, tak "better safe than sorry".
Vážně? Jaký problém by to mohlo způsobit? Stejně se musí vše ověřovat na serveru. Stejného stavu můžete dosáhnout třeba tím, že budete mít otevřené okno v prohlížeči a mezi tím uděláte změnu z jiného prohlížeče nebo z internetového bankovnictví.
-
Nepredpokladam ze to udelali takto umyslne (aka featura), spis to nemaj vychytany nebo je to technologicke omezeni frameworku (a s tim jako integratori nic nenadelaj).
S tímhle máte AFAIK pravdu. Pokud vím, má Fio web ve Wicketu. Ten si drží stránku v paměti serveru a když přijde AJAXový calback pro komponentu, tak na ní zavolá příslušný callback. Aby se nestalo, že komponenta už tam není / je v jiném stavu, tak pracuje s verzemi stránky, takže volání obsahuje i informaci, pro jakou verzi je určeno.
Problém s tím je, že server si musí držet ty verze zpětně a to žere hodně paměti, takže na zatíženějších serverech se to omezuje a pak je právě problém, když by vám přišel callback pro verzi, kterou už v paměti nemáte. Například když si otevřete stránku v jiném okně, něco na ní děláte a pak se vrátíte do původního s o dost starší verzí stránky. Proto se tomu v takovýchto setupech zamezuje a to je technologický důvod, proč to Fio neumí. Nicméně i kdyby to technologie uměla, tak to není moc žádoucí (viz dále).
Ale on tam zadny evidentni stav neni (...)
Ale je. Že vy byste zrovna dělal něco, co by bylo OK je hezké, ale těžko to obecně zaručit.
... musim to delat po jednom - opakovat+k podepsani, opakovat+k podepsani...
Poznámka mimo k workflow: AFAIK Fio umožňuje transakci vytvořit a podepsat později. Tedy si je můžete vytvořit a podepsat později v dalším kole.
Vážně? Jaký problém by to mohlo způsobit?
Že na něco kliknete a dostanete divnou interní chybu (protože se to ověřuje na serveru, jak správně píšete), protože je to v divném stavu, už neexistuje atp. Ono by se to dalo ošetřit, aby se to chovalo nějak rozumně, ale bylo by dost pracné vychytat (a vůbec identifikovat!) všechny scénáře. Práce ve víc oknech je sice občas užitečná, ale náklady jsou velké, takže se to nevyplatí podporovat a než to mít blbě, tak je lepší to odstřihnout.
Stejného stavu můžete dosáhnout třeba tím, že budete mít otevřené okno v prohlížeči a mezi tím uděláte změnu z jiného prohlížeče nebo z internetového bankovnictví.
Pokud se přihlásím z jiného prohlížeče, původní session se odloguje (může odlogovat), v tom problém není. Asi jste chtěl napsat "mobilního bankovnictví" - to je teoreticky možné, ale ne až tak pravděpodobné.
-
Ono by se to dalo ošetřit, aby se to chovalo nějak rozumně, ale bylo by dost pracné vychytat (a vůbec identifikovat!) všechny scénáře. Práce ve víc oknech je sice občas užitečná, ale náklady jsou velké, takže se to nevyplatí podporovat a než to mít blbě, tak je lepší to odstřihnout.
Já teda žiju ve světě, kde je tohle default, nemusí se pro to dělat žádné speciální extra podpora, a ty případy, kdy to nefunguje (Tesco a některé banky) jsou výjimka a příšerné (OMG! si v Tescu otevřete do tabů 10 výrobků a seznamů, že si je prohlídnete a naházíte do košíku, a ono si to obsah košíku navzájem přepíše!)
-
PayPal každopádně nechce přiznat chybu - mám nějaké páky na to, aby to napravil? Nejsou to nijak závratné částky, ale nelíbí se mi, jak se k tomu staví.
Zkuste stížnost u regulátora, což je ČNB. V nejhorším odpoví že jim to nepřísluší.
-
Že na něco kliknete a dostanete divnou interní chybu (protože se to ověřuje na serveru, jak správně píšete), protože je to v divném stavu, už neexistuje atp. Ono by se to dalo ošetřit, aby se to chovalo nějak rozumně, ale bylo by dost pracné vychytat (a vůbec identifikovat!) všechny scénáře. Práce ve víc oknech je sice občas užitečná, ale náklady jsou velké, takže se to nevyplatí podporovat a než to mít blbě, tak je lepší to odstřihnout.
Váš původní komentář jsem chápal tak, že píšete o pohledu uživatele – tedy že uživatel nechce používat internetové bankovnictví ve více záložkách, protože by to dělalo z jeho pohledu zmatené věci. Pokud je problém s použitou technologií, pak samozřejmě chápu, že je to raději zakázané (není to zase tak častý use case, aby se vyplatilo to řešit). Možná větší problém, než uživatelský diskomfort, vidím v tomhle případě v tom, že tohle řešení bude špatně škálovat. Obecně je podle mne zrovna u IB řešení vícenásobného přístupu poměrně snadné, ale samozřejmě ne v případě, kdy tomu brání použitá technologie.
Pokud se přihlásím z jiného prohlížeče, původní session se odloguje (může odlogovat), v tom problém není. Asi jste chtěl napsat "mobilního bankovnictví" - to je teoreticky možné, ale ne až tak pravděpodobné.
Ano, chtěl jsem napsat mobilní bankovnictví. Pokud je problém jenom v tom, že server drží stav klientského GUI, je zbytečné bránit uživateli používat dvě různé session – z pohledu serveru by to byly dvě různé instance s odlišným stavem (pokud by stav byl skutečně svázán se session a ne přímo s uživatelským účtem).
-
Mohl by pomoct finanční arbitr:
https://finarbitr.cz/cs/
Ale pokud to jsou nějaké malé částky, tak bych se na to vybodnul.
-
Já teda žiju ve světě, kde je tohle default, nemusí se pro to dělat žádné speciální extra podpora...
Ano, matematici zkoumají i různé bizardní světy, ale nevím v tom, že by v takovém někdo žil :) Celou věc diktuje logika. Viz dále.
Pokud je problém s použitou technologií...
On je problém nejen s použitou technologií. Ale hlavně s logikou. Viz dále.
Obecně je podle mne zrovna u IB řešení vícenásobného přístupu poměrně snadné, ...
Ani smykem. Respektive, udělat to tak, aby to "nějak" spatlaně fungovalo opravdu jednoduché je. Ale v bankovnictví je třeba preciznosti a jasnosti. A udělat to pořádně je obtížné až nemožné. Viz dále.
Pokud je problém jenom v tom, že server drží stav klientského GUI, je zbytečné bránit uživateli používat dvě různé session – z pohledu serveru by to byly dvě různé instance s odlišným stavem (pokud by stav byl skutečně svázán se session a ne přímo s uživatelským účtem).
To typický naivní, začátečnická představa. A fatálně chybná. Začnu nejprve "klasickým" případem, kdy přistupujete v jedné session. Trik je v tom, uvědomit si, že tady není jeden stav, ale dva(*) stavy. Jeden stav databáze serveru a druhý stav UI (= to co má uživatel zobrazeno, v případě webu HTML elementy). Tyto stavy je třeba synchronizovat a je to práce UI aplikace - když pošle mutaci na backend, musí si zajistit občerstvení stavu tak, aby její stav reflektoval změny na serveru.
V případě, kdy pracujete ve dvou session paralelně, tak nastává problém. V session 1 něco změním, ale aplikace v session 2 to neví, tedy neaktualizuje svůj stav ze serveru a stavy se rozejdou. Do určité míry by to šlo řešit nějakým systémem push aktualizací, třeba GraphQL na tohle má subscriptions, nicméně to není automatické, je potřeba ty závislosti naprogramovat a tak se to používá spíš jen ve specializovaných případech. Pak se dá používat nějaký polling, ale ten zase bere prostředky navíc a stejně není stoprocentní, když uživatel "stihne kliknout" než se data zaktualizují.
Tedy v okamžiku, kdy se rozjedou stavy na klientovi a na serveru, máme problém. Někdo tu zmiňoval nákupní košík, ukáži to tedy na něm. Mějme košík, kde mám u položky akce "odstranit kus", "přidat kus", "nastavit počet kusů" a "odstranit položku". Dále je možno zaplatit.
Vezměme si teď následující scénáře:
A) Uživatel má v košíku 5ks, v jedné session položku odstraní, ve druhé klikne na "přidat kus". Tady je několik možností, kde každá dává smysl:
1) vyhodit chybu, že položka už neexistuje (detekce neplatné operace)
2) přidat položku a mít tam jeden kus (operaci definujeme jako "přidej 1 ks tohoto výrobku do košíku ať se děje co se děje")
3) přidat položku a mít tam celkem 6 kusů (podle toho, co uživatel viděl, než klikl)
Problém je v tom, že každý uživatel bude mít jiný, silný, názor na to, která cesta je správná a když se bude aplikace chovat jinak, bude nadávat. Úplně klasický případ tu předvedl Jenda:
(OMG! si v Tescu otevřete do tabů 10 výrobků a seznamů, že si je prohlídnete a naházíte do košíku, a ono si to obsah košíku navzájem přepíše!)
Třeba zmiňované Tesco se chová podle logiky v bodě 3 (košík viděl uživatel prázdný a přidal jednu položku => má tam tu jednu položku). Nicméně Jenda by chtěl, aby se to chovalo podle logiky v bodě 2. Jenže to by pak zase jiný uživatel přišel s tím, jak to, že se mu v košíku objevují položky, které tam neviděl... Žádné řešení není správné.
S ostatními operacemi budou vznikat další kolize, ale ty vám nechám k analýze za domácí úkol :) Proberu ještě jednu věc související s placením:
B) Řekněme, že mám možnost placení uloženou kartou. Tedy uživatel dojde na stránku shrnutí objednávky, potvrdí ji a ta se zaplatí. Ale co když mezi zobrazením stránky a jejím odkliknutím přidá do košíku ještě další položku? Pak odklikne nějakou objednávku (a cenu) a zaplatí jinou! A tady už jde do tuhého, tady jde o peníze, takže uživatelé si na vás hezky smlsnou. (Podobná věc se stala právě zakladateli tohoto vlákna - potvrdil něco jiného, než co měl na obrazovce.)
Tenhle případ by se samozřejmě dal řešit - například tak, že při odkliknutí potvrzení pošle klient na server i objednávku
a pokud nesouhlasí s tam uloženým stavem, vyhodí se chyba, kterou klient nějak ošetří, například aktualizuje stav a napíše informaci, že se změnil a je třeba potvrdit znovu. A pak tedy ještě musí řešit, že třeba uživatel něco odebral, tím se dostal pod minimum zvoleného druhu dopravy a je třeba zvolit nový druh dopravy, tedy jít ve flow o stránku / dvě zpět - samé složitosti.
Už je to hrozné dlouhé, takže abych to shrnul: Je možné udělat aplikace, které umožňují paralelní práci, aby "nějak" fungovaly. Pokud se v nich převážně čte a na konzistenci obsahu až tak nezáleží, tak to docela funguje bez většího množství práce (třeba zrovna Root). Jenže pak jsou aplikace, kde narážíte na docela nepříjemné problémy, které musíte ošetřovat. Jen se podívejte, na co jsme narazili u pitomého nákupního košíku.
Pokud to chcete ošetřit pořádně, tak musíte:
1) Identifikovat jednotlivé scénáře (Kolik jste jich identifikovali jen u toho jednoduchého košíku? A jste si jistí, že jste identifikovali opravdu všechny? Můžete to nějak verifikovat?)
2) Definovat, jak se mají řešit (ale vždycky bude někdo nadávat, že to máte blbě)
3) Naprogramovat
4) Otestovat
5) V nových verzích aplikace myslet, jestli tím nemůžete způsobit nějakou další kolizi, ošetřovat je plus na tu kopu už existujících scénářů dělat regresní testy
Tedy u složitější aplikace pěkná kopa práce navíc, často pro podporu minoritních use-cases a uživatelé vám budou stejně nadávat. Proto složitější aplikace jako třeba IB práci ve víc paralelních session typicky nepodporují.
*) Kdybych měl být precizní, tak těch kopií stavů je ještě víc, v různých cache, frontend mívá svůj uložený datový model, který pak reflektuje v UI, ale synchronizace těchto stavů problém není, ty základní a z našeho pohledu zásadní jsou dva.
-
Děkuji všem za odpovědi. Nakonec PayPal přiznal chybu a napsal, že peníze z chybné transakce mi pošlou zpět. Nevím, jestli kontaktovali příjemce a požádali ho o vrácení druhé platby, nebo to pošlou ze svého, každopádně jsem ale s verdiktem spokojený.
Sice to chvíli trvalo (asi týden, komunikace s roboty a poté se třemi lidmi), ale nakonec to dopadlo dobře. Ale kdybych si neudělal screenshot z platby, asi bych měl smůlu, jelikož informaci o tom, komu jsem peníze chtěl ve skutečnosti poslat, nikde u sebe asi uloženou neměli.
Díky všem!
-
On je problém nejen s použitou technologií. Ale hlavně s logikou. Viz dále.
S logikou žádný problém není. O čemž svědčí i to, že spousta e-shopů (na příkladu e-shopu jste to ukazoval) práci ve více záložkách zvládá.
Začnu od konce – potvrzení (třeba objednávky). Tam vůbec není co řešit, uživatel potvrzuje vždy to, co vidí. Logika je tedy jasná, implementovat se to dá různě.
S tím přidáváním a odebíráním položek v košíku to pro programátora může být složitější. Ale uživatelské rozhraní nemá navrhovat programátor, ale UX designer, a pro něj jsou dvě možná řešení. To lepší řešení je, že se stav košíku bude na pozadí synchronizovat – takže když odeberu zboží v jedné záložce, odebere se i ve všech ostatních. Druhé řešení, z hlediska UX o něco horší ale zase jednodušší na implementaci, je to, že uživatel vždy pracuje s tím, co vidí. Takže když má v košíku pět kusů, zduplikuje záložky, v jedné záložce pět kusů ubere a v druhé záložce jeden kus přidá, bude mít v té druhé záložce v košíku šest kusů. Nikdy žádný uživatel nepředpokládá, že když vidí v košíku 5 kusů a klikne na tlačítko „+“, že dostane chybovou zprávu nebo že bude mít v košíku 1 kus.
Trochu komplikovanější implementace to bude akorát v případě, kdy přidání do košíku znamená rezervaci daného zboží (tj. máte po určitou dobu garanci, že zboží, které máte v košíku, vám nikdo „nevyfoukne před nosem“). Nicméně i tam musí být zachováno pravidlo, že pokud uživateli zobrazuji v košíku rezervaci, musí ta rezervace opravdu platit.
Takže pokud to chcete udělat opravdu pořádně, je to poměrně jednoduché. Nenechávejte uživatelské scénáře vymýšlet backendové programátory, ale nechte to na UX designerech. Ti navrhnou velmi jednoduchá pravidla, kterými se bude UI řídit. Díky tomu, že budou jednoduchá, budou je chápat i uživatelé a budou spokojení. Přičemž nejdůležitější z těch pravidel bude „platí to, co uživatel vidí“.
Přičemž v porovnání s e-shopem je běžné internetové bankovnictví jednodušší, protože v IB není ta zásadní limitace e-shopu, totiž sklad s fyzickým stavem zboží, navíc uživatelé považují za samozřejmé, že se s bankou pracuje v transakcích. Takže když má uživatel na účtu 100 000 Kč a dá příkaz k úhradě 5 000 Kč, očekává jen to, že se úhrada provede, pokud má na účtu dost peněz. Ale neočekává, že po provedení toho příkazu bude na účtu 95 000 Kč – protože ví, že mezitím může přijít příchozí platba nebo odejít jiná odchozí platba. Takže jediné, co se od banky očekává, je to, že seřadí požadavky nějak za sebe, u každého požadavku zkontroluje, zda je možné jej provést, provede ho, aktualizuje stavy a pokračuje na další požadavek. Konkrétně – pokud uživatel ve dvou session zadá dva příkazy k úhradě ale má nízký zůstatek účtu, takže není možné provést oba dva příkazy, není to nic, s čím by se banka neuměla vypořádat. Protože to samé může nastat i tak, že uživatel zadá jediný příkaz k úhradě, ale než ho stihne podepsat, zůstatek na účtu se sníží. A to samé může nastat i úplně bez internetového bankovnictví. Takže banky tyhle „problémy“ umí řešit už stovky let. Naopak svět IT se v mnohém inspiroval v tom, jak to dříve banky řešily „na papíře“.
-
podobny problem se mi stal pri objednavani letenek. Potreboval jsem objednat vic letu a mit jistotu, ze po tom, co objednam prvni 3 se neukaze, ze ctvrty se nepodari objednat. Tak jsem ve 4 tabech otevrel 4 objednavky, ve vsech jsem dosel az pred zaplaceni a teprve potom jsem je vsechny potvrdil a zaplatil. Udelalo to takovy neuveritelny bordel, ze jsem pak stravil 2 hodiny na telefonu s tou spolecnosti (easyjet), abych to dal do poradku, pricemz mi nekolikrat zduraznovali, ze mi delaji velkou laskavost, protoze za normalnich okolnosti kazda zmena stoji 20 euro. V podstate kdybych to vsechno objednal znovu a ty puvodni listky vyhodil, bylo by to levnejsi. Ale nastesti ty zmeny nakonec udelali zadarmo, ovsem nebyli ochotni uznat, ze to byla chyba jejich rezervacniho systemu. Dokonce me nutili namluvit na jejich zaznamnik, ze to byl muj omyl, ze jsem tam zadal spatna data. Takze stylem "chytra horakyne" jsem jim tam namluvil, ze to byl muj omyl otevrit vsechno najednou a objednat to takhle. Nastesti jim to stacilo. Asi i oni me uz meli plne zuby :-)
S paypalem jsem parkrat jednal z pozice vyvojare, nakonec to dopadlo tak, ze paypal v nasem produktu nepodporujeme. Po tom, co jsem cetl, jak Prusovi (3d tiskarny) zablokovali ucet s radove milionem dolaru, jsem o nich ztratil veskere iluze.
-
Já mám také špatnou zkušenost s podporou PayPalu, a to jsem ho ani nepoužil já, jen mě za nimi poslala podpora eBaye. Platil jsem na eBayi kartou za zboží z UK a zvolil jako měnu transakce GBP - rozdíl jejich kurzu oproti mojí bance dělal asi 6 800 vs 6 500 CZK. Měl jsem to potvrzené v emailu, ale z karty se mi strhlo přímo těch 6 800 CZK.
Po opravdu hodně dlouhé a natvrdlé výměně emailů se mi dostalo toho, že mi připsali na PP účet 15 USD jako "jednorázový projev dobré vůle i přesto, že absolutně vůbec nic ani v nejmenším není s jejich systémem v nepořádku". Pak jsem to už vzdal.
Na té podpoře ty emaily ani nečetli, téměř vždy jen odpověděli s nějakým zkopírovaným textem na irelevantní téma.
-
...
Už je to hrozné dlouhé, takže abych to shrnul: Je možné udělat aplikace, které umožňují paralelní práci, aby "nějak" fungovaly. Pokud se v nich převážně čte a na konzistenci obsahu až tak nezáleží, tak to docela funguje bez většího množství práce (třeba zrovna Root).
...
Celkovo velmi dobry komentar a pacila sa mi ta poznamka o Root-u, lebo velmi vystizna, ze to docela funguje, lebo aj tu sa da najst pekny priklad toho ako to nefunguje(funguje).
Moj bezny scenar navstevy Root-u.
1.Cez RSS citacku si otvorim zaujimave nove clanky alebo v diskusii zaujimvave temy v roznych taboch.
2.Postupne prechadzam taby a citam si ich.
3.V niektorom chcem pridat do diskusie moj nazor, tak sa musim prihlasit(bohuzial).
4.V aktualnom tabe kliknem na prihlasit. Zadam meno a heslo a prihlasim sa.
5. Po prihlaseni sa stane to, ze v aktualnom tabe mi nezobrazi stranku, na ktorej som bol pred prihlasenim ale stranku z posledneho tabu, ktory som otvoril.
Za mna jednoznacna chyba, aj som to uz celkom davno hlasil.
Takze sa vobec necudujem, ze to niektorych strankach nefunguje :)
-
Celkovo velmi dobry komentar a pacila sa mi ta poznamka o Root-u, lebo velmi vystizna, ze to docela funguje, lebo aj tu sa da najst pekny priklad toho ako to nefunguje(funguje).
Moj bezny scenar navstevy Root-u.
1.Cez RSS citacku si otvorim zaujimave nove clanky alebo v diskusii zaujimvave temy v roznych taboch.
2.Postupne prechadzam taby a citam si ich.
3.V niektorom chcem pridat do diskusie moj nazor, tak sa musim prihlasit(bohuzial).
4.V aktualnom tabe kliknem na prihlasit. Zadam meno a heslo a prihlasim sa.
5. Po prihlaseni sa stane to, ze v aktualnom tabe mi nezobrazi stranku, na ktorej som bol pred prihlasenim ale stranku z posledneho tabu, ktory som otvoril.
Za mna jednoznacna chyba, aj som to uz celkom davno hlasil.
Takze sa vobec necudujem, ze to niektorych strankach nefunguje :)
Pokud vím, takhle se chová SMF, které se používá pro zdejší fórum. SMF se chová divně v mnoha případech… A zrovna tohle se normálně řeší tak, že součástí odkazu na přihlašovací stránku je i návratová URL, tedy adresa, odkud jsem na login šel. Proč SMF nepoužívá tenhle standardní způsob, ale řeší to jinak, to ví asi jenom jeho autoři.
-
Já teda žiju ve světě, kde je tohle default, nemusí se pro to dělat žádné speciální extra podpora...
Ano, matematici zkoumají i různé bizardní světy, ale nevím v tom, že by v takovém někdo žil :) Celou věc diktuje logika. Viz dále.
To nebyl popis nějakého hypotetického bizarního světa. To je doslova ~14 let zkušeností z používání a trochu i vývoje všech možných webových aplikací, od Frantova eshopu s ponožkama přes Adminer po Alzu. Všude práce ve více tabech „prostě funguje“, je logická a ke konfliktům nedochází. Je to tak běžné, že když to někde nefunguje, tak je to opravdu výjimka a příšernost. Bohužel se toto děje čím dál častěji v posledních 5 letech -- místo toho, aby se technologie vylepšovala, tak se to naopak zhoršuje. „Nejlepší“ jsou různá javascriptová tlačítka a další prvky, takže ten nový tab z toho nejde otevřít.
Začnu od konce – potvrzení (třeba objednávky). Tam vůbec není co řešit, uživatel potvrzuje vždy to, co vidí.
Tak on tohle hlavně není use-case, který by uživatelé dělali. Use-case eshopu je, že si v 10 tabech pootvírám různé produkty, překlikávám mezi jejich popisy, pak si nějaké z nich naházím do košíku (v těch tabech) a pak už dělám checkout samozřejmě „lineárně“. Jediné, kdy tohle může být problém, je, když je to firemní účet a dva zaměstnanci současně se snaží udělat různé objednávky. Teď mi došlo, proč má tme.eu na první pohled tak šíleně komplikovaný systém „otevřených objednávek“ a ne jeden košík jako běžné eshopy -- umožňuje to přesně tuhle práci.
Takže když má v košíku pět kusů, zduplikuje záložky, v jedné záložce pět kusů ubere a v druhé záložce jeden kus přidá, bude mít v té druhé záložce v košíku šest kusů. Nikdy žádný uživatel nepředpokládá, že když vidí v košíku 5 kusů a klikne na tlačítko „+“, že dostane chybovou zprávu nebo že bude mít v košíku 1 kus.
Já bych jenom chtěl vyjasnit, že u toho Tesca je to horší než jste to asi pochopili: já očekávám, že když mám v košíku 2 květáky a 2 cibule a v jiném tabu (s prázdným košíkem) přidám cibuli, tak pak můžu mít 3 nebo 1 cibuli -- protože netuším, jestli ten eshop pošle „increment“ nebo „set“. A to je v pořádku, opět není use-case, že mám v několika tabech stejný produkt a přidávám ho do košíku. Jenže to Tesco nastavuje s každým požadavkem celý košík! Takže mi odstraní květáky! A nebo naopak se v košíku objeví věci, které jsem už v jiném tabu odstranil. To celé je navíc okořeněné tím, že zatímco v jiných obchodech člověk typicky kupuje pár věcí, tak tady je toho klidně stovka (typicky dělám nákup potravin na 2-3 týdny), takže spousta toho je odscrollovaná někam kde si té nehody nevšimnu.
Přičemž nejdůležitější z těch pravidel bude „platí to, co uživatel vidí“.
No ale jenom u toho jednoho produktu co právě modifikuju (pokud to nemá tu synchronizaci na pozadí, což je opruz navíc naprogramovat): jinak se stane to Tesco: mám prázdný košík, otevřu tab s cibulí, tab s květákem a tab s máslem, v každém přidám jeden kus, a výsledkem je, že v košíku mám 1 máslo.
-
Jediné, kdy tohle může být problém, je, když je to firemní účet a dva zaměstnanci současně se snaží udělat různé objednávky. Teď mi došlo, proč má tme.eu na první pohled tak šíleně komplikovaný systém „otevřených objednávek“ a ne jeden košík jako běžné eshopy -- umožňuje to přesně tuhle práci.
V drtivé většině e-shopů je košík naopak vázaný na session a ne na uživatele. Takže si na jednom počítači nahážete zboží do košíku, přejdete na jiný počítač a tam v košíku nic není.
Přičemž nejdůležitější z těch pravidel bude „platí to, co uživatel vidí“.
No ale jenom u toho jednoho produktu co právě modifikuju (pokud to nemá tu synchronizaci na pozadí, což je opruz navíc naprogramovat): jinak se stane to Tesco: mám prázdný košík, otevřu tab s cibulí, tab s květákem a tab s máslem, v každém přidám jeden kus, a výsledkem je, že v košíku mám 1 máslo.
Souhlas, tak to bylo myšleno – pokud uživatel něco edituje, je výsledný stav editované položky to, co uživatel vidí.
Mimochodem, na té synchronizaci dnes není nic složitého – košík může být uložen v localStorage, které je synchronizované napříč taby a při změně posílá události.
-
tak to bych rekl, ze to ma drtiva vetsina rozbity, jeste ze chodim asi na nejaky mensinovy eshopy.
pritom to muze bejt celkem i obchodni prilezitost, uz se mi stalo ze mi eshop napsal: zri, na kosikovane veci mame zrovna slevu. nebyl to teda cesky eshop.
-
Z vlastní zkušenosti vím, že při řešení problému s PayPalem je třeba být neústupný a když nic jiného nepomůže, tak pohrozit tím, že přestanete PP používat a každému na potkání řeknete o tom, co to je za zmetky :). Pak se problém najednou třeba i dá vyřešit. Je ale fakt, že ta komunikace je dost únavná, na každou odpověď je třeba čekat řádově hodiny a pokaždé odpoví někdo jiný, ale holt nic není zadarmo.