ปุ่ม Toggle ควรแสดงสถานะปัจจุบัน หรือแสดงสถานะที่จะเปลี่ยนไป? (2010)

 (ux.stackexchange.com)
3 คะแนน โดย GN⁺ 2024-02-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากใช้ toggle แบบเดียวกันกับทั้ง การกระทำที่เกิดขึ้นทันที อย่าง Play/Pause และ การตั้งค่าที่คงอยู่ อย่าง Shuffle ผู้ใช้อาจสับสนระหว่างสถานะปัจจุบันกับการกระทำถัดไป
  • About Face 2.0 แนะนำให้หลีกเลี่ยง flip-flop button ที่ใส่สองตัวเลือกไว้ในคอนโทรลเดียว และมองว่าการสื่อสารสถานะปัจจุบันสำคัญกว่าการประหยัดพื้นที่
  • แนวทางแก้ไขใกล้เคียงกับการ เขียนการกระทำเป็นวลีกริยา เช่น Switch to portrait mode หรือแยกสถานะกับการเปลี่ยนสถานะออกจากกันด้วย radio button, checkbox, ป้ายสถานะ + ปุ่ม action
  • หากข้อความอยู่ภายในปุ่มแบบสวิตช์สไตล์ iOS คำว่า ON อาจกำกวมว่าเป็นสถานะปัจจุบันหรือสถานะถัดไป แต่ถ้า วางข้อความสถานะไว้นอกปุ่ม แบบ OS X หรือ Windows Metro ความกำกวมจะลดลง
  • แบบแผน Play/Pause อาจเป็นข้อยกเว้นที่แสดงการกระทำถัดไปได้ แต่ตัวเลือกอย่าง Shuffle, Like, Auto save ควรเน้นสถานะปัจจุบัน และเสริมด้วย tooltip, สี, สถานะถูกกด, หรือป้ายแยกต่างหากจะปลอดภัยกว่า

ความขัดแย้งระหว่างการแสดงสถานะกับการแสดง action

  • สำหรับปุ่มที่สลับไปมาระหว่างสองสถานะ เช่น Play/Pause, Shuffle/Regular Play ประเด็นสำคัญคือควรแสดง สถานะปัจจุบัน หรือแสดง สถานะที่จะเปลี่ยนไป หลังคลิก
  • Play/Pause ผู้ใช้มักรับรู้เป็น action อย่าง “เริ่มเล่น” หรือ “หยุดชั่วคราว” ได้ง่าย จึงคุ้นเคยกับแบบแผนที่แสดง Play ตอนหยุดอยู่ และแสดง Pause ตอนกำลังเล่น
  • Shuffle/Regular Play ใกล้เคียงกับสถานะของตัวเลือกที่เป็นวิธีเล่นเพลง หากแสดงสถานะที่จะเปลี่ยนไป ผู้ใช้อาจสับสนว่าตอนนี้กำลังสุ่มหรือเล่นตามลำดับ
  • เครื่องเล่นเพลงในตัวของ Xbox 360 ถูกยกเป็นกรณีที่สร้างความสับสน เพราะเมื่ออยู่ในโหมด shuffle กลับแสดงไอคอนเล่นตรง และในสถานการณ์ตรงข้ามก็แสดงกลับกัน

คำแนะนำจาก About Face: หลีกเลี่ยง flip-flop button

  • About Face 2.0 จัดประเภทนี้ว่าเป็น flip-flop button ซึ่งเป็น “สำนวนการเลือกที่ควรหลีกเลี่ยง”
  • เมื่อปุ่มเดียวควบคุมตัวเลือกสองอย่างที่ใช้พร้อมกันไม่ได้ แม้จะประหยัดพื้นที่ แต่ทำหน้าที่ที่สองของคอนโทรลคือ การสื่อสารสถานะปัจจุบัน ได้ยาก
  • เมื่อปุ่มแสดงว่า ON แต่สถานะปัจจุบันคือปิด สถานะการตั้งค่าจะไม่ชัดเจน และถ้าขณะปิดอยู่แสดงว่า OFF ก็อาจสับสนว่าปุ่ม ON อยู่ที่ไหน
  • แนวทางแก้ไขที่แนะนำมีสองแบบ
    • ขยาย action ของปุ่มเป็นวลีกริยา เช่น Switch to portrait mode
    • ใช้เทคนิค UI อื่นที่ทำให้การเลือกสถานะเห็นได้ชัด เช่น radio button สองตัว

แยกปุ่ม action กับปุ่มสถานะ

  • action button และ state button ควรถูกออกแบบต่างกัน
    • ถ้าเป็น action อย่าง Play/Pause ให้แสดงสิ่งที่จะเกิดขึ้นเมื่อคลิก
    • ถ้าเป็นตัวเลือกอย่าง Shuffle/Linear ให้แสดงสถานะปัจจุบัน
  • หากเป็นปุ่ม Shuffle ที่มีแต่ไอคอน ควรคงไอคอน shuffle ไว้ตัวเดียว และทำให้ดูเหมือน เปิด/ปิดใช้งาน ตามสถานะ
    • สถานะเปิดให้ดูสว่างขึ้นหรือเหมือนปุ่มที่ถูกกดอยู่
    • ในสถานะปิด ผู้ใช้ควรรู้ได้ทันทีว่าเป็นการเล่นตามลำดับ
    • ในสภาพแวดล้อมที่ hover ได้ สามารถเพิ่ม tooltip เพื่อให้ชัดเจนยิ่งขึ้น
  • มีความเห็นว่า Play/Pause ก็ลดความสับสนได้หากไม่เปลี่ยน label แต่แสดงปุ่ม Play เป็นสถานะถูกกด

ความกำกวมที่เกิดจากข้อความในปุ่ม

  • ON และ OFF ในภาษาอังกฤษอ่านได้ทั้งเป็นสถานะและเป็นการกระทำเพื่อเปลี่ยนสถานะ เมื่อนำไปไว้ในปุ่มจึงอาจทำให้พร่าเลือนว่า เป็นสถานะหรือคำสั่ง
  • มีการเสนอคู่คำที่ชัดเจนกว่า เช่น
    • Enable / Disable
    • Enabled / Disabled
    • Start / Stop
    • Running / Stopped
  • การเลือกคำอย่างเดียวไม่ได้ทำให้ปัญหาหายไปทั้งหมด
    • ผู้ใช้อาจยังต้องตัดสินว่าข้อความบนปุ่มเป็นสถานะหรือคำสั่ง
    • ความต่างระหว่าง Enable กับ Enabled อาจไม่ชัดเจนพอใน UI

ป้ายนอกปุ่มและการแยกสถานะ + action

  • หากไม่ใส่ข้อความไว้ในตัวปุ่ม แต่จัดวาง ข้อความไว้ข้างนอกปุ่ม ก็สามารถแสดงทั้งสถานะปัจจุบันและสถานะที่เปลี่ยนไปได้พร้อมกัน
  • สวิตช์สไตล์ OS X ไม่ได้บอกว่า ON หรือ OFF บนตัวปุ่ม แต่ข้อความรอบสวิตช์แสดงสถานะ จึงลดคำถามว่า “ปุ่มนี้คือสถานะปัจจุบันหรือ action ถัดไป”
  • แนวทางแบบ Windows Metro UI ใช้สีของปุ่มแสดงสถานะปัจจุบัน และยืนยันสถานะปัจจุบันอีกครั้งด้วยข้อความ On/Off ใต้ข้อความตัวเลือก
  • สามารถแบ่งเป็น ป้ายสถานะ + ปุ่ม action เช่น Online [Go offline] ได้เช่นกัน
    • Online คือป้ายสถานะปัจจุบันที่คลิกไม่ได้
    • Go offline คือ action สำหรับเปลี่ยนสถานะที่คลิกได้
    • หลังคลิกจะเปลี่ยนเป็น Offline [Go online]
  • วิธีนี้กระชับกว่า radio button แต่ยังแยกบทบาทเชิงภาพของสถานะและ action ได้

Checkbox, radio button และสถานะถูกกด

  • ตัวเลือกอย่าง Shuffle เมื่อนำเสนอเป็น checkbox ที่มี label ว่า Shuffle จะลดความสับสนได้
  • หากใช้คำเดียวและแสดงว่าเปิดใช้งานหรือไม่ด้วยสถานะ checkbox จะลดภาระในการตีความความหมายระหว่างหลายคำ
  • ควรหลีกเลี่ยงคำที่มีคำนำหน้าปฏิเสธ
    • คำนำหน้าอย่าง Not, Non-, Un-, Dis-, Im-, Mis-, In-, Il-, Ir- อาจอ่านเหมือนปฏิเสธซ้อนเมื่อรวมกับสถานะไม่ถูกเลือก
  • ปุ่ม Like ของแอป Facebook Android เป็นตัวอย่างที่เมื่อปิดจะเป็นสีเทา และเมื่อเปิดจะเน้นเป็นสีน้ำเงิน
    • อย่างไรก็ตาม การใช้สีเพียงอย่างเดียวอาจไม่เพียงพอสำหรับผู้ใช้ที่มีภาวะการมองเห็นสีผิดปกติ

ตัวอย่าง UI จริงและข้อควรระวัง

  • มีแนวทางประนีประนอมอย่างปุ่ม Shuffle ในเว็บแอป Spotify ที่ใช้สีกลางเมื่อปิด และใช้สีเน้นเมื่อเปิด
  • การเปลี่ยนเมื่อ hover แบบ Twitter คือการแสดงสถานะปัจจุบันก่อน แล้วเมื่อวางเมาส์จึงแสดง action
    • อาจทำงานได้ในสภาพแวดล้อมที่มี hover แต่บนหน้าจอสัมผัส วิธีเดียวกันอาจใช้ไม่ได้
  • สวิตช์สไตล์ iOS แสดงทั้งสองสถานะในคอนโทรลเดียว แต่ก็ถูกวิจารณ์ว่า ON กำกวมว่าเป็นสถานะปัจจุบันหรือสถานะที่จะเปลี่ยนเมื่อกด
  • UI การตั้งค่าของ Discord เป็นตัวอย่าง toggle แบบ checkbox ที่ทำให้สถานะปัจจุบันและสถานะในอนาคตชัดเจนขึ้น
  • ยังมีตัวอย่างที่แสดงทั้งสถานะและความเป็นไปได้ในการควบคุมพร้อมกัน เช่น toggle แบบ mouseover ของ Evernote หรือสวิตช์มือจับแบบห้องน้ำบนเครื่องบิน

หลักการออกแบบ

  • เมื่อคอนโทรลเดียวรับหน้าที่ทั้ง การสื่อสารสถานะ และ การสื่อสาร action พร้อมกัน จะเกิดความกำกวม
  • ต้องสื่อสารสถานะปัจจุบันในรูปแบบใดรูปแบบหนึ่งเสมอ
    • Play/Pause อาจมี feedback ภายนอกอย่างเสียงเพลงหรือเวลาที่เดินเพื่อช่วยเติมเต็มสถานะปัจจุบัน
    • Shuffle รู้สถานะได้ยากจนกว่าจะเห็นว่าเพลงถัดไปถูกเลือกอย่างไรจริง ๆ การแสดงสถานะบนตัวปุ่มจึงสำคัญกว่า
  • วิธีวนหลายสถานะด้วยปุ่มเดียวสามารถบีบอัด UI และรวมการตั้งค่าที่ใช้พร้อมกันไม่ได้ไว้ด้วยกันได้ แต่ผู้ใช้ต้องเข้าใจสถานะปัจจุบันได้อย่างรวดเร็ว
  • Play/Pause อาจเป็นข้อยกเว้นที่แสดง action ถัดไปได้เพราะมีแบบแผนที่แข็งแรง ส่วน toggle ของตัวเลือกทั่วไปจะสอดคล้องกว่าหากเน้นสถานะปัจจุบัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-13
ความคิดเห็นจาก Hacker News

  • ช่วงนี้หงุดหงิดกับ Microsoft Teams มาก ในแอปเดสก์ท็อป ถ้าอยู่ในสถานะปิดไมค์ก็จะแสดงไอคอนไมโครโฟนมีขีดทับ และเมื่อเปิดไมค์แล้วก็เปลี่ยนเป็นไมโครโฟนไม่มีขีด ทำให้เข้าใจได้ง่าย
    แต่ถ้าเข้าร่วมผ่านแอปมือถือ ไอคอนไมโครโฟนมีขีดทับอันเดียวกันกลับหมายถึง “ตอนนี้ไม่ได้ปิดไมค์อยู่ ถ้ากดปุ่มนี้จะกลายเป็นปิดไมค์” พอกดแล้วไอคอนก็ยังเป็นไมโครโฟนมีขีดทับเหมือนเดิม แค่สลับสีพื้นหลังเท่านั้น
    เลยสงสัยว่าฝั่งหนึ่งเป็นปุ่ม “เปิดไมค์” ส่วนอีกฝั่งเป็นปุ่ม “เปิดการปิดไมค์” เลยใช้ไอคอนเดียวกันหรือเปล่า สุดท้ายคือต้องรู้ก่อนว่าปุ่มหน้าตาเป็นอย่างไรในสถานะตรงข้าม ถึงจะ判断สถานะปัจจุบันได้ เลยต้องกดลองอยู่หลายครั้งเสมอเพื่อดูว่าแอปนี้ใช้แนวทางไหน
    เลยสงสัยว่านี่คือราคาที่ต้องจ่ายของ flat UI ที่สูญเสียสิ่งอ้างอิงจากโลกจริงไปหรือไม่

    • ผมคิดว่าส่วนหนึ่งของความสับสนนี้มาจากกรอบความคิดที่ว่า ไมค์เปิดอยู่เป็นค่าเริ่มต้น รูปแบบที่ถือว่า “ไมค์ทำงานอยู่” คือค่าปกติ และการปิดไมค์เป็นสถานะที่เบี่ยงออกจากนั้น สืบทอดมาตั้งแต่ UI ของระบบประชุมทางโทรศัพท์ โทรศัพท์แอนะล็อก และย้อนไปไกลกว่านั้นถึงยุคที่คู่สนทนายังเชื่อมต่อกันด้วยสายจริง
      มิกเซอร์เสียงสำหรับดนตรีสดหรือการบันทึกเสียงก็มักใช้รูปแบบเดียวกัน ปุ่ม “Mute” จะมีไฟสีแดงติดเมื่อปิดช่องสัญญาณ และมีเพียงอุปกรณ์บางรุ่นเท่านั้นที่ใช้ปุ่ม “ON” เหนือเฟดเดอร์เพื่อแสดงว่าช่องสัญญาณเปิดใช้งานอยู่
      ตอนนี้ก็น่าจะถึงเวลาที่แอปประชุมจะเปลี่ยนไปใช้แนวคิดว่า เสียงปิดอยู่โดยค่าเริ่มต้น แล้วเหมือนกัน ซึ่งก็เริ่มเห็นอยู่บ้างจากวิธีที่องค์ประกอบ UI ติดสว่างขึ้นเมื่อผู้พูดกำลังพูด
    • ปุ่มแบบนี้ไม่ควรทำให้สับสนได้เลยจริง ๆ
    • ใน Plex ก็หงุดหงิดคล้ายกัน เพราะ UI ต่างกันไปตามแต่ละแอป เวลาดูซีซันของรายการทีวีบนมือถือ ตอนที่ดูแล้วจะมีเครื่องหมายถูกสีน้ำเงิน แต่ถ้าดูซีซันเดียวกันบนทีวี เครื่องหมายถูกสีน้ำเงินจะหายไป แล้วตอนที่ยังไม่ได้ดูจะมีสามเหลี่ยมสีเหลืองแทน
      ทุกครั้งที่สลับอุปกรณ์ สมองต้องสะดุดไปหนึ่งจังหวะ
    • Discord แย่กว่าอีก ปุ่มปิดไมค์กับปุ่มปิดกล้องใช้ตรรกะคนละแบบที่สวนทางกัน
    • ประเด็นเรื่องการแสดงผล/ควบคุมไมค์มีมุมน่าสนใจอยู่มาก ถ้าไม่มีฟีดแบ็กทางภาพโดยตรง ก็จะไม่รู้เลยว่าไมค์อยู่ในโหมดไหน จนกว่าจะมีคนอื่นตอบสนองหรือไม่ตอบสนอง
      ถึงจะเปิดอยู่ มันก็เป็นเครื่องมือที่มีความหน่วงของฟีดแบ็กสูง เพราะอีกฝ่ายอาจหยุดอยู่ หรือกำลังคิดก่อนจะตอบ ทำให้บ่อยครั้งต้องทดสอบสองสามครั้งกว่าจะมั่นใจ
      มันไม่เหมือน dark mode ที่เปิดหรือปิดแล้วเห็นผลทันที เพราะแบบนั้นไม่ว่าปุ่มจะทำงานอย่างไร การมีตัวบอกสถานะปัจจุบันด้วยภาพก็ช่วยได้มาก และก็ไม่น่าแปลกใจที่โดยเฉพาะกับไมค์ มักมีความพยายามจะผสม “สถานะ” กับ “การควบคุม” เข้าด้วยกัน

  • ถ้าเป็นเจ้าของ Tesla ก็น่าจะเข้าใจทันที ปุ่ม toggle ใน UI ของรถมีหลากหลายแบบเกินไปจนไม่มีทั้งความสม่ำเสมอและมาตรฐาน
    ตัวอย่างเช่น ปุ่มระบบปรับอากาศเป็นปุ่มเดียวที่แสดงอุณหภูมิ แต่จะตอบสนองต่างกันไปตามวิธีกดและระยะเวลาที่กด กดสั้นจะขึ้นป๊อปอัปเล็ก ๆ กดนานขึ้นหน่อยจะเปิดแผงควบคุมระบบปรับอากาศเต็มรูปแบบ และถ้ากดค้างไว้หลายวินาที ระบบปรับอากาศที่เปิดอยู่ก็อาจถูกปิดได้ ปัญหาคือทั้งหมดนี้ต้องทำในสถานการณ์ที่กำลังขับรถและยังต้องมองถนนอยู่
    แค่การประสานมือกับสายตาคลาดเคลื่อนไปนิดเดียว โดยเฉพาะเวลาขับผ่านพื้นถนนขรุขระซึ่งเกิดได้ง่ายมาก แค่พลาดไป 1 มม. ก็อาจไปกดปุ่มอื่นจนเกิดการทำงานที่ไม่ตั้งใจ
    หายนะอีกอย่างคือ UX การเชื่อมต่อ Bluetooth อย่างน้อยใน Model S ช่วงปี 2012~2022 มันเป็นหนึ่งในงานมั่ว UI ที่แย่ที่สุดเท่าที่เคยเห็นในผลิตภัณฑ์ที่วางขายจริง ปุ่มมุมขวาล่างยังคงแสดงคำว่า “Connect” แม้จะเชื่อมต่อสำเร็จแล้ว ขณะที่อีกฝั่งของหน้าจอด้านซ้ายบนจะแสดง “Connecting...” แล้วค่อยแสดงว่าเชื่อมต่อเสร็จ
    แถมนี่เป็น UI ในรถ เวลาขับอยู่ก็เหลือบมองได้เพียงเสี้ยววินาที แค่ UI ของ Bluetooth ใน Tesla อย่างเดียวก็แย่ได้ดีพอจะเขียนเป็นหนึ่งบทในหนังสือเรื่อง UI เลย

    • ในแอปมือถือ Tesla เอง toggle ที่อยู่ติดกันยังไม่สม่ำเสมอกันเลย
      ไอคอนแม่กุญแจปิดหมายถึงประตูล็อกอยู่ และเมื่อกดแล้วประตูจะปลดล็อก
      คำว่า “Open” บนท้ายรถหมายความว่าท้ายรถยังปิดอยู่ และเมื่อกดแล้วท้ายรถจะเปิด
    • น่าจะดีถ้าเอาเรื่องแบบนี้มาเขียนเป็นบทความจริงจัง การวิเคราะห์แนวนี้น่าสนใจเสมอ และถ้าเป็นเรื่อง Tesla ก็น่าจะดึงความสนใจได้มากขึ้นอีกเพราะมี Elon เข้ามาเกี่ยวด้วย
    • วิธีที่ผมใช้ปุ่มระบบปรับอากาศคือแบบนี้: มองปุ่มก่อน ถ้ามันดูโปร่งนิด ๆ และผมอยากเปิด ก็แค่คลิกแล้วมันจะเปิด คลิกอีกครั้งก็จะเปิดหน้าควบคุมทั้งหมด แล้วปัดลงเพื่อปิด
      ถ้าอยากปิด ก็ต้องกดปุ่มอีกครั้งเพื่อเปิดหน้าควบคุมทั้งหมด แล้วกดปุ่มปิด ส่วนอุณหภูมิก็คลิกปุ่มแล้วปัดซ้ายขวาเพื่อเพิ่มหรือลด
      สำหรับผมมันก็ดูค่อนข้างตรงไปตรงมา ครั้งหน้าตอนขับจะลองใช้วิธีกดค้างเพื่อปิดดูด้วย ดูแล้วน่าจะมีประโยชน์ทีเดียว
    • ใน Model Y ปี 2023 Bluetooth ใช้งานได้ดีจริง ๆ ซึ่งน่าพอใจ เพราะใน Audi กับ Ford คันก่อน ๆ ไม่เป็นแบบนั้น
      พอเห็นว่าการติดตั้งใช้งานมันแย่กันได้ขนาดนี้อยู่เรื่อย ๆ ก็อดคิดไม่ได้ว่าตัวสเปกของ Bluetooth เองอาจมีส่วนที่ยุ่งเหยิงหนักอยู่จริง
    • แบบนี้ควรผิดกฎหมายได้แล้ว

  • เมื่อก่อนฉันเคยมี สวิตช์ปุ่มกดของ NASA อยู่หลายตัว ซึ่งข้างในมีหลอดไฟสองดวง ถ้าสวิตช์ปิดอยู่ ทั้งสองดวงจะดับ แต่เมื่อกดปุ่ม หลอดสีเหลืองจะติดเพื่อแสดงว่ารับคำสั่งกดสวิตช์แล้ว
    เมื่ออุปกรณ์ที่ตั้งใจจะเปิดทำงานขึ้นจริง ไฟสีเขียวจะติดและไฟสีเหลืองจะดับ สถานะสีเหลืองจึงเป็นการยืนยันว่าได้สั่งสลับสวิตช์แล้ว ส่วนสีเขียวเป็นการยืนยันว่าการทำงานที่ต้องการเกิดขึ้นจริง เป็นกลไก การป้อนกลับของสถานะ ที่น่าสนใจ

    • เป็นวิธีที่ดี และเครื่องบินก็ทำแบบนี้เหมือนกัน[1] ปัญหาแบบนี้คนที่ให้ความสำคัญกับการใช้งานอย่างมากได้แก้ไว้แล้ว แต่ในวงการคอมพิวเตอร์กลับรับเอาแนวคิดจากสาขาอื่นช้ากว่ามาก
      วิธีติดป้ายกำกับไว้นอกตัวสวิตช์ก็ใช้ได้ดีเช่นกัน[2]
      [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
      [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
    • ฉันใช้เวลาช่วงต้นอาชีพไปมากกับการเขียนซอฟต์แวร์ GUI เพื่อควบคุมฮาร์ดแวร์ระยะไกลและแสดงสถานะ และไม่นานก็เลิกใช้ องค์ประกอบ UI ที่เก็บสถานะไว้เอง ทั้งหมด องค์ประกอบอย่าง toggle, switch, checkbox, radio button ที่เปลี่ยนพฤติกรรมตามสถานะของตัวเองนั้น มักเกิดปัญหาที่สถานะของอินเทอร์เฟซไม่ตรงกับสถานะฮาร์ดแวร์ได้บ่อย
      ฉันจึงใช้ปุ่มแยกสำหรับแต่ละตัวเลือกแทน และทำให้ปุ่มที่ตรงกับสถานะปัจจุบันสว่างขึ้น เช่น toggle เปิด/ปิด ก็เปลี่ยนเป็นปุ่ม “on” และ “off” สองปุ่ม ตอนแรกทั้งคู่เป็นสีเทา แล้วเมื่อได้รับ SOH จากฮาร์ดแวร์ว่าระบบเปิดอยู่ ปุ่ม on จะเป็นสีเขียว ถ้าปิดอยู่ ปุ่ม off จะเป็นสีแดง
      ถ้าการสื่อสารขาดหายไปสักพัก ก็ทำให้ทุกสีดูจางลงเพื่อบอกว่าสถานะนั้นเก่าแล้ว เมื่อกดปุ่ม ก็ยังคงแสดงสถานะเดิมต่อไปจนกว่าสถานะใหม่จะกลับมา แต่ทำให้เฉพาะชุดปุ่มนั้นดูจางลง
      ผู้ใช้สามารถสั่ง on หรือ off ได้โดยตรงเสมอ ไม่ว่า UI จะคิดว่าอยู่สถานะไหนก็ตาม แต่ toggle เปลี่ยนได้แค่ไปยัง “อีกสถานะหนึ่ง” เท่านั้น
      ส่วน radio button ก็เปลี่ยนเป็นชุดปุ่มที่มีชื่อสถานะกำกับ และลงสีเฉพาะรายการที่ UI เชื่อว่าเป็นสถานะปัจจุบัน สถานะกลางส่วนใหญ่ใช้สีน้ำเงิน ถ้ามีความหมายแบบดี/ระวัง/แย่ที่ผู้ปฏิบัติงานควรสังเกต ก็ใช้เขียว/เหลือง/แดง
      มันเป็นดีไซน์ที่แปลกอยู่บ้าง แต่ผู้ปฏิบัติงานส่วนใหญ่เข้าใจได้โดยแทบไม่ต้องฝึกเพิ่มเติม ปุ่มก็ดูเป็นปุ่มจึงเหมือนคลิกได้ ระยะห่างก็บอกว่าเป็นชุดเดียวกัน และในยุค UI ของทศวรรษ 90 สีเทาเป็นค่าปริยายอยู่แล้ว ปุ่มที่มีสีจึงเด่นขึ้นมาอย่างเป็นธรรมชาติว่าเป็นสถานะปัจจุบัน
      ฉันไม่แน่ใจว่าในยุคนี้ที่องค์ประกอบ UI ถูกใส่สีมั่ว ๆ ด้วยเหตุผลด้านความสวยงามหรือเพื่อชักนำให้เกิดการเปลี่ยนสถานะ และมีแค่บางครั้งเท่านั้นที่ใช้เพื่อสื่อข้อมูล มันจะยังใช้ได้ผลเหมือนเดิมหรือไม่ ฉันเคยลองแสดงทั้งสถานะของคำสั่งและสถานะที่ได้รับกลับมาพร้อมกันแบบปุ่ม NASA แต่ทั้งหมดกลับยิ่งทำให้สับสนกว่าเดิม
    • ชอบมาก ฉันไม่เข้าใจว่าทำไมวงการเราถึงไม่อ้างอิง วงการการบิน/การทหาร ให้บ่อยกว่านี้ ทั้งที่ความเข้าใจผิดในที่แบบนั้นอาจทำให้คนตายได้

  • ยกให้ checkbox ช่วงปี 1990~2009 เลย สมบูรณ์แบบและไม่กำกวม แต่ไม่รู้ทำไมนักออกแบบสมาร์ตโฟนถึงไม่ชอบมัน

    • ที่ตลกกว่านั้นคือจริง ๆ แล้วคุณสามารถทำสิ่งที่โดยสาระคือ checkbox ให้ดูสวยและเหมือน toggle ได้พอสมควร นี่ไม่ใช่ตัวอย่างที่ดีนัก แต่แสดงให้เห็นว่าไม่จำเป็นต้องเป็นสี่เหลี่ยมที่มีเครื่องหมายถูกเสมอไป: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
    • ระบบให้คำปรึกษาผ่านวิดีโอทางการแพทย์/telehealth ที่ฉันใช้ทำ checkbox พังไปเลย มันเปลี่ยนป้ายกำกับของฟิลด์ checkbox ในอินเทอร์เฟซส่งข้อความโดยตรงตามว่าถูกติ๊กหรือไม่
      ถ้าไม่ติ๊กจะแสดงว่า “Not Urgent” แต่ถ้าติ๊กจะแสดงว่า “Urgent” ฉันเคยติ๊กสลับเร็ว ๆ หลายครั้งจนคิดว่าตั้งค่าเป็นไม่ด่วนแล้ว ก่อนกดส่ง
    • เห็นด้วยว่า checkbox สมบูรณ์แบบ เพียงแต่ส่วนหนึ่งเป็นเพราะฉันไม่ค่อยพยายามกรอกฟอร์มบนสมาร์ตโฟนด้วย
      checkbox แบบค่าปริยายของเบราว์เซอร์เล็กเกินไปสำหรับการกดด้วยนิ้วโป้งบนสมาร์ตโฟน จึงใช้งานบ่อย ๆ ไม่สะดวก
    • ใครเป็นคนสร้าง widget แบบ checkbox ขึ้นมากันนะ? ใน System 1 (1984) มี “x box” ที่เทียบได้กับเครื่องหมายถูกในเมนู แต่เท่าที่ฉันรู้ มันยังไม่ใช่ checkbox เอง
    • Jony Ive คือ Thomas Midgley Jr แห่งวงการออกแบบหรือเปล่า? เขาทำให้ flat design ที่ใช้งานยากกลายเป็นกระแสหลักด้วย iOS 7 และยังต้องรับผิดชอบต่อเมาส์ iMac ทรงกลมกับคีย์บอร์ด MacBook ที่พังง่ายด้วย

  • ตัวอย่างที่แย่ที่สุดที่ฉันเคยเห็นคือ UI หน้าจอแดชบอร์ดของ Tesla มีป้ายกำกับที่ไม่ได้ดูเหมือนปุ่มติดอยู่บนภาพรถและเขียนว่า “Open”
    มันอ่านได้อย่างชัดเจนว่าหมายถึงส่วนนั้นเปิดอยู่แล้ว แต่ความหมายจริงไม่ใช่แบบนั้น ป้ายนั้นเป็นปุ่มสำหรับเปิดส่วนนั้น และผู้ใช้ไม่มีทางรู้ได้เลย

    • ใช่เลย สุดสัปดาห์นี้ฉันขับ Tesla ที่เช่ามา แล้วก็งงและตกใจอยู่หลายครั้งเพราะคิดว่าทั้งท้ายหน้าและท้ายหลังเปิดอยู่ทั้งคู่
    • เห็นด้วย 100% นั่นเป็นเรื่องที่น่าหงุดหงิดอันดับสองใน UX ของฝากระโปรงท้าย Tesla อันดับหนึ่งคือ แอนิเมชันที่ยาวเกินเหตุ ที่ต้องรอหลังจากเข้าเกียร์จอดก่อนถึงจะเปิดท้ายรถได้
      โดยรวมแล้ว UX ของ Tesla ล้ำกว่ารถคันอื่นมาก แต่เรื่องเล็ก ๆ แบบนี้น่าหงุดหงิดสุด ๆ
    • ฉันว่าไม่ได้ชวนสับสนเลย ภาพเรนเดอร์ของรถแสดงสถานะปัจจุบันของฝากระโปรงท้ายอย่างชัดเจนอยู่แล้ว และเมื่อกดปุ่มเปิด ก็มีแอนิเมชันให้เห็นว่าฝาท้ายกำลังเปิด
      ดูเหมือนแต่ละคนจะรู้สึกต่างกัน
    • ที่น่าสนใจคือ นี่เป็นปัญหาของภาษาอังกฤษ ในภาษาอังกฤษคำกริยาและคำคุณศัพท์มักเป็นคำเดียวกัน ในภาษาสเปนจะต่างกัน เช่น “Abrir” (กริยารูปพื้นฐาน) กับ “Abierto” (คำคุณศัพท์) จึงไม่เกิดปัญหาแบบนี้
      ถ้าเขียนเป็น “Do open” หรือ “Is open” ก็น่าจะหลีกเลี่ยงได้ แต่สำหรับเจ้าของภาษามันจะฟังแปลกไหม?
    • หรือว่านี่จะไม่ใช่ลักษณะเฉพาะของภาษาอังกฤษ? อย่างเช่นในภาษาสเปน คำกริยากับคำคุณศัพท์เป็นคนละคำกัน

  • ปัญหาหลักของปุ่มสลับคือ มันเป็นวัตถุเดียวที่บรรจุทั้ง สถานะของระบบ และ การกระทำ ที่ใช้เปลี่ยนสถานะนั้นไว้พร้อมกัน
    ดังนั้นคำว่า “ON” ที่เห็นบนปุ่มจึงไม่ชัดเจนว่าเป็นสถานะปัจจุบัน หรือเป็นการกระทำที่จะเกิดขึ้นเมื่อกด
    วิธีแก้คือแยกสถานะกับการกระทำออกจากกันในระดับหนึ่ง มีได้หลายวิธี เช่นแบบที่มีคำตอบหนึ่งในลิงก์เสนอไว้ คือเขียนป้ายกำกับไว้นอกตัวปุ่ม
    ถ้าเป็นปุ่มสลับแบบตัวอย่างของ Teams ไม่ใช่สวิตช์ ก็สามารถคงไอคอนไว้เหมือนเดิมแล้วเปลี่ยนคุณสมบัติอื่นของปุ่มได้ เช่นแสดงให้ค้างอยู่ในสถานะถูกกดเพื่อบอกว่าอยู่ในสถานะ “ON” ซึ่งเป็นวิธีที่ใช้ได้ดีมานานหลายสิบปี

    • ในคุณสมบัติเสียงของระบบใน Windows 11 มีตัวเลือก “Allow apps and Windows to use this device for audio” และมีปุ่ม “Don't allow” อยู่ข้าง ๆ ทำให้ไม่รู้เลยว่าสถานะปัจจุบันคืออะไร

  • เห็นด้วยกับข้อสรุป แต่ทั้งสถานะปัจจุบันคืออะไร และถ้าสลับแล้วจะกลายเป็นสถานะไหน ควรต้องชัดเจนทั้งคู่ บ่อยเกินไปที่ต้องลองสลับก่อน แล้วค่อยพบว่าไม่จำเป็นต้องเปลี่ยนด้วยซ้ำ
    ประเด็นเรื่องเล่น/หยุดชั่วคราวน่าสนใจ เพราะมันดูตรงข้ามกับข้อสรุป แต่ที่เป็นแบบนั้นได้เพราะมันอิงจากแบบอย่างทางกายภาพที่คนเข้าใจกันดี และโดยปกติก็เห็นชัดอยู่แล้วว่าเพลงหรือวิดีโอกำลังเล่นอยู่หรือไม่ ดังนั้นต่อให้ไอคอนปุ่มไม่เปลี่ยน ผู้ใช้ก็ยังเข้าใจได้ว่ากดแล้วจะเกิดอะไรขึ้น
    กลับมาที่ปุ่มสลับและ UI การเปลี่ยนสีของสวิตช์จากสีเทาอ่อนไปเป็นสีเทาอ่อนขึ้นอีกนิดแทบไม่ช่วยอะไรเลย ใส่ ป้ายกำกับ มาเถอะ ถ้าป้ายกำกับไม่เข้ากับธีมการออกแบบ ก็ต้องหาดีไซเนอร์ที่ดีกว่านี้

    • ถ้าจะยึดตามแบบอย่างทางกายภาพ รูปของปุ่มก็ควรแสดงการกระทำ คือการเล่น และใช้สถานะทางสายตาว่าปุ่มถูกกดหรือไม่ถูกกดเพื่อบอกว่าการกระทำนั้นกำลังทำงานอยู่หรือไม่
      แต่นักออกแบบซอฟต์แวร์ไม่ได้ทำแบบนั้น กลับสร้างความสับสนใหม่ด้วยการสลับไอคอนเล่น/หยุดชั่วคราวไปมา ไม่ใช่เพราะเป็นมิตรกับผู้ใช้กว่า แต่เพราะปุ่ม 3D แบบ skeuomorphic หลุดจากกระแสนิยมไปแล้ว
      ข้อดีอย่างเดียวของการแสดงสถานะคือเวลามีปัญหา โดยเฉพาะกับเสียงซึ่งเกิดบ่อยมาก เช่นปิดเสียงอยู่ ถอดหูฟังออก หรือไดรเวอร์เสียงของ Linux พังอีกแล้ว
      แม้ตอนนี้เวลาเห็นปุ่มเล่น/หยุดชั่วคราวก็ยังรู้สึกขัดแย้งทางการรับรู้นิด ๆ และไม่มั่นใจ 100% ว่าปุ่มหยุดชั่วคราวหมายถึงอะไรแน่ เวลาเกิดปัญหาก็เลยเผลอกดสองครั้งไปเลย
    • เห็นด้วยว่าต้องทำให้สถานะปัจจุบันชัดเจน สำหรับสวิตช์ไฟ เราไม่จำเป็นต้องรู้ว่าทิศทางไหนคือ “เปิด” และจริง ๆ ก็ไม่รู้ด้วย เพราะแค่ดูว่าไฟติดอยู่ไหมก็พอ
    • คำว่า “ใส่ป้ายกำกับมา ถ้าไม่เข้ากับธีมการออกแบบก็หาดีไซเนอร์ที่ดีกว่านี้” โดยเฉพาะบนมือถือ ทั้งไม่ค่อยช่วยและไม่สมจริง
      ตัวอย่างเช่น Spotify ไม่มีพื้นที่พอจะใส่ป้ายกำกับหลังทุกปุ่ม ยังต้องมีที่ไว้แสดงปกอัลบั้มด้วย และฉันก็ต้องการสิ่งนั้น
      มันไม่ใช่ปัญหาว่าต้องหาดีไซเนอร์ที่ดีกว่า แต่ข้อจำกัดด้านพื้นที่มีอยู่จริง บางฟังก์ชันต้องกดครั้งเดียวแล้วทำงานได้ทันที ฉันไม่อยากซ่อนการสุ่มเพลงไว้หลังเมนูป๊อปอัป

  • ปุ่มสลับควรแสดงสถานะปัจจุบัน ช่องทำเครื่องหมาย เป็นตัวอย่างที่ดี
    Muted [] กับ Muted [x] ค่อนข้างชัดเจน
    สิ่งต่าง ๆ จะยากขึ้นเมื่อนักออกแบบสร้าง UI ที่ความสัมพันธ์ระหว่างคำกับการออกแบบภาพไม่ชัดเจน เช่น Mute Off [---( )], Mute On [( )---] แบบนี้เอาการกระทำมาปนกับคำอธิบายสถานะจนไม่รู้ว่าหมายถึงอะไร

    • ถ้ามีพื้นที่พอ ปุ่มสลับที่มีป้ายกำกับทั้งสองด้าน จะใช้ได้ดี
      Loudspeaker [()---] Crossed-out loudspeaker
    • เครื่องหมายถูกคือติ๊ก[1] ในหน้าสถานะ[2] ติ๊กหมายถึง “ทำงานปกติ” ส่วนกากบาทหมายถึงล้มเหลว ถ้ามองจากมุมของ “ความชัดเจน” แล้ว Muted [x] อาจถูกอ่านว่าแปลว่ามีบางอย่างล้มเหลว
      ถ้าจะให้เข้าใจต่างจากนั้นก็ต้องอาศัยการเรียนรู้ UX ของคอมพิวเตอร์ ซึ่งตรงข้ามกับความชัดเจนพอดี หรือไม่ก็อาจตีความได้ว่าเป็นสิ่งที่ต้องคลิกเมื่ออยากปิดเสียง แบบเดียวกับ “X marks the spot”
      [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
      [2] e.g. https://www.githubstatus.com/
    • ช่องทำเครื่องหมายแสดงทั้งสถานะปัจจุบันและตัวเลือกที่เป็นไปได้ในรูปแบบใช่/ไม่ใช่อย่างง่ายพร้อมกัน
      ส่วนปุ่มสลับทำให้สับสนเพราะไม่รู้เจตนาของนักออกแบบ เว้นแต่จะแสดงตัวเลือกทั้งสองด้านพร้อมกัน
      Mute On[---()]Off
    • ปุ่มควรบอกว่าถ้าคลิกแล้วจะทำอะไร ถ้าอยากแสดงสถานะปัจจุบัน สิ่งนั้นควรเป็นตัวบ่งชี้แยกต่างหาก ไม่ใช่ตัวปุ่ม
      ปุ่มมีไว้เพื่อให้ถูกคลิก ดังนั้นมันควรสื่อว่าคลิกแล้วจะเกิดอะไรขึ้น
    • แล้วในระบบอักษรที่เขียนจากขวาไปซ้าย ควรสลับด้านทั้งสองข้างด้วยไหม?

  • เหมือนสวิตช์แอนะล็อก ควรแสดงทั้งสองอย่าง ต้องแสดงสถานะปัจจุบันให้ชัดเจนไม่กำกวม พร้อมกันนั้นก็ต้องแสดงสถานะที่จะเปลี่ยนไปด้วย
    ปุ่มสลับแบบเลื่อนซ้ายขวาของ Apple ทำเรื่องนี้ได้ดีมาก มองเห็นชัดว่าตอนนี้ปุ่มอยู่ตำแหน่งไหน จะเปลี่ยนไปทางไหน และค่าปัจจุบันเปิดใช้งานฟังก์ชันอยู่หรือไม่ผ่านพื้นหลังสีน้ำเงิน หรือปิดใช้งานอยู่ผ่านพื้นหลังสีเทา

  • หนึ่งในดีไซน์ที่ฉันเคยชอบคือมี ไฟสถานะ อยู่ข้างสวิตช์ และเมื่อสถานะเปิด ไฟนั้นก็จะติด แต่ตอนนี้หาไม่เจอแล้ว
    ข้อดีที่สุดคือมันยังแก้ปัญหาเรื่องความหน่วงของงานแบบอะซิงโครนัสได้ด้วย กดสวิตช์แล้วตัวสวิตช์สลับ จากนั้นอีกครู่หนึ่งไฟค่อยติด มันให้ความรู้สึกพึงพอใจมากเพราะมั่นใจได้ว่าการโต้ตอบนั้นทำอะไรบางอย่างจริง ๆ

    • ถ้าไม่ได้เห็นดีไซน์จริง มันก็ดูเหมือนจะเป็นอีกตัวอย่างของความกำกวมแบบที่บทความพูดถึงอยู่ดี ไม่ชัดว่าไอคอนหมายถึงสิ่งที่จะเกิดขึ้น หรือสิ่งที่กำลังเกิดขึ้นอยู่ในตอนนี้
      ปัญหาคือมันเป็นสถานะหรือการกระทำกันแน่ ดีไซน์บางแบบอาจไม่กำกวม แต่จากคำอธิบายอย่างเดียวมันยังไม่ชัด
    • ถ้ากลับไปที่หน้านั้นอีกครั้งหลังผ่านไปนาน แล้วเห็นว่าไฟติดอยู่ เราจะรู้ได้อย่างไรว่านั่นหมายถึงสถานะปัจจุบันเป็น ON หรือหมายถึงว่าถ้าคลิกแล้วจะเปลี่ยนเป็น ON มีวิธีแยกได้ทันทีจากแค่ไฟที่ติดอยู่ไหม?
    • ฟังดูเหมือนฟังก์ชันของอินเทอร์เฟซที่เห็นในอุปกรณ์ “สมาร์ต” คุ้นแค่สวิตช์ TP-Link Kasa แต่ใน UI ของแอปนั้นก็คล้ายกัน คือมีไอคอนสีที่มีหลายสถานะ และสถานะที่ใกล้กับ “เปิดอยู่” มากที่สุดน่าจะหมายถึงตรวจสอบกับตัวสวิตช์แล้วว่าเปิดอยู่จริง
    • น่าจะเป็นกรณีใช้งานที่ดีสำหรับ หน้าจอ HDR ทำให้ “ไฟแสดงสถานะ” สว่างกว่าส่วนอื่นของหน้าจอมากได้ จนเห็นชัดมากว่าไฟติดอยู่แล้ว
      แน่นอนว่าจะใช้ได้ก็ต่อเมื่อผู้ใช้ไม่ได้ตั้งความสว่างหน้าจอสูงเกินไปตั้งแต่แรก