Mobil ilovalarda xato xabarlarini dizayni foydalanuvchi qayerda xato qilayotganini, nima qilish kerakligini va muammo qay darajada jiddiy ekanini tez tushunishini ta’minlashi kerak. Buning uchun matn, vizual ierarxiya va texnik mexanizm (xato kodi, qayta urinish, log) bir-biriga mos bo‘lishi lozim.
Quyida xato xabarini loyihalashda tekshirib bo‘ladigan qoidalar, formatlar va amaliy tanlash mezonlari keltiriladi. Maqsad — “qulay” kabi umumiy so‘zlarsiz, aniq qaror qabul qilish imkonini berish.
1) Xato xabari maqsadini aniq ajrating: foydalanuvchi, tizim, integratsiya
Xato xabarlari kamida 3 toifaga ajratiladi: foydalanuvchi xatosi (masalan, noto‘g‘ri kiritish), tizim xatosi (masalan, server vaqtinchalik nosoz), va integratsiya/ta’minot xatosi (masalan, to‘lov provayderi). Har bir toifa uchun matn uslubi va tugmalar (Qayta urinish, Bosh sahifaga qaytish) boshqacha bo‘ladi.
Amaliy qoida: har bir xato uchun “kelib chiqish manbai” ni saqlang — input validatsiya (client), API javobi (server), tarmoq (network), yoki kutilmagan holat (unknown). Shunda UI xabarni xuddi shu manbaga bog‘lab render qiladi.
- Foydalanuvchi xatosi: “Nima noto‘g‘ri?” + “Qanday to‘g‘rilash?”
- Tizim xatosi: “Nima bo‘ldi?” + “Nima qilsa bo‘ladi (kutish/qayta urinish)?”
- Integratsiya xatosi: “Nima bilan bog‘liq?” + “Qanday yo‘l bilan davom etiladi (boshqa usul, qo‘llab-quvvatlash)?”
2) Matn shablonlari: “qisqa, aniq, harakat bilan” formulasi
Xato matnida uchta bo‘lak bo‘lsa yaxshi natija beradi: muammo (1 gap), ta’sir/oqibat (ixtiyoriy 1 gap), harakat (1 gap). Matn umumiy “xatolik yuz berdi” bo‘lsa, foydalanuvchi keyingi qadamni o‘zi topishi kerak bo‘ladi; bu esa UI/UX samaradorligini pasaytiradi.
Quyidagi shablonlar dizayn tiliga aylanishi uchun “bir xil ko‘rinish” va “bir xil tartib” saqlanishi kerak.
- Validatsiya (input): “Telefon raqami formatini tekshiring. Masalan, 998 90 123 45 67.”
- Autentifikatsiya: “Kod noto‘g‘ri yoki muddati tugagan. Yangi kod so‘rang.”
- Tarmoq: “Internet aloqasi yo‘q ko‘rinadi. Qayta urining yoki Wi‑Fi’ga ulang.”
- Server: “So‘rov vaqtida xatolik yuz berdi. 1 daqiqadan so‘ng qayta urining.”
- Ruxsat: “Sizga bu amal uchun ruxsat berilmagan. Profil sozlamalarini tekshiring.”
3) Vizual ierarxiya: rang, icon va joylashuvni tizimli qiling
Xato xabari dizayni faqat matn emas. Foydalanuvchi xatoni skanerlash orqali topishi uchun rang (masalan, semantik “xato” rang), ikon (masalan, ogohlantirish belgisi) va joylashuv (kirish maydoni yonida yoki umumiy banner sifatida) oldindan kelishilgan bo‘lishi kerak.
Amaliy qoida: input bilan bog‘liq xatoni faqat umumiy toastga tashlab yubormang. Masalan, “parol kam” xatosi login formadagi parol maydoni ostida ko‘rsatilsa, foydalanuvchi tuzatishni tez qiladi.
- Maydonga bog‘liq xato: maydon ostida, 1 qatorli matn, ikon va aniq sabab.
- Maydonga bog‘liq bo‘lmagan xato: ekranning yuqori qismi yoki markazida banner/modal, matn + harakat tugmasi.
- Kutilmagan xato: foydalanuvchiga sokin ohangda xabar, “Qayta urinish” bilan.
4) Xato kodlari va matn o‘rtasidagi bog‘lanish: UI har doim “to‘g‘ri sabab”ni ko‘rsatsin
Dizayn darajasida xato matnini “server qaysi kod qaytardi” bilan bog‘lash kerak. Aks holda UI noto‘g‘ri xabar chiqarishi mumkin (masalan, tarmoq muammosi o‘rniga “foydalanuvchi xatosi” aytiladi).
Amaliy model: API javobida kod bo‘lsa, UI uni xaritada matnga aylantiradi. Bu xarita versiyalanishi va test bilan tekshirilishi kerak.
- UI mapping: error_code → matn shabloni + tugma turi.
- Log mapping: xato kodi + kontekst (request id, user id emas, balki anonim identifikator).
- Fallback: kod yo‘q bo‘lsa, “unknown” shablon, lekin “Qayta urinish” bo‘lsin.
5) TARIX: HTTP kodlaridan boshlangan yondashuv va mobil dizaynga moslash
Xato xabari g‘oyasi tarmoq protokollaridan olingan: vebda HTTP status kodlari (masalan, 4xx va 5xx) 1990-yillardan beri resurs so‘rovi natijasini standartlashtirishga yordam beradi. Mobile ilovalarda ham shunga o‘xshash tamoyil kerak: foydalanuvchi ko‘radigan xabarni “status kod” yoki “error_code” asosida shakllantirish.
Quyidagi ajratish amaliyotda ishlaydi: 4xx odatda foydalanuvchi so‘rovi noto‘g‘ri yoki ruxsatsiz bo‘lishini bildiradi; 5xx odatda server tomoni vaqtincha nosozligini anglatadi. Lekin UI “aniq harakat”ni baribir alohida belgilashi kerak.
| Toifa | Misol (HTTP) | UI xabari yo‘nalishi | Tavsiya etilgan tugma |
|---|---|---|---|
| Foydalanuvchi xatosi | 400 (Bad Request) | “Kiritishni tekshiring” + maydon bo‘yicha yo‘naltirish | — (shaklni tuzatish) |
| Autentifikatsiya/ruhsat | 401 / 403 | “Kirish sessiyasi tugagan” yoki “ruxsat yetishmaydi” | “Kirishga o‘tish” / “Profil sozlamalari” |
| Tizim xatosi | 500–504 | “Serverda vaqtinchalik xatolik” + qayta urinish | “Qayta urinish” |
| Tarmoq/ulanish | — (HTTP kelmaydi) | “Internet aloqasi yo‘q” | “Qayta urinish” |
6) ISHLASH MEXANIZMI: xato paydo bo‘lishi, tan olinishi va render tartibi
To‘g‘ri mexanizm 4 bosqichdan iborat: (1) request holatini boshqarish, (2) javobni status yoki error_code bo‘yicha ajratish, (3) UI uchun semantik “xato turi”ni hisoblash, (4) foydalanuvchiga ko‘rsatiladigan komponentni tanlash. Bu tartib UI va backend o‘rtasida “mos kelish”ni kafolatlaydi.
Amaliy tartib (ketma-ket tekshirish): agar input valid bo‘lmasa, client-side validatsiya xabarini ko‘rsat; aks holda request yuboriladi; javob kelganda status/xato kodi bo‘yicha mapping qilinadi; agar response umuman kelmasa, tarmoq xatosi shabloni tanlanadi.
- Input validatsiyasi: maydon darajasida xato chiqarish (masalan, “parol uzunligi 8 dan kam”).
- Request: so‘rov yuborilganda “yuklanmoqda” holatini ko‘rsatish.
- Javob:
- 4xx → foydalanuvchi/ruhsat bo‘yicha shablon.
- 5xx → server vaqtinchalik xatolari shablon.
- Response ichida error_code bo‘lsa, aynan shunga tayanish.
- Response yo‘q (timeout, tarmoq uzilishi) → tarmoq shabloni + qayta urinish.
7) Amaliy sozlash: qayta urinish, time-out va toast/modal tanlovi
Qayta urinish tugmasi har doim “chaqirib qayta sinab ko‘rish” degani emas. Ba’zi xatolarda takrorlash foydasiz (masalan, noto‘g‘ri so‘rov formati). Ba’zi hollarda esa sinash kerak (masalan, server 503). Shuning uchun “qayta urinish siyosati”ni xato turiga bog‘lang.
Quyidagi jadval UI siyosatini aniq belgilash uchun xizmat qiladi: har bir xato turiga ketma-ket qayta urinish soni va kutish qoidasi beriladi.
| Xato turi | Qayta urinish (maks) | Kutish | UI komponent |
|---|---|---|---|
| Tarmoq uzilishi | 2 ta | 1 soniya, keyin 3 soniya | Banner yoki full-width toast |
| Server 503/504 | 2–3 ta | 2 soniya va keyin 5 soniya | Modal (kuchli xabarlarga), aks holda banner |
| Validatsiya (400 tip) | 0 ta | — | Maydon osti xabari |
| Autentifikatsiya (401) | 0 ta | — | “Kirish”ga qaytish tugmasi |
- Toast faqat qisqa va qayta yo‘naltirmaydigan holatlarda mos: masalan, “Tarmoq uzildi, qayta urining”.
- Modal muhim harakatni to‘xtatadigan xatolarda: masalan, to‘lov muvaffaqiyatsiz bo‘lsa, keyingi qadam tanlovi bo‘lsin.
- Inline (maydon ostida) validatsiya xatolari uchun eng samarali yo‘l.
8) Tipik xatolar va to‘g‘rilash yo‘li (dizayn hamda texnik)
Ko‘p ilovalarda xato xabarlari “bir xil” ko‘rinishda beriladi: hammasi uchun “Xatolik yuz berdi” deyiladi. Bu holat foydalanuvchini keyingi qadamni topishdan mahrum qiladi. Yechim — xato turini aniqlab, shablon va joylashuvni moslashtirish.
Quyida amaliy diagnostika ro‘yxati berilgan: mahsulotni test qilishda shu narsalarga qarang.
- Client-side validatsiya ishlamayapti: noto‘g‘ri forma yuboriladi → server 400 qaytaradi → foydalanuvchi “nimani tuzatishni” bilmaydi.
- Tarmoq muammosi ham server xatosi kabi ko‘rsatiladi: “Serverda xatolik” o‘rniga “Internet uzildi”.
- Autentifikatsiya xatosida qayta urinish taklif qilinadi: 401 bo‘lsa, qayta urinish emas, qayta kirish oqimi kerak.
- Ko‘p marotaba modal/alert chiqadi: bir request uchun 1 ta xabar qoidasi bo‘lsin (de-duplication).
De-duplication uchun amaliy usul: request id yoki xato kodi bo‘yicha oxirgi ko‘rsatilgan xabarni saqlang va “bir xil holat”ni 1 marta render qiling.
FAQ
Xato matnida texnik kodlarni foydalanuvchiga ko‘rsatish kerakmi?
Odatda yo‘q. Xato kodini foydalanuvchi ko‘rishi shart emas; lekin debug uchun ichki loglarda saqlang. Foydalanuvchiga “qanday tuzatish” kerak bo‘ladigan matn beriladi, kod esa so‘ralganda (masalan, qo‘llab-quvvatlashga) ishlatiladi.
Bir xato uchun toast, banner va modalni qanday tanlash kerak?
Qoidani soddalashtirish mumkin: validatsiya xatosi — inline; amalni davom ettirishni bloklaydigan xato — modal; foydalanuvchini jarayon davomida to‘xtatmaydigan holat — banner yoki toast. Agar foydalanuvchi keyingi qadamni tanlashi kerak bo‘lsa, modal afzal.
Xato xabari uzunligini cheklash bo‘yicha aniq norma bormi?
Aniq raqam kontekstdan bog‘liq, lekin amaliy yo‘l: 1–2 gapdan oshmasin. Agar qo‘shimcha izoh kerak bo‘lsa, uni “Batafsil” ochiladigan qismga joylang. Shunda asosiy harakat yo‘qolmaydi.
“Qayta urinish” tugmasi qachon ko‘rsatiladi, qachon yo‘q?
Qayta urinish server vaqtinchalik xatolari (masalan, 503/504) va tarmoq uzilishida mantiqli. Validatsiya xatolarida (odatda 4xx ichida) takrorlash foydasiz; u holda xatoni tuzatish yo‘li ko‘rsatiladi.
Network timeout bo‘lsa, server javob kutib qolish kerakmi?
Yo‘q: timeout holatini tarmoq xatosi sifatida ko‘rsatish kerak. Amaliy variant — so‘rovni bekor qilish yoki “kutish tugadi” xabarini chiqarish, keyin qayta urinish taklif qilish.
Har bir xato uchun albatta yangi dizayn yasash shartmi?
Shart emas. Yaxshi yondashuv — cheklangan shablonlar to‘plami: validatsiya, autentifikatsiya, ruxsat, tarmoq, server. Shu shablonlar ichida faqat maydon/harakat matni o‘zgaradi.
Xulosa
Mobil ilovalarda xato xabarlari dizayni “matnning chiroyliligi”dan ko‘ra ko‘proq tizimga bog‘liq: xato turi aniq aniqlansa, UI mos komponent va aniq harakatni tanlaydi, natijada foydalanuvchi tez tuzatadi yoki qayta urinish to‘g‘ri yo‘naltiriladi.
Eng amaliy qadam: xato kodlari bo‘yicha mapping jadvalini tuzing, inline/banner/modal qoidalarini belgilab chiqing va har bir xato turiga qayta urinish siyosatini ulang.
