Mọi khung hình đều hoàn hảo

• UI gần như là bề mặt duy nhất để người dùng đánh giá chất lượng ứng dụng, và để xây dựng niềm tin thì ở bất kỳ thời điểm nào chụp ảnh màn hình, trạng thái màn hình cũng phải có lý
• Một UI được hoàn thiện kỹ là tín hiệu cho thấy nhà phát triển đã dành thời gian tinh chỉnh, và trở thành một heuristic hợp lý rằng chất lượng mã nguồn cũng được trau chuốt tương tự
• Tiêu chuẩn thực sự là loại bỏ hiện tượng nháy trắng giữa các lần chuyển màn hình, tải từng phần, bố cục bị xê dịch trong lúc tải, câu chữ trạng thái không nhất quán và animation thiếu chính xác
• Dù trạng thái đầu và cuối có tốt đến đâu, nếu các khung hình ở giữa bị lệch thì vẫn tạo cảm giác các thành phần không được đồng bộ, và như ví dụ Photos, ngay cả ở chuyển đổi không có thay đổi thực sự cũng có thể tạo ra cảm giác giả
• Animation phải giúp người dùng hiểu được quá trình chuyển đổi, và không chỉ trạng thái đầu-cuối mà mọi khung hình ở giữa cũng phải được kiểm soát thì UI mới trở thành một công cụ chính xác

---

Nguyên tắc cốt lõi

• Mục tiêu được nêu rõ của Wayland là "every frame is perfect", một mục tiêu kỹ thuật nhằm giành lại quyền kiểm soát giữa sự phức tạp của ngăn xếp GPU hiện đại
• Nguyên tắc đó cũng áp dụng cho UI: ở bất kỳ khoảnh khắc nào của ứng dụng, ảnh chụp màn hình cũng phải trông tự nhiên và nhất quán
• Người dùng không thể nhìn thấy mã nguồn, vì vậy UI trở thành bề mặt duy nhất để đánh giá chất lượng ứng dụng
• Khi UI được trau chuốt tốt, đó là tín hiệu cho thấy nhà phát triển đã đầu tư thời gian đánh bóng, và dẫn đến nhận định rằng mã nguồn cũng được hoàn thiện ở mức tương tự

Tiêu chuẩn thực tế và ví dụ

• Để có những khung hình hoàn hảo, không được có nháy trắng giữa các màn hình, không có nội dung ở trạng thái chỉ tải một phần hoặc bố cục bị xê dịch trong khi tải
• Trạng thái nội bộ của UI phải nhất quán; không thể để một phần nói “1 update available” trong khi phần khác lại nói “Checking for updates...”
• Animation thường bị bỏ quên; dù trạng thái đầu và cuối có đẹp đến đâu, nếu phần ở giữa gượng gạo thì ảnh chụp màn hình ở giữa sẽ trở thành một khung hình vô lý
• Trong ví dụ Safari, văn bản placeholder di chuyển từ giữa, nhưng con trỏ lại được animate từ vị trí bên trái, tạo cảm giác hai thành phần không đồng bộ với nhau
• Trong ví dụ Photos, khi chuyển giữa chế độ Crop và Adjust, ảnh lập tức trở về đúng vị trí nhưng khung crop lại được animate, tạo ra cảm giác giả rằng có điều gì đó tinh vi đang thay đổi trong lúc chuyển chế độ
• Trong ví dụ UI tìm kiếm, animation lẽ ra phải giúp hiểu quá trình chuyển đổi thì ngược lại lại khiến chuyển động của biểu tượng kính lúp khó theo dõi hơn
• Trong ví dụ Youtube, ngay cả với tác vụ đơn giản là di chuyển một hình chữ nhật từ vị trí này sang vị trí khác, vẫn xuất hiện chuyển động kỳ lạ; bất kể nguyên nhân là gì, kết quả vẫn là những khung hình chưa hoàn hảo
• Kể cả với animation phóng to của ứng dụng Preview, điểm cốt lõi là phải chú ý không chỉ đến trạng thái đầu và cuối mà còn đến mọi khoảnh khắc ở giữa

[GN⁺]

Ý kiến trên Hacker News

• Đúng là một số ví dụ tác giả đưa ra là animation tệ, nhưng khó đồng ý với tiền đề của bài viết
  Đồ họa máy tính là lĩnh vực tận dụng đặc tính của hệ thống thị giác con người, và thứ đang chuyển động được cảm nhận khác với thứ đứng yên. Nếu tách riêng ra, một khung hình “sai” có khi lại trông đẹp nhất trong dòng chảy thời gian thực
  Lấy điện ảnh làm ví dụ, một cú tracking shot nhanh có thể khiến từng khung hình trông xấu vì motion blur, và một cảnh góc rộng có thể làm vật thể trông “sai” vì méo hình, nhưng nếu trong rạp nó tạo ra hiệu ứng nghệ thuật như chủ ý thì đó vẫn là lựa chọn đúng

  • Ban đầu tôi tưởng “Every Frame Perfect” có nghĩa là phải nghiêm ngặt tránh hiện tượng giật hay khựng trong chuyển động, và điểm đó thì tôi hoàn toàn đồng ý. Nhưng nhìn từ góc độ phim ảnh, video và công nghệ 3D, các artifact theo thời gian như motion blur không chỉ là thứ trông “đúng” nhất với hệ thống thị giác con người mà còn là dạng dễ diễn giải nhất
    Nếu thêm đúng loại blur vào chuyển động thì cảm giác sẽ sắc nét hơn, nhưng khi nhìn ảnh tĩnh thì dĩ nhiên không sắc nét hơn. Điểm mấu chốt là motion blur đúng sẽ bảo đảm hình ảnh chỉ sắc nét đến mức tương ứng với lượng chi tiết chuyển động mà con người có thể cảm nhận ở tốc độ đó. Vì vậy, đánh giá một khung hình motion blur đang đứng yên theo tiêu chí độ sắc nét hay khả năng diễn giải là sai
    Phần còn lại của bài viết tập trung vào chi tiết triển khai, nhưng lại bỏ lỡ cơ hội đặt câu hỏi liệu ngay từ đầu một số kiểu animation này có nên tồn tại hay không. Chuyển động có thể là một affordance tốt nếu dùng có chừng mực, nhưng giờ đây có lúc nó không chỉ bị lạm dụng mà còn xâm phạm tầm nhìn và tải nhận thức của người dùng. Designer và PM xem đó như dấu hiệu của “UX hiện đại tinh tế”, nhưng ở khía cạnh nào đó nó đã thoái hóa thành lớp trang trí chạy theo mốt, bắt chước thiết kế tốt chứ không phải thiết kế tốt thật sự
  • Bài này sẽ thuyết phục hơn nếu cũng đưa ra các ví dụ dùng tốt. Dù vậy, tôi đồng ý rằng cảm giác tổng thể của chuyển cảnh quan trọng hơn từng khung hình riêng lẻ
    Một số animation được nêu ra rõ ràng có thể cải thiện. AI có vẻ khá hợp để đẩy mạnh những niềm vui nhỏ kiểu này, vì trước đây độ ưu tiên thấp nên khó dành thời gian cho chúng
  • So sánh này có vẻ đi hơi xa. Khác với phim ảnh, UI không ghi lại hiện thực mà mọi pixel trên màn hình đều là kết quả do chúng ta sắp đặt, nên phép so sánh gần hơn là cartoon. Các khung hình trung gian trong cartoon không phải là khung hình lỗi mà thực sự là những khung hình hoàn chỉnh được trau chuốt kỹ
    Một khung hình trung gian của animation trông hơi “lạ” nhưng vẫn hợp logic là một chuyện, còn trạng thái trung gian thực sự vô lý và chỉ đơn thuần là hậu quả của việc chẳng ai quan tâm điều gì đang xảy ra trong lúc animation chạy lại là chuyện khác. Nếu là vế sau thì thà bỏ animation đi hoặc làm đơn giản hơn còn hơn
  • Animation phóng to của ứng dụng Preview ở cuối cũng cho thấy ví dụ ngược lại. Mọi khung hình đều hoàn hảo nếu xem riêng như điều tác giả mong muốn, nhưng vấn đề chỉ lộ ra khi xem như chuyển động
  • Ý tưởng rằng animation phải luôn nhất quán khi mổ xẻ theo từng khung hình không mấy thuyết phục. Người dùng thực tế không nhìn theo cách đó
    Góc nhìn của bài viết xem độ hoàn thiện UI như chỉ dấu thay thế cho chất lượng phần mềm là hay, và việc chỉ ra animation tệ cũng đúng. Chỉ là tính nhất quán theo từng frame không phải thước đo tốt nhất để đánh giá animation có “tốt” hay không

• Một số thiết bị vẫn còn Sonoma, và tôi chỉ có thể nói là mọi thứ đang thoái lùi dần đều
  Hộp thoại lưu có hơi rung một chút nhưng không rối như ví dụ. Các nút trong Notes di chuyển hoàn toàn mượt mà giữa các panel. Nếu liên tục focus rồi bỏ focus thanh Safari thì thỉnh thoảng animation bị lỗi, nhưng con trỏ vẫn khớp thời điểm chính xác với văn bản, và chỉ fade in sau khi văn bản đã dịch sang trái xong. Lỗi của Preview có vẻ cũng là vấn đề gần đây và tôi không tái hiện được
  https://streamable.com/kx7op6
  Tôi nhớ thời Apple, Sony, IBM và những công ty tương tự còn chăm chút các chi tiết cực nhỏ. Đặc biệt là Apple, hãng đạt giá trị như ngày nay nhờ iPhone; thời đó so với Windows Mobile hay Symbian PDA thì nó không hẳn có tính năng gì vượt trội, thậm chí ở vài mặt còn thua chức năng, nhưng ít ra đó là thiết bị cảm ứng hoàn toàn mà bạn không muốn dùng vài phút rồi ném vào tường. Những animation bây giờ gợi lại đúng cảm giác Windows Mobile và Symbian
  Tôi còn nhớ Steve thích animation của OS X đến mức nào. Trên sân khấu ông đã nhiều lần phát lại chúng ở chế độ slow motion. Mấy thứ bây giờ tệ đến mức nếu giao cho những người từng phải chịu số phận như người phụ trách vụ ăng-ten iPhone 4 thì cũng không lạ

  • Animation trong đoạn video ngắn thực sự trông trật tự hơn và bớt rối hơn. Có thể Apple trước đây dùng AppKit trên Sonoma, còn giờ đã chuyển sang SwiftUI

• Có vẻ một UI không có những khung hình lỗi kiểu này sẽ đem lại cảm giác tốt hơn, nhưng giờ tôi chỉ muốn có ai đó sửa từng clip rồi cho xem thực tế nó sẽ trông thế nào
  Đồng thời tôi cũng thắc mắc vì sao cái gì cũng cần chuyển động. Theo cách tôi hiểu, chuyển động nên được dùng khi UI thay đổi tinh tế ở một khu vực khác với nơi người dùng bắt đầu thao tác, kiểu như toast
  Khá nhiều chuyển cảnh ở đây có vẻ không cần thiết, và có lẽ chỉ cần đổi ngay lập tức kèm bố cục sắp xếp lại tức thì cũng đã đủ ổn

  • “Khung hình lỗi” trong ô tìm kiếm Safari xét về thực tế là ổn, và cách làm cho nó trông đẹp hơn trong ảnh chụp màn hình có thể còn tệ hơn
    Lý do con trỏ xuất hiện ở bên trái là vì đó là nơi người dùng thực sự bắt đầu gõ. Người hiểu UI có lẽ sẽ nhìn vào đó. Làm con trỏ xuất hiện ở giữa màn hình rồi mới di chuyển đi là thừa và gây xao nhãng
    Việc chữ giữ chỗ trượt sang trái là để thu hút sự chú ý của người dùng chưa quen
  • Máy đánh bạc lúc nào cũng phải có thứ gì đó chuyển động, và animation của Apple quá năng động cũng làm đúng vai trò đó. Animation UI nói chung giúp người dùng phổ thông đỡ bị choáng khi nội dung màn hình thay đổi đột ngột, đồng thời cũng giúp frame rate trông mượt hơn hoặc che giấu độ trễ từ API call hay xử lý backend
  • Nếu chơi một game có UI tốt, bạn sẽ thấy animation được dùng ở khắp nơi. Chuyển ngay lập tức chỉ hay trên lý thuyết
  • Không phải mọi thứ đều cần chuyển động. Phần lớn là không cần. Mấy việc vớ vẩn kiểu này tạo việc làm cho một số người, đồng thời cho vài người khác cái cớ để huênh hoang rằng ngôn ngữ thiết kế của $BRAND vượt trội hơn các lựa chọn khác
    Phần lớn ví dụ ở đây có lẽ sẽ cho cảm giác tốt hơn nếu không có animation. Bấm nút rồi thì cứ hiển thị kết quả. Đừng bắt nó nhảy múa xong mới hiện, cứ hiện luôn đi
  • Chuyển động rất quan trọng để khôi phục cảm nhận phương hướng sau một lần chuyển cảnh
    Nếu không có chuyển động, nhiều khi mỗi lần làm mới là não lại phải quét lại toàn bộ trang

• Tôi thấy lập luận của bài viết này được trình bày khá yếu. Cũng không có phương án thay thế tốt hơn, và cũng không thực sự giải thích vì sao những điều được nêu ra lại tiêu cực với người dùng. Chúng có thể tiêu cực, nhưng cách chỉ vào các smear frame của truyền thông hay các điểm chuyển tiếp để phê phán cũng giống một kiểu chỉ trích rỗng tuếch
  Tiêu chí “mọi frame đều phải hợp lý” cũng rất khó gánh nổi. Tôi cho là bất khả thi, và muốn hỏi nếu phải giữ mọi frame hoàn hảo ngay cả khi đang thay đổi kích thước cửa sổ thì sẽ làm thế nào
  Có vẻ ngay cả chính tác giả cũng thấy việc chỉ ra những frame có lỗi còn dễ hơn là thực hành tiêu chí mình nói ra. Nếu bấm vào liên kết ở phần đầu blog, hoạt ảnh chỉ chạy sau khi cú nhấp đã kết thúc. Nhìn vào dự án UI của chính tác giả thì cũng có chỗ văn bản và đối tượng không nằm gọn trong container. Nếu nói rằng nên tuân theo những nguyên tắc này thì bản thân cũng phải tự thể hiện được điều đó
  Nếu là một bài viết được viết chỉn chu hơn, nó hẳn đã tập trung vào vì sao những điều được nêu ra lại tệ với người dùng cuối và nên xử lý thay thế thế nào. Một lời phê bình tốt không chỉ có “cái gì” mà còn phải có cả vì sao và như thế nào

  • Lời phê bình này trái lại mới là thứ có vẻ rỗng tuếch nhất ở đây
    Bài viết đang đưa ra ý tưởng chứ không phải giải pháp. Không nhìn ra điều đó rồi dựng lên hàng loạt ngụy biện người rơm để chỉ trích
    Quan trọng hơn là bài viết không được viết theo kiểu khẳng định chắc nịch. Nó dùng những cách diễn đạt dè dặt như “I think”, “Next thought:”, “Probably”, “So yeah.”. Đây là một người đang chia sẻ suy nghĩ của mình, và đó là những suy nghĩ khá hoàn chỉnh, đủ để khiến nhiều người hợp lý khác suy nghĩ theo hướng tương tự
    Việc tác giả không đưa ra giải pháp không có nghĩa là họ bắt buộc phải làm vậy. Tiêu chí đó vừa kỳ quặc vừa không hợp lý
    Việc công kích trang của tác giả cũng không tạo cảm giác tốt đẹp gì. Khoảng cách về gu thẩm mỹ là điều ai cũng biết, và trừng phạt một đóng góp mang tính khái niệm chỉ vì nó đi trước kỹ thuật thực thi thực tế là điều khá khó chịu
    Một lời phê bình đúng nghĩa hơn hẳn đã rộng lượng hơn, đúng với tinh thần của cộng đồng này

• Tôi đã thấy vài phản hồi nói rằng họ ước tác giả có kèm ví dụ cách giải quyết. Gần đây tôi đã viết một bài rất giống bài này, cũng phân tích chi tiết vấn đề của animation như ở đây, rồi giải thích mình đã cải thiện nó ra sao
  Nếu tò mò thì có thể xem ở đây: https://www.thisischris.dev/projects/project-6/

  • Trên Chrome di động của Android, có vẻ animation không hoạt động

• Tôi cho rằng một frame chưa hoàn hảo ngay lúc này còn tốt hơn một frame hoàn hảo về sau. Trong mọi UI, độ trễ phải là ưu tiên số một. Nếu độ trễ đủ thấp thì nó sẽ có cảm giác như một phần cơ thể mình và làm giảm tải nhận thức. Animation đặc biệt tệ ở điểm này vì nó thêm vào độ trễ hàng trăm mili giây

  • Tôi nghĩ đó là một thế lưỡng nan sai lầm. Những ví dụ tác giả đưa ra, nếu được triển khai đúng cách, sẽ hoàn toàn không chậm đi chút nào
  • Có thể bạn tưởng tiêu đề đang nói về Wayland, và suy nghĩ đó là đúng. Nhưng đây không phải câu chuyện về Wayland

• Tôi ước gì ngoài các ví dụ tiêu cực còn có cả ví dụ tích cực. Lúc này kết luận tôi rút ra chỉ là nên tránh animation, trong khi có lẽ đó không phải điều tác giả thực sự muốn nói

  • Kết luận “nên tránh animation” không phải bài học tệ nhất. Nói chung nên tránh animation chỉ để có animation. Ví dụ, hãy tưởng tượng trên bàn phím điện thoại, mỗi lần gõ một chữ thì ký tự lại bay vọt lên ô nhập văn bản

• Animation tốt thường không nhất thiết trông hoàn hảo ở mọi frame; không hiếm trường hợp nó dùng một chút đánh lừa khi đang chuyển động. Giống như smear frame trong hoạt hình: nếu dừng sai frame thì trông kỳ quặc, nhưng trong toàn bộ animation nó lại khiến chuyển động trở nên thuyết phục hơn về mặt thị giác

  • Smear frame không phải kỹ thuật thường áp dụng cho kiểu animation này. Nó gần như chỉ dành riêng cho animation theo từng frame, và bài này không hề có smear frame
  • Khác biệt nằm ở chỗ các frame mờ được dùng có chủ đích để tạo hiệu ứng tổng thể. Còn các animation ở đây giống giật khựng ngoài ý muốn làm lộ ra một ứng dụng chưa được gọt giũa hơn
  • Tôi không nghĩ phép so sánh này phù hợp. Frame mờ trông ổn khi đang chuyển động, còn các frame trong bài blog thì nhìn lúc đang chuyển động cũng vẫn khủng khiếp. Ví dụ đầu tiên tệ đến mức lần đầu xem tôi tưởng phía trên sẽ còn lại ba nút, rồi đến lúc nhận ra cuối cùng chỉ có hai nút thì cảm giác vừa kỳ quặc vừa mất phương hướng
  • Trên macOS, tôi có cảm giác chất lượng thị giác và chất lượng animation đã thay đổi rất nhiều khi Apple bắt đầu dùng SwiftUI cho OS và ứng dụng
    Tôi không phải lập trình viên, nhưng vẫn cảm nhận được những khu vực mà icon hay cửa sổ không được sắp đặt hoặc di chuyển như trước đây, hoặc như lẽ ra chúng phải thế
    Cảm giác chắp vá này cũng không thay đổi theo thời gian. Có rất nhiều ví dụ khắp OS và ứng dụng khiến người ta muốn nói “nó vốn đã luôn như vậy”, nhưng thật ra không phải. Apple từng đặt ra tiêu chuẩn, và tiêu chuẩn đó rất cao, chất lượng cũng rất xuất sắc
    Có cảm giác như để đạt được cùng một cách bố trí UI hay animation bằng SwiftUI thì phải dùng rất nhiều mẹo vá víu
    Cuối cùng, điều tôi thường nghĩ đến là sáng tạo analog thực sự rất khó, trước đây đã vậy và giờ vẫn vậy. Với kỹ thuật số, ta vẫn thường nghĩ rằng sau này có thể quay lại chỉnh sửa, nhưng trên thực tế lại không làm vậy, và đáng buồn là nhiều khi chỉ chồng thêm cái tệ hơn lên trên cái đã tệ
  • Overwatch là một ví dụ hiện đại khá xuất sắc [1]. Nó có rất nhiều animation cực kỳ mượt, nhưng nếu dừng frame lại thì trông thực sự rất kỳ lạ
    [1]: https://youtu.be/vIdeGmN__Pw?t=550

• Một ứng dụng hoàn toàn không có animation sẽ cho cảm giác rất tệ. Nếu dùng Android, bạn có thể tự thử bằng cách vào tùy chọn nhà phát triển và đổi tốc độ animation thành 0x. Sự thay đổi tức thì gây khó chịu, và não thậm chí còn mất khoảng 1 giây để xử lý chuyện gì vừa xảy ra, quá trình đó có khi còn chậm hơn cả khi có animation
  Tôi để 0.5x và thấy là đủ. Vẫn nhanh nhưng vẫn có thể thấy ứng dụng mở ra và đóng lại

  • Tôi tắt animation trên Android và dùng rất hài lòng. Đó là cách duy nhất khiến nó thực sự có cảm giác “tức thì”. Trong bối cảnh từ đầu vào dẫn tới thay đổi UI, tôi cho rằng độ trễ luôn tệ hơn việc không có các trạng thái chuyển tiếp hào nhoáng
  • Trường hợp của tôi thì không vậy. Tôi luôn tắt animation. Vẫn hoàn toàn ổn, và vì không phải chờ animation chạy xong nên có thể thao tác điện thoại nhanh hơn nhiều
  • Tôi cũng dùng 0.5x
    Vấn đề của 0x là nó có vẻ chỉ áp dụng cho khoảng 90% UI. Một số thứ vẫn còn animation, và vì thế nhịp điệu trở nên rất kỳ quặc
    Ở 0.5x, những thứ kỳ lạ không chịu ảnh hưởng đúng bởi thiết lập tốc độ animation sẽ bớt gây khó chịu hơn
    Nếu nó hoạt động đúng nghĩa, tôi sẽ dùng 0x
  • Sau gần 10 năm dùng Android, cuối cùng tôi đã chuyển sang iPhone 12 Mini khi nó còn là máy mới. Điều tôi vẫn nhớ trên Android là khả năng tắt animation như vậy. Tôi chắc chắn 110% rằng nếu có thể tắt toàn bộ những animation chỉ tồn tại cho có thì chiếc điện thoại hiện tại của tôi sẽ nhanh hơn 200%
    Nếu cần thì tôi thà dành 1 giây cho xử lý còn hơn, mà thực ra tôi cũng không nghĩ là cần. Còn tốt hơn nhiều so với việc mỗi lần ứng dụng đổi trang lại bị chậm thêm 1 giây vì animation, khiến mọi thứ khi điều hướng đều đặc quánh như mật đường
  • Mọi animation chỉ là thời gian bị lãng phí trong lúc bạn không thể tương tác đúng nghĩa với UI, nên tốt hơn nhiều là tắt sạch tất cả

• Tôi đồng cảm với bài này, nhưng giá mà có thêm cả ví dụ tích cực thì tốt hơn. Giọng điệu không đến mức như đang than phiền, nhưng ở góc độ một người không biết nhiều về cách xây dựng UI tốt, tôi không cảm thấy mình tiến gần hơn tới việc nên lấy gì làm ngôi sao Bắc Cực

  • Gần đây tôi vừa viết đúng về chuyện đó. Trước hết tôi đi sâu vào những điểm chưa hoàn thiện về mặt khái niệm tương tự bài này, rồi sau đó giải thích quá trình cải thiện mà chính tôi đã làm
    Nếu tò mò, có thể xem ở đây: https://www.thisischris.dev/projects/project-6/
  • Hoặc tác giả cũng có thể đã làm mockup để cho thấy mỗi ví dụ tệ kia sẽ trông ra sao nếu được triển khai đúng cách

[GN⁺]

Ý kiến trên Lobste.rs

• Tôi cho rằng tiền đề cơ bản của bài viết này là sai. Người ta không dùng những ứng dụng như thế này theo từng khung hình
  Chỉ cần học một lớp hoạt hình cơ bản cũng sẽ biết cách con người nhận thức chuyển động khác với ảnh tĩnh. Nếu tìm demo về "squash and stretch", bạn sẽ thấy rằng kích thước của một vật thể ở từng khung hình riêng lẻ có thể hoàn toàn vô lý, nhưng trong chuyển động thì lại hoạt động rất đẹp mắt

  • Các ví dụ trong bài thậm chí khi đang chuyển động cũng không hề đẹp
  • Vấn đề không phải là hoạt ảnh xấu, mà là nó tạo ra một khoảng thời gian trong đó UI có thể dùng được bị thay bằng một chuỗi hoạt ảnh không thể tương tác
    Thậm chí như ví dụ cắt xén, nó còn có thể hiển thị sai trạng thái của chương trình. Người dùng buộc phải gần như “tắt não” và chờ khoảng một phần ba giây trong lúc UI tự lắp lại, rồi mới có thể tiếp tục dùng chương trình

• Tôi hoàn toàn không nghĩ frame-perfectness mà dự án Wayland nói tới có nghĩa là như vậy
  Nó gần với việc nói về các chi tiết kỹ thuật ở tầng thấp hơn, như khi thay đổi kích thước cửa sổ. Ví dụ như nội dung bị resize bất đồng bộ, hoặc vsync bị lỗi gây tearing hay các artifact chéo kỳ lạ trên màn hình, hoặc việc báo cáo vùng hỏng chỉ diễn ra theo các vùng con hình chữ nhật
  Tất nhiên sẽ rất tốt nếu cả chi tiết tầng thấp lẫn hoạt ảnh tầng cao đều hoàn hảo ở mức từng khung hình

  • Đồng ý. Và có vẻ tác giả bài viết cũng nhìn nhận như vậy

    Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

• Giả sử bạn muốn kiểm thử những hoạt ảnh kiểu này, và viết test để bảo đảm các thuộc tính đó không bị phá vỡ theo thời gian
  Hiện nay trong web app và native app, những kỹ thuật hiện đại nào được dùng để kiểm thử các thuộc tính như vậy? Có loại test cụ thể nào gần như bất khả thi hoặc rất khó viết vì bạn không thể kiểm soát event loop không?

  • Tôi chỉ có thể nói về native Android app. Nếu dùng bộ công cụ UI Jetpack Compose, bạn có thể điều khiển chính đồng hồ chạy UI, nên có thể chụp screenshot tĩnh ở bất kỳ điểm nào của transition để kiểm thử
    Hoặc dùng công cụ như Paparazzi để ghi lại toàn bộ transition thành Animated PNG nhằm làm kiểm thử hồi quy tự động
  • Lý tưởng nhất là thông tin kích thước phải được lộ ra, layout engine tổng quát phải có thể được kiểm thử độc lập, và hoạt ảnh cũng nên được tách rời
    Khi đó bạn có thể xác minh riêng hai phần đó, rồi cuối cùng chỉ cần kiểm tra trạng thái kết thúc. Hoạt ảnh không nên bị cố định vào đầu vào thời gian, mà phải có thể được điều khiển từng bước từ bên ngoài

• Tôi nghĩ ví dụ YouTube khá sát với một trường hợp của View Transitions
  Đây là kiểu khai báo “khi phần tử này thay đổi thì hãy tự động biến đổi hình dạng của nó”, và kết quả là một transition trông hơi nhão và lỏng lẻo dù về mặt kỹ thuật rất ấn tượng, với các phần tử lơ lửng và biến hình qua lại
  Công nghệ này rất ngầu, nhưng ngoài những hiệu ứng nhấn nhẹ khi điều hướng ra thì tôi hiếm khi thấy nó cho kết quả thực sự đẹp. Muốn tránh bị quá rối mắt thì phải dùng rất tiết chế