Nếu là một cái nút, thì chỉ có một việc phải làm

• Ngay cả một nút đơn giản như xoay ảnh cũng có thể tạo ra trải nghiệm người dùng rất khác nhau tùy theo cách xử lý nhập lặp nhanh
• iPhone ghi nhớ nhiều lần nhấn xoay 90 độ và tiếp tục thực hiện lượt xoay tiếp theo ngay khi hoạt ảnh kết thúc
• Nothing Phone/Android xác nhận thao tác chạm bằng rung phản hồi và âm thanh, nhưng các lần chạm tiếp theo trong lúc hoạt ảnh xoay đang chạy thì bị bỏ qua
• Trong tình huống phải xoay nhiều ảnh tài liệu, ngay cả UI chỉnh sửa ảnh mang tính casual cũng cần thao tác nhanh hơn và dễ đoán hơn
• Thay vì buộc người dùng phải chờ hoạt ảnh kết thúc, nút nên nhận đầu vào bằng cách đệm lần chạm hoặc dừng/tăng tốc hoạt ảnh

---

Cách nút xoay ảnh xử lý nhập lặp

• Nút xoay ảnh là một điều khiển tiêu chuẩn: mỗi lần nhấn thường sẽ xoay 90 độ ngược chiều kim đồng hồ, và nhấn lại thì lặp lại cùng hành động đó
• Hoạt ảnh xoay cho thấy quá trình ảnh đổi hướng, giúp người dùng không mất cảm giác về phương hướng
• Nếu nhấn nhanh 8 lần để xoay 90 độ, thì giống như “no op” theo cách các kỹ sư nói: ảnh phải quay đủ hai vòng và trở về hướng ban đầu
• Trên iPhone, kỳ vọng này thực sự đúng
  • Ghi nhớ các lần chạm nhanh
  • Khi lượt xoay trước kết thúc, sẽ thực hiện lượt xoay tiếp theo đang chờ
• Trên Nothing Phone/Android, kết quả lại khác
  • Nút cung cấp xác nhận chạm bằng rung phản hồi và âm thanh
  • Nếu hoạt ảnh xoay trước դեռ chưa kết thúc thì sẽ bỏ qua lần chạm mới

Ngay cả UI casual cũng cần xử lý đầu vào mạnh hơn khi có tác vụ lặp

• Khuyết tật theo hoàn cảnh là khái niệm cho rằng khuyết tật không chỉ xảy ra với một số người, mà bất kỳ ai trong một hoàn cảnh nhất định cũng có thể trải nghiệm nó một cách hiệu quả
• Chụp ảnh nhìn chung là một hoạt động khá casual, nhưng camera điện thoại có thể nhầm hướng ảnh khi chụp hướng xuống dưới
• Nếu chụp nhiều ảnh tài liệu nằm ngang rồi phải xoay từng ảnh, người dùng có thể phải xoay hàng chục ảnh lần lượt
• Trong những tình huống như vậy, sẽ dễ chịu hơn và đỡ phiền hơn nếu nút hoạt động một cách dễ đoán ngay cả khi bấm ba lần ở tốc độ người dùng muốn
• Nếu xét trên khoảng thời gian đủ dài hoặc một nhóm người dùng đủ lớn, ngay cả giao diện casual cũng sẽ có lúc cần được đối xử nghiêm túc hơn
  • Kiểu “power user theo hoàn cảnh” này cũng xuất hiện trong các trường hợp như chỉnh sửa ảnh trên điện thoại hay GarageBand
• Giải pháp không nhất thiết phải là đệm lần chạm
  • Có thể dừng hoặc tăng tốc hoạt ảnh khi nhận được lần chạm có tính ngắt quãng
  • Điểm cốt lõi là không ép người dùng phải chờ hoạt ảnh kết thúc

[GN⁺]

Các ý kiến trên Hacker News

• Vậy phải làm gì khi người dùng vô tình nhấp quá nhiều lần, hoặc tin rằng lần nhấp đầu tiên chưa được ghi nhận?
  Tôi vẫn nhớ bài keynote khi Steve Jobs trình diễn việc hiển thị tài liệu PDF trên macOS mới đã nhanh hơn đến mức nào. Các kỹ sư đã tạo một nút để cuộn tài liệu PDF trên màn hình, nhưng Jobs lỡ bấm quá một lần và nói kiểu “nó sẽ cuộn đến cuối hai lần à?”, rồi thực tế là thao tác đã bị đưa vào bộ đệm. Cuối cùng ông phải quay lại phía trên và chờ lần cuộn thứ hai kết thúc
  Jobs chữa cháy bằng cách nói rằng “ngay cả tính cả thời gian xem lướt tài liệu lần thứ hai thì vẫn nhanh hơn PDF trên OS trước đây”

  • Debouncing tồn tại là có lý do. Có lúc bấm nút hai lần thì phải thực thi hai lần, cũng có lúc không nên như vậy. Phân biệt tình huống nào nên theo hướng nào không hề đơn giản
    Ít nhất cũng phải suy nghĩ xem cách xử lý nào phù hợp với tình huống nào. Trong UI, có nút thì rõ ràng nên theo một hướng, nút khác lại rõ ràng nên theo hướng ngược lại, nhưng một số thì mơ hồ, và nếu cả hai hành vi đều có thể biện minh được thì cuối cùng sẽ thành UI thiếu nhất quán
    Tôi cũng không rõ giải pháp tốt là gì

  • Theo bài viết:

    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.

    Đây mới là vấn đề. Số lần ứng dụng xác nhận rằng đầu vào từ nút đã được ghi nhận phải bằng số hành động thực sự được thực hiện. Debouncing là thực hành tốt, nhưng nếu dùng thì không được đưa ra phản hồi cho những lần chạm đã bị debounce

  • Tôi khá bối rối khi phần “nếu người dùng vô tình nhấp quá nhiều lần, hoặc tin rằng lần nhấp đầu tiên chưa được ghi nhận thì sao?” lại kéo sang chuyện khả năng tiếp cận. Vì tôi lập tức nghĩ đến trường hợp người bị run tay, định bấm một lần nhưng lại bấm hai lần
    Và cũng có những người nhấp đúp vào mọi nút. Việc vô hiệu hóa nút gửi trong onclick để xử lý các trường hợp này là chuyện rất phổ biến

  • Dù tôi không còn là fanboy Apple/Mac/Jobs như ngày xưa, tôi vẫn nhớ những buổi ra mắt của Apple có cảm giác do một người thật sự muốn khoe thứ gì đó tuyệt vời dẫn dắt
    Các buổi ra mắt Apple gần đây quá cứng nhắc, thiếu tính người, có cảm giác do những người mặc vest vận hành, đến mức tôi không xem nổi đến hết. Ai cũng trông như robot che giấu cảm xúc và tính người vì sợ bị sa thải nếu đi chệch khỏi kịch bản thiêng liêng
    Có thể hơi lạc đề, nhưng điều này làm tôi nhớ các bài thuyết trình ứng biến có phần lộn xộn của Jobs từng thú vị đến mức nào

  • Nếu nói “vậy trường hợp này thì sao?” thì tình huống này rõ ràng không phải vậy. Có hai lý do:

    1. “The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]”
    2. Có lý do chính đáng để bấm nút này liên tiếp 3 lần

• Tôi muốn ủng hộ lập luận “thế còn debouncing thì sao?” được nêu ở nơi khác, và tác giả không nên chỉ bỏ qua nó
  Nhưng tôi cũng ghét meme you had one job, và muốn phản đối cách dùng thiếu suy nghĩ của nó. Phần lớn meme này là sai, và với nút bấm thì nhìn chung cũng vậy. Trong giao diện người dùng thông thường, một nút cụ thể thường đồng thời đảm nhận nhiều vai trò sau:

  • Truyền đạt rằng khi bấm nút thì sẽ xảy ra hành động gì
  • Đôi khi truyền đạt trạng thái hiện tại của một phần hệ thống, ví dụ nút bật/tắt một chế độ hiển thị trực quan chế độ hiện tại
  • Thực thi hành động mong muốn khi được nhấp
  • Đôi khi truyền đạt rằng lệnh đã được nhận và đang được thực thi, ví dụ như trường hợp trong bài gốc: vô hiệu hóa nút trong lúc animation xoay đang chạy để tránh gây nhầm lẫn
  • Phía sau meme you had one job gần như luôn có thể thêm câu “vì tôi đã từ chối xét đến độ phức tạp thực sự trong công việc của bạn”
  • Nhận xét hay, đặc biệt tốt ở chỗ nhấn mạnh rằng mỗi người có kỳ vọng khác nhau về việc cái gì là nút bấm và cái gì không phải. Từng điểm ở trên lần lượt mô tả nút có nhãn, nút dạng toggle, nút thật sự, và chỉ báo tiến trình. Tùy người dùng, tất cả những thứ này đều có thể là “nút bấm”
  • Nếu nói “thế còn debouncing” thì chẳng phải chỉ cần thực thi chức năng của nút khi nhả chạm thay vì khi bắt đầu chạm là được sao?

• Cụm “một việc” không thật sự hợp với nút bấm. Vì nút không chỉ có một việc là có thể nhấp, mà phải làm nhiều việc
  Có phản hồi khi được nhấp, phản hồi khi rê chuột lên, trạng thái đang tải, trạng thái bị vô hiệu hóa, và các tổ hợp của tất cả những thứ đó. Điều này có thể gây rất bực bội. Ví dụ, nếu bạn bấm một nút kết nối với dịch vụ backend mà không có phản hồi trực quan nào, bạn sẽ không biết nút đó đã được bấm hay chưa. Nếu cũng không có trạng thái đang tải, bạn sẽ không biết phía sau có đang xử lý gì không và sẽ tiếp tục bấm nhiều lần

• Tác giả muốn rằng nếu nhấp ba lần với bất kỳ tốc độ nào thì cùng một chức năng luôn được thực hiện. Ý là muốn lướt ảnh nhanh và xoay từng ảnh một cách dự đoán được, điều đó hợp lý

  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.

Tác giả đưa ra lý do dựa trên khả năng tiếp cận
Tuy nhiên cũng có thể hình dung một lập luận hoàn toàn ngược lại. Ví dụ, người bị rối loạn vận động hoặc Parkinson có thể thích hành vi bỏ qua các lần nhấp dư thừa hơn khi ý định đã được xác định
Làm cho đúng kiểu này khá khó

• iOS có một tùy chọn trợ năng tên là Ignore Repeats, và vì là thiết lập toàn hệ thống nên có vẻ là cách tiếp cận tốt hơn. Người cần kiểu hiệu chỉnh này cũng có thể được áp dụng ở những chỗ như bàn phím trên màn hình, và những người khác cũng không phải gõ chậm lại

• Tôi không nghĩ mọi widget UI đều phải tính đến cả những chuyện như vậy
  Có lẽ có thể xử lý bằng thiết lập toàn thiết bị. Chẳng hạn, nếu các lần chạm trong phạm vi 50px với nhau bị lặp lại trong vòng 100ms thì bỏ qua

• Hoàn toàn đồng ý. Ngay cả chưa cần nói đến Parkinson, nếu nhìn những người có tuổi, dù chưa quá cao tuổi, dùng điện thoại và màn hình cảm ứng, ta có thể thấy họ thường khó bấm chính xác vào một nút nhỏ và có được cảm giác “mình đã bấm rồi”
  Vì vậy từ góc độ trợ năng, tôi nghĩ hành vi của Nothing Phone phù hợp hơn nhiều. Những người dùng đó sẽ không đếm số để nhấp 6 lần nhằm đặt hình ảnh vào một vị trí cụ thể. Hơn nữa, việc nhấp trước 8 lần để quay lại chính xác vị trí hiện tại cũng không hợp lý lắm
  Lối suy nghĩ trong trường hợp này gần với “nhấp, chờ, so sánh xem đã đúng vị trí mong muốn chưa, rồi nhấp tiếp”. Ngược lại, một nút nhạy kiểu đệm đầu vào rất dễ gây quá đà rồi lại quay ngược quá nhiều, tạo ra hiện tượng overshoot. Nó giống như khi cố cuộn danh sách đến đúng điểm mong muốn nhưng cứ bị lệch liên tục
  Cách của iPhone phù hợp hơn với người trẻ hoặc dân mê công nghệ muốn thao tác nhanh mà không phải chờ. Cũng giống như trên bàn phím máy tính, vì có độ trễ nên ta có thể nhập sẵn nhiều ký tự trước khi ký tự đầu tiên xuất hiện trên màn hình

• Trước đây tôi từng dùng một thiết bị có nút vật lý; đó là nút khi bấm sẽ kêu bíp và cộng thêm 30 giây vào thời gian. Nhưng đôi khi có tiếng bíp mà không cộng thêm 30 giây, và đôi khi không có tiếng mà lại cộng thêm 30 giây. Vì vậy lúc nào tôi cũng phải nheo mắt nhìn cái màn hình hiển thị tối om để kiểm tra xem nó đã hoạt động chưa
  Tôi từng nghĩ đó là một thiết kế đặc biệt tệ, nhưng từ đó về sau tôi đã thấy vô số nút thuần phần mềm tái hiện y nguyên hành vi hỏng hóc này. Việc màu nút trên màn hình có đổi hay không và việc hành động được yêu cầu có thực sự được thực hiện hay không chỉ liên hệ với nhau rất lỏng lẻo. Tại sao lại như vậy? Rốt cuộc họ đã triển khai kiểu gì?

  • Cái này được gọi là vấn đề làm hai việc
    Bạn viết mã mệnh lệnh để ra hai lệnh, và cả hai đều có thể thất bại độc lập
    Có rất nhiều cách để giả vờ rằng mình đã “xử lý” chuyện này
    Trước hết, các bài test đều sẽ pass, nên hầu hết lập trình viên có thể dừng suy nghĩ ngay tại đó
    Cũng có thể nghĩ rằng chỉ cần bắt exception rồi ghi log là được, nhưng như vậy thì không sửa được vấn đề
    Cũng có thể chạy một thời gian trong môi trường production để xem có phát sinh vấn đề không. Rốt cuộc nếu có vấn đề, lập trình viên sẽ thử lại, và lần thứ hai có lẽ sẽ chạy được, nên lại có thể dừng suy nghĩ
    Vài ngày trước cũng có một cuộc thảo luận lớn về outbox pattern. Cách làm là tách việc đầu tiên thành hai nửa và xử lý nguyên tử, còn việc thứ hai giao cho bên đọc
    Tôi cho rằng lý do vấn đề này cứ tiếp tục xuất hiện trong thực tế là vì các lập trình viên ở trong trạng thái chồng chập lượng tử giữa “chuyện đó không xảy ra”, “tôi đã sửa rồi”, và “không thể sửa được”
  • Chuyện này cực kỳ phổ biến vì hai đặc tính thiết kế mà hầu hết các UI framework đều có chung:
    Mã đổi màu nút là hành vi nội bộ của component “button”, nên không cần triển khai riêng cho từng nút. Nhưng điều đó cũng có nghĩa là nó bị tách khỏi mã thực hiện hành động thực tế ở một mức nào đó. Nếu trong trình xử lý on click có một bước kiểm tra cuối cùng như trong bài gốc, kiểu “nếu đang chạy hoạt ảnh xoay thì không xoay ảnh”, thì thường không có cách nào báo cho nút hủy việc đổi màu. Ngược lại, dù animation đổi màu không phát đúng, trình xử lý on click vẫn có thể chạy
    Nút thường đổi màu khi nhấn nút chuột xuống, nhưng hành động lại được thực hiện khi thả nút chuột ra. Cách này còn cố ý cho người dùng cơ hội kéo ra ngoài nút khi đang giữ để hủy ở khoảnh khắc cuối, và trên di động còn có thể diễn giải lại tương tác thành cuộn thay vì nhấp. Những lúc khác, nó chỉ làm tăng thêm cơ hội để hành động bị chặn sau khi màu đã đổi
  • Tôi thấy chuyện này khá thường xuyên trong thang máy. Nếu bấm nút rất nhanh, đèn sẽ sáng trong lúc bấm nhưng thực tế đầu vào của nút không được ghi nhận
  • Sự đổi màu của nút cho thấy thao tác nhấn đã thành công. Nếu không làm điều đó ngay lập tức, hầu hết mọi người đã được điều kiện hóa để thử lại. Điều này đặc biệt quan trọng với những người kiểm soát vận động kém
    Nó hoàn toàn độc lập với việc ở trạng thái hiện tại của phần mềm, lần nhấn đó có phải là đầu vào hữu ích hay không. Phần mềm được viết tốt lẽ ra phải biết rằng không thể nhận đầu vào và vô hiệu hóa nút; phần mềm làm tương đối tốt thì ít nhất cũng nên cung cấp phản hồi gần như tức thì rằng hành động đang được xử lý hoặc đã bị hủy
  • Có lẽ là do thiếu kiểm thử và do giả định rằng lỗi hành động hiếm đến mức không đáng cân nhắc. Nhưng mẫu hành vi kiểu này khiến giao diện trở nên khó tin cậy và khó sử dụng hiệu quả

• Mọi người thường quên rằng animation chỉ đóng vai trò hỗ trợ, chứ bản thân animation không phải là mục đích
  Animation tồn tại để che thời gian tải và giúp chuyển mượt từ trạng thái này sang trạng thái khác. Vì vậy người ta mới dùng nó
  Kiến thức này cuối cùng đã biến mất, và giờ thì xuất hiện cả những đoạn mã phải chờ animation kết thúc
  Lại là một ví dụ nữa về cargo cult đáng kinh ngạc

  • Tôi muốn mở rộng thêm phần giải thích “che thời gian tải và giúp chuyển mượt từ trạng thái này sang trạng thái khác”. Nếu dùng tốt, nó cho thấy một thay đổi trạng thái đang trực tiếp xảy ra do một hành động cụ thể của người dùng, đồng thời cũng gợi ý cách hoàn tác hoặc chỉnh sửa điều đó
    Thật ra tôi không đồng ý với cách nói “che”. Trên màn hình cảm ứng, việc thứ gì đó xuất hiện ngay lập tức mà không có gợi ý vì sao nó xuất hiện rõ ràng là một anti-pattern
  • Animation không chỉ thuần túy phục vụ mục đích đó. Nó còn đóng góp một cách sáng tạo vào cảm giác khi dùng ứng dụng
  • Apple ngày xưa từng hiểu điều này. Họ thêm animation sau khi một mục biến mất, nhưng tránh animation trước khi hiển thị một mục
    Apple ngày xưa hiểu rằng thiết kế không chỉ là làm cho đẹp. Apple với phong cách kính ngày nay thì chỉ quan tâm nó trông ra sao trong demo
  • Animation hầu như lúc nào cũng cảm thấy không cần thiết. Tôi tắt nó ở mọi nơi mà ứng dụng hoặc hệ thống cho phép
  • Tôi đã tắt mọi animation trên Android và thấy dễ chịu hơn nhiều. Đặc biệt tôi cực kỳ ghét animation overscroll làm cả màn hình bị kéo giãn khi cố cuộn quá đà

• Khi xem phép so sánh đầu tiên, nói thật là tôi nghĩ vấn đề nằm ở ví dụ iPhone. Mỗi lần nhấn nút xoay, nút và thanh trượt bên dưới ảnh lại biến mất rồi fade in trở lại; đây là hành vi tôi đã thấy trong nhiều ứng dụng iOS và nó gây khó chịu không dứt. Đặc biệt, cá nhân tôi rất bất mãn với ứng dụng Screenshot
  Nếu đó là một yếu tố UX có thể thao tác được cả trước lẫn sau một tương tác nào đó, thì dù đang biến đổi hay xử lý, nó vẫn nên được giữ hiển thị suốt thời gian đó. Trên iPhone, việc ẩn các nút này trong lúc xoay mang lại lợi ích UX gì? Trông cũng chẳng đẹp hơn. Dĩ nhiên, phần mềm Apple gần đây đã hy sinh những cải thiện UX thực sự trên bàn thờ của vẻ bề ngoài
  Tuy vậy, tôi đồng ý với lập luận của tác giả rằng những cú chạm như thế này nên được xử lý độc lập với hoạt ảnh

  • Ước gì các ứng dụng phần mềm cũng có quy tắc tape-out giống như chip máy tính. Khi thiết kế chip, một chương trình sẽ kiểm tra thiết kế và đối chiếu với bộ quy tắc dài 300 trang kiểu như “đường dây của kim loại X và kim loại Y không được nằm trong khoảng cách Z”
    Với UX cũng có thể làm điều tương tự. Tức là một tập hợp các ràng buộc mẫu thiết kế sẽ đưa ra cảnh báo nếu bạn định phát hành khi vẫn còn các khiếm khuyết UX đã được biết rõ

• Tôi nhớ lại hồi trước từng triển khai BabyButton, được làm để em bé cũng dùng được. Thay vì hành vi click thông thường, tôi dùng sự kiện touchdown, nhờ vậy trẻ có thể thấy ngay là có gì đó đã xảy ra, và cũng không sao nếu nhấn nút quá lâu hoặc di chuyển ngón tay trong lúc vẫn đang nhấn
  Việc có nên xây dựng một hệ thống cho độ tuổi đó hay không là một chủ đề hoàn toàn khác, nhưng tôi cảm thấy đó là một thử thách hay trong việc thiết kế thứ phù hợp với nhu cầu của người dùng

  • Thật thú vị khi thấy chúng ta đã quen đến mức nào với việc nút GUI chỉ thực thi khi thả nút chuột, và có những hành vi đặc thù như giữ chuột rồi đi ra khỏi vùng nút rồi quay lại
    Nút ngoài đời thực thì hơn 99% là hoạt động ngay khi được nhấn. Nhưng trong GUI, một nút hoạt động như vậy hẳn sẽ tạo cảm giác kỳ lạ

• Bài viết thực sự gần hơn với ý chính mà tác giả muốn nói là bài này: https://aresluna.org/show-your-hands-honor/

• Khi đang gọi điện mà nhấn nút bật/tắt màn hình của iPhone, có lúc cuộc gọi bị kết thúc, có lúc lại chỉ tắt màn hình thôi phải không?
  Đến giờ tôi vẫn chưa hiểu quy luật, nhưng trước khi bỏ iPhone vào túi, tôi từng nhấn nút đó rồi thỉnh thoảng vô tình cúp máy

  • Khi ở chế độ loa ngoài/rảnh tay thì nó chỉ tắt màn hình. Có vẻ họ giả định rằng khi áp điện thoại lên tai thì màn hình sẽ tự tắt, nên bạn sẽ không nhấn nút khóa. Vấn đề là đôi khi vì lỗi mà màn hình vẫn sáng, hoặc trong phòng yên tĩnh thì người ta cũng dùng nó như chế độ rảnh tay

[GN⁺]

Ý kiến trên Lobste.rs

• Hơi châm biếm nhẹ thôi, nhưng nếu nói về UI/UX tốt thì nhúng video không có cả điều khiển lẫn hiển thị là tệ nhất.
  Nhiều người mặc định tắt tự động phát, và tôi đã nhìn hai hình ảnh gần như giống hệt nhau khá lâu, nghĩ “vậy khác gì nhau?”

  • Tôi đã nghĩ “có video à?”, có vẻ tôi cũng bỏ lỡ.
  • Không hiểu vì sao lại là “tệ nhất”. Có phải chỉ cứ nghĩ “rồi sao?” mà không kéo xuống một chút để đọc phần giải thích vấn đề không?
  • Với chủ đề này thì phải công nhận GitHub hiển thị điều khiển phát cho GIF động. Gần như không thấy ở nơi khác.
  • Cũng có thể là khác biệt trình duyệt. Trên Vivaldi ở Android, tôi thấy nút phát lớn và thanh tiến trình.

• Tôi hoàn toàn đồng ý với “đừng bao giờ bắt người dùng chờ cho đến khi animation kết thúc”.
  Nếu là ứng dụng, lệnh của người dùng phải luôn được ưu tiên hơn việc trông cho đẹp.

• Tôi nghĩ nguyên tắc này cũng áp dụng cho game. Có những game sau khi mở menu sẽ có một độ trễ rất ngắn trước khi input được ghi nhận.
  Đây là vấn đề kiểu như trong một game có animation menu hào nhoáng, nếu bấm tạm dừng rồi nhanh chóng bấm phím xuống, thì sau khi menu hiện ra mục thứ hai có nên được chọn hay không.
  Trong game, input buffering là một chủ đề tinh tế, nhưng với thao tác menu thì nhìn chung hiếm khi bị cảm nhận là tệ.

• Cách video truyền tải thông tin không hay lắm. Phải tập trung nhìn mới nhận ra khoảnh khắc nút được bấm liên tiếp nhiều lần.
  Đi vào vấn đề chính thì cũng không rõ điện thoại Android có thật sự làm sai hay không. Tôi hiểu sự bực bội khi muốn bấm nhanh 8 lần để đạt kết quả mong muốn, nhưng nó làm tôi nhớ đến phát hiện double-click do nhầm trên OS desktop.
  Rốt cuộc có vẻ gần với khác biệt giữa tính khả dụng mà nhà sản xuất hình dung và sự tiện lợi mà người dùng cảm nhận. Nếu phải nói thì iPhone hiển thị nút “Done” ngay cả trong lúc animation lại khiến tôi thấy phân tâm hơn.

• Khó nói Android hoàn toàn sai. Tôi từng vì UI phản hồi chậm mà vô tình thực hiện một thao tác hai lần.
  Cách tốt nhất có thể là vô hiệu hóa nút cho đến khi animation kết thúc.

  • Làm vậy thì đúng vấn đề được nêu trong bài sẽ xảy ra. Gần như không thể xoay 90 độ ngược chiều kim đồng hồ mà không nhìn màn hình.
    “Bấm ba lần” không hoạt động, các lần bấm thêm trong lúc animation bị bỏ qua. Quy trình bấm, nhìn màn hình chờ animation kết thúc, rồi bấm lại và lại chờ rất chậm và đòi hỏi nhiều sự chú ý của người dùng.
    Giải pháp tốt hơn có vẻ là UI đưa phản hồi tức thì. Có thể render ngay trạng thái nút cho thấy cú bấm đã được xử lý, hoặc trước khi chạy animation toàn cục chậm, tạm thời vẽ lại màn hình thật nhanh để hiển thị tiến trình hiện tại.

• Tôi đồng ý mạnh mẽ với toàn bộ bài viết. Tôi muốn diễn đạt đây là vấn đề animation vi phạm lời thề Hippocrates.
  Nguyên tắc số một của animation phải là “trước hết, đừng gây hại”, tức “trước hết, đừng cản trở input của người dùng”.

• Bạn đã từng gặp rotary encoder không theo kịp chưa? Núm âm lượng trên headphone amp của tôi nếu xoay quá nhanh thì chẳng có gì xảy ra.
  Nếu tôi được làm tổng thống chỉ một ngày…

• Mỗi khi thấy những chuyện như thế này, tôi lại nghĩ nếu là GUI toolkit của mình thì sẽ ra sao. Toolkit của tôi xử lý hai cú bấm nhanh như double-click, giống hành vi mượn từ nền tảng Windows, và điều này đôi khi khiến tôi phát điên.
  Bản thân double-click là một quy ước phổ biến và có giá trị khác với click. Lý tưởng là nên làm event click có tính idempotent để dù xảy ra hai lần cũng không gây vấn đề. Ví dụ, nếu click là chọn mục, còn double-click là thực hiện hành động mặc định, thì chọn cùng một mục hai lần không gây hại. Nhưng thực tế không phải lúc nào cũng vậy.
  Vấn đề là nếu click một nút thật nhanh, nút có thể chỉ chạy một lần, còn lần tiếp theo đi thành event double-click và có thể không làm gì cả. Vì vậy sinh ra hành vi bấm nhanh thì một nửa số click bị bỏ qua.
  Vì vấn đề này tôi đã tạo một boolean tên triggersOnMultiClick; nếu đặt thành true, nó sẽ phát event trigger ngay cả với các lần bấm nhanh nhiều lần như double-click. Tuy nhiên vì tương thích ngược nên tôi để mặc định là false, nhưng đã đến lúc ra major release mới, và vì thấy lập luận trong bài có lý nên giờ tôi định đổi mặc định thành true.
  Có thể để lại kiểu như: “Bổ sung ngày 2 tháng 7 năm 2021, mặc định false. Ngày 5 tháng 7 năm 2026 (v13.0), đổi mặc định thành true để mọi lần click vào nút đều trigger theo mặc định. Nếu muốn hành vi cũ, hãy override event double-click hoặc đặt triggersOnMultiClick = false sau khi gọi constructor của lớp cha”.
  Ở phía triển khai animation cũng có thể vô tình sinh ra hành vi tương tự. Nếu trong object có biến vị trí animation và khi click thì đặt giá trị đó, thì khi click hai lần đại khái có hai lựa chọn. Hoặc bỏ qua phần animation còn lại và chuyển ngay sang trạng thái nội bộ tiếp theo, hoặc bỏ qua event để giữ độ mượt thị giác, kiểu if(animationCounter) return;. Có vẻ lập trình viên Android trong bài đã chọn cách sau.
  Phía Apple có lẽ dùng cách thứ ba, tức có một hàng đợi animation đang chờ và đưa event vào đó. Điều tôi tò mò là trạng thái nội bộ thay đổi khi đưa vào hàng đợi, khi hoàn tất, hay thật sự xoay ảnh bằng animation. Nếu cắt ngang animation rồi lưu thì có thể ra ảnh xoay 45 độ không? Nếu là tôi, có lẽ tôi sẽ cập nhật EXIF nguyên tử theo 90 độ và chạy animation chuyển tiếp riêng.
  Có thể có nhiều lựa chọn hợp lý giữa độ đơn giản triển khai, độ trung thực thị giác và hành vi UI. Cá nhân tôi cũng thích cách lần bấm thứ hai không chờ animation mà snap ngay sang trạng thái mới. Có lẽ tôi sẽ không làm hẳn hàng đợi animation.
  Thật buồn cười là lại sửa code vào thời điểm tương tự. Lần sửa trước cũng là 2 tháng 7, lần này tình cờ là 5 tháng 7. Tôi thích ghi luôn lịch sử như vậy vào comment tài liệu. Sau này khi thay đổi còn có thể đọc lại như một kỷ niệm.
  Apple có lẽ cung cấp hàng đợi animation mặc định, nhưng thời điểm thay đổi trạng thái vẫn là vấn đề riêng. Trên web, có lẽ sẽ cập nhật trạng thái một cách nguyên tử và tách riêng animation chỉ phục vụ hiển thị như chuyển tiếp CSS transform. Cũng tránh được recalculation layout, nên triển khai có vẻ dễ và hiệu quả. Nếu đổi tên class nhanh hơn animation thì nó sẽ nhảy hay được queue, sau này tôi muốn thử nghiệm.

• Có lẽ do già đi, tôi từng vài lần bực mình với hành vi kiểu này khi vô tình tap hai lần.
  Dùng nút ở cùng vị trí hoặc double-tap làm phương thức xác nhận là cực tệ. Nếu thật sự cần xác nhận, không nên thiết kế để việc xác nhận có thể xảy ra dễ dàng do nhầm.
  Tuy vậy trong ví dụ này, chấp nhận input liên tiếp nhanh có vẻ là ý hay. Trong trường hợp khác thì có thể không. Trong các nút vật lý, có những nút cố ý chặn việc bấm hai lần cho đến khi một thứ gì đó “kết thúc”, và dù không phải lúc nào cũng là thiết kế có ý thức, đôi khi đó là lựa chọn đúng.
  Cũng có nhiều người phải dùng thiết bị giật lag hoặc bị lỗi, và nếu có vấn đề sức khỏe như run tay hay run ngón tay, việc giới hạn input có thể có lợi.
  Ví dụ này có vẻ là trường hợp có thể xem cả hai phía đều ổn. Có những ví dụ phải chờ nên càng bực hơn, và chắc chắn cũng có những ví dụ mà ta muốn có giới hạn input, dù là do animation hay điều kiện khác.

• Việc kết quả tìm kiếm trên trình duyệt di động cập nhật ngay dưới ngón tay và đẩy lựa chọn tôi định bấm sang vị trí khác thật sự gây khó chịu không ngừng.
  Tôi đã tự rèn mình chờ lâu hơn, nhưng thật vô lý khi tương tác UI phải nhạy cảm với tác vụ bất đồng bộ nền có thời gian hoàn tất dao động vì tình trạng thu sóng.