Jika Anda Sebuah Tombol, Tugas Anda Hanya Satu

• Bahkan tombol sesederhana rotasi foto bisa sangat memengaruhi pengalaman pengguna tergantung bagaimana ia menangani input berulang cepat
• iPhone mengingat input rotasi 90 derajat yang ditekan beberapa kali, lalu menjalankan rotasi berikutnya segera setelah animasi selesai
• Nothing Phone/Android mengonfirmasi ketukan dengan haptic dan suara, tetapi mengabaikan ketukan lanjutan yang masuk saat animasi rotasi sedang berjalan
• Dalam situasi ketika banyak foto dokumen perlu diputar, UI pengeditan foto yang kasual sekalipun dituntut menyediakan operasi yang lebih cepat dan dapat diprediksi
• Tombol seharusnya menerima input melalui buffering ketukan atau menghentikan/mempercepat animasi, alih-alih membuat pengguna menunggu sampai animasi selesai

---

Cara tombol rotasi foto menangani input berulang

• Tombol rotasi foto adalah kontrol standar yang, ketika ditekan sekali, biasanya melakukan rotasi 90 derajat berlawanan arah jarum jam, lalu mengulangi aksi yang sama saat ditekan lagi
• Animasi rotasi menunjukkan proses berubahnya orientasi foto sehingga membantu pengguna tidak kehilangan rasa arah
• Jika 8 kali menekan rotasi 90 derajat dengan cepat, gambar semestinya berputar dua putaran penuh dan kembali ke orientasi semula, seperti yang oleh engineer disebut “no op”
• Di iPhone, ekspektasi ini benar-benar terpenuhi
  • Mengingat input ketukan cepat
  • Setelah rotasi sebelumnya selesai, menjalankan rotasi berikutnya yang sedang menunggu
• Di Nothing Phone/Android, hasilnya berbeda
  • Tombol memberikan konfirmasi ketukan lewat haptic dan suara
  • Jika animasi rotasi sebelumnya belum selesai, ketukan baru diabaikan

UI kasual pun membutuhkan penanganan input yang lebih kuat untuk pekerjaan berulang

• Disabilitas situasional adalah konsep bahwa disabilitas tidak hanya dialami oleh sebagian orang, tetapi siapa pun bisa secara efektif mengalami disabilitas dalam situasi tertentu
• Pengambilan foto umumnya tergolong penggunaan kasual, tetapi kamera ponsel bisa keliru mengenali orientasi foto saat memotret menghadap ke bawah
• Setelah mengambil beberapa foto dokumen dalam orientasi lanskap lalu harus memutar masing-masingnya, pengguna mungkin perlu memutar foto puluhan kali satu per satu
• Dalam situasi seperti ini, tombol yang tetap bekerja secara dapat diprediksi meski ditekan tiga kali pada kecepatan yang diinginkan pengguna akan terasa lebih menyenangkan dan tidak terlalu merepotkan
• Jika dilihat dalam rentang waktu yang cukup panjang atau pada kelompok pengguna yang besar, antarmuka kasual pun akan bertemu momen ketika ia perlu diperlakukan lebih serius
  • “Sifat power user situasional” seperti ini juga muncul pada contoh seperti pengeditan foto di ponsel atau GarageBand
• Solusinya tidak harus selalu berupa buffering ketukan
  • Saat ketukan interuptif masuk, animasi juga bisa dihentikan atau dipercepat
  • Intinya adalah tidak memaksa pengguna menunggu animasi selesai

[GN⁺]

Komentar Hacker News

• Bagaimana jika pengguna tanpa sengaja mengeklik terlalu banyak, atau mengira klik pertama tidak terdaftar?
  Saya masih ingat keynote Steve Jobs saat mendemonstrasikan betapa jauhnya peningkatan kecepatan tampilan dokumen PDF di macOS baru. Para engineer sudah menyiapkan tombol untuk menggulir PDF di layar, lalu Jobs tanpa sengaja menekannya lebih dari sekali dan berkata, “Apakah ini akan menggulir sampai akhir dua kali?” dan ternyata aksi itu benar-benar terbuffer. Akhirnya ia harus kembali ke atas dan menunggu guliran kedua selesai
  Jobs menutupinya dengan berkata, “Bahkan jika memasukkan waktu untuk menelusuri dokumen kedua kalinya, ini tetap lebih cepat daripada PDF di OS sebelumnya”

  • Debouncing ada karena memang ada alasannya. Ada kalanya tombol memang harus dijalankan dua kali saat ditekan dua kali, dan ada kalanya justru tidak boleh begitu. Tidak mudah membedakan situasi mana yang lebih tepat untuk masing-masing perilaku
    Setidaknya kita perlu memikirkan penanganan seperti apa yang cocok untuk situasi tertentu. Dalam UI, ada tombol yang jelas cocok ke satu sisi, dan tombol lain jelas cocok ke sisi sebaliknya, tetapi sebagian bersifat ambigu sehingga jika kedua perilaku sama-sama bisa dibela, hasilnya menjadi UI yang tidak konsisten
    Saya sendiri tidak tahu solusi yang bagus

  • Menurut artikelnya:

    The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating.

    Itu inti masalahnya. Jumlah kali aplikasi menandai bahwa input tombol sudah terdaftar harus sama dengan jumlah aksi yang benar-benar dijalankan. Debouncing adalah praktik yang baik, tetapi kalau dipakai, tap yang ter-debounce tidak boleh memberi umpan balik

  • Saya agak bingung karena bagian “Bagaimana jika pengguna tanpa sengaja mengeklik terlalu banyak, atau mengira klik pertama tidak terdaftar?” tiba-tiba membawa pembahasan aksesibilitas. Soalnya yang langsung terlintas bagi saya adalah orang dengan tremor tangan yang berniat menekan sekali tetapi malah menekan dua kali
    Dan ada juga orang yang memang selalu melakukan double-click pada semua tombol. Menonaktifkan tombol submit di onclick untuk menangani kasus seperti ini adalah hal yang sangat umum

  • Saya sudah bukan fanboy Apple/Mac/Jobs seperti dulu, tetapi saya rindu presentasi Apple yang terasa dibawakan oleh orang yang benar-benar ingin menunjukkan sesuatu yang keren
    Presentasi Apple belakangan terasa terlalu kaku, tidak manusiawi, dan seperti dijalankan orang-orang bersetelan rapi, sampai saya bahkan tidak menontonnya sampai habis. Semuanya tampak seperti robot yang menyembunyikan emosi dan sisi manusianya karena takut dipecat kalau menyimpang dari naskah suci
    Mungkin ini agak melenceng dari topik, tetapi itu justru mengingatkan saya betapa menyenangkannya gaya presentasi spontan Jobs yang agak berantakan

  • Untuk mengatakan “lalu bagaimana dengan kasus ini?”, ini jelas bukan contohnya. Ada dua alasan:

    1. “The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]”
    2. Ada alasan yang baik untuk menekan tombol ini 3 kali berturut-turut

• Saya ingin mendukung argumen “bagaimana dengan debouncing?” yang muncul di tempat lain, dan penulis tidak seharusnya begitu saja mengabaikannya
  Tetapi saya juga tidak suka meme you had one job, dan ingin menolak pemakaiannya yang tanpa berpikir. Dalam banyak kasus meme itu salah, dan untuk tombol pun umumnya demikian. Dalam antarmuka pengguna biasa, tombol tertentu sering kali menjalankan beberapa peran berikut sekaligus:

  • menyampaikan aksi apa yang akan terjadi saat tombol ditekan
  • kadang menyampaikan status saat ini dari sebagian sistem, misalnya tombol untuk mengaktifkan dan menonaktifkan mode yang juga secara visual menunjukkan mode saat ini
  • menjalankan aksi yang dimaksud saat diklik
  • kadang menyampaikan bahwa perintah sudah diterima dan sedang dijalankan, misalnya seperti kasus di artikel asal, menonaktifkan tombol selama animasi rotasi untuk menghindari kebingungan
  • Di balik meme you had one job hampir selalu bisa ditambahkan, “karena saya menolak mempertimbangkan kompleksitas nyata dari pekerjaanmu”
  • Ini poin yang bagus, terutama karena menekankan bahwa ekspektasi tiap orang tentang apa itu tombol dan apa yang bukan bisa berbeda-beda. Masing-masing poin tadi menjelaskan tombol berlabel, tombol dengan toggle, tombol sungguhan, dan indikator progres. Bergantung pada penggunanya, semuanya bisa dianggap sebagai “tombol”
  • Kalau pertanyaannya “bagaimana dengan debouncing”, bukankah fungsi tombol bisa dijalankan saat touch release alih-alih saat touch start?

• Ungkapan bahwa tombol hanya punya “satu tugas” tidak begitu cocok. Tombol tidak hanya harus bisa diklik, tetapi juga harus melakukan banyak hal lain
  Ada umpan balik saat diklik, umpan balik saat kursor diarahkan, status loading, status nonaktif, dan berbagai kombinasi dari semuanya. Ini juga bisa terasa sangat menjengkelkan. Misalnya, saat menekan tombol yang terhubung ke layanan backend tetapi tidak ada umpan balik visual sama sekali, kita tidak tahu apakah tombol itu benar-benar sudah ditekan. Jika juga tidak ada status loading, kita tidak tahu apakah ada sesuatu yang sedang diproses di belakang, sehingga akhirnya terus menekannya berulang kali

• Penulis ingin agar jika tombol diklik tiga kali, pada kecepatan berapa pun, fungsi yang sama selalu dijalankan. Ia ingin bisa membolak-balik foto dengan cepat dan memutarnya satu per satu secara dapat diprediksi, dan itu masuk akal

  And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you."

Penulis mengajukan alasan aksesibilitas.
Namun, argumen yang sepenuhnya berlawanan juga bisa dibayangkan. Misalnya, orang dengan gangguan motorik atau Parkinson mungkin justru lebih menyukai perilaku yang mengabaikan klik berlebihan ketika niat mereka sudah pasti.
Membuat hal seperti ini dengan benar memang rumit.

• Di iOS ada opsi aksesibilitas Ignore Repeats, tetapi itu adalah pengaturan seluruh sistem, jadi tampak seperti pendekatan yang lebih baik. Orang yang memerlukan penyesuaian semacam ini bisa mendapatkannya juga di tempat seperti keyboard di layar, dan semua orang lain juga tidak perlu dipaksa mengetik lebih lambat.

• Saya juga tidak merasa semua widget UI harus memikirkan hal seperti ini.
  Sepertinya ini bisa ditangani sebagai pengaturan tingkat perangkat. Misalnya, ketukan yang berulang dalam 100ms pada area yang berjarak kurang dari 50px satu sama lain bisa diabaikan.

• Sangat setuju. Bahkan tanpa sampai ke Parkinson, kalau melihat orang yang tidak terlalu lanjut usia tetapi sudah berumur menggunakan ponsel dan layar sentuh, sering terlihat bahwa menekan tombol kecil tepat di posisi yang benar sambil merasakan “saya sudah menekannya” itu cukup sulit.
  Karena itu, dari sudut pandang aksesibilitas, perilaku Nothing Phone tampaknya jauh lebih cocok. Pengguna seperti itu tidak akan menghitung klik sampai 6 kali untuk menaruh gambar di posisi tertentu. Lagi pula, mengklik 8 kali lebih dulu agar bisa kembali tepat ke posisi sekarang juga tidak terlalu masuk akal.
  Cara berpikir dalam kasus ini lebih dekat ke “klik, tunggu, bandingkan apakah sudah di posisi yang diinginkan, lalu klik lagi”. Sebaliknya, tombol sensitif yang melakukan buffering input cenderung membuat orang melewati target terlalu jauh lalu balik terlalu banyak, sehingga terjadi overshooting. Mirip seperti saat mencoba scroll ke titik yang diinginkan dalam daftar tetapi terus meleset.
  Pendekatan iPhone lebih cocok untuk orang muda atau penggemar teknologi yang ingin memproses sesuatu dengan cepat tanpa menunggu. Mirip seperti di keyboard komputer, karena adanya jeda, orang bisa mengetik beberapa huruf lebih dulu sebelum huruf pertama muncul di layar.

• Saya pernah memakai perangkat dengan tombol fisik; saat ditekan, tombol itu berbunyi bip dan menambah 30 detik pada waktu. Tetapi kadang bunyi bip terdengar tanpa penambahan 30 detik, dan kadang 30 detik bertambah tanpa bunyi sama sekali. Jadi saya selalu harus memicingkan mata ke display yang redup untuk memastikan apakah itu benar-benar berfungsi.
  Saya menganggap ini rancangan yang sangat buruk, tetapi sejak itu saya sudah tak terhitung kali melihat perilaku rusak ini direproduksi persis sama pada tombol-tombol yang murni berbasis software. Apakah warna tombol berubah di layar dan apakah tindakan yang diminta benar-benar dijalankan ternyata hanya terhubung secara longgar. Kenapa bisa begitu? Sebenarnya diimplementasikan bagaimana?

  • Saya menyebut ini masalah melakukan dua hal.
    Anda menulis kode imperatif yang memberi dua perintah, dan keduanya bisa gagal secara independen.
    Ada banyak cara untuk berpura-pura bahwa ini sudah “ditangani”.
    Pertama, semua tes akan lolos, jadi sebagian besar pengembang bisa langsung berhenti memikirkannya.
    Mereka mungkin berpikir cukup dengan menangkap exception dan hanya mencatat log, tetapi itu tidak benar-benar memperbaikinya.
    Bisa juga dibiarkan berjalan di produksi untuk sementara waktu lalu dilihat apakah masalah muncul. Ketika akhirnya masalah memang muncul, pengembang akan mencoba lagi, dan pada percobaan kedua kemungkinan besar akan berhasil, jadi mereka bisa berhenti memikirkannya lagi.
    Beberapa hari lalu juga ada diskusi besar tentang outbox pattern. Di sana, tugas pertama dipecah menjadi dua bagian dan ditangani secara atomik, lalu tugas kedua diserahkan kepada pembaca.
    Menurut saya, alasan masalah ini terus muncul di dunia nyata adalah karena para pengembang berada dalam superposisi kuantum antara “hal seperti itu tidak akan terjadi”, “sudah saya perbaiki”, dan “itu tidak bisa diperbaiki”.
  • Ini sangat umum karena dua karakteristik desain yang dimiliki kebanyakan framework UI:
    Kode yang mengubah warna tombol adalah perilaku internal komponen “button”, jadi tidak perlu diimplementasikan ulang untuk setiap tombol. Namun itu juga berarti ia terpisah sampai tingkat tertentu dari kode yang melakukan tindakan sebenarnya. Jika ada pemeriksaan terakhir di handler on click, seperti “jangan putar gambar jika animasi rotasinya sedang berjalan” seperti di contoh asli, sering kali tidak ada cara untuk memberi tahu tombol agar membatalkan perubahan warnanya. Sebaliknya, bahkan jika animasi perubahan warna gagal diputar dengan benar, handler on click tetap bisa dijalankan.
    Tombol biasanya berubah warna saat tombol mouse ditekan, tetapi tindakannya dilakukan saat tombol mouse dilepas. Pendekatan ini sengaja memberi kesempatan untuk membatalkan di saat terakhir dengan menahan lalu menyeret keluar dari tombol, dan di mobile juga memungkinkan interaksi ditafsirkan ulang sebagai scroll, bukan klik. Di lain waktu, ini hanya menambah lebih banyak kesempatan bagi tindakan untuk diblokir setelah warna telanjur berubah.
  • Di lift saya cukup sering melihat ini. Jika tombol ditekan sangat singkat, lampunya menyala selama ditekan tetapi input tombol sebenarnya tidak terdaftar.
  • Perubahan warna tombol menunjukkan bahwa penekanan berhasil dilakukan. Jika ini tidak dilakukan segera, kebanyakan orang akan terkondisikan untuk mencoba lagi. Ini terutama penting bagi orang dengan kontrol motorik yang lemah.
    Hal ini sepenuhnya terpisah dari apakah penekanan itu merupakan input yang berguna dalam keadaan software saat ini. Software yang ditulis dengan baik seharusnya sudah tahu kapan ia tidak bisa menerima input dan menonaktifkan tombol tersebut, dan software yang lumayan baik setidaknya harus memberikan umpan balik yang hampir seketika bahwa tindakan sedang diproses atau telah dibatalkan.
  • Mungkin karena kurangnya pengujian, dan asumsi bahwa kegagalan tindakan terlalu jarang terjadi untuk layak dipertimbangkan. Namun pola seperti ini membuat antarmuka sulit dipercaya dan sulit digunakan secara efisien.

• Orang sering lupa bahwa animasi itu murni bersifat pendukung, bukan tujuan itu sendiri.
  Animasi ada untuk menyamarkan waktu pemuatan dan membuat perpindahan dari satu keadaan ke keadaan lain terasa mulus. Itulah alasan animasi dipakai.
  Pengetahuan ini pada akhirnya hilang, dan sekarang muncul kode yang memaksa kita menunggu sampai animasi selesai.
  Ini contoh lain dari cargo cult yang mengagumkan.

  • Saya ingin sedikit memperluas penjelasan “menyamarkan waktu pemuatan dan membuat perpindahan dari satu keadaan ke keadaan lain terasa mulus”. Jika digunakan dengan baik, animasi menunjukkan bahwa perubahan keadaan sedang terjadi secara langsung karena tindakan tertentu dari pengguna, dan juga memberi petunjuk bagaimana cara membatalkan atau memperbaikinya.
    Sebenarnya saya tidak setuju dengan kata “menyamarkan”. Sesuatu yang langsung muncul tanpa petunjuk kenapa itu muncul adalah antipola yang jelas di layar sentuh.
  • Animasi bukan hanya untuk itu. Animasi juga bisa berkontribusi secara kreatif pada rasa saat memakai aplikasi.
  • Apple dulu memahami ini. Mereka menambahkan animasi setelah item menghilang, tetapi menghindari animasi sebelum item ditampilkan.
    Apple lama memahami bahwa desain lebih dari sekadar membuat sesuatu terlihat indah. Apple bergaya kaca masa kini hanya peduli bagaimana tampilannya dalam demo.
  • Animasi hampir selalu terasa tidak perlu. Saya mematikannya di aplikasi atau sistem kapan pun itu dimungkinkan.
  • Di Android saya mematikan semua animasi dan rasanya jauh lebih baik. Terutama animasi overscroll saat layar keseluruhan meregang ketika kita mencoba scroll terlalu jauh; saya benar-benar membencinya.

• Saat melihat perbandingan pertama, jujur saya merasa masalahnya ada pada contoh iPhone. Setiap kali tombol putar ditekan, tombol dan slider di bawah gambar menghilang lalu muncul lagi dengan fade-in; ini adalah perilaku yang pernah saya lihat di berbagai aplikasi iOS dan sangat mengganggu tanpa henti. Terutama aplikasi Screenshot, yang secara pribadi sangat saya keluhkan
  Jika sebuah elemen UX dapat dioperasikan baik sebelum maupun sesudah suatu interaksi, entah itu transformasi atau pemrosesan, elemen itu seharusnya tetap terlihat selama proses tersebut. Apa keuntungan UX dari menyembunyikan tombol-tombol ini saat rotasi di iPhone? Tidak juga terlihat lebih baik. Tentu saja, belakangan ini perangkat lunak Apple memang sering mengorbankan perbaikan UX yang nyata di altar penampilan
  Namun, saya setuju dengan pendapat penulis bahwa tap seperti ini harus ditangani secara independen dari animasi

  • Akan bagus kalau aplikasi perangkat lunak juga punya aturan tape-out seperti chip komputer. Saat mendesain chip, ada program yang meninjau desain dan membandingkannya dengan aturan setebal 300 halaman seperti “jalur logam X dan logam Y tidak boleh berada dalam jarak Z”
    Hal serupa bisa dibuat untuk UX. Semacam kumpulan batasan pola desain yang memunculkan peringatan saat seseorang hendak merilis produk dalam kondisi masih memiliki cacat UX yang sudah dikenal

• Ini mengingatkan saya pada saat dulu saya mengimplementasikan BabyButton agar bisa digunakan bayi. Alih-alih tindakan klik biasa, saya memakai event touchdown, sehingga anak bisa langsung melihat bahwa sesuatu terjadi, dan tidak masalah jika tombol ditekan terlalu lama atau jari digerakkan sambil tetap menekan
  Apakah kita memang perlu membuat sistem untuk kelompok usia seperti itu adalah topik yang sama sekali berbeda, tetapi rasanya itu tantangan yang baik untuk merancang sesuatu sesuai kebutuhan pengguna

  • Menarik melihat betapa terbiasanya kita dengan tombol GUI yang hanya dijalankan saat tombol mouse dilepas, dan dengan perilaku tertentu seperti keluar lalu masuk lagi ke area tombol sambil tetap menekan
    Tombol di dunia nyata, lebih dari 99%, langsung melakukan sesuatu begitu ditekan. Tetapi tombol yang berperilaku seperti itu di GUI akan terasa aneh

• Tulisan yang benar-benar lebih dekat dengan inti yang ingin disampaikan penulis ada di sini: https://aresluna.org/show-your-hands-honor/

• Saat menelepon, kenapa menekan tombol nyala/mati layar di iPhone kadang mengakhiri panggilan, dan kadang hanya mematikan layar?
  Saya masih belum tahu polanya, tetapi sebelum memasukkan iPhone ke saku saya pernah menekan tombol itu dan kadang tanpa sengaja memutus panggilan

  • Saat mode speakerphone/hands-free aktif, yang mati hanya layarnya. Saat ponsel ditempelkan ke telinga, layar akan mati otomatis jadi sepertinya diasumsikan Anda tidak akan menekan tombol kunci. Masalahnya, kadang karena bug layar tetap menyala, atau di ruangan yang tenang orang juga bisa memakainya seperti hands-free

[GN⁺]

Komentar Lobste.rs

• Sindiran ringan, tapi kalau membahas UI/UX yang baik, embed video tanpa kontrol dan tanpa indikator itu yang paling buruk
  Banyak orang menonaktifkan autoplay secara default, dan saya sempat lama melihat dua gambar yang hampir sama sambil berpikir, “Jadi apa bedanya?”

  • “Ada videonya?” Saya juga sempat berpikir begitu, jadi sepertinya saya juga melewatkannya
  • Saya tidak paham kenapa ini disebut “yang paling buruk”. Apakah karena Anda terus berpikir “Jadi kenapa?” tanpa menggulir sedikit ke bawah untuk membaca penjelasan masalahnya?
  • Untuk topik seperti ini, harus diakui bahwa GitHub menampilkan kontrol putar pada GIF animasi. Hampir tidak pernah melihat itu di tempat lain
  • Mungkin juga ini perbedaan browser. Di Vivaldi pada Android, saya melihat tombol putar besar dan bilah progres

• Saya sepenuhnya setuju dengan “jangan pernah membuat pengguna menunggu sampai animasi selesai”
  Dalam aplikasi, perintah pengguna harus selalu lebih diprioritaskan daripada tampil cantik

• Menurut saya prinsip ini juga berlaku untuk game. Beberapa game punya jeda yang sangat singkat antara saat menu dibuka dan saat input mulai terdaftar
  Dalam game dengan animasi menu yang mewah, ini jadi pertanyaan seperti: jika menekan pause lalu tombol arah bawah dengan cepat, apakah setelah menu muncul item kedua seharusnya sudah terpilih?
  Input buffering di game memang topik yang rumit, tetapi dalam pengoperasian menu, jarang terasa sebagai hal yang baik

• Cara video itu menyampaikan informasi kurang bagus. Untuk menyadari momen saat tombol ditekan beberapa kali berturut-turut, saya harus menonton dengan sangat fokus
  Kalau masuk ke inti masalah, juga masih belum jelas apakah ponsel Android benar-benar salah. Saya paham frustrasi ingin menekan cepat 8 kali untuk mendapatkan hasil yang diinginkan, tapi ini mengingatkan pada deteksi salah klik ganda di OS desktop
  Pada akhirnya ini terasa lebih seperti perbedaan antara usability yang dibayangkan produsen dan kenyamanan yang dirasakan pengguna. Kalau harus memilih, iPhone yang tetap menampilkan tombol “Done” saat animasi berlangsung justru terasa lebih mengganggu

• Sulit mengatakan Android sepenuhnya salah. Saya pernah secara tidak sengaja mengeksekusi sesuatu dua kali karena UI merespons terlalu lambat
  Solusi terbaik mungkin adalah menonaktifkan tombol sampai animasi selesai

  • Tapi itu justru menimbulkan masalah yang ditunjukkan di tulisan ini. Menjadi hampir mustahil melakukan rotasi 90 derajat berlawanan arah jarum jam tanpa melihat layar
    “Klik tiga kali” tidak akan berhasil, dan klik tambahan selama animasi akan diabaikan. Klik, lalu lihat layar sambil menunggu animasi selesai, lalu klik lagi dan menunggu lagi, itu lambat dan menuntut terlalu banyak perhatian pengguna
    Solusi yang lebih baik tampaknya adalah memberi umpan balik langsung di UI. Status tombol yang menandakan klik sudah diproses bisa dirender segera, atau sebelum animasi penuh yang lambat muncul, layar bisa digambar ulang cepat secara sementara untuk menunjukkan progres saat ini

• Saya sangat setuju dengan keseluruhan tulisan ini. Saya ingin menyebut ini sebagai kasus animasi yang melanggar Sumpah Hipokrates
  Prinsip pertama animasi seharusnya adalah “jangan membahayakan terlebih dahulu”, yaitu “jangan terlebih dahulu mengganggu input pengguna”

• Pernah mengalami rotary encoder yang tidak bisa mengikuti? Knop volume pada amplifier headphone saya tidak melakukan apa-apa kalau diputar terlalu cepat
  Kalau saya jadi presiden sehari…

• Setiap melihat hal seperti ini saya berpikir bagaimana jadinya kalau di GUI toolkit saya. Toolkit saya, seperti perilaku yang dipinjam dari platform Windows, memperlakukan dua klik cepat sebagai double-click, dan ini kadang membuat frustrasi
  Double-click sendiri adalah kebiasaan umum dan memang ada nilainya untuk dibedakan dari klik biasa. Secara ideal, event klik harus dibuat idempoten sehingga meski terjadi dua kali tidak menimbulkan masalah. Misalnya, jika klik memilih item dan double-click menjalankan aksi default, memilih item yang sama dua kali tidak merugikan. Tapi kenyataannya tidak selalu begitu
  Masalahnya, jika tombol diklik sangat cepat, tombol itu bisa hanya dieksekusi sekali, lalu berikutnya masuk sebagai event double-click dan akhirnya tidak melakukan apa-apa. Jadi ketika ditekan cepat, separuh klik bisa terabaikan
  Karena masalah ini saya membuat boolean triggersOnMultiClick, dan jika diatur true, maka event trigger juga akan dipancarkan pada klik cepat berulang seperti double-click. Namun demi kompatibilitas sebelumnya, nilai default-nya saya biarkan false, tetapi karena sudah waktunya merilis major release baru, dan menurut saya argumen dalam tulisan ini masuk akal, saya ingin mengubah default-nya menjadi true sekarang
  Bisa ditulis seperti, “Tambahan 2 Juli 2021, default false. Pada 5 Juli 2026 (v13.0), default diubah menjadi true agar semua klik tombol secara default memicu trigger. Jika menginginkan perilaku lama, override event double-click atau setelah memanggil konstruktor induk setel triggersOnMultiClick = false”
  Pada sisi implementasi animasi, perilaku serupa juga bisa muncul tanpa sengaja. Jika ada variabel posisi animasi di dalam objek dan nilainya diatur saat klik, maka saat terjadi double-click kira-kira ada dua pilihan. Lewati sisa animasi dan langsung pindah ke state internal berikutnya, atau abaikan event demi menjaga kehalusan visual dengan sesuatu seperti if(animationCounter) return;. Developer Android dalam tulisan itu tampaknya memilih yang kedua
  Di pihak Apple, sepertinya mereka mungkin memakai cara ketiga, yaitu queue animasi yang menunggu dan memasukkan event ke sana. Yang membuat saya penasaran adalah apakah state internal berubah saat dimasukkan ke queue, saat selesai, atau mereka benar-benar memutar gambar dengan animasi. Jika animasi dipotong di tengah lalu disimpan, apakah bisa keluar gambar yang berputar 45 derajat? Kalau saya yang melakukannya, saya mungkin akan memperbarui EXIF 90 derajat secara atomik dan menjalankan animasi transisi secara terpisah
  Antara kesederhanaan implementasi, fidelitas visual, dan perilaku UI, ada beberapa pilihan yang sama-sama masuk akal. Secara pribadi saya juga suka pendekatan di mana penekanan kedua langsung snap ke state baru tanpa menunggu animasi. Saya mungkin tidak akan sampai membuat queue animasi
  Lucu juga bahwa saya mengubah kode di waktu yang hampir sama. Perubahan sebelumnya juga pada 2 Juli, dan yang sekarang kebetulan 5 Juli. Saya suka menuliskan riwayat seperti ini langsung di komentar dokumentasi. Menyenangkan untuk dibaca kembali sebagai kenangan saat mengubahnya nanti
  Apple mungkin menyediakan queue animasi default, tetapi kapan state diubah tetap masalah terpisah. Di web, saya mungkin akan memperbarui state secara atomik, lalu memisahkan animasi visual murni seperti transisi CSS transform. Itu juga menghindari perhitungan ulang layout, jadi implementasinya tampak mudah dan efisien. Jika nama class diubah lebih cepat daripada animasinya, apakah hasilnya akan melompat atau masuk antrean, itu sesuatu yang ingin saya uji nanti

• Mungkin karena saya makin tua, tapi beberapa kali saya sangat kesal dengan perilaku seperti ini saat tidak sengaja mengetuk dua kali
  Mengandalkan tombol di posisi yang sama atau double-tap sebagai sarana konfirmasi itu mengerikan. Kalau memang perlu konfirmasi, jangan buat konfirmasi itu mudah terjadi secara tidak sengaja
  Namun dalam contoh ini, menerima input cepat beruntun tampaknya ide yang baik. Dalam kasus lain belum tentu begitu. Ada tombol fisik yang memang sengaja mencegah penekanan dua kali sampai sesuatu “selesai”, dan meski tidak selalu desain yang sepenuhnya sadar, kadang itu pilihan yang tepat
  Banyak juga orang yang harus memakai perangkat yang tersendat atau rusak, dan jika ada masalah kesehatan seperti tangan atau jari gemetar, membatasi input bisa punya manfaat
  Contoh ini tampaknya kasus di mana kedua sisi bisa dianggap masuk akal. Ada contoh yang lebih menjengkelkan karena harus menunggu, dan jelas juga ada contoh di mana kita justru berharap ada pembatasan input, entah karena animasi atau kondisi lain

• Hasil pencarian di browser mobile yang terus diperbarui di bawah jari saya dan mendorong opsi yang hendak saya tekan ke posisi lain itu benar-benar menjengkelkan tanpa henti
  Saya memang sudah melatih diri untuk menunggu lebih lama, tetapi sungguh tidak masuk akal kalau interaksi UI harus peka terhadap pekerjaan asinkron di latar belakang yang waktu selesainya berubah-ubah karena kondisi penerimaan sinyal