Hỏi về quy chuẩn xử lý lỗi & hiển thị trên giao diện mobile/desktop/web

#1

Khi xây dựng ứng dụng (mobile/web/desktop), mình muốn hỏi về các quy chuẩn hoặc best practice khi xử lý lỗi và hiển thị lỗi trong ứng dụng, đặc biệt trong các tình huống như:

  1. Khi không có dữ liệu (empty state)
  2. Khi gặp lỗi mạng hoặc lỗi hệ thống
  3. Khi người dùng không có quyền truy cập (403)
  4. Khi phiên đăng nhập hết hạn (401)
  5. Khi thao tác người dùng thất bại (gửi form, upload, …)

Một số câu hỏi cụ thể:

  1. Nên hiển thị lỗi trực tiếp trong content view, hay popup/modal/snackbar? Khi nào thì dùng cái nào?

  2. Các ứng dụng lớn (Google, Facebook, Slack, …) thường áp dụng những nguyên tắc gì để xử lý và hiển thị lỗi?

  3. Có những mẫu giao diện (error UI patterns) nào được xem là chuẩn cho từng loại lỗi?

  4. Có nên cố gắng tự động retry hoặc refresh trong một số trường hợp không?

  5. Đành rằng mỗi công ty sẽ có đôi chút khác biệt, nhưng có những chuẩn chung như vậy mà cộng đồng quy ước không ?

Rất mong được chia sẻ về các nguyên tắc hay framework mà mọi người đang dùng liên quan đến vấn đề này.
Xin cảm ơn !

#2

Hiện thị lỗi thì dựa vào UX (trải nghiệm người dùng), thường mấy bạn design có nghiên cứu UI/UX sẽ đưa ra insight nên dùng cái gì, hoặc update dựa trên user feedback.

Thông thường lỗi mà block luồng của app thì nên hiện popup/modal đi kèm message lỗi với action để điều hướng user nó biết nên làm gì, còn lỗi nhẹ nhẹ thì hiện toast mấy giây rồi auto dismiss cũng được.

Có thể auto-retry 3-4 lần gì đó trước khi báo lỗi. Hoặc tăng khoảng thời gian giữa các lần retry.

2 Likes
#3

Hầu như các thư viện chuyên call API như rxJS, tanstack Query (react) đều có code chế retry và recommended triển khai retry đối với các lỗi như

  • lỗi mạng, timeout: có thể user 4G yếu, mất sóng, một thời gian sau sẽ hoạt động lại bình thường
  • lỗi http 500: Có thể do server đang “kẹt phà” thử lại phát xem sao?

Những trường hợp không những retry mà còn phải đi kèm với back-off như http 429, giãn cách giữa những lần thử để tránh server tưởng đang spam dẫn tới bị block account hoặc block IP (như comment bên trên là tăng khoảng thời gian giữa các lần).

Top những trường hợp không được retry:

  • lỗi 400, user đã nhập sai thì cố retry bao nhiêu lần vẫn 400.
  • lỗi 403, server đã bảo không có quyền thì cố bao nhiêu lần vẫn không cho truy cập.

Có thể thêm fallback, nếu retry nhiều lần vẫn lỗi thì trả về dữ liệu cache hoặc call tới server dự phòng.

Mỗi lần retry không cần thông báo trên UI, UI chỉ thông báo kết quả cuối cùng sau nhiều lần thử.

Còn vấn đề refresh data thì không nên tự ý refresh data của user. Trên app sẽ có chức năng pull to refresh để user chủ động refresh data. Đối với các app ERP khi user đang xem bảng biểu mà có người khác update table thì chỉ hiện notify có 10 thay đổi mới, có 8 update by Nguyễn Văn A, … Khi nào user chủ động ấn button refresh mới fetch lại API, hoặc khi user đang scroll xem dữ liễu cũ trong ListView mà ListView đó append thêm data thì cũng hiện icon số lượng data mới vừa được update, user sẽ chủ động scroll ngược lại.

3 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?