Cập nhật lần cuối:
Thiết kế UX cho văn bản thông báo - Số ký tự tối ưu cho thông báo trong ứng dụng, Toast và Banner
Thông báo trong ứng dụng, tin nhắn Toast và thông báo Banner là các thành phần UI được thiết kế để truyền tải thông tin mà không làm gián đoạn luồng thao tác của người dùng. Tuy nhiên, việc nhồi nhét văn bản dài vào Toast có thời gian hiển thị hạn chế, hay thông báo Banner có quá ít ký tự để truyền đạt ý nghĩa là những thất bại thiết kế số ký tự thường gặp. Trong khi thiết kế số ký tự thông báo đẩy bị ràng buộc bởi giới hạn cấp OS, thông báo trong ứng dụng cho phép nhà phát triển tự do thiết kế, khiến việc đánh giá số ký tự phù hợp càng quan trọng hơn.
Phân loại thành phần thông báo và thiết kế số ký tự cơ bản
| Thành phần | Thời gian hiển thị | Vị trí | Yêu cầu thao tác | Số ký tự khuyến nghị | Mục đích |
|---|---|---|---|---|---|
| Toast | 3-5 giây | Dưới hoặc trên màn hình | Không (tự biến mất) | 15-40 ký tự | Xác nhận thành công/thất bại |
| Snackbar | 5-10 giây | Dưới màn hình | Tùy chọn (nút hành động) | 20-50 ký tự | Xác nhận + hoàn tác |
| Banner | Liên tục (đóng thủ công) | Trên màn hình | Có (nút đóng) | 30-80 ký tự | Thông báo quan trọng, trạng thái hệ thống |
| Cảnh báo nội tuyến | Liên tục | Trong nội dung | Không | 40-120 ký tự | Lỗi biểu mẫu, cảnh báo |
| Hộp thoại modal | Liên tục (đến khi thao tác) | Giữa màn hình | Có (xác nhận/hủy) | 50-200 ký tự | Xác nhận quan trọng, cảnh báo thao tác phá hủy |
| Trung tâm thông báo | Liên tục (danh sách) | Màn hình riêng | Không | 40-100 ký tự | Lịch sử thông báo |
Toast có giới hạn ký tự nghiêm ngặt nhất. Với chỉ 3-5 giây hiển thị, 15-40 ký tự tiếng Nhật là giới hạn thực tế. Điều quyết định giới hạn đó không phải bản thân tốc độ đọc, mà là khoảng trễ trước khi người dùng bắt đầu đọc. Toast xuất hiện ở một góc màn hình mà không báo trước, nên một phần thời gian bị mất cho việc nhận ra nó và di chuyển tầm mắt, chỉ còn lại khoảng một nửa thời gian hiển thị để thực sự theo hết câu chữ. Ngay sau một thao tác, mắt người dùng vẫn còn ở nút vừa bấm, thường nằm cách xa vị trí Toast phía dưới màn hình. Thay vì suy ra một giới hạn lý thuyết từ tốc độ đọc, hãy hiển thị văn bản trên thiết bị thật và kiểm tra bằng mắt xem nó có biến mất trước khi đọc xong hay không.
Thiết kế số ký tự Toast - Truyền đạt trong 3 giây
| Mẫu | Số ký tự | Ví dụ | Đánh giá |
|---|---|---|---|
| Chỉ động từ | 5-8 ký tự | "Đã lưu" | ○ Ngắn gọn nhất nhưng không rõ lưu gì |
| Đối tượng + động từ | 10-20 ký tự | "Đã lưu bản nháp" | ◎ Đối tượng rõ ràng, ngắn gọn |
| Đối tượng + động từ + bổ sung | 20-40 ký tự | "Đã lưu bản nháp. Tự động lưu mỗi 5 phút" | △ Quá dài cho Toast |
| Biểu tượng + động từ | 5-10 ký tự | "✓ Lưu hoàn tất" | ○ Biểu tượng tăng khả năng nhận biết |
Mẫu "đối tượng + động từ" (10-20 ký tự) là phạm vi tối ưu cho Toast. Chỉ rõ đối tượng giúp người dùng xác định chính xác thao tác nào đã hoàn thành khi nhiều thao tác chạy song song.
Thiết kế số ký tự Banner - Mật độ thông tin trong hiển thị liên tục
| Loại Banner | Số ký tự khuyến nghị | Ví dụ | Nút hành động |
|---|---|---|---|
| Banner thông tin | 30-60 ký tự | "Tính năng mới: Chế độ tối đã có sẵn" | "Thử ngay" / "Đóng" |
| Banner cảnh báo | 30-70 ký tự | "Phương thức thanh toán sắp hết hạn. Vui lòng cập nhật" | "Cập nhật" / "Để sau" |
| Banner lỗi | 30-80 ký tự | "Kết nối máy chủ không ổn định. Một số tính năng bị hạn chế" | "Thử lại" / "Chi tiết" |
| Banner thành công | 20-50 ký tự | "Nâng cấp gói hoàn tất" | "Xem chi tiết" / "Đóng" |
| Banner đồng ý Cookie | 50-120 ký tự | "Trang web này sử dụng cookie để cải thiện trải nghiệm" | "Đồng ý" / "Cài đặt" |
Thiết kế phân cấp thông báo - Mức độ khẩn cấp và số ký tự
| Mức khẩn cấp | Thành phần khuyến nghị | Số ký tự | Ví dụ | Thao tác người dùng |
|---|---|---|---|---|
| Thấp (xác nhận) | Toast | 10-25 ký tự | "Đã lưu cài đặt" | Không cần |
| Trung bình (chú ý) | Snackbar / Banner | 20-60 ký tự | "Dung lượng lưu trữ đã đạt 80%" | Tùy chọn |
| Cao (cảnh báo) | Banner / Cảnh báo nội tuyến | 30-80 ký tự | "Cần cập nhật bảo mật. Vui lòng cập nhật trong cài đặt" | Khuyến nghị |
| Khẩn cấp (xử lý ngay) | Hộp thoại modal | 50-150 ký tự | "Có thay đổi chưa lưu. Rời đi mà không lưu?" | Bắt buộc |
Sử dụng văn bản dài cho thông báo mức khẩn cấp thấp hoặc hiển thị bằng hộp thoại modal tạo ra "hiệu ứng cậu bé chăn cừu". Khi thông báo không quan trọng liên tục gián đoạn luồng thao tác, thông báo thực sự quan trọng cũng bị bỏ qua. Khớp chính xác mức khẩn cấp với số ký tự và lựa chọn thành phần là chìa khóa duy trì độ tin cậy của toàn bộ hệ thống thông báo.
Văn bản thông báo như microcopy
Áp dụng nguyên tắc microcopy hiệu quả vào văn bản thông báo:
- Cụ thể: "Đã xảy ra lỗi" thành "Tải ảnh lên thất bại (giới hạn kích thước: 5 MB)". Truyền đạt cụ thể điều gì đã xảy ra và tại sao
- Viết từ góc nhìn người dùng: "Lỗi kết nối cơ sở dữ liệu" thành "Không thể kết nối dịch vụ. Vui lòng thử lại sau". Truyền đạt tác động và giải pháp, không phải nguyên nhân kỹ thuật
- Viết tích cực: "Mật khẩu sai" thành "Mật khẩu không khớp. Vui lòng thử lại". Tránh biểu đạt phủ định, đưa ra giải pháp
- Giữ giọng điệu nhất quán: Thống nhất giọng điệu thông báo (trang trọng/thân mật) trong toàn ứng dụng. Như thiết kế tin nhắn chatbot, phản ánh giọng nói thương hiệu
Hướng dẫn văn bản thông báo trong hệ thống thiết kế
| Mục hướng dẫn | Quy tắc | Ví dụ |
|---|---|---|
| Số ký tự tối đa | Toast: 40, Banner: 80, Modal: 200 | Kiểm tra tự động qua lint |
| Kết thúc câu | Thống nhất mẫu "Đã..." / "Vui lòng..." | "Đã lưu" / "Vui lòng cập nhật" |
| Nút hành động | Bắt đầu bằng động từ. Dưới 8 ký tự | "Cập nhật" / "Xem chi tiết" / "Đóng" |
| Thuật ngữ kỹ thuật | Cấm trong văn bản hướng đến người dùng | "HTTP 500" thành "Lỗi máy chủ" |
Cần nhấn mạnh một điểm: những giới hạn ký tự như trong bảng trên không được ghi trong bất kỳ hướng dẫn thiết kế chính thức nào. Tìm trong các hướng dẫn thiết kế của nền tảng, bạn sẽ không thấy giới hạn ký tự cho Snackbar hay hộp thoại cảnh báo; lượng văn bản thường được diễn đạt theo số dòng hoặc số câu, vì số ký tự vừa một dòng thay đổi theo chiều rộng màn hình, cỡ chữ và ngôn ngữ nên không dùng làm chuẩn chung được. Nhìn ngược lại, việc đo xem một dòng chứa được bao nhiêu ký tự ở chiều rộng hẹp nhất mà ứng dụng hỗ trợ, rồi chuyển quy tắc theo dòng thành giới hạn ký tự riêng, chính là việc của hệ thống thiết kế. Các con số trong bảng trên cũng nên được hiểu như vậy: một thỏa thuận nội bộ cố định kết quả chuyển đổi đó cho cả nhóm, không phải điều được một nguồn bên ngoài bảo chứng.
Cân bằng tần suất thông báo và số ký tự
- Xử lý hàng loạt: Khi nhiều thông báo cùng loại xảy ra liên tiếp, gộp thành "Đã tải lên 3 tệp" thay vì thông báo từng cái
- Lọc ưu tiên: Thông báo ưu tiên thấp chỉ ghi vào trung tâm thông báo, không hiển thị Toast hay Banner
- Thời gian chờ: Thông báo cùng loại cách nhau ít nhất 30 giây. Thông báo liên tiếp ghi đè thông báo trước
- Thông báo tổng hợp: "Tanaka và 4 người khác đã bình luận" gộp nhiều sự kiện thành một thông báo
Khả năng tiếp cận và văn bản thông báo
Đặt role="status" và aria-live="polite" cho Toast để thông báo mà không gián đoạn thao tác hiện tại. Đặt role="alert" cho thông báo lỗi để đọc ngay lập tức.
Số ký tự văn bản thông báo ảnh hưởng trực tiếp đến thời gian đọc của trình đọc màn hình. Chỗ khó là phía phát triển không thể ước lượng được thời gian đọc đó. Tốc độ đọc là một thiết lập của người dùng và dao động rất rộng; người dùng thành thạo trình đọc màn hình thường cho giọng đọc chạy nhanh hơn mức mặc định khá nhiều. Thêm vào đó, aria-live="polite" chờ phần đang đọc kết thúc mới đọc tiếp, nên ngay cả thời điểm bắt đầu đọc cũng xê dịch. Vì vậy cách tính theo kiểu "bao nhiêu ký tự thì đọc xong trong thời gian hiển thị" không đứng vững, do tiền đề của nó không thể cố định. Còn một cái bẫy nữa: xóa phần tử vừa được đọc khỏi DOM đúng lúc thông báo biến mất có thể làm câu đọc bị ngắt giữa dòng. Chính vì thế, nên cho người dùng trình đọc màn hình một tùy chọn kéo dài thời gian hiển thị Toast, hoặc một lịch sử thông báo để xem lại sau.
Ràng buộc văn bản thông báo theo nền tảng
| Phần tử | iOS (UIKit / SwiftUI) | Android | Web (CSS) |
|---|---|---|---|
| Toast | Không có API chuẩn (tùy chỉnh) | Snackbar (văn bản + nút hành động) | Thiết kế tự do |
| Banner | Không có API chuẩn (tùy chỉnh) | Không có API chuẩn (tùy chỉnh) | Thiết kế tự do |
| Alert | UIAlertController (tiêu đề + nội dung + nút) | AlertDialog (tiêu đề + nội dung + tối đa 3 nút) | Thiết kế tự do |
iOS không có thành phần chuẩn tương đương Snackbar của Android, nên Toast cần triển khai tùy chỉnh. Đổi lại quyền tự đặt giới hạn ký tự, bạn cũng phải tự quyết định thời gian hiển thị, vị trí và hiệu ứng chuyển động. Phần dễ bỏ sót là những gì xê dịch khi văn bản dài ra: chiều cao tăng lên và chồng vào tab bar hay home indicator, hoặc khung thông báo lệch ra ngoài safe area khiến góc bo tròn che mất chữ. Không lỗi nào trong số đó được ngăn chặn chỉ bằng việc đặt giới hạn ký tự; ranh giới cần để mắt tới là chỗ chiều cao nhảy từ một dòng thành hai dòng.
Snackbar của Android có thành phần chuẩn nên cách nghĩ về giới hạn cụ thể hơn: văn bản dài ra thì tăng số dòng và phần không vừa bị cắt bớt, nên giới hạn thực chất được đặt theo số dòng cho phép chứ không theo số ký tự. Với tiếng Nhật là khoảng 20-25 ký tự mỗi dòng (con số ước lệ ở màn hình 360dp và cỡ chữ mặc định), tức khoảng 50 ký tự cho hai dòng là mức thực tế. Số ký tự đó giảm ngay khi người dùng tăng cỡ chữ. Ngoài ra, nhãn nút hành động chia chiều rộng cùng một dòng với nội dung, nên chỉ cần đặt một nhãn ngắn cũng đã thu hẹp rõ phần chiều rộng còn lại cho nội dung. Kiểm tra đồng thời ba điều kiện: cỡ chữ lớn nhất, chiều rộng thiết bị hẹp nhất dự định hỗ trợ và nhãn hành động dài nhất, giúp bố cục không bị vỡ về sau.
Chiến lược bản địa hóa văn bản thông báo
Điểm bất tiện là chính những chuỗi ngắn như văn bản thông báo mới giãn nở nhiều nhất khi dịch: một đoạn giải thích dài giữ được mức tăng vừa phải, còn một chuỗi chỉ vài từ có thể dài hơn gấp đôi. Nghĩa là ngân sách dịch chặt nhất lại rơi đúng vào Toast và nút hành động, nơi giới hạn vốn đã nghiêm ngặt nhất. Điều dễ bỏ qua tiếp theo là số ký tự và chiều rộng hiển thị là hai thước đo khác nhau: một ký tự tiếng Nhật hay tiếng Trung chiếm chiều rộng xấp xỉ hai ký tự Latin, nên số ký tự nhỏ hơn không bảo đảm dòng chữ vừa khung. Chỉ quản lý giới hạn ký tự là để hở cả hai khoảng trống đó.
- Thiết kế bố cục cho ngôn ngữ dài nhất: Tỷ lệ giãn nở không do riêng ngôn ngữ quyết định mà phụ thuộc nhiều vào độ dài chuỗi gốc. Theo mức tham khảo trong bài viết về quốc tế hóa của W3C, chuỗi tiếng Anh từ 10 ký tự trở xuống có thể dài tới 200-300% sau khi dịch, còn chuỗi trên 70 ký tự chỉ còn khoảng 130%. Dựng bố cục với khoảng 1,3 lần dư địa vốn được nói cho văn bản dài sẽ khiến những chuỗi ngắn như nhãn nút vỡ trước tiên, nên hãy tính dư địa hơn gấp đôi cho chuỗi ngắn
- Cho phép xuống dòng: Thiết kế thành phần có chiều cao thay đổi theo lượng văn bản thay vì Toast chiều rộng cố định
- Truyền đạt giới hạn ký tự cho dịch giả: Thêm ghi chú số ký tự tối đa trong tệp i18n
- Kiểm tra bằng pseudo-localization: Áp dụng bản dịch giả có kéo dài chuỗi để kiểm tra khả năng chịu đựng của bố cục. Không dùng một tỷ lệ kéo dài chung cho mọi chuỗi, mà kéo dài chuỗi càng ngắn càng mạnh (hơn gấp đôi) để tiến gần kết quả dịch thật
Như đã thảo luận trong thiết kế số ký tự tin nhắn Slack, văn bản thông báo công cụ doanh nghiệp đòi hỏi cả sự ngắn gọn và chính xác.