- อินเทอร์เฟซผู้ใช้ (UI) ที่ซับซ้อนของซอฟต์แวร์เสรี กลายเป็นอุปสรรคในการเริ่มต้นสำหรับผู้ใช้ทั่วไป
- แม้แต่งานง่าย ๆ อย่างการแปลงวิดีโอก็ทำให้คนทั่วไปยอมแพ้ เพราะ UI ที่ออกแบบมาเพื่อผู้เชี่ยวชาญ ของเครื่องมืออย่าง Handbrake
- เพื่อแก้ปัญหานี้ ผู้เขียนจึงสร้างฟรอนต์เอนด์แบบเรียบง่ายชื่อ Magicbrake ที่มีอินเทอร์เฟซปุ่มเดียว และให้เพียงฟังก์ชัน “แปลงไฟล์วิดีโอประหลาดให้เป็น MP4 ปกติ”
- หากซ่อนความสามารถที่ซับซ้อนและ แสดงเฉพาะ 20% ของฟังก์ชันที่ผู้ใช้ส่วนใหญ่ต้องการจริง ๆ ก็จะช่วยเพิ่มทั้งประสิทธิภาพการทำงานและความพึงพอใจ
- หากระบบนิเวศของซอฟต์แวร์เสรีหันมาใช้ การออกแบบที่เป็นมิตรกับผู้ใช้ทั่วไป มากขึ้น ก็จะช่วยขยายขอบเขตการใช้งานของเครื่องมือเหล่านี้ได้
ช่องว่างระหว่างซอฟต์แวร์เสรีกับผู้ใช้ทั่วไป
- ผู้ใช้ทั่วไปมักมีปัญหากับเรื่องฟอร์แมต แม้แต่ในงานพื้นฐานอย่าง แปลงวิดีโอ อัปโหลด และเล่นไฟล์
- ไฟล์รูปแบบใดก็ตามที่ QuickTime หรือ Facebook เล่นไม่ได้ จะถูกมองว่าเป็นไฟล์ ‘ประหลาด’ ทั้งหมด
- Handbrake ทรงพลังมาก แต่เพราะมี UI ที่เน้นผู้ใช้ระดับเชี่ยวชาญ จึงทำให้ผู้ใช้ทั่วไปทั้งไม่สบายใจและสับสน
- ปัญหานี้พบได้ทั่วไปในโลกของ FOSS (Free and Open Source Software) และสุดท้ายผู้ใช้ทั่วไปก็มักเลิกใช้งานหรือไม่ก็ต้องขอให้ผู้เชี่ยวชาญช่วย
กรณีของ Magicbrake
- Magicbrake ซ่อนความสามารถที่ซับซ้อนของ Handbrake และทำเพียงหน้าที่เดียวคือ “แปลงวิดีโอประหลาดให้เป็น MP4 ปกติ”
- ผลลัพธ์ที่ได้คือ ไฟล์ MP4 ขนาดเล็ก ที่ใช้งานได้ในแทบทุกสภาพแวดล้อม
- ในอินเทอร์เฟซมี เพียงปุ่มเดียว
- แนวทางนี้เป็น วิธีแก้ที่รวดเร็วและเรียบง่าย เหมาะกับผู้ใช้ที่ไม่ได้ต้องการความสามารถซับซ้อน
ข้อโต้แย้งต่อการทำให้เรียบง่าย และคำตอบ
- บางคนตั้งคำถามว่า “ทำไมถึงทำให้ Handbrake ทรงพลังน้อยลง”, “ถ้าต้องการฟอร์แมตอื่นล่ะ?”, “แล้วฟีเจอร์พิเศษล่ะ?”
- คำตอบนั้นชัดเจน: คนที่ต้องการความสามารถขั้นสูงก็ใช้ Handbrake ตามเดิมได้ ส่วนคนที่ไม่ต้องการก็ใช้เครื่องมือแบบเรียบง่ายแทน
- แนวคิดนี้คล้ายกับ การเอาเทปไปปิดปุ่มที่ไม่จำเป็นบนรีโมตทีวี คือฟังก์ชันยังคงอยู่เมื่อจำเป็น แต่ไม่มารบกวนการใช้งานพื้นฐาน
คุณค่าของ UI ที่เรียบง่าย
- มีเครื่องมือมากมายในโลกนี้ เช่น มีเดียเซิร์ฟเวอร์ที่คนทั่วไปตั้งค่าได้ยาก, โปรแกรมตัดต่อเสียงที่ต้องเรียนรู้แม้แค่งานพื้นฐาน, และ เครื่องมือตรวจสอบเครือข่ายที่กันผู้เริ่มต้นออกไปโดยปริยาย
- เครื่องมือเหล่านี้มีความสามารถยอดเยี่ยม แต่เพราะ การออกแบบที่พยายามยัดทุกฟังก์ชันไว้ใน UI เดียว จึงทำให้ผู้ใช้ทั่วไปเข้าถึงไม่ได้
- เนื่องจาก ผู้ใช้ 80% ต้องการเพียง 20% ของฟังก์ชัน การซ่อนส่วนที่เหลือจึงอาจมอบประสบการณ์ที่มีประสิทธิภาพและน่าพึงพอใจกว่า
ข้อเสนอถึงนักพัฒนา
- การออกแบบอินเทอร์เฟซที่เรียบง่ายสำหรับผู้ใช้ทั่วไป เป็นสิ่งที่ทำได้ภายในเวลาเพียงเย็นเดียว แต่ให้คุณค่าอย่างแท้จริง
- แทนที่จะแสดงความสามารถที่ซับซ้อนทั้งหมด ปรัชญาการออกแบบที่เปิดเผยเฉพาะสิ่งที่จำเป็น จะช่วยเพิ่มการเข้าถึงของซอฟต์แวร์เสรี
- ผู้เขียนแนะนำให้นักพัฒนา สร้างเครื่องมือแบบเรียบง่ายลักษณะนี้ให้มากขึ้น
9 ความคิดเห็น
อาจอธิบายได้ว่าเป็นความซับซ้อนของ UI/UX
แต่ผมคิดว่าปัญหาคือซอฟต์แวร์ที่ถูกสร้างขึ้นทุกวันนี้ ไม่ว่าจะเป็นซอฟต์แวร์เสรีหรือเชิงพาณิชย์ มักถูกทำมาให้ผ่านได้แค่กรณีเดียวที่กำหนดไว้พอดี และแทบไม่ใส่ใจเลยว่าประสบการณ์อื่น ๆ จะเป็นอย่างไร
ยกตัวอย่างเช่น ตอนแก้ไขคอนฟิก
tomlหรือyamlก็มีหลายครั้งที่เรื่องซึ่งดูเหมือนควรจะทำได้กลับทำไม่ได้ ปกติแล้วก็มักไม่มีการเขียนเอกสารไว้อย่างชัดเจนว่านี่เป็นปัญหาเรื่อง encoding, เรื่อง indentation หรือเป็นฟีเจอร์ที่ใช้ไม่ได้เมื่อมี flag บางตัวอยู่หรือไม่ ผู้ใช้จึงต้องลองผิดลองถูกสารพัดกรณีทีละอย่าง กว่าจะหาคำตอบที่ถูกต้องเจอได้อย่างยากลำบากในส่วนของ UI นั้นยิ่งหนักกว่า อย่างที่ประสบการณ์ตอนรีเซ็ตรหัสผ่านซึ่งหลายคนคุ้นเคยกันดีถูกนำไปพูดกันจนกลายเป็นมีม ถ้าบนหน้าจอมีฟิลด์อยู่ 100 อย่าง ก็ไม่มีทางรู้ได้เลยว่ามันเกี่ยวข้องกันอย่างไร หรือควรเปลี่ยนแบบไหนถึงจะดีที่สุด "ถ้าไม่ลองทำดูก็ไม่มีทางรู้"
นี่เป็นปัญหาของ UI/UX ก็จริง แต่ก็เป็นปัญหาของ "ความเชี่ยวชาญ" ที่ซ่อนอยู่ด้วยเช่นกัน ในสภาพที่ไม่มีการเตรียม learning curve แบบเป็นขั้นเป็นตอนไว้ให้ ปัญหาที่คนมีความเชี่ยวชาญสามารถกรอกคำตอบที่ถูกต้องได้ทันที กลับทำหน้าที่เป็นเหมือนข้อสอบหรือด่านกั้นสำหรับผู้เริ่มต้น ทำให้พวกเขาต้องเผชิญกับการถูกปฏิเสธซ้ำแล้วซ้ำเล่าเป็นจำนวนมาก
ในบริบทที่คล้ายกัน ดูเหมือนว่า GUI จะสะดวกกว่า CLI อยู่เหมือนกัน ตอนนี้ก็ใช้งาน
yt-dlpผ่านyt-dlgแบบ GUI อยู่ ส่วนffmpegก็จดคำสั่งที่ใช้บ่อยเอาไว้แล้วค่อยใช้งานอยู่ แต่ก็น่าจะทำ GUI ได้เหมือนกันนะก็เรื่อง UI/UX นั่นแหละ!!
ส่วนตัวแล้วผมเองก็เคยคิดอะไรคล้าย ๆ กันอยู่บ่อย ๆ เลยรู้สึกเห็นด้วยพอสมควรครับ ตอนที่พยายามหาแอปบน Linux ที่แบบ "แค่เปิดขึ้นมาไว ๆ แล้วก็ใช้งานพอประมาณได้เลย" เหมือน Paint, Notepad, Media Player ในยุค WinXP~7 นี่ ถ้าได้ลองติดตั้งสัก 5~6 ตัวแล้วสุดท้ายเจอตัวที่ถูกใจก็ยังถือว่าโชคดีเลย
ทั้งที่แค่ต้องการจับภาพหน้าจอแล้วครอปนิดหน่อย จะให้ใช้ Gimp ก็คงไม่ไหว และแม้จะจำไม่ได้แล้วว่าลองอะไรไปบ้าง แต่ก็หาในบรรดาแอป gtk ไม่เจอ สุดท้ายเลยมาจบที่ Kolourpaint ส่วน Notepad ก็มีทั้ง Gedit, Kate, Mousepad, Leafpad, Xed ฯลฯ แล้วถ้าจะหาตัวที่เบากว่านี้ ก็ต้องไปถึงพวก xedit, nano, vim ที่แทบจะยอมแพ้เรื่องความเป็นมิตรกับผู้ใช้ไปเลย ส่วนมีเดียเพลเยอร์นี่ แค่นึกถึงพวก mpv, VLC, mplayer ก็เริ่มอึดอัดแล้วครับ
บทความแบบนี้ดูแปลก ๆ ตรงที่อ้างว่าตัวเองถูกต้องทั้งที่ไม่มีสถิติอะไรเลยนะ
ผู้ใช้สนใจแอปพลิเคชันเพียง 20% เท่านั้น
ถ้ามองอีกแง่หนึ่ง ก็ดูเหมือนว่าจะเชื่อมโยงกับบทความข้างต้นด้วยนะครับ
"ผู้ใช้ส่วนใหญ่ใช้เพียงประมาณ 20% ของฟังก์ชันของแอปพลิเคชันที่ตัวเองต้องการ แต่ 20% นั้นแตกต่างกันไปในแต่ละคน"
นี่ไม่ใช่ประเด็นสำคัญหรอกหรือ?
พอทำอะไรนิดหน่อยก็มักจะได้คำตอบกลับมาว่า "ไปอ่าน man/readme/docs ก่อนสิ"
แต่จริง ๆ แล้วสิ่งสำคัญในด้าน UX คือ ต่อให้แค่ลองใช้ก็ต้องพอเข้าใจวิธีใช้งานได้ทันที
แน่นอนว่าเพราะมันไม่ใช่งานที่ทำเพื่อรับเงินก็เลยพอปล่อยผ่านได้ แต่ถ้าลองคิดจากมุมของผู้ใช้ที่ไม่ใช่นักพัฒนา ก็ต้องยอมรับว่าประสบการณ์การใช้งานนั้นไม่ได้ดีนัก
ความคิดเห็นจาก Hacker News
เป็นบทความที่ดี แต่ผมคิดว่าตรรกะผิดไป
การสร้าง อินเทอร์เฟซที่เรียบง่ายเพียงหนึ่งเดียว ไม่ใช่เรื่องง่ายเลย
การทำ UI ให้เหมาะกับกรณีใช้งานเฉพาะอย่างหนึ่งไม่ยากนัก แต่สิ่งที่ยากจริง ๆ คือการนิยามว่า ‘กรณีใช้งานที่ถูกต้องนั้น’ คืออะไร และกันคำขอแบบ “ขอเพิ่มอีกนิดได้ไหม” ออกไป
ความเรียบง่ายแบบนี้เป็นสิ่งที่พึงประสงค์ แต่ก็เป็น สภาวะที่ไม่มั่นคง
ความซับซ้อนของโค้ดมองเห็นได้ แต่ความซับซ้อนของ UI มองไม่เห็น
ปุ่มกับช่องกรอกข้อมูลดูเหมือนเรียบง่าย แต่การแก้ปัญหาด้วยภาษานั้นซับซ้อนมาก
ความล้มเหลวเห็นได้ชัด แต่ความสำเร็จคลุมเครือและต่างกันไปในแต่ละผู้ใช้
อินเทอร์เฟซที่ดีจะสื่อสารหลายอย่างแบบ ‘โดยนัย’ และนั่นคือส่วนที่ยากที่สุด
ทั้งที่ปุ่มนั้นแทบไม่เกี่ยวกับหน้าที่เดิม Y เลย แต่ก็ยังยืนยันว่าปุ่มนั้นต้องทำสิ่งนั้น
คำขอแบบ ‘ขอเปลี่ยนนิดเดียว’ เหล่านี้พอสะสมเข้าก็ทำให้ UI ซับซ้อนขึ้นเรื่อย ๆ และสุดท้ายก็พัง
ไม่ค่อยยอมเสียความสะดวกของตัวเองเพื่อ usability ของผู้ใช้ทั่วไป 80%
คือกำหนดชุดฟีเจอร์ไว้ล่วงหน้า แล้วหลังจากนั้นโฟกัสที่การแก้บั๊กกับเพิ่มประสิทธิภาพ
ฟีเจอร์ใหม่จะเพิ่มได้ก็ต่อเมื่อผ่านการพิจารณาอย่างเข้มงวด
แม้จะใช้ยากกับซอฟต์แวร์ที่เปลี่ยนเร็ว แต่คิดว่าน่าจะได้ผลในสาขาส่วนใหญ่ที่ค่อนข้างนิ่ง
ในระยะยาว ตัวแอปเองอาจผสาน AI เข้าไป และพัฒนาไปสู่การสร้าง UI ตามที่ผู้ใช้ต้องการโดยอัตโนมัติ
ผมคิดว่าปัญหานี้สุดท้ายแล้วคือเรื่องของ ความคุ้นเคย
ภรรยาของผมไม่ค่อยถนัดเทคโนโลยี แต่เป็นผู้ใช้ Linux
พอเริ่มธุรกิจใหม่แล้วจำเป็นต้องใช้ Windows ก็รู้สึกอึดอัดมากจนอยากกลับไปใช้ Linux อีก
ตัวผมเองก็มีประสบการณ์คล้ายกันกับ Mac vs PC
ตอนที่ถูกบังคับให้ใช้ Mac ประสิทธิภาพการทำงานของผมตกไปเหลือราว 10% และลำบากมาก
สุดท้ายแล้วคนเราทำงานได้ดีที่สุดในสภาพแวดล้อมที่ตัวเองคุ้นเคย
สุดท้ายมันก็เป็นแค่ ‘คอมพิวเตอร์เครื่องหนึ่ง’ เท่านั้น
โชคดีที่ VPN และแอปที่จำเป็นทั้งหมดใช้งานผ่าน Linux + เว็บอินเทอร์เฟซ ได้
เราต้องการดิสโทรที่เสถียร ซึ่งให้ UI ที่เกือบเหมือนกับ OS เชิงพาณิชย์และไม่ต้องเปิดเทอร์มินัล
สิ่งสำคัญไม่ใช่แค่ “คล้ายกันพอประมาณ” แต่คือ ความประณีตในรายละเอียด
UI ของโอเพนซอร์สมักให้ความรู้สึก แปลกและซับซ้อน ในตอนแรก
เพราะมันถูกสร้างโดยยึดนักพัฒนาเป็นศูนย์กลาง จึงไม่ค่อยรักษาหลักการ ‘อย่าทำให้ผู้ใช้ตกใจ’ ของผู้ใช้ทั่วไป
แต่ถ้าใช้อย่างต่อเนื่อง ก็จะคุ้นกับปรัชญาใหม่และใช้งานได้อย่างประสบความสำเร็จ
ผมเองก็ใช้ Firefox, LibreOffice, Avidemux, Virt-manager ได้ดี
ปัญหาคือ การขาดแคลนบุคลากรด้านดีไซน์
FOSS มักมีแต่นักพัฒนาที่พอมีเวลาว่างเข้ามาร่วม แต่มีศิลปินหรือนักออกแบบค่อนข้างน้อย
เลยทำให้หลายครั้งมีแค่ UI ในระดับพื้นฐานเท่านั้น
นักออกแบบรับรู้ปัญหา UX ของโปรแกรมตัดต่อเสียงฟรี Audacity อยู่แล้ว
และได้อัปโหลด วิดีโอรีดีไซน์ UX เพื่อแก้ปัญหาเรื่อง “mode” และ “Audacity says no”
ต่อจากนี้น่าจะดีขึ้น และถึงแม้ UX ที่ดี ในโอเพนซอร์สยังมีไม่พอ แต่ก็กำลังเปลี่ยนแปลงอยู่
ตอนแรกเป็นแอปที่ทำไว้ใช้เอง แต่พอคนเริ่มใช้ก็จะบอกว่า “ฟีเจอร์ดีนะ แต่ UX ไม่ดี”
ในทางกลับกัน ถ้าปรับ UX ก็จะมีคนบอกว่า “ฟีเจอร์ยังไม่พอ”
สุดท้ายพอพยายามทำให้ทุกคนพอใจ ก็จะตกไปอยู่ใน นรกแห่งการรีดีไซน์ไม่รู้จบ
หลายโปรเจกต์ก็พังเพราะไปทำอะไรอย่างเอนจินธีม
ถ้าออกใหม่โดยเปลี่ยนชื่อเฉย ๆ ก็คงไม่มีใครบ่น
ผมคิดว่าทางออกของปัญหานี้อยู่ที่ การทำให้เป็นมาตรฐานในระดับ OS
OS ควรให้ UI และ workflow ที่สอดคล้องกัน
เช่น แทนที่จะมี “Handbrake” ก็มีแอปพื้นฐานชื่อ “Video Converter”
ที่เข้าใจคำสั่งอย่าง “แปลงให้เล่นบน Facebook ได้” และตั้งค่าให้อัตโนมัติ
ควรลดการเน้นแบรนด์ของแอปให้น้อยที่สุด และให้ผู้ใช้ควบคุม ธีมและฟอนต์ ได้อย่างสมบูรณ์
อีกทั้งยังต้องมี ภาษาเชลล์มาตรฐาน ที่เชื่อมกับความสามารถของ GUI ด้วย
ผู้คนสุดท้ายแล้วต้องการ ฟังก์ชันการใช้งาน
ต่อให้ UI ซับซ้อน ถ้าเรียนรู้แล้วทำสิ่งที่ต้องการได้ คนก็ยอมรับ
ซอฟต์แวร์ที่มีแค่ตัวเลือกง่าย ๆ มักมีตลาดเล็ก
ผู้ใช้ที่ไม่เข้าใจฟอร์แมตวิดีโอก็มักไปค้นเว็บว่า “convert x to y” แล้วแก้ปัญหาเอา
ถ้าถึงขั้นใช้เครื่องมือเฉพาะทาง ก็ถือว่าอยู่ในขอบเขตของ ผู้ใช้ระดับมืออาชีพ แล้ว
UI แบบ เรียบง่าย อย่าง “ลากไฟล์มาวางตรงนี้แล้วกด Fix It” ก็เป็นไปได้
ผมคิดว่านั่นแหละคือประเด็นที่บทความต้นฉบับต้องการสื่อ
มีหลายเหตุผลที่โอเพนซอร์สดูซับซ้อน
แต่ FOSS ส่วนใหญ่ยังมีโครงสร้างที่ต้องอาศัย ความรู้เท่าทันทางเทคนิค
และการเรียนรู้ซอฟต์แวร์ที่ซับซ้อนกลับมีประสิทธิภาพกว่าในระยะยาว
นักพัฒนาโอเพนซอร์สมีเวลาจำกัด จึงยากที่จะให้สิ่งนี้เป็นลำดับความสำคัญ
มีมุกว่าถ้าคิดว่า Handbrake ยาก ก็อย่าได้ไปให้เห็น ffmpeg เลย
ตอนที่ผมใช้ Handbrake ครั้งแรก ผมก็รู้สึกว่ามันสะดวกกว่า ffmpeg มาก
ในขณะที่เครื่องมือ GUI ต้องดูวิดีโอถึงจะเรียนรู้ได้
ffmpeg -i input.avi output.mp4แค่บรรทัดเดียวก็จบHandbrake แสดงตัวเลือกทั้งหมด แต่ ffmpeg ให้กรอกเฉพาะสิ่งที่ต้องใช้
พอชำนาญแล้วก็จะควบคุมได้อย่าง แม่นยำมาก
ความเรียบง่ายแบบ “ใส่แค่อินพุตกับเอาต์พุตก็เสร็จ” นี่เองที่มีเสน่ห์
มันไม่สมบูรณ์แบบ แต่ผมรู้สึกว่ามันเก่งกว่าผม
เพราะอย่างนั้นจึงรู้สึกว่ามันเป็นตัวอย่างที่แปลกไปหน่อยสำหรับบทความต้นฉบับ
คนอย่างผมชอบ อินเทอร์เฟซที่ซับซ้อน
ผมอยากให้ระบบสมมติว่าผมฉลาดพอ
ยิ่งเป็นเครื่องมือที่ใช้บ่อย ก็ยิ่งอยากให้ทำงานได้เร็วแม้จะซับซ้อนก็ตาม
ปัญหาคือทุกคนต่างต้องการ ฟีเจอร์ 20% ที่ไม่เหมือนกัน
UI/UX ที่ดีต้องอาศัย วงจรฟีดแบ็กที่ใกล้ชิดระหว่างผู้ทดสอบ–นักออกแบบ–นักพัฒนา–ผู้ใช้
ซึ่ง FOSS ไม่มีทรัพยากรมากพอสำหรับสิ่งนั้น
แต่ผู้ใช้เฉลี่ยของ FOSS คือ power user ระดับ 1% บนสุด จึงไม่เข้าใจเรื่องนั้น
เพราะฉะนั้นพอจะเปลี่ยนให้ยึดผู้ใช้ทั่วไปเป็นศูนย์กลาง ก็จะเจอแรงต้านจากชุมชน
นักพัฒนาสร้างเพราะความต้องการของตัวเอง ดังนั้น ความพึงพอใจของผู้ใช้ อาจไม่ใช่เป้าหมาย
นั่นไม่ใช่ความล้มเหลว แต่เป็นแค่เป้าหมายที่ต่างกัน
มีเพียงบางส่วนเท่านั้นที่ใช้ฟีเจอร์ขั้นสูง
เพราะอย่างนั้นการแยกเป็น UI พื้นฐาน + โหมดขั้นสูง จึงเป็นแนวทางที่สมจริง
เพราะมีแต่ผู้ใช้ที่คุ้นกับ UI เดิมอยู่แล้วมาเป็นผู้ทดสอบ จึงมักมีเสียงว่า “อย่าเปลี่ยน”
ในขณะที่บริษัทใหญ่สามารถทำ การทดสอบผู้ใช้แบบมีค่าใช้จ่าย กับผู้ใช้ใหม่ได้
จึงปรับปรุง UX ได้เร็วกว่า
พอขอให้ผู้เชี่ยวชาญด้าน UI/UX มาช่วยร่วมพัฒนา ก็มักจะ ไม่ได้รับความเข้าใจ