Vissza a Journal-hoz
adminhu

Mobil-admin: mit tud es mit nem

Tablet majdnem mindent tud, telefon 5 specifikus action - es miert vettuk ki a drag-and-drop reorderinget mobilon ket honap UAT utan.

A Netorigo Admin nem egy mobil-elsodleges termek. Egy ERP-rendszer adminisztracioja altalaban asztali kepernyon zajlik, sok ablakkal, multi-column nezeteket. De van ket valos use case, ahol a mobil-elerheteseg nem opcionalis: (1) a tenant-tulajdonos vasarnap delelott egy gyors megerositest tudjon adni egy nagy rendelesre, es (2) a logistics-felhasznalo a raktarban scaneljen. Ezt a ket use case-et celzottan tamogatjuk, a tobbit nem.

Tablet: elsorendu allampolgar

10 colos vagy nagyobb tablet (iPad, Android tablet) majdnem mindent kezel, ami az asztalon mukodik. A breakpoint a Tailwind md (768 px) felett van. A multi-column listak (peldaul a rendelesek tablazata) keskenyebb oszlopokkal, a sidebar collapsible-ve valik. A katalogus-szerkesztes mukodik, a brand-szerkeszt mukodik, az audit-log szuro mukodik. Egyetlen kivetel: a riport-szerkeszto (drag-and-drop widget-elrendezes) nem mukodik tableten, csak desktop.

A UAT-ban hasonlitottuk az iPad Air 11" + Magic Keyboard kombinaciot egy laptop-tal: a feladatok 86%-ban mindketto egyforman gyors, 14%-ban (foleg multi-window workflow-knal, peldaul "a rendelest egyik tabban, a vasarlot a masikon") a laptop gyorsabb.

Telefon: 5 specifikus action

Mobil telefonon (375 px - 640 px szelesseg) az admin react-ja egy keszult-kepernyot mutat alapertelmezesben, amely 5 muveletet enged:

  1. Rendeles jovahagyasa - egy pending order megerositese (egy gomb, swipe-to-confirm interakcioval, hogy veletlenul ne kattintsanak)
  2. Rendeles megszakitasa - hasonloan swipe-to-cancel
  3. Visszateritlt indtasa - reszbeni vagy teljes refund (osszeg-input + indok-dropdown)
  4. Komment hozzaadasa - a rendeleshez vagy a vasarlohoz egy belso jegyzet
  5. Push-ertesites kuldese - a vasarlonak (web push vagy SMS, ha a tenant beallitotta)

Minden mas oldalra navigalas eseten a felhasznalo egy "Ez a funkcio nem optimalizalt mobilra" overlay-t lat, ket gombbal: "Folytatas mobilban" (a desktop UI-t kapja zsugorítva, hasznalhato de nem szep) vagy "Email link kuldese" (a sajat email-cimere kuldi az oldalt, hogy desktopon folytassa).

Ez a megszoritas szandekos. Egy proba-fazisban (2025 Q4) mindent mobilrendezett: a katalogus-szerkesztes mobilon olyan nehez volt, hogy 18%-os support-ticket-novekedest okozott. A korlatozott mobil-UI azt biztositja, hogy csak az kerul mobilra ami valoban kenyelmes.

Touch-target meretek

44 px minimum touch-target (Apple HIG ajanlas), 48 px az alapertelmezett (Google Material). A formok input-mezoi 56 px magasak (kenyelmesen kattinthatoak nagy ujjakkal is). A gombok kozott minimum 8 px ures hely.

A bottom-sheet pattern: a modalok nem teljes kepernyot toltik be mobilon, hanem alulrol felcsuszo bottom-sheet-ek. Ez gyorsabban bezarhato (swipe-down), es a felhasznalo egyik kezzel is hasznalhatja a hivelykjevel.

Offline-aware service worker

A service worker az utolso 10 megnyitott oldalt cache-eli (asset-eket es API-valaszokat is). Ha a felhasznalo a raktarban egy gyenge wifi-vel megnyit egy oldalt, majd a wifi elesik, a mar latott oldalakat tudja gorgetni. Iras (rendeles modositas, stb.) ekkor egy queue-be kerul, es a wifi visszajavulasakor (a navigator.onLine listener-rel) automatice retry-ozodik. A UI mutat egy "Offline mod, 3 valtoztatas varakozik" badge-et.

Ezt nem hasznaljuk minden modulra, csak a logistics_picker szerepre, ahol a hasznalat a raktarban tortenik es a wifi-stabilitas nem garantalt.

Mit vettunk ki: drag-and-drop reordering

A kategoria-fa egy idoben drag-and-drop-pal volt rendezheto. Mobilon ez katasztrofa volt: a long-press hatasara megnyilt a context-menu, a kategoria mozgatasakor a scroll is megindult, es a final drop helye gyakran a rossz parent-be esett. Ket honap UAT-feedback utan visszavettuk: most a kategoriaknak fel/le nyilbillentyu-gombjuk van. Egyszerubb, lassabb, de nem hibazik.

A drag-and-drop desktopon megmaradt, mert ott tokeletes UX.