Tần suất bạn cần thăm dò các nút UI trước khi chúng bị coi là lag?

Mặc dù có thể, và đôi khi mong muốn, sử dụng các ngắt thay đổi pin để đọc trạng thái của các nút, việc thăm dò trạng thái của các nút trong sẽ đơn giản hơn loop(). Đây là một kỹ thuật thường được sử dụng.

Nếu bạn loop()thực hiện đủ nhanh, thì việc nhấn nút sẽ luôn bị bắt và người dùng sẽ không thể nhận thấy bất kỳ độ trễ hoặc độ trễ nào.

Có thể là vòng lặp của bạn sẽ mất nhiều thời gian để gây ra sự chậm trễ hoặc độ trễ được nhận thấy.

Câu hỏi là, nói chung sẽ mất bao lâu trước khi người dùng thấy điều này?

Câu trả lời ngắn gọn là bạn có 100 triệu giây để trả lời người dùng nếu bạn muốn họ cảm thấy hành động xảy ra tức thời.

Theo Jacob Nielsen trong cuốn sách Kỹ thuật sử dụng , từ năm 1993, được coi là một tài liệu tham khảo quan trọng trong Hệ thống sử dụng và trải nghiệm người dùng:

• 0,1 giây là giới hạn để người dùng cảm thấy rằng hệ thống đang phản ứng tức thời, nghĩa là không cần phản hồi đặc biệt nào ngoại trừ việc hiển thị kết quả.

Ông cũng đề cập rằng lời khuyên cơ bản này về thời gian trả lời là giống nhau trong nhiều thập kỷ [Miller 1968; Thẻ et al. 1991].

Tôi đã lấy trích dẫn này từ bài viết này: Thời gian phản hồi: 3 giới hạn quan trọng , cũng được viết bởi Jacob Nielsen.

Lưu ý rằng trong thời gian này, bạn phải bao gồm tất cả thời gian dành để đọc nút nhấn và đưa ra phản hồi cho người dùng.

Các ngưỡng thời gian phản hồi khác quan trọng đối với trải nghiệm người dùng, từ cùng một nguồn, nhưng điều đó không được OP đề cập trực tiếp là:

• 1,0 giây là khoảng giới hạn để dòng suy nghĩ của người dùng không bị gián đoạn, mặc dù người dùng sẽ nhận thấy sự chậm trễ. Thông thường, không có phản hồi đặc biệt là cần thiết trong thời gian trễ hơn 0,1 nhưng dưới 1,0 giây, nhưng người dùng sẽ mất cảm giác vận hành trực tiếp trên dữ liệu.

• 10 giây là giới hạn để giữ sự chú ý của người dùng tập trung vào cuộc đối thoại. Đối với sự chậm trễ lâu hơn, người dùng sẽ muốn thực hiện các tác vụ khác trong khi chờ máy tính kết thúc, vì vậy họ sẽ được cung cấp phản hồi cho biết khi nào máy tính dự kiến ​​sẽ được thực hiện. Phản hồi trong thời gian trễ đặc biệt quan trọng nếu thời gian phản hồi có khả năng thay đổi cao, vì khi đó người dùng sẽ không biết phải mong đợi điều gì.

Người ta thường biết rằng mọi người không thể nhận ra những thay đổi khi chúng xảy ra bên dưới 10ms sau hành động của họ. Khả năng đáp ứng này sẽ dẫn đến một trải nghiệm gần đây được mô tả là "linh hoạt". Nó đáng chú ý nhưng đối với người dùng thật khó để đặt tên cho nó.

Vì vậy, nếu bạn muốn sự hoàn hảo, hãy trì hoãn khoảng 15ms. Nếu bạn muốn thực sự tốt, hãy trì hoãn 100 ms. 100ms là trung bình 50ms, và chắc chắn sẽ vượt qua cho mọi người.

Ứng dụng và thời gian đáp ứng dự kiến ​​cũng rất quan trọng. Cửa trượt hoặc thang máy được cung cấp dung sai rất lớn (vì đối tượng vật lý sẽ luôn mất nhiều thời gian hơn) trong khi giao diện máy bán vé không được cung cấp bất kỳ lúc nào.

Giới hạn trên cho bỏ phiếu sẽ là khoảng 1500ms. Xung quanh mọi người sẽ luôn nhận thấy nó chậm.

Dữ liệu này hoàn toàn là kinh nghiệm cá nhân như một game thủ và lập trình viên. YMMV và hãy nhớ rằng chỉ cần tự mình thử là cách tốt nhất để tìm hiểu cảm giác của nó. Câu trả lời "khoa học" duy nhất là <10 mili giây, ngoài ra đó là về khả năng nhận biết độ trễ (thay đổi theo từng người và từng thời điểm) và khả năng chịu đựng của người dùng.

Là một lưu ý phụ, bạn có thể thử dao động độ trễ để tiết kiệm thời gian sử dụng pin hoặc CPU khi giao diện không được sử dụng. Hành động của người dùng, bỏ phiếu càng nhanh. Khi ứng dụng đang hoạt động, hãy thăm dò ý kiến ​​rất chậm. Tốt hơn để thăm dò ý kiến ​​khi nó quan trọng!