Thông báo toast là UX tệ

• Điểm yếu cốt lõi của thông báo toast là điểm chú ý hiện tại của người dùng và vị trí phản hồi bị tách rời, khiến khó liên hệ ngay kết quả với thao tác vừa thực hiện
• Luồng lưu của YouTube khiến ánh nhìn di chuyển từ nút Save bên phải, sang modal ở giữa, rồi đến toast ở góc dưới bên trái, làm gián đoạn tương tác và cũng không có chỉ báo tải trong lúc chờ
• Sau khi thay đổi checkbox, người dùng phải đợi đến khi toast trước biến mất mới có thể thấy thông báo xác nhận mới nhất, và nút Undo trên toast cũng là không cần thiết khi chỉ cần bấm lại vào checkbox
• Cách tốt hơn là đặt phản hồi ngay tại vị trí thao tác, ví dụ hiển thị playlist bên dưới nút và dùng chỉ báo tải trong lúc thay đổi checkbox để cho thấy trạng thái đang xử lý
• Điều còn tệ hơn toast là hoàn toàn không có phản hồi nào, nên nếu không có thời gian thiết kế hoặc triển khai phản hồi tốt hơn thì toast vẫn còn tốt hơn là không có gì

---

Vấn đề cơ bản của toast

• Thông báo toast thường xuất hiện ở vị trí khá xa so với nơi sự chú ý của người dùng đang hướng tới
• Khi phản hồi xuất hiện ở vị trí khác với nút vừa bấm hoặc vùng đang chỉnh sửa, người dùng sẽ khó liên kết hành động với kết quả để hiểu điều gì vừa xảy ra

Vấn đề trong luồng lưu của YouTube

• Trong ví dụ YouTube, sau khi người dùng nhấn nút Save ở bên phải màn hình, họ lần lượt phải nhìn vào modal ở giữa màn hình rồi toast ở góc dưới bên trái
• Luồng này buộc ánh nhìn phải di chuyển qua nhiều vị trí, đồng thời cũng khiến phản hồi khó được hiểu ngay lập tức
  • Toast bị trễ mà không có chỉ báo tải
  • Khi bật hoặc tắt checkbox trong modal, người dùng phải đợi vài giây cho đến khi toast trước biến mất mới thấy được toast xác nhận mới nhất
  • Nút Undo trên toast là không cần thiết vì người dùng chỉ cần bấm lại vào checkbox

Cách giải quyết không cần toast

• Chỉ với một thay đổi thiết kế đơn giản cũng có thể xử lý cùng loại phản hồi mà không cần toast
  • Hiển thị playlist ngay bên dưới nút thay vì trong modal
  • Hiển thị chỉ báo tải trong lúc bật hoặc tắt checkbox
  • Khi chỉ báo tải biến mất, người dùng sẽ tự nhiên hiểu rằng thao tác đã hoàn tất
• Vì phản hồi nằm ngay tại vị trí người dùng thao tác nên không cần toast riêng

Ví dụ về Gmail và phản hồi khi sao chép

• Khi lưu trữ email trong Gmail, một toast xác nhận sẽ xuất hiện
  • Nhưng chỉ riêng việc email biến mất khỏi danh sách cũng đã đủ cho thấy thao tác lưu trữ thành công
  • Tuy vậy, trong trường hợp có chức năng hoàn tác và khi dùng phím tắt, phản hồi bằng toast vẫn có thể hữu ích
• Cũng có những trường hợp sau khi sao chép thứ gì đó vào clipboard thì toast sẽ xuất hiện
  • Trong ví dụ này, bản thân nút đã bao gồm trạng thái xác nhận nên toast là hoàn toàn không cần thiết

Dù vậy, phản hồi vẫn là cần thiết

• Điều còn tệ hơn toast là không có bất kỳ phản hồi nào
• Nếu không có thời gian để thiết kế hoặc triển khai cơ chế phản hồi tốt hơn, thì toast vẫn tốt hơn là không có gì

Cách Cakedesk tránh dùng toast

• Cakedesk là ứng dụng hóa đơn ưu tiên offline, không thu phí thuê bao và có thể gửi email ngay trong ứng dụng
• Thay vì dùng toast để phản hồi sau khi nhấn nút Send của email, ứng dụng được thiết kế để sự thay đổi trạng thái tiếp diễn ngay trong cùng một luồng
  • Các hóa đơn chưa gửi có nút Send trong danh sách
  • Trong lúc gửi email, modal vẫn được giữ mở và nút gửi hiển thị trạng thái đang gửi
  • Khi gửi thành công, email được animate ra khỏi màn hình để biểu thị việc gửi đã hoàn tất
  • Nút Send trong danh sách đổi thành checkbox Paid, vừa xác nhận rằng email đã được gửi vừa dẫn người dùng sang hành động hữu ích tiếp theo
• Người dùng cũng có thể nhấn nút ngữ cảnh để kiểm tra xem email đã được gửi hay chưa

[wkang586]

Ý là toast tệ mới là vấn đề đúng không??

[GN⁺]

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

• https://en.wikipedia.org/w/index.php?title=Toast_(computing)

• Chưa bị thuyết phục. Phần lớn lập luận có vẻ theo kiểu UX dư thừa là UX tệ
  Tôi khó đồng ý mạnh với các ví dụ như: khi lưu trữ email thì nó biến mất khỏi danh sách nên đã ngầm báo thành công rồi, hoặc nút có dấu xác nhận nên toast là không cần thiết. Truyền đạt cùng một nội dung đồng thời bằng nhiều cách khác nhau không phải là bug mà là feature, và điều đó tồn tại trong ngôn ngữ con người nói chung. Vì nó giúp thông điệp vẫn được truyền tải ngay cả trong điều kiện không lý tưởng
  Toast thông báo trạng thái của mọi thao tác theo một cách chuẩn hóa, và nếu có thể thì cung cấp cả hoàn tác, nên giúp người dùng nhanh chóng học được pattern. Chỉ báo bổ sung gần thao tác cũng có giá trị, nhưng thường ý nghĩa sẽ rõ hơn khi đi cùng toast. Nếu bỏ toast và thay bằng nhiều chỉ báo cụ thể khác nhau, người dùng phải học nhiều cách diễn đạt “giờ đã xong” chỉ dựa vào ngữ cảnh. Điều này có thể đặc biệt không tốt với người cao tuổi, người khiếm thị, trẻ em
  Miễn là thực sự không gây cản trở, toast không phải UX tệ mà là UX dư thừa, và nhà thiết kế UX không nên ám ảnh với việc loại bỏ tính dư thừa

  • Đáng tiếc là hai thứ đó không truyền đạt cùng một nội dung
    Trong ví dụ YouTube, checkbox 100% là cập nhật lạc quan còn thông báo toast nghĩa là yêu cầu gửi bất đồng bộ tới backend đã thành công. Lưu trữ email cũng vậy: thư được loại khỏi danh sách một cách lạc quan, còn toast cho biết nó thực sự đã được lưu trữ
    Thà tôi chỉ muốn nhận toast khi commit thay đổi thất bại. Thường thì toast lóe lên sẽ kéo sự chú ý của tôi khỏi việc tôi đang làm, và nếu nó ở xa vị trí thao tác trên màn hình thì càng gây phân tâm hơn
  • Không, toast là tệ. Một thông điệp nằm ở rìa tầm nhìn hoặc sự chú ý của tôi, ví dụ bật lên ở một bên màn hình rộng, chủ động gây rối. Tôi đang xử lý vấn đề này ở đây, thế mà ở đằng kia có gì đó lóe lên. Đến lúc tôi chuyển tiêu điểm để đọc thì một nửa đã biến mất
    Nên đặt thông điệp ở nơi sự chú ý của người dùng đã hướng tới. UI đã dẫn mắt tôi tới đó, vậy thì hãy hiển thị ở đó
  • Tôi chủ yếu dùng máy tính với công cụ phóng đại, phóng to văn bản và vùng quanh con trỏ chuột/ngón tay. Toast và hầu hết thông báo không nằm ở vị trí tôi đang làm việc nên tôi gần như bỏ lỡ chúng. Với cách dùng của tôi, chỉ phản hồi ở gần mục đang tương tác mới có giá trị
  • Có người nói “sự dư thừa trong giao tiếp là feature chứ không phải bug”, nhưng nếu có quá nhiều thông tin nhiễu, người dùng sẽ được huấn luyện để phớt lờ chúng, và vấn đề nảy sinh khi thỉnh thoảng có thông tin thật sự quan trọng bị trộn vào
    Bài học là đừng gửi cho người dùng những thông tin không thật sự cần thiết
    Đọc thêm:
    https://en.wikipedia.org/wiki/Banner_blindness
    https://en.wikipedia.org/wiki/Alarm_fatigue
    https://en.wikipedia.org/wiki/Inattentional_blindness
    https://en.wikipedia.org/wiki/Habituation
  • Tôi nghĩ ý của cải tiến được đề xuất là thế này: nếu bạn lo rằng yếu tố UI mà người dùng tương tác không truyền đạt đủ tình huống hiện tại, thì đừng thêm một yếu tố thứ hai buộc người dùng phải chia sự chú ý, đọc nhanh rồi tự liên kết; hãy cải thiện chính yếu tố đó. Phải truyền đạt lỗi trong ngữ cảnh của yếu tố mà người dùng đã tương tác thì mối liên hệ mới rõ ràng
    Trong trường hợp tệ nhất, toast có lý như phương án cuối cùng để truyền đạt cho người dùng khi không còn ngữ cảnh. Ví dụ, người dùng bỏ chọn một playlist rồi đóng danh sách playlist trong lúc đang lưu, nhưng lưu thất bại; lúc đó ngữ cảnh của thao tác đã biến mất nên toast hiển thị thông tin ở một vị trí tùy ý nào đó trên màn hình cũng có thể hiểu được
    Dù vậy, nếu muốn người dùng thật sự hiểu lỗi, rất có thể toast không phải cách tốt nhất. Trong các ứng dụng dựa vào quảng cáo nơi người dùng là sản phẩm như YouTube, có thể họ không quá quan tâm việc người dùng bỏ lỡ lỗi này, thậm chí còn muốn vậy; nhưng với ứng dụng công việc, bạn sẽ không muốn đánh cược vào việc người dùng bỏ lỡ toast hoặc nhầm nó với lỗi khác. Thông thường, sẽ hữu ích hơn nếu mở lại yếu tố tương ứng cho người dùng và hiển thị lỗi trong ngữ cảnh. Có thể mở danh sách playlist và dùng animation để thu hút chú ý vào việc thay đổi chưa được lưu. Đây có thể là một lý tưởng luận khó triển khai một cách có hệ thống, nhưng về lý tưởng thì người dùng luôn nên thấy lỗi trong ngữ cảnh

• Điểm tệ nhất là toast biến mất quá nhanh, và còn thu hút sự chú ý một cách không cần thiết ngay cả với những thao tác mà thành công là điều hiển nhiên. Khi hai điều này kết hợp lại thì đặc biệt gây khó chịu. Sự chú ý bị cướp đi không cần thiết, nhưng vì nó biến mất quá nhanh nên bạn không biết liệu nội dung đó có thực sự không quan trọng hay không. Ngược lại cũng có biến thể tồn tại quá lâu, che mất một phần UI mà bạn định nhìn và dùng ngay
  Cách làm desktop truyền thống là tốt. Thông báo lỗi được hiển thị dưới dạng modal để không bị bỏ lỡ, còn thông báo thành công thì hiển thị bằng văn bản thông thường, không gây gián đoạn, trên thanh trạng thái luôn hiện và không có giới hạn thời gian. Nếu không có modal lỗi, người dùng có thể giả định thao tác đã thành công; nếu cần xác nhận, họ có thể kiểm tra trên thanh trạng thái mà không bị áp lực thời gian. Cũng có thể chứa thêm thông tin phụ
  Một số ứng dụng còn hiển thị lịch sử thông báo trên thanh trạng thái dưới dạng popup. Trong cách này, thanh trạng thái giống như dòng output cuối cùng của terminal dòng lệnh, và có thể gọi lại cả các output trước đó

  • Nói thêm, có những toast hiển thị thông tin quan trọng mà người dùng cần, nhưng lại biến mất quá nhanh, và do giới hạn kích thước của toast nên nội dung cũng không đầy đủ
    Tôi thường phải vào phần thông báo để xem lại nội dung đã bỏ lỡ. Vì nó trông có vẻ quan trọng nhưng tôi không có đủ thời gian để đọc hết. Khi nhấn vào một mục trông như một thông điệp bị cắt cụt ở đó, tôi kỳ vọng nó sẽ đưa tôi đến ngữ cảnh đầy đủ, nhưng thực tế là thông báo biến mất, ứng dụng chỉ được mở ra, và không deep link đến vấn đề tương ứng. Khi đó tôi phải lần mò tìm một vấn đề có thể có hoặc không được lộ ra trong UI tiêu chuẩn của ứng dụng
    Tôi đã gặp chuyện này không đếm xuể, và lần nào cũng tức giận với người đã thiết kế ra hệ thống như vậy
  • Toast khiến người ta có cảm giác rằng hẳn ở đâu đó sẽ có một event log để sau này nhìn lại xem chuyện gì đã xảy ra. Thực tế là không có event log nào có thể truy cập được, và khi thông điệp toast hết thời gian rồi biến mất thì nó biến mất mãi mãi
  • Thử một thí nghiệm tư duy: toast nên ở lại trên màn hình trong bao lâu? Phải cho người dùng thời gian đọc, nhưng vì không biết khi nào người dùng sẽ ngước mắt lên, cũng không biết tốc độ đọc của họ, nên không có giới hạn trên nào an toàn
    Hôm nay tôi đã gặp vấn đề này với con trai mình. Thằng bé đang luyện tốc độ đọc nên chúng tôi cùng dùng một ứng dụng mới, nhưng các toast cứ liên tục hiện lên khiến nó khó theo kịp và bị xao nhãng. Cuối cùng tôi phải đọc to cho nó nghe. Nếu thông điệp ở lại lâu hơn, có lẽ nó đã có thể làm được mà không cần trợ giúp thêm
  • Cách giải quyết tốt hơn là giả định thành công, và chỉ hiển thị những thông điệp như vậy khi xảy ra lỗi
  • Kiểu triển khai toast tệ nhất là thật sự che các phần tử UI, khiến chúng vừa không nhìn thấy vừa không bấm được cho đến khi toast biến mất

• YouTube có một ví dụ hay hơn
  Vào https://www.youtube.com/feed/history, nhấn “Comments” ở bên phải rồi thử xóa một bình luận; một toast cho biết bình luận dự kiến sẽ bị xóa sẽ hiện ra, và 1–2 giây sau lại có thêm một toast nữa cho biết đã xóa
  Nếu xóa nhanh nhiều bình luận liên tiếp, trước hết sẽ hiện nhiều toast báo dự kiến xóa, rồi sau độ trễ 1–2 giây, từng toast xác nhận sẽ lần lượt hiện ra. Việc xóa thực tế cũng diễn ra tuần tự, nên phải chờ tất cả các toast xác nhận. Dù bạn bấm 10 bình luận chỉ trong 2–3 giây, phần xác nhận vẫn mất hơn 10 giây
  Bình luận trực tiếp cũng tương tự:
  https://myactivity.google.com/page?page=youtube_live_chat&co...

• Tôi thường không đồng ý với đoạn “nút Undo trên toast là không cần thiết vì người dùng chỉ cần bấm lại checkbox”. Khi lỡ bấm nhầm vào đâu đó mà không biết chính xác là đâu, và bạn không rành ứng dụng đến mức chỉ nhìn thông báo là dễ dàng đảo ngược được, thì hoàn tác là rất hữu ích

  • Trong ví dụ cụ thể này, nút hoàn tác vốn đã có sẵn. Chính là checkbox đó. Vấn đề là nó không khớp với trạng thái chính xác mà checkbox phải biểu thị. Khi tích vào, trong vài giây nó đã được tích nhưng video vẫn chưa được lưu; khi bỏ tích, cho đến khi toast xuất hiện thì nó vẫn chưa được bỏ lưu. Nếu liên tục tích/bỏ tích, bạn không thể biết trạng thái cuối cùng là gì
  • Tôi đã gặp chuyện như vậy ở một số hệ thống. Tôi biết mình vừa đổi nhầm một mục, nhưng không biết đó là mục nào và cũng không có manh mối. Điều này đặc biệt thành vấn đề khi cũng có khả năng là chẳng có gì thay đổi, nhưng bạn không thể chắc chắn
    Lấy ví dụ cực đoan: giả sử trong lúc bạn quay lưng đi, một quả bóng lăn khỏi kệ và đập vào bàn phím. Có gì đã thay đổi không? Thứ gì đã thay đổi? Sửa thế nào?

• Toast chỉ hợp lý trong đúng một trường hợp: khi đó là thông báo không liên quan đến hành động hiện tại của người dùng. Nó giống kiểu thông báo cấp OS mà Growl đã tạo ra và nay đã biến mất
  Phản hồi cho hành động của người dùng phải diễn ra trong ngữ cảnh của chính hành động đó. Nếu là thao tác bất đồng bộ thì điều đó phải rõ ràng, và phản hồi phải ngay lập tức cho thấy tác vụ đó đã được đưa vào hàng đợi xử lý. Trong trường hợp này, phản hồi nên cung cấp các lựa chọn như hủy, truy cập hàng đợi, và tốt hơn nữa là xem được tiến độ

  • Tôi muốn bổ sung thêm một kịch bản. Thường là khi phần tử UI để đưa ra phản hồi đã bị loại bỏ, nhưng ta vẫn muốn hiển thị phản hồi
    Nếu bạn xóa một tác vụ khỏi board, bạn không thể hiển thị cách hoàn tác ngay trên tác vụ đó. Có thể hoàn tác bằng phím tắt, nhưng làm sao người dùng biết được bằng trực quan?
    Danh sách tác vụ chỉ nên có các tác vụ, nên tôi sẽ không chèn ghi chú thay cho tác vụ. Tôi cũng sẽ không tạo ra một thứ giống tác vụ phái sinh chỉ để hiển thị thông báo. Làm vậy chẳng khác nào nhét một ý đồ không có chức năng vào component tác vụ. Tôi cũng không muốn hoàn toàn không báo cho người dùng. Việc tác vụ đã bị xóa thì rõ ràng, nhưng cách hoàn tác một hành động đáng lo xảy ra chỉ bằng một cú nhấp thì lại không rõ. Cũng không thể lần nào trước khi xóa tác vụ cũng bắt xác nhận phiền phức. Đây là chức năng cốt lõi của danh sách tác vụ, nên nó phải được thực hiện ngay và có thể hủy ngay
    Sẽ có nhiều trường hợp đặc biệt nhỏ kiểu này. Toast được phát minh là có lý do. Việc người ta lạm dụng nó một cách “dễ thương” không có nghĩa là nó không hữu ích cụ thể trong một số kịch bản nhất định
  • Với các thao tác dạng modal mà sau khi người dùng khởi động, trong 99% trường hợp họ muốn đưa tác vụ đó chạy ở nền rồi làm việc khác, thì nên đưa phản hồi như vậy ở đâu?
  • Cũng có ví dụ tuy liên quan đến hành động hiện tại của người dùng nhưng nằm ngoài phạm vi màn hình đang hiển thị. Chẳng hạn khi cắm USB hoặc thực hiện một chức năng liên quan đến phần cứng khác
    Những hành động như vậy không có ngữ cảnh trên màn hình, và thường cần thêm hành động bổ sung. Ngay cả khi không cần hành động bổ sung, việc xác nhận rằng hành động của người dùng đã được phát hiện rõ ràng vẫn hữu ích
  • Không phải nói rằng Growl đã phát minh ra thông báo kiểu OS. Growl ra mắt năm 2004, còn Windows XP đã có thông báo từ năm 2001. Nếu xem các thông điệp của Clippy là thông báo, thì ít nhất có thể lần ngược về Microsoft Bob (1995)

• Nói cho những ai từng bối rối: bài này nói về một loại widget UI [2], chứ không phải bánh mì nướng [1]
  [1] https://en.wikipedia.org/wiki/Toast_(food)
  [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

  • Thật mỉa mai khi một bài viết bàn về các mô thức giao tiếp kém lại không giải thích toast ở đây nghĩa là gì
    Đây là từ quan trọng nhất trên trang, vậy mà rõ ràng ngay cả trong nhóm độc giả kỹ thuật cũng có người không hiểu thuật ngữ chuyên môn này
    Dù vậy, có lẽ nhờ những độc giả quan tâm đến làm bánh và công thức bữa sáng mà mức độ tương tác còn tăng thêm

• Về câu “nút Undo trong toast là không cần thiết vì người dùng chỉ cần nhấp lại checkbox”, tôi đặc biệt biết ơn chức năng này. Không biết bao nhiêu lần tôi tưởng mình đã lưu trữ email, nhưng toast lại cho biết tôi đã bấm nút báo cáo spam. Nếu không có nó thì tôi đã hoàn toàn không biết
  Một vấn đề nền tảng khác của toast mà bài gốc bỏ sót là các thao tác web có tính bất đồng bộ. Ta không biết thao tác đã thành công, thất bại, hay thậm chí đã được ghi nhận trên server chưa. Toast cung cấp cập nhật bất đồng bộ về trạng thái server
  Tất nhiên tôi đồng ý rằng một số toast gây khó chịu, có khi che nội dung UI quan trọng và còn không thể đóng

  • Bài gốc đã hoàn toàn bỏ lỡ điểm chính của toast. Một số hành động của người dùng 1) có thể được thực hiện do nhầm lẫn và 2) thường được thực hiện lặp đi lặp lại, nên không phù hợp với hộp xác nhận
    Vì vậy, nếu bạn lỡ bấm nhầm gì đó và email đột ngột biến mất khỏi hộp thư đến, bạn cần một toast có nút hoàn tác. Nếu chỉ đang đứng yên mà người bạn tựa vào nút nào đó rồi toast đột nhiên hiện ra, bạn sẽ thấy may là nó có mặt. Nếu có thể, nên có mô tả hành động đã thực hiện và nút hoàn tác
    Trong Gimp, nhấn Tab sẽ ẩn toàn bộ UI, và nếu không biết phím tắt thì không có cách nào khôi phục. Với nghệ sĩ muốn tập trung xem ảnh thì đây là tính năng đáng mong muốn. Nhưng khi tôi lỡ nhấn và phải tìm “gimp how to fix interface disappeared”, tôi mới thấy mình tha thiết cần một toast có nút undo đến mức nào. Tôi không thể tưởng tượng người không rành máy tính sẽ phản ứng ra sao

• Toast có thể là UX tệ. Thường là khi nó là phản hồi duy nhất, nhưng nếu dùng cùng các yếu tố khác thì rất tuyệt
  Toast xác nhận hiện cùng với chuyển hướng trang là một dấu hiệu bổ sung tốt cho biết việc gửi đã thành công
  Toast cảnh báo hoặc lỗi hiện cùng với chỉ báo kiểm tra form chuẩn trở thành dấu hiệu thứ cấp rất tốt rằng người dùng cần thay đổi gì đó
  Nếu triển khai để xử lý bao quát các lỗi không xác định, nó có thể giữ nguyên trạng thái trang của người dùng mà không phải đưa họ sang trang lỗi
  Nếu dùng như một công cụ trong hộp đồ nghề, chứ không phải công cụ duy nhất, thì đó là một lựa chọn tốt

• Có thứ còn tệ hơn toast. Đó là panel trượt bị ẩn. Về cơ bản là một toast bị ẩn, cần cho một số thao tác nhưng hoàn toàn không trực quan, cũng không thể tìm thấy hay phát hiện ra. Trải nghiệm tệ nhất của tôi là khi dùng Waze trên điện thoại của người khác. Tôi phải làm gì đó nhưng không nhớ là gì, chỉ nhìn chằm chằm vào màn hình và đoán xem nên làm gì. Cuối cùng người đó lấy lại điện thoại và trượt panel ẩn từ bên phải ra cho tôi xem
  Tôi hiểu là để tiết kiệm không gian, nhưng thật sự quá vô lý. Chuyên gia UX làm sao có thể kỳ vọng người dùng đoán ra chuyện đó? UI ngày nay được làm với giả định rằng người ta sẽ chọc chỗ này chỗ kia như trẻ con để khám phá à?

  • Nếu người dùng đã biết, và không vượt quá 1 phần chính cùng 2 sidebar, thì tôi nghĩ UX mở sidebar bằng cách trượt trái/phải là ổn
    Ứng dụng di động Discord trước đây dùng cách này cho cả sidebar bên trái lẫn bên phải, nhưng đến một lúc nào đó có ai đó nảy ra ý tưởng “tuyệt vời” rằng cử chỉ “vuốt để trả lời” quan trọng hơn điều hướng trong app, và giờ muốn xem sidebar bên phải thì phải bấm một nút nhỏ, mơ hồ
  • Tôi nhớ ngay khi cài Snapchat đã lập tức nhận ra nó kinh khủng đến mức nào. Mỗi góc khác nhau lại có một chức năng khác nhau. Những thứ như thế nên bị coi là bất hợp pháp
  • Hoàn toàn đồng ý. iOS tất nhiên đầy rẫy những thứ như vậy, kể cả trên tablet có dư dả không gian màn hình
  • Phần lớn “toast” — giờ thì tôi đã biết thuật ngữ này — tôi thấy là thừa và vô dụng. Thường thì tôi bỏ lỡ hoàn toàn. Nhìn chung tôi cho là chúng không gây hại, nhưng không nên dùng để truyền tải thông tin quan trọng
    Về “panel ẩn”, tôi luôn nghĩ đó là bug, nhưng có lẽ ai đó đã xem nó là một ý tưởng hay
    Tôi thường dùng ứng dụng Apple Connect để quản lý app trên App Store. Khi dùng iPad Mini ở chế độ dọc rồi chọn một trong các app của mình, nút quay lại thường biến mất. Khi đó tôi không thể chọn tài khoản khác hoặc chọn app khác trong tài khoản hiện tại
    Cho đến khi tôi xoay iPad sang ngang về mặt vật lý. Lúc đó navigator xuất hiện ở bên trái, và tôi có thể chọn app khác hoặc đổi tài khoản
    Thành thật mà nói, tôi khá thất vọng với toàn bộ UX backend của Apple App Store. Frontend thì tôi cũng không thích lắm, nhưng backend là nơi tôi dùng thường xuyên. Xét việc họ chăm chút rất nhiều cho trải nghiệm người dùng ở phần còn lại của nền tảng, điều đó khá gây sốc