Nút bật/tắt nên hiển thị trạng thái hiện tại hay trạng thái sẽ được chuyển sang? (2010)

• Nếu dùng cùng một kiểu toggle cho hành động được thực thi ngay như Play/Pause và thiết lập được duy trì như Shuffle, người dùng có thể nhầm lẫn giữa trạng thái hiện tại và hành động tiếp theo
• About Face 2.0 khuyến nghị tránh flip-flop button, tức đưa hai lựa chọn vào một control; sách cho rằng việc truyền đạt trạng thái hiện tại quan trọng hơn tiết kiệm không gian
• Cách giải gần với việc viết hành động dưới dạng cụm động từ như Switch to portrait mode, hoặc tách trạng thái và thao tác chuyển đổi bằng radio button, checkbox, nhãn trạng thái + nút hành động
• Nếu văn bản nằm trong nút như switch kiểu iOS, ON có thể mơ hồ: đó là trạng thái hiện tại hay trạng thái tiếp theo; còn nếu đặt văn bản trạng thái bên ngoài nút như kiểu OS X hoặc Windows Metro thì giảm được sự mơ hồ
• Quy ước Play/Pause có thể là ngoại lệ, khi hiển thị hành động tiếp theo; nhưng với các tùy chọn như Shuffle, Like, Auto save, an toàn hơn là nhấn mạnh trạng thái hiện tại và bổ sung bằng tooltip, màu sắc, trạng thái được nhấn, nhãn riêng

---

Xung đột giữa hiển thị trạng thái và hiển thị hành động

• Với các nút chuyển qua lại giữa hai trạng thái như Play/Pause, Shuffle/Regular Play, vấn đề cốt lõi là nên hiển thị trạng thái hiện tại hay trạng thái chuyển đổi sau khi bấm
• Play/Pause dễ được người dùng hiểu như hành động “bắt đầu phát” hoặc “tạm dừng”, nên quy ước hiển thị Play khi đang dừng và Pause khi đang phát đã trở nên quen thuộc
• Shuffle/Regular Play gần với trạng thái tùy chọn của cách phát nhạc; nếu hiển thị trạng thái sẽ chuyển sang, người dùng có thể bối rối không biết hiện đang phát ngẫu nhiên hay phát tuần tự
• Trình phát nhạc tích hợp của Xbox 360 được nêu như một ví dụ gây nhầm lẫn: khi đang ở chế độ shuffle thì lại hiển thị biểu tượng phát trực tiếp, và trong tình huống ngược lại cũng hiển thị ngược lại

Khuyến nghị của About Face: tránh flip-flop button

• About Face 2.0 phân loại kiểu này là flip-flop button, một “mẫu lựa chọn nên tránh”
• Khi một nút điều khiển hai tùy chọn loại trừ lẫn nhau, nó tiết kiệm không gian, nhưng khó đáp ứng nhiệm vụ thứ hai của control là truyền đạt trạng thái hiện tại
• Nếu nút hiển thị ON trong khi trạng thái hiện tại là tắt, trạng thái thiết lập sẽ không rõ ràng; còn nếu hiển thị OFF khi đang tắt, người dùng có thể bối rối không biết nút ON ở đâu
• Có hai giải pháp được khuyến nghị
  • Diễn đạt hành động của nút thành cụm động từ như Switch to portrait mode
  • Dùng kỹ thuật UI khác làm lộ rõ việc chọn trạng thái, chẳng hạn hai radio button

Phân biệt nút hành động và nút trạng thái

• action button và state button cần được thiết kế khác nhau
  • Nếu là hành động như Play/Pause, hãy hiển thị điều sẽ xảy ra khi bấm
  • Nếu là tùy chọn như Shuffle/Linear, hãy hiển thị trạng thái hiện tại
• Nếu là nút Shuffle chỉ có biểu tượng, cách phù hợp là giữ một biểu tượng shuffle duy nhất và làm cho nó trông bật/tắt tùy theo trạng thái
  • Trạng thái bật có thể sáng hơn hoặc trông như nút đang được nhấn
  • Ở trạng thái tắt, người dùng phải có thể nhận ra ngay đó là phát tuần tự
  • Trong môi trường có hover, có thể thêm tooltip để làm rõ hơn
• Cũng có ý kiến cho rằng Play/Pause có thể giảm nhầm lẫn nếu không đổi nhãn mà hiển thị nút Play ở trạng thái đang được nhấn

Sự mơ hồ do văn bản bên trong nút tạo ra

• Trong tiếng Anh, ON và OFF có thể được đọc như trạng thái hoặc như hành động chuyển đổi, nên nếu đặt trong nút thì ranh giới trạng thái hay lệnh có thể bị mờ
• Các cặp từ sau được đề xuất là rõ ràng hơn
  • Enable / Disable
  • Enabled / Disabled
  • Start / Stop
  • Running / Stopped
• Chỉ chọn từ thôi không làm vấn đề biến mất hoàn toàn
  • Người dùng vẫn có thể phải phán đoán văn bản trên nút là trạng thái hay lệnh
  • Khác biệt giữa Enable và Enabled có thể không đủ rõ trong UI

Nhãn bên ngoài nút và tách trạng thái + hành động

• Nếu không đặt văn bản trong chính nút mà bố trí văn bản bên ngoài nút, có thể hiển thị cùng lúc trạng thái hiện tại và trạng thái có thể chuyển sang
• Switch kiểu OS X không nói nút là ON hay OFF; văn bản xung quanh switch biểu thị trạng thái, nên giảm câu hỏi “nút này là trạng thái hiện tại hay hành động tiếp theo”
• Cách của Windows Metro UI dùng màu nút để biểu thị trạng thái hiện tại và dùng dòng On/Off dưới văn bản tùy chọn để xác nhận lại trạng thái hiện tại
• Cũng có thể tách thành nhãn trạng thái + nút hành động như Online [Go offline]
  • Online là nhãn trạng thái hiện tại không bấm được
  • Go offline là hành động chuyển đổi có thể bấm
  • Sau khi bấm, nó đổi thành Offline [Go online]
• Cách này gọn hơn radio button nhưng vẫn tách được vai trò trực quan của trạng thái và hành động

Checkbox, radio button và trạng thái được nhấn

• Các tùy chọn như Shuffle sẽ ít gây nhầm lẫn hơn nếu được biểu diễn bằng checkbox có nhãn Shuffle
• Khi dùng một từ duy nhất và trạng thái checked để cho biết đang bật hay không, người dùng bớt phải diễn giải ý nghĩa giữa nhiều từ
• Nên tránh các biểu thức có tiền tố phủ định
  • Các tiền tố như Not, Non-, Un-, Dis-, Im-, Mis-, In-, Il-, Ir- có thể bị đọc như phủ định kép khi kết hợp với trạng thái bỏ chọn
• Nút Like của ứng dụng Facebook Android là ví dụ: màu xám khi tắt và được nhấn mạnh bằng màu xanh khi bật
  • Tuy vậy, chỉ dùng màu sắc có thể chưa đủ với người dùng có rối loạn nhận biết màu

Ví dụ UI thực tế và điểm cần chú ý

• Có phương án dung hòa như nút Shuffle của Spotify web app: dùng màu trung tính khi tắt và màu nhấn khi bật
• Chuyển đổi khi hover kiểu Twitter là cách hiển thị trạng thái hiện tại, rồi khi đưa chuột lên thì hiển thị hành động
  • Cách này có thể hoạt động trong môi trường có hover, nhưng trên màn hình cảm ứng thì cùng một cơ chế có thể không áp dụng được
• Switch kiểu iOS hiển thị cả hai trạng thái trong một control, nhưng cũng bị phê bình vì ON mơ hồ: đó là trạng thái hiện tại hay trạng thái sẽ đổi sang khi bấm
• UI thiết lập của Discord là ví dụ về toggle dạng checkbox làm rõ hơn trạng thái hiện tại và trạng thái tương lai
• Cũng có các ví dụ như toggle khi mouseover của Evernote, hay công tắc tay nắm kiểu nhà vệ sinh trên máy bay, nơi trạng thái và khả năng thao tác cùng được bộc lộ

Nguyên tắc thiết kế

• Khi một control đồng thời đảm nhiệm truyền đạt trạng thái và truyền đạt hành động, sự mơ hồ sẽ phát sinh
• Trạng thái hiện tại phải được truyền đạt bằng cách này hay cách khác
  • Với Play/Pause, phản hồi bên ngoài như âm nhạc đang phát hoặc thời gian đang chạy có thể bổ sung cho trạng thái hiện tại
  • Với Shuffle, khó biết trạng thái cho đến khi thấy bài tiếp theo thực sự được chọn như thế nào, nên việc chính nút hiển thị trạng thái càng quan trọng hơn
• Cách dùng một nút duy nhất để xoay vòng qua nhiều trạng thái có thể nén UI và gom các thiết lập loại trừ lẫn nhau, nhưng người dùng phải có thể nhanh chóng nhận biết trạng thái hiện tại
• Do quy ước mạnh, Play/Pause có thể là ngoại lệ hiển thị hành động tiếp theo; với toggle tùy chọn nói chung, nhấn mạnh trạng thái hiện tại sẽ nhất quán hơn

[GN⁺]

Ý kiến trên Hacker News

• Dạo này tôi thật sự bực mình vì Microsoft Teams. Trên ứng dụng desktop, khi đang tắt tiếng thì biểu tượng micro có một gạch chéo, còn khi bỏ tắt tiếng thì đổi thành micro không có gạch, nên rất dễ hiểu
  Nhưng khi tham gia bằng ứng dụng điện thoại, cùng biểu tượng micro có gạch chéo đó lại có nghĩa là “hiện không tắt tiếng, nhấn nút này sẽ tắt tiếng”. Sau khi nhấn, biểu tượng vẫn là micro có gạch chéo, chỉ có nền bị đảo màu
  Tôi tự hỏi có phải một bên là nút “bật micro”, còn bên kia là nút “bật tắt tiếng”, nên mới dùng cùng một biểu tượng không. Rốt cuộc phải biết nút trông như thế nào ở trạng thái ngược lại thì mới phán đoán được trạng thái hiện tại, nên lần nào tôi cũng phải bấm thử vài lần để kiểm tra xem ứng dụng này dùng kiểu nào
  Không biết đây có phải là cái giá của flat UI khi đã mất đi vật tham chiếu trong thế giới thực không

  • Tôi nghĩ một phần sự lẫn lộn này đến từ tư duy rằng micro mặc định là bật. Mẫu thiết kế coi “micro hoạt động” là mặc định và tắt tiếng là trạng thái lệch khỏi mặc định đó kéo dài từ UI của hệ thống hội nghị qua điện thoại, điện thoại analog, và xa hơn nữa là thời kỳ còn có đường dây vật lý nối giữa các bên
    Mixer âm thanh cho nhạc live hoặc thu âm cũng thường dùng cùng mẫu này. Khi kênh bị tắt, nút “Mute” sáng đèn đỏ; chỉ một số thiết bị mới có nút “ON” phía trên fader sáng lên để biểu thị kênh đang hoạt động
    Tôi nghĩ đã đến lúc các ứng dụng họp chuyển sang cách tiếp cận âm thanh mặc định là tắt. Ta đã thấy điều này lác đác qua cách phần tử UI sáng lên khi người nói phát biểu
  • Đây thật sự là một nút không được phép gây nhầm lẫn
  • Trong Plex cũng bực tương tự vì UI khác nhau giữa các ứng dụng. Khi xem một season chương trình TV trên điện thoại, các tập đã xem có dấu tick xanh; nhưng khi xem cùng season đó trên TV thì không có dấu tick xanh, còn các tập chưa xem lại có tam giác vàng
    Mỗi lần chuyển qua lại giữa các thiết bị, não tôi lại khựng một nhịp
  • Discord còn tệ hơn. Nút tắt tiếng micro và nút tắt camera lại dùng hai cách ngược nhau
  • Vấn đề hiển thị/điều khiển micro có một khía cạnh khá thú vị. Nếu không có phản hồi thị giác trực tiếp, bạn không thể biết micro đang ở chế độ nào cho đến khi người khác phản ứng hoặc không phản ứng
    Ngay cả khi nó đang bật, đây vẫn là một công cụ có độ trễ phản hồi lớn. Người bên kia có thể đã dừng lại, hoặc đang suy nghĩ trước khi trả lời, nên thường phải thử hai ba lần mới chắc chắn
    Nó khác với chế độ tối, bật tắt là thấy ngay. Vì vậy, dù nút thực hiện hành động gì, một chỉ báo trực quan về trạng thái hiện tại vẫn rất hữu ích; và cũng không lạ khi với micro, người ta đặc biệt hay cố trộn lẫn “trạng thái” và “điều khiển”

• Nếu là chủ xe Tesla thì chắc chắn sẽ đồng cảm. Các nút toggle trong UI xe quá đa dạng, không có tính nhất quán hay chuẩn mực nào
  Ví dụ nút điều hòa chỉ là một nút hiển thị nhiệt độ, nhưng phản ứng khác nhau tùy vào cách bấm và bấm trong bao lâu. Bấm ngắn thì hiện popup nhỏ, bấm hơi lâu thì hiện toàn bộ bảng điều khiển điều hòa, còn giữ vài giây thì điều hòa đang bật có thể bị tắt. Vấn đề là phải làm tất cả những việc này trong lúc lái xe và phải nhìn đường
  Chỉ cần phối hợp tay-mắt lệch một chút, mà đặc biệt khi đang lái qua đoạn đường gồ ghề thì rất dễ xảy ra, lệch chỉ 1 mm thôi cũng có thể bấm nhầm nút khác và gây ra hành động ngoài ý muốn
  Một thảm họa khác là UX kết nối thiết bị Bluetooth. Ít nhất trong bản triển khai Model S 2012–2022, đó là một trong những mớ UI tệ nhất tôi từng thấy trong sản phẩm ra mắt. Nút ở góc dưới bên phải vẫn tiếp tục hiển thị “Connect” ngay cả sau khi đã kết nối, trong khi ở phía đối diện, góc trên bên trái màn hình, nó hiện “Connecting...” rồi mới báo kết nối hoàn tất
  Đây cũng là UI trong xe, nên nếu đang lái thì bạn chỉ có thể liếc nhìn trong khoảnh khắc. Chỉ riêng UI Bluetooth của Tesla đã đủ tệ một cách xuất sắc để viết đầy một chương sách về UI

  • Trong ứng dụng di động của Tesla, ngay cả các toggle nằm ngay cạnh nhau cũng không nhất quán
    Ổ khóa đang đóng nghĩa là cửa đã khóa, và nhấn vào thì cửa mở khóa
    Chữ “Open” trên cốp xe nghĩa là cốp đang đóng, và nhấn vào thì cốp mở
  • Những bài kiểu này rất đáng tự viết. Dạng phân tích này lúc nào cũng thú vị, và nếu chủ đề là Tesla thì còn dính tới Elon nên có lẽ sẽ được chú ý nhiều hơn
  • Cách tôi dùng nút điều hòa là thế này: trước tiên nhìn nút, nếu nó hơi trong suốt và tôi muốn bật thì chỉ cần nhấp là bật. Nhấp lại thì mở toàn bộ điều khiển, vuốt xuống thì đóng
    Khi muốn tắt, tôi nhấn nút lần nữa để mở toàn bộ điều khiển rồi bấm nút tắt. Nhiệt độ thì nhấp vào nút rồi vuốt sang trái/phải để tăng hoặc giảm
    Với tôi thì nó khá trực quan. Lần tới khi lái xe tôi định thử cách nhấn giữ để tắt, nghe có vẻ khá hữu ích
  • Trên Model Y đời 2023, Bluetooth thực sự hoạt động tốt. Tôi thấy hài lòng vì trên Audi và Ford trước đây thì không được như vậy
    Nhìn các bản triển khai lúc nào cũng tệ như thế, tôi tự hỏi có phải bản đặc tả Bluetooth tự thân đã có chỗ gì đó rối nghiêm trọng không
  • Việc này đáng lẽ phải là bất hợp pháp

• Trước đây tôi từng có vài công tắc nút nhấn NASA, bên trong có hai bóng đèn. Khi công tắc tắt thì cả hai đều tắt; khi nhấn nút, đèn vàng bật lên để cho thấy thao tác công tắc đã được ghi nhận
  Khi thiết bị thực sự muốn bật đã bật lên, đèn xanh lá sáng và đèn vàng tắt. Trạng thái màu vàng là xác nhận rằng bạn đã gạt công tắc, còn màu xanh lá là xác nhận rằng hành động mong muốn đã thực sự diễn ra; đó là một cơ chế phản hồi trạng thái thú vị

  • Cách này hay, và máy bay cũng làm như vậy[1]. Những vấn đề kiểu này đã được những người rất coi trọng tính dễ dùng giải quyết từ lâu, nhưng ngành máy tính lại chậm tiếp thu những thứ như vậy từ các lĩnh vực khác
    Cách đặt nhãn bên ngoài công tắc cũng hoạt động tốt[2]
    [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
    [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
  • Tôi đã dành phần lớn giai đoạn đầu sự nghiệp để viết phần mềm GUI điều khiển phần cứng từ xa và hiển thị trạng thái, và chẳng mấy chốc đã loại bỏ toàn bộ thành phần UI tự lưu trạng thái. Những phần tử thay đổi hành vi tùy theo trạng thái của chính nó như toggle, switch, checkbox, radio button không hiếm khi khiến trạng thái của giao diện và phần cứng bị lệch nhau
    Thay vào đó, tôi đặt một nút cho từng lựa chọn và làm cho nút tương ứng với trạng thái hiện tại sáng lên. Ví dụ, toggle bật/tắt được đổi thành hai nút “on” và “off”. Ban đầu cả hai đều màu xám; khi nhận SOH từ phần cứng cho biết trạng thái là bật, nút on chuyển xanh lá, còn nếu là tắt thì nút off chuyển đỏ
    Nếu mất liên lạc một thời gian, toàn bộ màu sẽ bị làm mờ để cho thấy trạng thái đã cũ. Khi nhấn nút, trạng thái cũ vẫn tiếp tục được hiển thị cho đến khi trạng thái mới quay về, nhưng chỉ nhóm nút đó được hiển thị mờ đi
    Người dùng có thể trực tiếp ra lệnh on hoặc off bất cứ lúc nào, bất kể UI nghĩ đang ở trạng thái nào. Ngược lại, toggle chỉ có thể đổi sang “trạng thái khác”
    Radio button cũng được đổi thành nhóm các nút ghi tên trạng thái, và chỉ mục mà UI cho là hiện tại mới được tô màu. Phần lớn trạng thái trung lập dùng màu xanh dương; nếu có ý nghĩa tốt/cần chú ý/xấu mà operator muốn nhấn mạnh thì dùng xanh lá/vàng/đỏ
    Thiết kế này khác thường, nhưng nhìn chung các operator hiểu được mà không cần đào tạo riêng. Nút trông giống nút nên có vẻ bấm được, khoảng cách cho thấy chúng thuộc cùng một nhóm, và trong UI thập niên 90 màu xám là mặc định nên nút có màu khác tự nhiên nổi bật như trạng thái hiện tại
    Tôi không biết trong môi trường ngày nay, khi các phần tử UI dùng đủ loại màu vì lý do thẩm mỹ hoặc để thúc đẩy chuyển đổi, và chỉ đôi khi mới truyền tải thông tin, thì điều đó có còn đúng không. Chúng tôi cũng đã thử cách hiển thị đồng thời trạng thái lệnh và trạng thái nhận được như nút của NASA, nhưng tất cả đều gây rối hơn
  • Tôi thích cách này. Không hiểu tại sao ngành của chúng ta không tham khảo lĩnh vực hàng không/quân sự thường xuyên hơn, nơi hiểu nhầm có thể làm chết người

• Hỡi checkbox, 1990~2009. Nó hoàn hảo và không mơ hồ, vậy mà vì lý do nào đó các nhà thiết kế smartphone lại ghét nó

  • Điều buồn cười hơn là thứ về bản chất là checkbox hoàn toàn có thể được làm khá đẹp và trông như toggle. Đây không phải ví dụ tốt, nhưng cho thấy nó không nhất thiết phải là một hình vuông có dấu tick: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
  • Hệ thống tư vấn video y tế/khám từ xa mà tôi dùng đã làm hỏng checkbox. Trong giao diện nhắn tin trực tiếp, nó thay đổi nhãn của trường checkbox tùy theo việc có được tick hay không
    Nếu không tick thì hiển thị “Not Urgent”, nếu tick thì hiển thị “Urgent”. Tôi đã tick nhanh vài lần, nghĩ rằng mình đã đánh dấu là không khẩn cấp, rồi nhấn gửi
  • Tôi đồng ý rằng checkbox là hoàn hảo. Nhưng một phần cũng vì trên smartphone người ta không muốn điền form
    Checkbox mặc định của trình duyệt quá nhỏ để bấm bằng ngón cái trên smartphone, nên khó dùng thường xuyên
  • Ai đã tạo ra widget checkbox? System 1 (1984) có “ô x” tương đương với dấu tick trong menu, nhưng theo tôi biết thì đó chưa phải là checkbox đúng nghĩa
  • Jony Ive có phải là Thomas Midgley Jr của giới thiết kế không? Ông ấy đã phổ biến thiết kế phẳng kém khả dụng với iOS 7, và cũng chịu trách nhiệm về chuột iMac hình tròn cùng bàn phím MacBook dễ hỏng

• Ví dụ tệ nhất tôi từng thấy là UI màn hình bảng điều khiển Tesla. Trên hình chiếc xe có gắn một nhãn trông không giống nút, ghi “Open”
  Điều này rõ ràng được đọc như nghĩa là phần đó đang mở, nhưng ý nghĩa thực tế không phải vậy. Nhãn đó là nút để mở phần tương ứng, và người dùng không có cách nào biết được

  • Đúng vậy. Cuối tuần này tôi lái một chiếc Tesla thuê, và đã nhiều lần bối rối, hoảng vì tưởng cả cốp trước lẫn cốp sau đều đang mở
  • Đồng ý 100%. Đây là điểm gây khó chịu thứ hai trong UX cốp xe Tesla. Điểm thứ nhất là animation quá dài mà bạn phải chờ sau khi chuyển sang chế độ đỗ xe để mở cốp
    Nhìn chung UX của Tesla đi trước các xe khác rất nhiều, nhưng những chi tiết nhỏ như thế này quá khó chịu
  • Tôi thấy hoàn toàn không gây nhầm lẫn. Hình render của chiếc xe cho thấy rõ trạng thái hiện tại của cốp, và khi nhấn nút mở thì cũng có animation cốp mở ra
    Có vẻ mỗi người cảm nhận khác nhau
  • Điều thú vị là đây là vấn đề của tiếng Anh. Trong tiếng Anh, động từ và tính từ thường giống nhau. Nếu là tiếng Tây Ban Nha thì “Abrir” (động từ nguyên mẫu) và “Abierto” (tính từ) khác nhau, nên sẽ không xảy ra chuyện này
    Có vẻ có thể tránh bằng cách viết kiểu “Do open” hoặc “Is open”, nhưng với người bản ngữ thì nghe có kỳ không?
  • Đây có phải là đặc tính chỉ có trong tiếng Anh không? Ví dụ trong tiếng Tây Ban Nha, động từ và tính từ là hai từ khác nhau

• Vấn đề cốt lõi của nút toggle là một đối tượng duy nhất đồng thời chứa trạng thái của hệ thống và hành động để thay đổi trạng thái đó
  Vì vậy không rõ chữ “ON” hiển thị trên nút là trạng thái hiện tại, hay là hành động sẽ được thực hiện khi bấm
  Cách giải quyết là tách trạng thái và hành động ra ở một mức độ nào đó. Có nhiều cách, chẳng hạn như một trong các câu trả lời trong liên kết là đặt nhãn bên ngoài nút
  Nếu đó không phải công tắc mà là nút toggle như ví dụ Teams, thì có thể giữ nguyên biểu tượng và thay đổi thuộc tính khác của nút. Ví dụ, như cách đã làm suốt hàng chục năm mà không gặp vấn đề: để nút ở trạng thái được nhấn xuống nhằm biểu thị trạng thái “ON”

  • Trong phần thuộc tính âm thanh hệ thống của Windows 11 có tùy chọn “Allow apps and Windows to use this device for audio”, bên cạnh là nút “Don't allow”. Vì vậy hoàn toàn không biết trạng thái hiện tại là gì

• Tôi đồng ý với kết luận, nhưng cả trạng thái hiện tại là gì lẫn việc khi đổi toggle thì nó sẽ trở thành trạng thái nào đều phải rõ ràng. Quá thường xuyên phải thử bật/tắt toggle rồi mới biết là thật ra không cần đổi
  Điểm về phát/tạm dừng khá thú vị, vì nó có vẻ trái với kết luận. Nhưng trường hợp này đi theo một tiền lệ vật lý đã được hiểu rõ, và thường thì việc nhạc hay video có đang phát hay không cũng rõ ràng. Vì vậy dù biểu tượng nút không đổi, người dùng vẫn hiểu bấm vào sẽ xảy ra chuyện gì
  Quay lại với toggle và UI, việc đổi màu toggle từ xám nhạt sang xám hơi nhạt hơn là cực kỳ vô ích. Hãy gắn nhãn vào. Nếu nhãn không hợp với motif thiết kế thì nên tìm một nhà thiết kế giỏi hơn

  • Nếu theo tiền lệ vật lý, hình ảnh trên nút lẽ ra phải thể hiện hành động, tức là phát, còn trạng thái thị giác nhấn/chưa nhấn mới cho biết hành động đó có đang hoạt động hay không
    Các nhà thiết kế phần mềm đã không làm theo điều này mà tạo ra cách hoán đổi biểu tượng phát/tạm dừng, sinh ra sự nhầm lẫn mới. Lý do không phải vì thân thiện với người dùng, mà vì các nút 3D skeuomorphic đã hết thời
    Ưu điểm duy nhất của việc hiển thị trạng thái là khi có sự cố. Đặc biệt với âm thanh thì chuyện này rất thường gặp: bị tắt tiếng, rút tai nghe, driver âm thanh Linux lại hỏng, v.v.
    Đến giờ khi nhìn nút phát/tạm dừng tôi vẫn hơi bị bất hòa nhận thức, và không thể chắc chắn 100% nút tạm dừng chính xác có nghĩa gì, nên khi có vấn đề tôi đôi khi cứ bấm hai lần
  • Tôi đồng ý rằng trạng thái hiện tại phải rõ ràng. Với công tắc đèn, bạn không cần biết hướng nào là “bật”, và thực tế cũng không biết. Vì chỉ cần nhìn xem đèn có sáng hay không
  • Câu “hãy gắn nhãn, nếu nhãn không hợp với motif thiết kế thì tìm nhà thiết kế giỏi hơn” đặc biệt không hữu ích và không thực tế trên di động
    Ví dụ Spotify không có chỗ để đặt nhãn sau mọi nút. Cũng cần không gian để hiển thị bìa album, và tôi muốn điều đó
    Đây không phải vấn đề nhà thiết kế giỏi hơn; giới hạn không gian là có thật. Một số chức năng cần có thể thực hiện ngay bằng một lần chạm. Tôi không muốn giấu shuffle sau một menu bật lên

• Nút toggle nên hiển thị trạng thái hiện tại. Checkbox là ví dụ tốt
  Muted [] và Muted [x] khá rõ ràng
  Mọi thứ trở nên khó khi nhà thiết kế tạo ra UI mà mối liên hệ giữa từ ngữ và thiết kế thị giác không rõ ràng. Ví dụ Mute Off [---( )], Mute On [( )---] kiểu như vậy trộn hành động vào phần mô tả trạng thái nên không biết nghĩa là gì

  • Nếu có đủ không gian, việc mô phỏng toggle có nhãn hai bên hoạt động tốt
    Loudspeaker [()---] Crossed-out loudspeaker
  • Dấu check là dấu tick[1]. Trên trang trạng thái[2], dấu tick nghĩa là “đang hoạt động” còn dấu thập nghĩa là thất bại. Xét theo góc nhìn “hiển nhiên”, Muted [x] có thể được đọc là có gì đó đã thất bại
    Để hiểu theo cách khác cần học UX máy tính, và điều đó trái ngược với sự hiển nhiên. Hoặc nó cũng có thể có nghĩa là đối tượng cần bấm khi muốn tắt tiếng, như “X marks the spot”
    [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
    [2] ví dụ https://www.githubstatus.com/
  • Checkbox đồng thời hiển thị trạng thái hiện tại và lựa chọn khả dĩ dưới dạng có/không đơn giản
    Nút toggle gây rối vì không thể biết ý đồ của nhà thiết kế. Trừ khi hiển thị cả hai lựa chọn cùng lúc, rất khó biết
    Mute On[---()]Off
  • Nút phải cho biết nó làm gì khi được bấm. Nếu muốn hiển thị trạng thái hiện tại thì đó là một chỉ báo riêng, không phải nút
    Nút tồn tại để được bấm, nên nó phải truyền đạt bấm vào thì chuyện gì sẽ xảy ra
  • Trong các hệ chữ viết từ phải sang trái, hai bên cũng có nên đảo lại không?

• Nên hiển thị cả hai như công tắc analog. Vừa hiển thị trạng thái hiện tại một cách rõ ràng, không gây hiểu lầm, vừa đồng thời cho thấy trạng thái sẽ được chuyển sang
  Toggle dạng thanh trượt trái-phải của Apple làm điều này rất tốt. Có thể thấy rõ toggle hiện đang ở đâu, sẽ chuyển sang đâu, và thiết lập hiện tại có đang bật tính năng hay không bằng nền xanh, hay đang tắt bằng nền xám

• Một thiết kế tôi từng thích là có đèn trạng thái cạnh công tắc, và khi trạng thái bật thì đèn đó sáng, nhưng giờ tôi không tìm thấy nữa
  Điểm hay nhất là nó cũng giải quyết độ trễ của tác vụ bất đồng bộ. Khi bấm công tắc, công tắc được toggle, rồi một lúc sau đèn sáng. Nó tạo cảm giác tương tác thực sự đã làm được điều gì đó, nên rất thỏa mãn

  • Nếu không thấy thiết kế thực tế, điều này cũng giống một ví dụ cho sự mơ hồ được bàn trong bài. Không rõ biểu tượng nghĩa là việc sẽ xảy ra tiếp theo, hay việc đang xảy ra hiện tại
    Vấn đề là trạng thái hay hành động. Thiết kế cụ thể có thể đã không mơ hồ, nhưng chỉ qua mô tả thì không như vậy
  • Nếu lâu rồi quay lại trang đó và thấy đèn đang sáng, làm sao biết đó nghĩa là trạng thái hiện tại đang ON hay bấm vào thì nó sẽ chuyển sang ON? Có cách nào chỉ nhìn đèn sáng là phân biệt được ngay không?
  • Nghe giống một tính năng giao diện thấy trên thiết bị “thông minh”. Tôi chỉ quen với công tắc TP-Link Kasa, nhưng UI ứng dụng của nó cũng có vẻ tương tự: biểu tượng màu có nhiều trạng thái, và trạng thái gần với “bật” nhất hình như nghĩa là đã kiểm tra với công tắc và xác nhận là đang bật
  • Có lẽ đây là trường hợp dùng tốt cho màn hình HDR. Có thể làm “đèn báo” sáng hơn hẳn phần còn lại của màn hình để cho thấy rất rõ rằng đèn giờ đã bật
    Tất nhiên chỉ hiệu quả nếu ngay từ đầu người dùng không đặt độ sáng màn hình quá cao