@Slamb co si o tom myslí Google :-)

Pomalost moderních telco samoobsluh není dána tím, že by nezvládal samotný frontend v prohlížeči nebo v telefonu, ale architekturou integračního řetězce na pozadí. Když uživatel otevře dashboard nebo klikne na změnu balíčku, systém neprovádí jeden SQL dotaz do jedné databáze, ale spouští komplexní orchestraci napříč desítkami let starými i novými systémy.

Hlavní technické příčiny, proč to v praxi drhne:

1. Extrémní fragmentace backendu a distribuované dotazy

K zobrazení jediné úvodní obrazovky (přehled čísel, zbývající data, dlužná částka, aktivní roaming, stav objednávky) musí API gateway/BFF agregovat data z mnoha heterogenních systémů:

• Online Charging System (OCS) / PCRF: dotaz na aktuální zůstatek jednotek v reálném čase.

• Billing engine (např. Amdocs / Netcracker): fakturační cyklus a zúčtovací období.

• SAP FI-CA / RM-CA: finanční saldo, stav plateb a otevřené položky.

• CRM (Salesforce / Amdocs): klientský strom, role, oprávnění a smluvní závazky.

• Provisioning & Inventory (OSS): technické parametry SIM / eSIM, stav sítě.

Pokud se tato volání řetězí sekvenčně nebo na ně BFF čeká paralelně, celková latence odpovědi odpovídá nejpomalejšímu článku řetězce (často zatížený interní mainframe, legacy SOAP webová služba nebo stará databáze běžící za firewallem).

2. Nelze agresivně cachovat (paradox reálného času)

U běžného e-shopu se produktový katalog a statická data nacachují na CDN a odezva je v milisekundách. U telekomunikační samoobsluhy:

• Uživatel očekává okamžitý stav: spotřebovaná data po dokoupení balíčku, zaplacená faktura kartou, změna roamingu před odletem.

• Pokud by aplikace data cachovala déle než pár sekund, uživatel po provedení akce neuvidí změnu, klikne znovu nebo volá infolinku.

• Každé obnovení stránky tak často propadne skrz CDN až na fyzické backendy, které nejsou dimenzované na webový concurrency provoz statisíců paralelních uživatelů.

3. Masivní integrační mezivrstvy (ESB / API Gateway bloat)

Data netečou napřímo. Po cestě z mobilní aplikace do jádra systému leží:

• Web Application Firewall (WAF) a API Gateway,

• Identity & Access Management (validace JWT / OAuth tokenů, kontrola scopes a oprávnění pro každé volání),

• Podniková sběrnice (Enterprise Service Bus – např. MuleSoft, Tibco nebo IBM), která provádí transformace z moderního JSON do obstarožního XML/SOAP, mapuje datové modely a validuje schémata.

Každý takový mezikrok přidává deserializaci, síťový hop a serializaci, což při 5–10 interních voláních na jednu obrazovku snadno nasčítá latenci přes 1,5 až 3 sekundy.

4. Transakční rigoróznost a CPQ validace při změnách

Zatímco pouhé čtení je pomalé kvůli agregaci, jakákoli změna služby (objednávka balíčku, změna tarifu) je výpočetně brutální:

• Telco CPQ (Configure, Price, Quote) enginy musí v reálném čase vyhodnotit matice závislostí: Je tento balíček kompatibilní s tarifem X? Nemá klient starou generaci SIM? Má zapnutou službu Y, která vylučuje Z? Nemá neuhrazenou fakturu v SAPu?

• Následně se spouští dvoufázové commity, zápis do CRM, vytvoření objednávky v Order Managementu, odeslání požadavku na aktivaci do HLR/HSS v síti a založení položky v účtovacím systému. Celý tento proces je navržen na 100% transakční integritu, nikoli na nízkou latenci.

5. Masivní "Over-fetching" na frontendu

Moderní frontendy (často postavené v těžkých frameworcích s mnoha vrstvami abstrakce) stahují megabajty JavaScriptu a následně z klienta odpalují desítky paralelních asynchronních požadavků na různé endpointy. Pokud mobilní zařízení běží na horším signálu nebo má slabší procesor, kombinace parsování objemných JSONů, re-renderování DOMu a čekání na zpožděné API hovory vytváří dojem zamrzající a těžkopádné aplikace.

nj, to by bylo na víc než jenom na novou webovou samoobsluhu 😔 na druhou stranu pořád platí, že máme třikrát dražší mobilní služby než jinde v evropě, tak by snad bylo z čeho to zaplatit, navíc v dnešní době AI by nemuselo bejt tak hrozný to všechno zvládnout 🤔 jenomže vodafone frčí na službách microsoftu a nejsem si jistej, jak moc schopnej je ten copilot ve vývoji, zatim sem to po předchozích zkušenostech s jinejma záležitostma nenašel odvahu zkoušet 🤔 ale když do dneška nikoho nenapadlo ani dát blbej autofocus na políčko pro zadání dvoufázovýho ověřování, tak bude lepší nepouštět se do žádnejch větších akcí 😐 radši ať ty prachy daj na kostel a třeba nějakej bůh tu sámošku bude aspoň ochraňovat před zhroucením (a její uživatele taky) 🤔

@Slamb K tomu „autofocusu na políčko pro zadání dvoufázového ověřování“... Není to tak, že by to někoho nenapadlo. Automatické umístění kurzoru do prvního políčka může komplikovat používání stránky lidem, kteří využívají čtečky obrazovky. Při návrhu proto musíme zohledňovat pravidla digitální přístupnosti, která vycházejí mimo jiné i z legislativních požadavků Evropského aktu o přístupnosti (EAA). Jinými slovy, nejde o zapomenutou funkci, ale o záměrné řešení s ohledem na přístupnost.

@Ondra - Vodafone Pane Ondro a proč to třeba jde u přihlášení u T-M a u O2 (osobně vyzkoušeno)? Oni tohle jako vy nemusí dodržovat?

@Ondra - Vodafonezeptal sem se clauda, aby udělal analýzu tý 2FA stránky přímo u vodafonu, a závěr je, že by to jít mělo 🤔 bylo to trochu víc textů, tak tady je stručnej souhrn:

1. Fokus nastavit skriptem, ne atributem autofocus. Nativní autofocus se u SPA při výměně obsahu nespouští spolehlivě, takže po vykreslení kroku 2FA zavolat pin0.focus().

2. Počkat na cookie dialog. Fokus dát až po jeho zavření (nebo hned, pokud už je odsouhlasený), jinak fokus utíká pod dialog.

3. Kontext navázat na pin0: aria-describedby="t hint", kde t je ID H1 a hint ID odstavce s instrukcí a číslem telefonu. U SPA se <title> neoznámí, takže tohle je jediný zdroj kontextu.

4. Ponechat to, co už funguje: fieldset + skrytá legend, aria-label „Číslice X ze 6“, inputmode="numeric", autocomplete="one-time-code".

5. Opravit chybovou oblast: role="alert" bez aria-live="polite" (ten ho zeslabuje).

6. Po špatném kódu: nastavit aria-invalid="true" na pole, naplnit alert textem chyby a vrátit fokus na pin0.

7. Mobil: autofocus vyvolá klávesnici. Tady to pomáhá, protože pole je nahoře a kód se nabídne z SMS.

8. Otestovat v NVDA (Firefox/Chrome) a VoiceOveru. Já jsem to ověřil jen v DOMu, ne se skutečnou čtečkou.

Pozor na jednu věc: bod 3 jsem odvodil z toho, že se krok odesílá přes XHR. Pokud by přechod nakonec byl plné načtení, <title> se oznámí a bod 3 se zjednoduší na samotnou instrukci (aria-describedby="hint").

Dobrý den,

cca poslední měsíc mám problém s příhlášením do Můj Vodafone. Po přihlášení mi to píše stejnou hlášku, jako je na začátku tohoto vlákna. Zkoušel jsem to v mobilní aplikaci i na PC. Na infolince mi moc neporadí, dá se to nějak řešit?

@Tomasm23 Pěkný den, mohu potvrdit, že o plošné potíže se nejedná. Pošlete nám prosím screenshoty postupu na e-mailovou adresu pece@vodafone.cz. Do e-mailu nezapomeňte uvést více podrobností a také číslo některé ze služeb (nebo číslo plátce) a ideálně také 1. a 3. pozici z číselného hesla administrátora. Prověříme to. Veronika

@Tomasm23 Ještě před odesláním e-mailu prosím zkontrolujte, zda nemáme aktivní VPNku.

Nejedná se o plošný problém? Zajímavé. :-) :-) Zákazníci jsou neplatící testeři nebo to mám chápat jak? Stačí se podívat na předešlou stránku. Aktuálně jsme tři, co vím jenom tady. Asi tam bude nějaký problém.

Sorry, ale prostě takhle to určitě nejde a nemělo by být, aby zákazník (v tomto případě já) strávil na lince 30 minut, řešili jsme to, nevyřešili jsme nic, následně další telefon 15 minut a vyřešila se jenom mobilní aplikace. Nechcete screenshoty, nechcete videa, zákazníku je to tvůj problém u tebe, vyřeš si ho jak chceš.

Mě tedy dnes aplikace po zadání kódu z SMSky se vrátí zpět na zadání přihlašovacích údajů a aplikace nefunguje. V prohlížeči mi to funguje.

Na mobilní appku by melo pomoct jí odinstalovat, znovu nainstalovat, případně smazat data a paměť té appky.