Gnome Files: การวิเคราะห์ UI อย่างละเอียด
(datagubbe.se)- เป็นคำวิจารณ์ว่าในระหว่างใช้ Gnome Files เพื่อจัดระเบียบไฟล์จริง การใช้งานพื้นฐานอย่าง การสลับมุมมอง, การป้อนพาธ, ความช่วยเหลือ, ทูลทิป และการย้ายหน้าต่าง ทำให้ผู้ใช้สับสน
- ดรอปดาวน์ “View Options” แสดง ตัวเลือกการจัดเรียง ในทางปฏิบัติ ส่วนการสลับมุมมองซ่อนอยู่ในพื้นที่อีกส่วนของ split button ทำให้ชื่อและการจัดวางฟังก์ชันไม่สอดคล้องกัน
- แถบแสดงพาธดูเหมือนช่องป้อนข้อความ แต่แก้ไขด้วยเมาส์ไม่ได้ และเปิดใช้งานได้ด้วยคีย์ลัด Ctrl-L เท่านั้น ทำให้ความสามารถในการค้นพบฟังก์ชันของ GUI ต่ำลง
- พื้นที่ด้านบนที่ตัดแถบชื่อหน้าต่างออกไปมีการทำงานซ้อนกันระหว่างการคลิกปุ่ม การลากหน้าต่าง และเมนูบริบท ส่วนสกรอลล์บาร์ที่ซ่อนไว้ก็ขยับตำแหน่งเมื่อวางตัวชี้เมาส์ทับ ทำให้การใช้งานพื้นฐานไม่แน่นอน
- พาราไดม์ UI แบบใหม่ไม่ได้ให้ผลลัพธ์ที่ดีกว่าแพตเทิร์นที่ผ่านการพิสูจน์แล้ว เช่น แถบเมนูแบบเดิม แถบชื่อหน้าต่าง และการแสดงคีย์ลัดอย่างสม่ำเสมอ และวิธีเก่าก็ไม่ได้แปลว่าแย่โดยอัตโนมัติ
เหตุผลที่เลือก Gnome Files และสมมติฐานตั้งต้น
- จุดเน้นของคำวิจารณ์ไม่ใช่ flat design เอง แต่เป็นวิธีเข้าถึงฟังก์ชันหลักของโปรแกรม
- ยอมรับว่าดีไซน์สมัยใหม่อาจเป็นมิตรกับผู้เริ่มต้น แต่ power user ที่ใช้คอมพิวเตอร์วันละหลายชั่วโมงก็ควรถูกนับเป็นกลุ่มเป้าหมายของการออกแบบด้วย
- ยิ่งอินเทอร์เฟซซ่อนฟังก์ชันไว้มากเท่าไร ผู้ใช้ก็ยิ่งมีแนวโน้มเสียโอกาสในการค้นพบและเรียนรู้ฟังก์ชันมากขึ้นเท่านั้น
- Gnome มักเป็นสภาพแวดล้อมเดสก์ท็อปเริ่มต้นของ Linux distribution หลัก ๆ และประกาศแนวทางต่อสาธารณะ เช่น “usable by everyone”, “structurally and aesthetically elegant”, “distraction free”, “traditional desktop is dead”
- Gnome Files เป็นตัวจัดการไฟล์ซึ่งเป็นองค์ประกอบศูนย์กลางของสภาพแวดล้อมเดสก์ท็อป จึงเป็นกรณีสำคัญในการตรวจสอบปรัชญา UI ของ Gnome
ปัญหาโครงสร้างเมนูที่เผยให้เห็นจากการสลับเป็นมุมมองรายการ
- ความประทับใจแรกถูกประเมินว่าสะอาดตา นิ่ง และองค์ประกอบที่คลิกได้ก็แยกแยะได้ในระดับหนึ่ง
- ปัญหาเริ่มขึ้นระหว่างพยายามเปลี่ยนจากไอคอนขนาดใหญ่เป็น มุมมองรายการ
- บนทูลบาร์มีไอคอนที่ดูคล้ายกันหลายตัว และดรอปดาวน์ที่มีทูลทิป “View Options” ไม่ได้แสดงตัวเลือกมุมมอง แต่แสดง ตัวเลือกการจัดเรียง หลายรายการ
- ตัวเลือกที่เกี่ยวกับมุมมองจริง ๆ อย่าง “Icon Size” และ “Show Hidden Files” อยู่ใน “Main Menu” ทำให้ชื่อ “View Options” ไม่ตรงกับโครงสร้างจริง
- การสลับเป็นมุมมองรายการไม่ได้อยู่ในดรอปดาวน์ “View Options” แต่อยู่ในพื้นที่ toggle ของ split button
- ฟังก์ชัน toggle ไม่ได้ถูกแสดงร่วมในดรอปดาวน์ จึงไม่ชัดเจนว่าทำไมจึงถูกรวมไว้เป็นวิดเจ็ตเดียวกัน
- โครงสร้างนี้ทำให้ต้องใช้เวลาหาปุ่มสลับมุมมองรายการ และให้ความรู้สึกหงุดหงิดมากกว่าความสง่างามเชิงโครงสร้าง
ปัญหาความสามารถในการค้นพบของความช่วยเหลือและทูลทิป
- แม้ค้นหา “list view” ในความช่วยเหลือในตัว ก็ยังยากที่จะหาวิธีเปิดใช้มุมมองรายการได้ทันที
- แม้เปิดความช่วยเหลือจากเมนูของ Gnome Files ผลการค้นหาก็ยังแสดงรายการที่เกี่ยวข้องกับแอปพลิเคชันอื่นปะปนมาด้วย
- “Browse files and folders” เกี่ยวข้องกับ Gnome Files แต่ปรากฏหลังรายการอย่าง “Manage volumes and partitions”, “Edit contact details”
- เมื่อไล่ดูความช่วยเหลือด้วยตนเอง รายการที่เกี่ยวกับ “List View” ที่พบกลับเป็นเรื่องการทำงานที่ทำได้หลังจากเลือกมุมมองรายการแล้ว
- ทูลทิปอาจมีประโยชน์ แต่ใน Gnome Help และ Gnome Files ทูลทิปที่ไม่จำเป็น กลับกลายเป็นสิ่งรบกวน
- ใน Gnome Help ทูลทิปที่มีข้อความเดียวกับชื่อรายการบังชื่อรายการถัดไป
- ในแถบด้านข้างซ้ายของ Gnome Files รายการอย่าง “Recent”, “Starred” ก็แสดงทูลทิปที่เห็นได้ชัดอยู่แล้ว
- พฤติกรรมเช่นนี้อาจทำให้ผู้ใช้เรียนรู้ว่าทูลทิปไม่ใช่ข้อมูลที่มีประโยชน์ แต่เป็นสิ่งรบกวน
การย้ายพาธและการเปิดเผยฟังก์ชันที่เน้นคีย์ลัด
- การนำทางใน Gnome Files โดยรวมถือว่าใช้ได้ แต่ก็น่าเสียดายที่ไม่มีปุ่ม parent directory สำหรับไปยังไดเรกทอรีระดับบน
- ปุ่มย้อนกลับ/ไปข้างหน้าเพียงเลื่อนตามประวัติการนำทาง ไม่เหมือนกับการไปยังโฟลเดอร์ระดับบน
- สามารถคลิกชื่อไดเรกทอรีในแถบตำแหน่งเพื่อย้ายได้ แต่มีโอกาสคลิกพลาดสูงกว่าปุ่มโฟลเดอร์ระดับบน และสะดวกน้อยกว่า
- แถบตำแหน่งดูเหมือนกล่องข้อความ แต่ไม่สามารถเปิดโหมดแก้ไขทั่วไปด้วยเมาส์ได้
- ดูเหมือนว่าโหมดแก้ไขจะเปิดใช้งานได้ด้วยคีย์ลัด Ctrl-L เท่านั้น
- ตอนแรกคิดว่าฟังก์ชันนี้ไม่ได้ถูกทำไว้ จนมารู้จากการค้นหา และคีย์ลัดนี้ก็ปรากฏอยู่ในหน้าต่าง Keyboard Shortcuts
- หากองค์ประกอบ GUI เข้าถึงด้วยเมาส์ไม่ได้ ความสามารถในการค้นพบก็ลดลง
ข้อจำกัดของหน้าต่างคีย์ลัดและการแทนที่แถบเมนู
- รายการคีย์ลัดมี 3 หน้าและมีฟังก์ชันค้นหา แต่ถ้าไม่รู้ว่าต้องค้นหาอะไร ก็ใช้งานได้ยาก
- Gnome Help เรียกแถบตำแหน่งว่า “path bar” แต่เมื่อค้นหา “path” ในหน้าต่างคีย์ลัดกลับไม่พบผลลัพธ์
- รายการคีย์ลัดไม่มีสารบัญหรือวิธีไล่ดูหมวดหมู่อย่างรวดเร็ว จึงต้องตรวจทีละหน้า
- มีคีย์ลัดสำหรับเปิดหน้าต่าง Keyboard Shortcuts ด้วย แต่ต่างจากคีย์ลัดบางตัว ตรงที่ไม่ได้แสดงไว้ข้างรายการที่เกี่ยวข้องใน Main Menu
- แถบเมนู แบบดั้งเดิมจัดหมวดหมู่ฟังก์ชันของโปรแกรมให้มองเห็นอยู่เสมอ แสดงคีย์ลัดอย่างสม่ำเสมอ และทำให้ตัวเลือกที่ค้นพบสามารถสั่งงานได้ทันที
- ใน Gnome Files ฟังก์ชันกระจัดกระจายอยู่ทั่ว UI และฟังก์ชันที่ซ่อนอยู่บางส่วนเรียนรู้ได้ผ่านหน้าต่างคีย์ลัดแบบ modal เท่านั้น
- หน้าต่างคีย์ลัดไม่เป็นแบบโต้ตอบ และเป็น modal จึงไม่สามารถเปิดทิ้งไว้แล้วทดลองไปด้วยได้
- ผู้ใช้ต้องค้นหาคีย์ลัด จดจำ ปิดหน้าต่าง แล้วจึงเรียกใช้ฟังก์ชัน
- ในสภาพแวดล้อมที่เน้นเมาส์ หากไม่มีวิธีค้นหาและเรียกใช้ฟังก์ชันผ่าน GUI ก็ถือว่าจำกัดและชวนสับสน
ความกำกวมของ UI ด้านบนที่ไม่มีแถบชื่อหน้าต่าง
- Gnome Files ไม่มีแถบชื่อหน้าต่างจริง ๆ จึงย้ายหน้าต่างด้วยการคลิกและลากบริเวณด้านบนของหน้าต่าง
- พื้นที่ด้านบนนี้มีทูลบาร์อยู่ด้วย ดังนั้นแม้คลิกค้างที่คอนโทรล UI ที่มีฟังก์ชันอยู่แล้ว ก็ยังสามารถขยับหน้าต่างได้
- สามารถคลิกไอคอนค้นหาเพื่อเปิดการค้นหาได้ และก็สามารถคลิกค้างที่ไอคอนเดียวกันแล้วลากเพื่อย้ายหน้าต่างได้ด้วย
- ปุ่มย้อนกลับ/ไปข้างหน้าสามารถเปิดประวัติตำแหน่งด้วยการคลิกบริบทหรือ long click ได้ แต่ตัวปุ่มเองไม่ได้แสดงให้เห็นว่ามีฟังก์ชันนั้น
- ฟังก์ชันนี้ดูเหมือนไม่มีคีย์ลัด
- เมื่อ long click รายการอื่นก็ไม่ได้เปิดเมนูบริบทเสมอไป ทำให้พฤติกรรมไม่สม่ำเสมอ
- หากต้องการนำหน้าต่างขึ้นมาด้านหน้า ต้องหาพื้นที่ที่คลิกได้โดยไม่ไปแตะฟังก์ชันของโปรแกรม
- ต้องหลีกเลี่ยงการทำงานผิดพลาด เช่น เรียกค้นหา ย้ายพาธ สลับมุมมอง หรือเข้าถึงฟังก์ชันอื่น
- แม้แต่การเปิดใช้งานหน้าต่างธรรมดา ๆ ก็ทำให้ผู้ใช้ต้องระวัง เพิ่มภาระทางความคิด
- เมื่อคลิกขวาที่พื้นที่ด้านบน จะมีเมนูจัดการหน้าต่างหรือเมนูการทำงานกับไดเรกทอรีปรากฏขึ้นตามตำแหน่ง และผลลัพธ์แตกต่างกันไปตามไดเรกทอรีปัจจุบันหรือจุดที่คลิก
- การคลิกกลางสามารถเปิดชื่อไดเรกทอรี รวมถึงไดเรกทอรีปัจจุบัน เป็นแท็บใหม่ได้ และฟังก์ชันนี้ก็มีอยู่ในเมนูบริบทด้วย
สกรอลล์บาร์ที่ซ่อนไว้และพฤติกรรมของธีมเริ่มต้น
- Gnome Files หรือ GTK 4 ใช้ สกรอลล์บาร์ที่ซ่อนไว้
- เป็นพฤติกรรมที่ตรวจสอบในสภาพแวดล้อมที่ใช้การตั้งค่าเริ่มต้นและธีม GTK 4 เริ่มต้นที่ Debian จัดมาให้
- สกรอลล์บาร์ที่ซ่อนไว้ไม่เพียงซ่อนความเป็นไปได้ในการควบคุม แต่ยังซ่อนข้อมูลว่าตอนนี้อยู่ตำแหน่งใดในรายการไฟล์หรือเอกสารด้วย
- เมื่อขยับเมาส์ สกรอลล์บาร์จะปรากฏขึ้น แต่รู้สึกว่ามันเล็กและคอนทราสต์ต่ำจนมองยาก
- เมื่อนำตัวชี้ไปวางบนสกรอลล์บาร์ สกรอลล์บาร์จะขยายใหญ่และเห็นชัดขึ้น แต่จะเลื่อนไปทางซ้ายเท่ากับความกว้างเดิม ทำให้ตัวชี้ไม่ได้อยู่บนสกรอลล์บาร์อีกต่อไป
การประเมินโดยรวมและบทสรุป
- UI ของ Gnome Files ถูกประเมินว่า haphazard, incoherent และบางครั้งให้ความรู้สึกเป็นอันตราย
- ปัญหาหลักมีดังนี้
- ชื่อเมนูไม่ตรงกับเนื้อหา และตัวเลือกมุมมองจริง ๆ กระจัดกระจายอยู่หลายจุด
- คีย์ลัดไม่ได้แสดงในเมนูอย่างสม่ำเสมอ
- ฟังก์ชันทั่วไปบางอย่างเข้าถึงและค้นพบได้ผ่านคีย์ลัดเท่านั้น
- รูปลักษณ์ของวิดเจ็ตไม่ได้บอกพฤติกรรมอย่างแม่นยำ
- ทูลทิปก่อให้เกิดความเข้าใจผิดหรือรบกวนโดยไม่มีคุณค่าทางข้อมูล
- วิธีคลิกไอคอนฟังก์ชันเพื่อย้ายหน้าต่างสร้างความเสี่ยงในการคลิกผิด
- ผลลัพธ์ของการคลิกบริบทในพื้นที่ด้านบนคาดเดาได้ยาก
- สกรอลล์บาร์ของธีมเริ่มต้นขยับตำแหน่งเมื่อวางตัวชี้ทับ
- คำศัพท์ในความช่วยเหลือกับ GUI จริงไม่ตรงกัน
- ความไม่สอดคล้องเหล่านี้ทำให้ผู้ใช้สร้าง mental model ที่มั่นคงเกี่ยวกับ UI ได้ยาก
- ในเชิงฟังก์ชัน Gnome Files สามารถใช้จัดการไฟล์ได้ และหากไม่มีตัวเลือกอื่น ก็อาจคุ้นชินกับลักษณะ UI ของมันได้
- อย่างไรก็ตาม แม้แต่แอปพลิเคชันศูนย์กลางอย่าง Gnome Files ก็มีองค์ประกอบจำนวนมากที่มองได้ว่าแย่จากมุมมองการออกแบบ UI
- ไม่ได้หมายความว่าพาราไดม์เดสก์ท็อปแบบเก่าหรือโปรแกรมเดิมทั้งหมดสมบูรณ์แบบ แต่ยังคงมีประเด็นว่า พาราไดม์ใหม่ควรสร้างผลลัพธ์ที่ดีกว่านี้
- ปัญหาส่วนใหญ่ที่ถูกวิจารณ์มีวิธีแก้ที่ถูกขัดเกลามาหลายสิบปีแล้ว
- แถบชื่อหน้าต่างจริง
- วิธีแสดงคีย์ลัดในเมนูอย่างสม่ำเสมอ
- การจัดหมวดหมู่เมนูและตัวเลือกอย่างสอดคล้อง
- ภาษาการออกแบบที่สมบูรณ์ยิ่งขึ้น
- วิธีเก่าไม่ได้แย่กว่าโดยอัตโนมัติ และวิธีใหม่ก็ไม่ได้ดีกว่าโดยอัตโนมัติ
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
นึกถึงปัญหาในมุมมองรายการของ Files ที่เวลาจะสร้างเอกสารใหม่หรือวางไฟล์ อนุญาตให้ทำได้แค่ คลิกขวาบนพื้นที่ว่าง เท่านั้น
ในมุมมองรายการ ถ้ามีไฟล์มากขึ้นนิดเดียวจนหน้าต่างเต็ม พื้นที่ว่างให้คลิกก็จะหายไป
เคยมีคนเจอปัญหาเดียวกันมาก่อน 0 และดูเหมือนว่ายังไม่ได้แก้ให้ดีจริง ๆ 1
พอลองค้นดู พบว่าใน Thunar ถ้ากด
Ctrlค้างไว้แล้วคลิกขวาตรงไหนก็ได้ จะมีเมนูอย่างสร้างโฟลเดอร์ใหม่, วาง, เปิดในเทอร์มินัลขึ้นมาแต่ถ้ามีไฟล์ถูกเลือกอยู่ เมนูบริบทของรายการที่เลือกจะโผล่ขึ้นมา ทำให้ไม่มีตัวเลือกสร้างโฟลเดอร์ใหม่ สุดท้ายก็ยังต้องคลิกพื้นที่ว่างเพื่อยกเลิกการเลือก หรือรู้จักใช้
Escapeซึ่งก็ไม่ใช่ทางออกที่เหมาะนักทั้งไทล์ข่าวทั้งก้อน, ข้อความลิงก์, รูปภาพ และพื้นที่ว่างกว้าง ๆ ล้วนกลายเป็นลิงก์ เหลือแค่ช่องว่างแคบ ๆ ระหว่างไทล์ที่คลิกเป็นพื้นหลังได้
ถ้าเป็นการออกแบบแบบ touch-first ก็พอเข้าใจได้ แต่แม้แต่ซอฟต์แวร์เดสก์ท็อปอย่าง GNOME ก็ดูเหมือนมีเป้าหมายทำนองเดียวกันแทรกเข้ามา เพราะพยายามรองรับวิธีป้อนข้อมูลหลายแบบพร้อมกัน
ใน issue ที่ลิงก์ไว้มีภาพแสดง พื้นที่ที่คลิกขวาได้
https://gitlab.gnome.org/-/project/1/uploads/50ac36ab40f9049f4a823f77aa9a8a29/gr-files-right-click-zones.jpg
เลยต้องย้อนขึ้นไปยังโฟลเดอร์แม่จนกว่าจะเจอโฟลเดอร์ที่ยังไม่เต็ม จากนั้นเปิด Terminal ที่นั่น แล้วค่อย
cdกลับลงมายังโฟลเดอร์เดิมเมนูบริบทควรแสดงการกระทำที่ใช้กับวัตถุที่คลิกขวาได้ และ “เอกสารใหม่” ไม่ใช่ฟังก์ชันของไอคอนไฟล์หรือโฟลเดอร์
เวลาเราคลิกขวาที่โฟลเดอร์ ก็ยังไม่ชัดว่าจะสร้างเอกสารใหม่ในโฟลเดอร์ปัจจุบัน หรือสร้างข้างในโฟลเดอร์ที่คลิก
งานทั่วไปแบบนี้ควรอยู่ในรายการเมนูบนแถบไอคอนที่มองเห็นเสมอ แยกจากเมนูบริบทของการคลิกขวาบนพื้นที่ว่างจะดีกว่า
เป็นคำวิจารณ์ที่ดี แต่เอา ภาษาการออกแบบ กับความขัดใจจากรายละเอียดที่ยังไม่เนี้ยบมาปะปนกัน
ถ้าดู macOS Finder ตอนนี้ จะเห็นว่าดีไซน์คล้ายกับ GNOME Files มาก: https://a.qoid.us/20240907-finder.png
ดังนั้นข้อเสียของตัวดีไซน์เอง เช่น ลากหน้าต่างยาก หรือคลิกหน้าต่างเพื่อเปิดใช้งานยาก ก็มีใน Finder เช่นกัน
แต่ macOS เลี่ยงปัญหารายละเอียดส่วนใหญ่ที่ผู้เขียนชี้ไว้ได้
ตัวเลือกมุมมองมีไอคอนคล้ายกัน แต่ใน Finder ลูกศรเล็กด้านขวาของไอคอนก็เป็นส่วนหนึ่งของปุ่มเดียวกันเสมอ และไม่ได้ใช้ปุ่มแบบแบ่งส่วนในลักษณะที่ผู้เขียนบ่น
ส่วนความช่วยเหลือ macOS User Guide อธิบายความหมายของไอคอน และเมื่อพิมพ์ใน Help ก็จะค้นหาและแสดงรายการในทุกเมนูให้
ถ้าพิมพ์ “list” ก็จะเห็นรายการเมนู “as List” และสั่งการที่ต้องการได้
Tooltip ไม่มีในรายการตำแหน่งด้านซ้าย มีเฉพาะไอคอนบนแถบเครื่องมือ และยังปรากฏช้าด้วย
การนำทางใน Finder แทบไม่มีแถบตำแหน่ง กล่องโต้ตอบเปิดด้วยพาธก็ถูกซ่อนไว้ และคำสั่งไปยังโฟลเดอร์แม่ก็ไม่เด่นสะดุดตา
ถึงอย่างนั้น ก็ไม่มีองค์ประกอบที่ดูเหมือนแก้ไขได้แต่แก้ไขไม่ได้
Scrollbar ถูกซ่อนไว้เป็นค่าเริ่มต้น แต่ยังอยู่ที่ด้านขวาของหน้าต่าง และไม่ได้เด้งไปทางซ้ายอย่างที่ผู้เขียนบ่น
ถ้าไม่เชื่อ ลองเปิด https://macos9.app บนอุปกรณ์ที่มีเมาส์ แล้วลองจัดระเบียบและท่องไฟล์ดูได้
มันให้ความรู้สึกมาตลอดว่าเป็นของที่พอร์ตมาจาก NeXTStep แบบลวก ๆ แล้วถูกปล่อยทิ้งไว้อย่างรวดเร็ว
โดยรวมแล้ว Apple สูญเสีย เซนส์ด้าน UI ไปในราวสิบปีที่ผ่านมา และไม่ควรใช้ macOS เป็นตัวอย่าง UI เดสก์ท็อปที่ดีอีกต่อไป
มีรายการเมนูที่เปิดใช้ได้
ตลกดีถ้ายังมีคนเชื่อการตลาดของ Apple ที่บอกว่า OS ของตัวเองถูกหลักสรีรศาสตร์ที่สุด
แค่การสร้างโฟลเดอร์ใหม่หรือวางไฟล์ในที่ที่คล้าย tree view ก็เป็นฝันร้าย เพราะมันจะไปอยู่ในโฟลเดอร์แม่ระดับบนสุด
การเรียงตามวันที่ล่าสุดก็ไม่สมเหตุสมผล
โดยรวมเรียงจากใหม่ไปเก่า แต่ภายในกลุ่มอย่างวันที่หนึ่ง ๆ หรือสัปดาห์ก่อน กลับเรียงจากเก่าไปใหม่
นอกจากนี้ยังมีการตัดสินใจแปลก ๆ แบบนี้อีกเป็นร้อยอย่าง
การทำให้ปุ่ม
Enterแก้ไขชื่อไฟล์แทนที่จะเปิดไฟล์ก็เข้าใจได้ยากเหมือนเอาปุ่มหลักไปใช้กับงานที่แทบไม่ได้ทำ
GNOME ซ่อน Power off ไว้ในเมนูย่อยเพิ่มเติมเพื่อไม่ให้ผู้ใช้กดพลาด แต่ใน Files กลับวาง Format ไว้ติดกับ “Safely remove drive”
optจะสามารถปิดเครื่อง/รีสตาร์ตได้ทันทีด้วยการคลิกสองครั้งโดยไม่ต้องยืนยัน แต่ GNOME ต้องคลิกถึงสี่ครั้ง แถมยังมีแอนิเมชันที่ดูขัด ๆทั้งสองฝั่งยัดคอนโทรลลงในแถบชื่อหน้าต่างมากเกินไป จนแทบไม่เหลือพื้นที่ให้ลากหน้าต่าง
ช่วงนี้ได้ลองใช้ OS X 10.5 บน G4 อยู่หนึ่งสัปดาห์ และรู้สึกว่านั่นอาจเป็นจุดสูงสุดของเดสก์ท็อปแล้ว
เช่น ในเมนูของอุปกรณ์จัดเก็บข้อมูล USB จะแสดง ‘Eject’ กับ ‘Format’ อยู่ติดกัน
อันหนึ่งไม่เป็นอันตราย แต่อีกอันอาจทำลายข้อมูลได้
หลัง Format มี
...ต่อท้าย ซึ่งหมายความว่าจะเปิดกล่องโต้ตอบขึ้นมา และกล่องโต้ตอบนั้นเป็นกระบวนการ 2 ขั้นตอน โดยขั้นสุดท้ายมีคำเตือนสีแดงว่าข้อมูลทั้งหมดจะถูกลบถาวรไม่มีทางเผลอฟอร์แมตอุปกรณ์ได้หรอก
ถ้าอยากปิดเครื่องให้เร็ว ก็เปลี่ยนพฤติกรรมของปุ่มเปิด/ปิดจากพักเครื่องเป็นปิดเครื่องได้
ดีใจที่ได้อ่านบทความแบบนี้
ผมเองก็มักจินตนาการว่าอยากลองไล่ตรวจปัญหาจุกจิกน่ารำคาญใน GUI อย่างละเอียด แล้วสรุปว่ามันควรดีขึ้นอย่างไร
Ctrl+Lถ้ามองโดยไม่มีบริบทก็เป็นคีย์ลัดที่แปลก แต่ผมคุ้นกับมันเพราะรู้จักจากการใช้เบราว์เซอร์มา 15 ปีการที่ Windows, GNOME และ Nautilus ใช้ร่วมกันหมดถือว่าดีสำหรับผู้ใช้เก่าหรือผู้ใช้ขั้นสูง
อ่านซ้ำแล้ว ความไม่พอใจอาจไม่ได้อยู่ที่คีย์ลัดเองเท่าไร แต่อยู่ที่ ไม่มีวิธีอื่น มากกว่า
ปัญหาใหญ่ที่บทความไม่ได้พูดถึงคือ UI ของ GNOME ปัจจุบันคล้าย Windows 11 มาก แต่กลับทำรายละเอียดหลายอย่างเสียไป เช่น tooltip หรือแถบตำแหน่งที่คลิกได้
ผมใช้ GNOME บน Ubuntu 14.04 และ 20.04 แล้วเจอปัญหาเสถียรภาพใน 22.04 ตอนนี้เลยหันมาใช้ XFCE อย่างพอใจ และความเสถียรระยะยาวนี่แหละดีที่สุด
ตอนนี้ถ้าคลิกแถบตำแหน่ง ก็จะเข้าสู่โหมดแก้ไขได้ทันที
สิ่งที่แย่ที่สุดของแนวทาง GNOME อาจเป็น ความหยิ่ง
พอบอกว่าทำ usability research และย้ำว่ามุ่งเน้นการใช้งานซ้ำ ๆ เวลาคนคนหนึ่งรู้สึกว่าใช้งานยาก มันเลยยิ่งน่าหงุดหงิดเป็นสองเท่า
ฟังดูเหมือน “ผู้ใช้โดยเฉลี่ยพอใจ ดังนั้นคุณนั่นแหละมีปัญหา”
ถ้าคุณมีความพิการจริง ๆ ลำดับความสำคัญในการปรับ UI ให้เข้ากับคุณน่าจะสูงขึ้นด้วยเหตุผลทางการเมือง
บางครั้งผมก็ขำเวลาเผลอจินตนาการว่าในส่วนลึกของลัทธิ GNOME มีคนเพียงคนเดียวชื่อ Mother Gnome
โดยตั้งคาแรกเตอร์ว่าเป็นคนตาบอดตามกฎหมาย ใช้คีย์บอร์ดทางกายภาพไม่ได้ อยู่ในทุกกลุ่มที่ตามประวัติศาสตร์ถูกมองข้ามในหมู่ผู้ใช้คอมพิวเตอร์พร้อมกันทั้งหมด ตัวเองไม่เคยใช้คอมพิวเตอร์ และได้เรียนรู้ iPhone มาสองสามอย่างจากหลานเหลน Gen Alpha
เมื่อองค์ประกอบทั้งหมดนี้รวมกัน ก็กลายเป็นสัตว์ประหลาดแห่งอรรถประโยชน์ของการออกแบบ UI และการปรับทุกอย่างให้เหมาะกับคนคนนั้นไม่ว่าจะต้องแลกด้วยอะไรก็กลายเป็นคำสั่งทางศีลธรรมแบบเด็ดขาด
อยากให้ดิสโทรสักเจ้ารับบทบาทนี้ไป
“ผมเห็นด้วยว่ากรอบคิดการออกแบบสมัยใหม่เป็นมิตรกับผู้ใช้มือใหม่ในหลายด้าน แต่สักวันผู้คนก็จะไม่ใช่มือใหม่อีกต่อไป คนที่ใช้คอมพิวเตอร์วันละหลายชั่วโมงและทำงานหลากหลายในหลายโปรแกรมก็ควรถูกคำนึงถึงในการออกแบบด้วย ดังนั้นคำวิจารณ์ของผมจึงมาจากมุมมองที่มักเรียกกันว่าผู้ใช้ขั้นสูง อีกอย่าง ยิ่งอินเทอร์เฟซซ่อนสิ่งต่าง ๆ มากเท่าไร ก็ยิ่งให้โอกาสผู้ใช้เติบโตและเรียนรู้น้อยลงเท่านั้น”
พูดมาถึงขนาดนี้แล้วมาบ่นว่าต้องใช้คีย์ลัด ผมว่ามันเกินไปหน่อย
แถมฟีเจอร์นั้นก็เป็นฟีเจอร์ที่ต้องใช้คีย์บอร์ดอยู่แล้ว
คำบ่นว่าไม่มีปุ่มขึ้นไปโฟลเดอร์บน หรือคำวิจารณ์เรื่องมุมมองรายการก็ไม่ค่อยน่าเชื่อ
จากภาพหน้าจอ ไอคอนรายการดูออกได้ทันที และผมกลับชอบหน้าต่างที่ไม่วางปุ่มฟังก์ชันซ้ำซ้อนกระจายไปทั่ว
ข้ออ้างว่า “กดยาก” ก็แปลก
เจ้าตัวบอกว่าใช้คอมพิวเตอร์มา 35 ปี แต่คลิกพาธหนึ่งด้วยเมาส์ไม่ได้ ฟังแล้วไม่น่าเชื่อ
อ่านแล้วเหมือนคำบ่นแบบคลาสสิกของคนที่คุ้นกับระบบหนึ่งในระดับหนึ่ง แล้วมองว่าตัวเองเป็น ผู้ใช้ขั้นสูง จากนั้นก็คาดหวังให้ทุกอย่างอื่นทำงานเหมือนกันหมด
คนกลุ่มเดียวกันนี้มักบ่นว่า “คีย์ลัดมาตรฐาน” ถูกทำลาย เพราะในเทอร์มินัลใช้
Ctrl-Cเพื่อคัดลอกไม่ได้สิ่งที่ง่ายสำหรับคุณไม่ได้แปลว่าจะง่ายสำหรับคนอื่น และนั่นคือสมมติฐานของงานด้าน usability
ไม่น่าเชื่อว่าชุมชนเทคนิคแบบข้างต้นจะต่อต้านเรื่องพื้นฐานมาก ๆ ของการรับรู้ของมนุษย์ได้ขนาดนี้
ความเห็นนั้นต่างหากที่เป็นการบ่น ส่วนบทความต้นฉบับกำลังนำข้อมูลจริงจากงานวิจัยหลายสิบปีมาใช้
บทความที่เคยเขียนไว้: https://news.ycombinator.com/item?id=41303387
คงไม่คิดเลยว่าไอคอนนั้นเป็น toggle
เพราะมันไม่ได้ถูกเรนเดอร์ให้เหมือน toggle และเพราะคาดหวังว่าจะมีตัวเลือกมุมมองมากกว่าสองแบบ
อาจวางพาธลงไปก็ได้
อาจใช้เทคโนโลยีช่วยเหลืออย่างการป้อนตามเสียง หรืออยู่ในสภาพแวดล้อมที่มีวิธีป้อนข้อมูลเหมือนโทรศัพท์ แต่ไม่มีวิธีกด
Ctrlก็ได้แน่นอนว่า UI บนโทรศัพท์ควรถูกตัดสินด้วยเกณฑ์อีกแบบ
ที่แย่กว่านั้นคือแต่ละแอปเทอร์มินัลไม่มีความสอดคล้องกันเลยว่าจะใช้คีย์ลัดอะไร
มันเละเทะ และมีเหตุผลพอให้บ่น
ผมเพิ่งรู้หลังจากอ่านบทความเมื่อหลายปีก่อนที่วิจารณ์การเอากล่องข้อความออก คล้ายกับบทความต้นฉบับนี้
ไม่อย่างนั้นผมคงไม่มีทางรู้เลยว่าสามารถเปิดใช้งานกล่องข้อความพาธด้วยคีย์ลัดได้
UI ไม่ควรแค่ใช้ง่าย แต่ต้อง ค้นพบได้ ด้วย
ถ้าแม้แต่ผู้ใช้ขั้นสูงยังหาฟีเจอร์ที่ต้องการได้ยาก แล้วทำไมเราถึงควรคิดว่า UI ที่เหลือจะง่ายและค้นพบได้สำหรับทุกคน?
พูดตามตรง ผมแทบไม่ใช้ UI อยู่แล้ว ปกติใช้เทอร์มินัล และจะใช้ตัวจัดการไฟล์ของ Jade เฉพาะตอนอัปเกรดเฟิร์มแวร์คีย์บอร์ดเท่านั้น
แก้กล่องโต้ตอบบันทึกแล้วหรือยัง?
ถ้าป้อน
-s filenameก็คาดหวังว่าไฟล์ปัจจุบันจะถูกบันทึกเป็น filenameอาจมีการเติมนามสกุลไฟล์ด้วยก็ได้
พฤติกรรมของ gtk-2 คือเมื่อเริ่มป้อน filename มันจะค้นหารายการไฟล์/ไดเรกทอรี และเมื่อกด
Enterก็จะเลือกไอเท็มที่ถูกไฮไลต์อยู่อย่างไรก็ตาม ไม่มีความคิดจะติดตั้ง GNOME เพื่อตรวจสอบอยู่ดี
ก็ไม่น่าแปลกใจที่ file browser จะแย่เท่าที่บทความบรรยายไว้
โมเดลวิศวกรรมซอฟต์แวร์ cadt (cascade of attention deficit teenagers) ของ jwz เดิมทีตั้งใจใช้อธิบายพฤติกรรมของโปรเจกต์ GNOME
ดังนั้นถือว่าแก้แล้ว
ไม่เข้าใจว่าทำไมถึงหมกมุ่นกับ UI ที่ “สะอาดตา” ขนาดนั้น
ไม่เข้าใจว่าการซ่อนทุกอย่าง แล้วเปลี่ยนเป็นพื้นที่ว่างกว้าง ๆ กับไอคอนที่ไร้ลักษณะเด่น มัน “สงบ” ตรงไหน
รู้สึก ปลอดเชื้อและเย็นชา เหมือนบ้านว่างหรือเวิร์กช็อปที่ไม่ได้ใช้งาน
การมีทางเลือกที่ซับซ้อนน้อยกว่าก็เป็นเรื่องดี และไม่เห็นเหตุผลว่าทำไมทุก desktop environment ต้องทำงานเหมือนกันหมด
มันแค่ทำงาน ไม่ต้องไปยุ่ง และไม่รบกวน
สิ่งที่แย่ที่สุดใน GNOME รวมถึง Files คือ
gtkfilechooserwidget.cของ gtk3 และ gtk4มีบั๊กที่ถ้าวางพาธไฟล์ลงในกล่องโต้ตอบ
file->openแล้วจะเกิดข้อผิดพลาดและมีป๊อปอัปเด้งขึ้นมานักพัฒนา Gtk บอกว่าโค้ด filechooser เป็น สปาเกตตีโค้ด มากจนไม่มีใครอยากทำให้ filename-entry location-mode กลับมาเป็นพฤติกรรมเริ่มต้นอีก
ผมก็เห็นด้วย
ผมลองเป็นพัก ๆ อยู่ 1 ปีเพื่อแพตช์เองใน gtk 3.22 และ 3.24 แต่แก้ได้เฉพาะการเรียก
File->Openครั้งแรกของโปรเซสบางตัวเท่านั้น ส่วนการเปิดครั้งถัด ๆ ไปก็กลับมา error อีกGNOME UI และ Gtk หลังปี 2014 ไม่ได้เขียนโดยคำนึงถึงคนที่ใช้คีย์บอร์ด
นั่นคือจุดอ่อนด้าน UI ที่ใหญ่ที่สุด
มันเป็นหนึ่งในจุดเจ็บปวดหลายอย่างของ GNOME และเป็นปัญหาที่ตาม GNOME มานานแล้ว
แต่ GNOME ค่อนข้าง หรืออาจจะเป็นหลัก ๆ เลยที่ เน้นคีย์บอร์ด
มีมีมหลัง 3.0 ว่า “ทำมาแบบ touch-first” แต่คนที่พูดแบบนั้นคงไม่มีใครเคยใช้ GNOME บนอุปกรณ์สัมผัสจริง ๆ
มันคือฝันร้าย
การควบคุมหลัก ๆ ของ GNOME ทำผ่านคีย์ลัด หรือ gesture เมาส์ขนาดใหญ่ที่มีทางเลือกผ่านคีย์บอร์ดที่เร็วกว่า
ข้อร้องเรียนเหล่านี้ไม่ได้ผิด แต่ก็สงสัยว่าจริง ๆ แล้วมีผู้ใช้มากแค่ไหนที่สะดุดกับเรื่องพวกนี้
การคลิกไอคอนที่ดูเหมือนรายการเมื่อต้องการ list view ไม่ใช่พฤติกรรมที่แปลก
เห็นด้วยว่าพฤติกรรมของ dropdown แปลกอยู่บ้าง
ในทำนองเดียวกัน ทุกวันนี้แอป GNOME มี title bar ที่ใส่ control อยู่มากมาย ซึ่งก็เป็นสิ่งที่ยอมรับกันแล้ว
ถ้าคลิก control ไม่แม่นแล้วเริ่มลากเมาส์จนหน้าต่างขยับ ผมก็ไม่ได้มองว่ามันน่ารำคาญถึงขนาดนั้น
แต่ GNOME บอกว่า “ซอฟต์แวร์ของเราถูกสร้างให้ทุกคนใช้ได้ เราให้ความสำคัญอย่างลึกซึ้งกับประสบการณ์ผู้ใช้”
คำวิจารณ์ GNOME มีมากมายมหาศาลอยู่แล้ว และผมเองก็เคยเขียนไว้ที่นี่บ้าง จนรู้สึกว่าพูดต่อไปก็เสียเวลา
นักพัฒนามีวิสัยทัศน์ที่ชัดเจนมากเกี่ยวกับสิ่งที่พวกเขาต้องการทำให้สำเร็จ จึงไม่เปลี่ยนความคิด
ผู้ใช้ก็ชอบและรู้สึกสบายใจกับวิธีนั้น จึงไม่เปลี่ยนความคิด
คนที่ไม่ชอบ หรือไม่ชอบอีกต่อไป ก็จะไม่เปลี่ยนใจ เพราะมันรู้สึกแปลก สับสน และจำกัด
เดินมาในทิศทางนี้เกิน 10 ปีแล้ว แต่แทบจะไม่เปลี่ยนอะไร
อย่างที่ผู้เขียนบอก GNOME เป็นโปรเจกต์ที่ “มีเสียงดังมาก หรือก็คือดันทุรังมาก ว่าควรทำอย่างไร”
สุดท้ายถ้าชอบวิถีของ GNOME ก็ใช้ไป ถ้าไม่ชอบก็ต้องไปที่อื่น
เพียงแต่สิ่งนี้ค่อนข้างขัดกับสโลแกนว่า “ให้ทุกคนใช้ได้”
พอพวกมันทำ decoration และการออกแบบหน้าต่างเอง แท็บก็ครอบครองพื้นที่ title bar ที่ลากได้ไป 95% ทำให้หลายครั้งที่ตั้งใจจะย้ายหน้าต่าง กลับกลายเป็นย้ายแท็บแทน
ไม่รู้ว่าใครจะยอมถอยก่อนในสถานการณ์การออกแบบที่ย่ำแย่นี้ แต่ผู้ใช้เป็นคนจ่ายราคา
พูดตรง ๆ คือเบราว์เซอร์ควรเป็นฝ่ายเปลี่ยน
GNOME แสดงให้เห็นแล้วว่ามันเป็นค่าเริ่มต้นของคนส่วนใหญ่และค่อนข้างหัวแข็ง