Seberapa sering Anda perlu polling tombol UI sebelum mereka dianggap lamban?

Sementara dimungkinkan, dan kadang-kadang diinginkan, untuk menggunakan interupsi penggantian pin untuk membaca keadaan tombol, lebih mudah untuk menyurvei keadaan tombol di loop(). Ini adalah teknik yang umum digunakan.

Jika Anda loop()menjalankan cukup cepat, maka penekanan tombol selalu akan ditangkap dan pengguna tidak akan dapat merasakan keterlambatan atau keterlambatan.

Mungkin saja pengulangan Anda akan memakan waktu lama hingga menyebabkan penundaan atau keterlambatan dirasakan.

Pertanyaannya adalah, berapa lama, secara umum, sebelum seorang pengguna melihat ini?

Jawaban singkatnya adalah Anda memiliki 100 milidetik untuk merespons pengguna jika Anda ingin mereka merasakan tindakan tersebut terjadi secara instan.

Menurut Jacob Nielsen dalam bukunya Usability Engineering , dari tahun 1993, yang dianggap sebagai referensi penting dalam Sistem Usability dan Pengalaman Pengguna:

• 0,1 detik adalah tentang batas untuk membuat pengguna merasa bahwa sistem bereaksi secara instan, artinya tidak diperlukan umpan balik khusus kecuali untuk menampilkan hasilnya.

Dia juga menyebutkan bahwa nasihat dasar mengenai waktu respons ini hampir sama selama beberapa dekade [Miller 1968; Card et al. 1991].

Saya mengutip kutipan ini dari artikel ini: Waktu Tanggapan: 3 Batas Penting , juga ditulis oleh Jacob Nielsen.

Perhatikan bahwa saat ini Anda harus memasukkan semua waktu yang diperlukan untuk membaca tombol tekan dan memberikan umpan balik kepada pengguna.

Ambang waktu respons lainnya yang penting untuk pengalaman pengguna, dari sumber yang sama, tetapi yang tidak disebutkan secara langsung oleh OP adalah:

• 1,0 detik adalah tentang batas aliran pemikiran pengguna untuk tetap tidak terganggu, meskipun pengguna akan melihat penundaan. Biasanya, tidak ada umpan balik khusus yang diperlukan selama penundaan lebih dari 0,1 tetapi kurang dari 1,0 detik, tetapi pengguna tidak kehilangan perasaan beroperasi langsung pada data.

• 10 detik adalah tentang batas untuk menjaga perhatian pengguna terfokus pada dialog. Untuk penundaan yang lebih lama, pengguna akan ingin melakukan tugas-tugas lain sambil menunggu komputer selesai, sehingga mereka harus diberi umpan balik yang menunjukkan kapan komputer mengharapkan untuk dilakukan. Umpan balik selama penundaan sangat penting jika waktu respons cenderung sangat bervariasi, karena pengguna tidak akan tahu apa yang diharapkan.

Sudah umum diketahui bahwa orang tidak dapat melihat perubahan ketika mereka terjadi di bawah 10ms setelah tindakan mereka. Responsif ini akan menghasilkan pengalaman yang baru-baru ini sebagian besar digambarkan sebagai "tajam". Itu terlihat tetapi untuk pengguna sulit untuk menyebutkan nama di atasnya.

Jadi, jika Anda menginginkan kesempurnaan, luangkan sekitar 15 ms. Jika Anda ingin yang benar-benar bagus, ambil penundaan 100 ms. 100ms adalah 50ms rata-rata, dan pasti akan lulus untuk orang-orang.

Aplikasi dan waktu respons yang diharapkan juga vital. Pintu geser atau lift diberikan toleransi yang sangat besar (karena objek fisik akan selalu membutuhkan lebih banyak waktu) sedangkan antarmuka mesin penjual tiket tidak diberikan waktu sama sekali.

Batas atas untuk polling adalah sekitar 1500ms. Di sekitar sana orang akan selalu menyadari bahwa itu lambat.

Data ini murni pengalaman pribadi sebagai seorang gamer dan programmer. YMMV dan ingat bahwa hanya mencobanya sendiri adalah cara terbaik untuk mengetahui bagaimana rasanya. Satu-satunya jawaban "ilmiah" adalah <10 milidetik, di luar itu tentang kemampuan untuk merasakan keterlambatan (yang bervariasi per orang dan momen) dan toleransi pengguna.

Sebagai catatan, Anda dapat mencoba fluktuasi penundaan untuk menghemat waktu baterai atau CPU saat antarmuka tidak digunakan. Tindakan pengguna, semakin cepat pemungutan suara. Ketika aplikasi melakukan hal itu, jajak pendapat sangat lambat. Lebih baik jajak pendapat ketika itu penting!