Theppitak's blog

My personal blog.

24 เมษายน 2548

Global Menu

เรื่องมันเริ่มมาจากที่ Matthew Thomas (mpt) นักออกแบบ GUI เขียน blog วิจารณ์ usability ของ Ubuntu 5.04 (ซึ่งหลายเรื่องก็หมายถึงของ GNOME 2.10 นั่นเอง) แล้วหลายคน (ที่ Footnote, OSnews) อ่านแล้วพูดตรงกัน ว่าแม้จะอ้างทฤษฎีโน่นนี่ แต่ท้ายที่สุด ก็เป็นการวิจารณ์โดยใช้ Mac เป็นบรรทัดฐานนั่นเอง (แต่คนที่เห็นด้วยก็มีไม่น้อย) และเรื่องที่กลายเป็นประเด็นถกเถียงกันมาก ก็คือ เรื่อง global menu มีคน ไม่เห็นด้วย ซึ่งต่อมาก็มี คำโต้ตอบ จากฝ่ายสนับสนุน global menu

มีคน เขียน blog ตอบโต้ mpt เป็นเรื่องเป็นราวอีกคนด้วย

ที่ ubuntu forum มี การอภิปราย กันด้วย

เริ่มที่คำวิจารณ์ของ mpt ก่อน ความจริงอ่านแล้วมีหลายประเด็นที่น่าสนใจ เช่น:

  • (ข้อ 8) การแสดง keyboard shortcut เช่น Ctrl+F ในเมนู GNOME จะเรียงชิดขวา แทนที่จะเรียงให้เครื่องหมาย + ตัวสุดท้ายตรงกัน
  • (ข้อ 9) เมนู GNOME ด้านซ้ายเป็นรูปรอยเท้ากับคำว่า "Application" ซึ่งแปลกที่ทั้งสองเป็นรายการเดียวกัน
  • (ข้อ 15) ไดอะล็อกหลายอย่างไม่เป็น modal ทำให้มีไดอะล็อกเก่าตกค้างบนหน้าจอ
  • (ข้อ 16) ไม่ซ่อน mouse pointer เมื่อมีการพิมพ์บนแป้นพิมพ์
  • (ข้อ 25, 26) ค่า "Last" สำหรับภาษาและ session ใน gdm ไม่ระบุว่าค่าล่าสุดเป็นค่าอะไร
  • (ข้อ 28) การกลับจากการ lock จอ พบไดอะล็อกที่ไม่เข้าชุดกับตอน login (เห็นแว้บๆ ว่ามี การพิจารณา เรื่องนี้ที่โครงการ XScreenSaver อยู่เหมือนกัน รวมทั้งมีผู้เสนอ ไดอะล็อกสำหรับ GNOME ไปก่อนหน้านี้แล้ว)
  • (ข้อ 31) มีการนับถอยหลังขณะป้อนรหัสผ่านเพื่อปลดล็อกจอ ซึ่งน่าจะเคลียร์ timer ทุกครั้งที่มีการกดปุ่มบนแป้นพิมพ์ เผื่อคนพิมพ์ช้า ไม่ใช่กำหนดเวลาให้พิมพ์รหัสผ่านให้เสร็จ

แต่ข้อที่อ่านแล้วเกิดข้อถกเถียงก็คือ:

  • (ข้อ 1) ใช้เมนูในหน้าต่าง แทนที่จะใช้ global menu
  • (ข้อ 36) ไม่สามารถคลิกเพื่อเปลี่ยนชื่อไฟล์ได้

เรื่องการคลิกเปลี่ยนชื่อไฟล์ มีคนเคย เขียนชื่นชม ว่าการเปลี่ยนชื่อไฟล์ด้วย context menu ที่ nautilus ใช้นั้น ดีกว่าการคลิกเปลี่ยนชื่อ ที่ทำให้เกิดการเปลี่ยนชื่อไฟล์โดยอุบัติเหตุได้ง่าย

ส่วนเรื่องการอยากใช้ global menu นั้น ดูเหมือน Fitt's Law จะเป็นเหตุผลหลักสำหรับผู้ที่สนับสนุน โดยอ้างว่าเป็นเหตุผลที่เป็นวิทยาศาสตร์เสียด้วย แต่ในความเห็นส่วนตัว คิดว่ายังมีปัจจัยอื่นอีกที่น่าจะต้องพิจารณา

คนที่ชอบใช้ sloppy focus mode แบบผม พอจะจินตนาการถึงปัญหาที่จะพบได้ไม่ยาก เพราะขณะที่ใช้ gimp ที่ใช้หลายหน้าต่าง ก็รู้สึกว่าใช้ inspector dialog ต่างๆ ได้ยาก อย่างจะเลื่อนเมาส์ไป layer dialog แต่ดันลากผ่านหน้าต่างของอีกรูปหนึ่ง พอไปถึง layer dialog ก็กลายเป็นข้อมูลของรูปที่ลากผ่านไปแล้ว เรื่อง global menu ก็คงคล้ายกัน ถ้าต้องลากเมาส์จากหน้าต่างไปยัง global menu สุดท้าย ผมก็คงพยายามเลื่อนหน้าต่างที่จะใช้ เข้าหา global menu ก่อนน่ะแหละ แล้วอย่างนี้จะแยกเมนูออกไปทำไม

นอกจากนี้ ยังรู้สึก (ตามประสาคนไม่เคยใช้ Mac) อีกว่า พื้นที่หลักของระบบ ก็ควรทำงานของระบบ การนำเอามาแทนเมนูของหน้าต่างใดหน้าต่างหนึ่ง มันจะไม่ "ผิดความคาดหมาย" (ตามความหมายที่นักออกแบบ UI ชอบใช้กัน) ไปหน่อยรึ?

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

คนที่ตอบสนับสนุน global menu ก็บอกว่า เมนูนี่แหละ ที่ช่วยสั่งงานโปรแกรมได้ครบถ้วน การใช้ toolbar มันรก (จริงอะ? อย่างเว็บเบราว์เซอร์นี่ มีใครใช้เมนูเพื่อ back/forward/reload มั่ง?) และที่สำคัญ ดันตอบปัญหาที่ผมสนใจ คือเรื่อง sloppy focus mode แบบสั้นๆ ว่า focus mode แบบนี้ไม่น่าใช้หรอก อ้าว แล้วถ้าฉันชอบใช้ ฉันก็ต้อง anti global menu ไปเรื่อยๆ ล่ะสิเนี่ย :P

ปล. ผมไม่ได้ต่อต้านแนวคิด GUI จาก Mac นะ อย่างน้อยผมก็ชอบปุ่ม OK ที่อยู่ด้านขวาละ มันคลิกง่ายดี แต่ว่า อย่า navigate ด้วย keyboard ด้วยปุ่ม tab ละกัน จะเจอปุ่ม Cancel ก่อน แล้วก็เลือกพลาดอยู่เรื่อย (ถ้าแก้ให้ไปโดน OK ก่อน ก็จะไม่คงเส้นคงวาอีกแหละ)

14 ความเห็น:

  • 24 เมษายน 2548 เวลา 11:28 , Blogger Isriya แถลง…

    เผอิญผมก็อ่านเหมือนกัน ในฐานะที่ใช้มาหมดแล้วก็เลยมาตอบหน่อย

    - Fitt's Law นี่จริงครับ คือ ลากๆ ขึ้นไปไม่ต้องมองมากนัก ก็ถึงแล้ว เพียงแต่บน OS ตัวอื่นผมจะเปิด Maximize ไว้เหมือนกัน ทำให้ความรู้สึกมันไม่ต่างกันมากนัก ยิ่งโปรแกรมที่หน้าต่างเยอะๆ เช่นบราวเซอร์ เดี๋ยวนี้มันเป็น Tab หมด มันเลยเหมือน SDI มากกว่า MDI เลยไม่ลำบาก โปรแกรมอย่าง Photoshop ก็เมนูอยู่บนเช่นกัน ที่คิดออกตอนนี้ก็คงมีแต่ Gimp กับ IM ที่จะได้รับผลกระทบจาก Global Menu หน่อย

    - จุดที่ต่างออกไปคือ Global Menu ของแมคมันเป็นมากกว่า Local Menu ที่ย้ายที่ เพราะมันเอาไว้เก็บส่วนประกอบอื่นๆ ด้วย เช่น Notification Area ที่เป็นเหมือนกับ System Tray ของวินโดวส์ หรือ Panel ของ Gnome สาเหตุที่ต้องทำอย่างงี้เพราะว่าข้างล่างของแมคมันเป็น Dock (ที่ใสๆ ยืดได้) ไม่มีที่สำหรับพวกนี้ ก็จำเป็นต้องไว้ที่ Global Menu ในขณะที่ Gnome ไปลอกแมคมาแต่ไม่มี Dock (มีแต่ Panel) มันก็เลยไม่จำเป็นมากนักที่ Notification ต้องไปอยู่ข้างบนด้วย

    - ส่วนเรื่องคลิกเพื่อเปลี่ยนชื่อนี่ มันเป็น Feel (ที่ไม่ใช่ Look) ที่ต่างกันของแมคกับวินโดว์ เข้าใจว่า mpt คงมาจากสายแมคมากกว่า ผมเองแรกๆ ก็แปลกเหมือนกัน

    แมค: คลิก(เดียว)=เปลี่ยนชื่อ Ctrl+O/Cmd+O=เปิดไฟล์
    วิน: คลิกขวาแล้วเลือก(หรือคลิกสองทีช้าๆ)=เ้ปลี่ยนชื่อ ดับเบิลคลิก=เปิดไฟล์

    อันนี้สรุปว่าแล้วแต่คนชอบ ใช้ๆ ไปสมองมันจะแยกได้เองว่าตอนนี้ใช้อะไรอยู่ เพียงแต่ค่า default ของ Ubuntu จะเป็นยังไงก็คงแล้วแต่ทีมงานชอบมากกว่า

     
  • 24 เมษายน 2548 เวลา 14:10 , Blogger veer แถลง…

    Global menu หรือ MDI

     
  • 25 เมษายน 2548 เวลา 13:41 , Blogger the ancient แถลง…

    mpt เก่งมากนะ คุยด้วยบ่อยๆ

    1. global menu ก็ไม่จำเป็นต้องเป็น horizontal global menu ของ Mac (global menu ไม่จำเป็นต้องเรียกจากนอกหน้าต่าง) จริงๆแล้ว mpt เองก็ criticize Mac UI รวมถึง menu ไว้เยอะเหมือนกัน (NeXTstep ก็ด้วย) คือแม้ว่า mpt จะค่อนข้างเอียงไปทาง horizontal menu แต่ mpt ก็เคยบอกว่า Mac menu ไม่ควรจะเอามาเป็นต้นแบบแบบตรงๆ ส่วน sloppy focus นี่ส่วนตัวคิดว่าน่าจะเลิกใช้ไปเลย แต่ก็เป็นปัญหาแค่ Mac ส่วน GNUstep ไม่มีปัญหา เพราะ main (global) menu สามารถเปิดด้วย right-click ตรงไหนก็ได้ใน application ใช้กับ sloppy focus ได้สบาย (หรือจะ implement เป็น MDI อย่างวีร์ว่าก็ได้ แต่ MDI sucks)

    2. เห็นด้วยกับการเอา toolbar ไว้ด้านบน ส่วน app ที่ใช้ toolbar หนักๆ ก็ควร redesign application หรือ toobar ใหม่ (เช่นใน OSX ยอมให้ user สามารถ customize toolbar เพื่อให้สอดคล้องกับการใช้งานของตัวเองได้) แต่การเอา toolbar ไว้ขอบบนจอก็มีข้อเสียคือในหลายกรณีเช่นถ้า toolbar มี widget ที่ไว้ใช้ monitor document เช่น url field ใน web browser
    มันก็จะมองเห็นพร้อมๆกันไม่ได้เพราะมี toolbar เดียว ทางแก้หนึ่งคือยอมให้ user สามารถ customize ตำแหน่งของ toobar item ได้ว่าจะให้อยู่บน window หรือบนขอบจอ (ด้วย การเข้า mode edit toolbar แล้ว drag & drop toolbar item แบบ osx) การมี api ตรงนี้เพื้อสนับสนุน toolbar สองกลุ่ม (กลุ่มที่เป็น tool-based กับกลุ่มที่เป็น action/previewer-based) น่าจะแก้ปัญหาเรื่อง toolbar ของ panel ที่ focus ไม่ยอมให้ focus ไปด้วย

    3. การอยู่ชิดขอบนี้ต้องทำความเข้าใจหน่อยนึง ว่าต้องชิด 100% จะเหลือ 1-2 pixels ไม่ได้ เพราะมันต้องเป็นจุดที่ mouse ไปจอดพอดี การเว้นที่จะให้ผลที่แตกต่างกันมากพอสมควร

     
  • 25 เมษายน 2548 เวลา 13:48 , Blogger the ancient แถลง…

    4. horizontal menu มีปัญหาเรื่องขาไปไปเร็ว แต่ขากลับ ไม่ได้กลับเร็วด้วย เมื่อเปรียบเทียบกับ toolbar item กลุ่ม tool-based ซึ่งเราไม่ต้องไปกลับหลายๆครั้ง แต่ก็ขึ้นกับงานมากเหมือนกัน และ global menu ก็น่าจะแก้ไขได้ด้วยการกำหนด shortcut key ระหว่างใช้งานได้เหมือนที่ gtk+ ทำ

     
  • 26 เมษายน 2548 เวลา 10:12 , Blogger Thep แถลง…

    Mk,

    - ผมไม่สงสัย Fitt's Law นะ เพียงแต่ไม่เห็นด้วยที่จะเอามันมาเป็นเหตุผลทั้งหมดโดยไม่ดูปัจจัยอื่น แล้วก็อ้างว่าเป็นเหตุผลที่เป็นวิทยาศาสตร์

    - จริงๆ gnome ก็มี notification area เหมือนกัน และถ้าใครจะ config gnome ในแบบแมค ก็คงเอา notification area ขึ้นไปบน panel บนเหมือนกัน และผมก็เอา launcher ขึ้นไปด้วย แบบนี้ ก็ไม่เหลือที่สำหรับ global menu เหมือนกัน

    ประเด็นคงไม่ได้อยู่ที่ทำไมแมคต้องมี panel ข้างบน (ตามที่ Mk อธิบายว่าเอาไว้ใส่ notification area) แต่น่าจะเป็นคำถามว่า ทำไม gnome จึงควรใช้ global menu เหมือนอย่าง mac ด้วย

    global menu กับ panel บน เป็นคนละเรื่องกันนะ

     
  • 26 เมษายน 2548 เวลา 10:29 , Blogger Thep แถลง…

    id,

    - ผมชอบให้ right-click เป็น context menu มากกว่า global menu น่ะ เมนูมันจะได้เล็กๆ มีเฉพาะคำสั่งสำหรับ object นั้นๆ เท่านั้น แต่ถ้า right click ที่ workspace area ให้ได้ global menu (แบบ wmaker) เนี่ย เห็นด้วยนะ แต่คำถามก็คือ เนื้อหาของ global menu จะเป็น system menu หรือ application menu? ถ้าตามแบบ Mac นี่ต้องได้ application menu ซึ่งดูแปลกๆ

    - ผมชอบ sloppy focus เพราะมันไม่จำกัดว่า หน้าต่างที่รับ input จะต้องทับหน้าต่างอื่นทั้งหมด บ่อยมากที่ผมวางหน้าต่างที่ป้อนข้อมูลไว้ข้างหลัง เผยออกมาแค่ text widget แล้วก็ดูหน้าต่างอื่นไปพิมพ์ไป หรือบางทีอยากสลับหน้าต่างโดยไม่เปลี่ยน layout การวางหน้าต่าง ถ้าอยากยกขึ้นมาข้างบนเมื่อไร ค่อยคลิกที่ window handle แต่ถ้าต้องเสีย feature ตรงนี้ไปเพื่อใช้ global menu ผมคงเลือก sloppy focus มากกว่าน่ะ และความจริงแล้ว โปรแกรมเปิดหลายหน้าต่างแบบ gimp ก็เป็นปัญหาด้วย อยากเปลี่ยนเป็น MDI มากกว่า

    - การ customize toolbar ให้วางนอกหน้าต่างได้ ก็จะสร้างความยุ่งยากกับ sloppy focus มากกว่า อยากใช้ UI แบบ inkscape มากกว่าแบบ sodipodi

     
  • 26 เมษายน 2548 เวลา 15:31 , Blogger the ancient แถลง…

    global menu เนี่ย มันหมายถึงการใช้ command pattern คือ encapsulate transaction เป็น object ที่อิสระที่จะส่งไปไหนก็ได้ concept ของมันก็คือ dynamic binding นั่นเอง ดังนั้นมันก็คงจะเอาไปรวมกับ system menu ไม่ได้

    สำหรับ gnustep ถ้า right click ในจุดที่มี object ที่ถือ contextual menu อยู่ มันก็จะแสดง context menu นั้นขึ้นมาแทน click ตรงอื่นๆเช่นตรงที่ว่างๆหรือ titlebar ก็จะได้ global menu แต่ถ้า global menu ใน wmaker (ซึ่งจริงๆ wmaker ก็มีของมันเองนะ แต่อาจไม่เคยเห็นกัน เอาไว้ส่ง keyboard events ให้ app ได้ ทำเป็น user-defined macro สำหรับแต่ละ app ได้) เวลาอยู่ใน sloppy mode มันจะคอย set ให้ menu ตามเกาะขอบหน้าต่างเวลาถูกย้าย แต่ไม่ชอบ

    sloppy มีปัญหาอีกอย่างคือเวลาใช้ app ทั่วไป ตัว mouse cursor มันชอบมาบังเอกสาร ซึ่งสามารถซ่อนได้เช่นตอนพิมพ์ text ใน text field แต่ก็ไม่ทุกกรณี

    ส่วนการ input หน้าต่างข้างหลังนี่ใช้ right-click focus window ก็ได้มันก็จะไม่ raise ขึ้นมา แต่ต้องไป set ที่ wm

    เรื่องการวาง toolbar นอกหน้าต่างใน mode sloppy ไม่น่าเป็นปัญหา แก้ได้ด้วยการเลิกใช้ sloppy focus

     
  • 27 เมษายน 2548 เวลา 10:05 , Blogger Isriya แถลง…

    สงสัยเขียนอธิบายไม่ค่อยดีน่ะครับ ที่จะสื่อคือ Mac UI ถูกออกแบบมาให้เป็น Global Menu อย่างเดียว ในขณะที่ Gnome UI จะกึ่งๆ สามารถปรับเลือกได้

    คำถามของผมก็คงเหมือนพี่เทพที่ว่า จำเป็นหรือไม่ที่ gnome จะใช้ global menu ด้วย

    คำตอบก็คงเป็นเพราะหลังๆ gnome หน้าตาเหมือนแมคเข้าไปทุกวัน ความชอบของทีมงานละมั้ง

     
  • 27 เมษายน 2548 เวลา 17:20 , Blogger Thep แถลง…

    Id,

    โอเค พอเข้าใจ global menu ของ gnustep ละ แบบนั้นก็อาจจะโอเคนะ แต่ดูเหมือนมันคนละอย่างกับของ mac ที่ gnome กำลังถกว่าจะเอามาใช้หรือเปล่า? แบบของ mac นี่คือจะย้าย app menu ขึ้นไป panel บนเลย

    ใช้ right click focus window แล้วจะใช้ปุ่มไหนเปิดเมนูอีกรึ?

    จริงๆ left click ไม่ต้อง raise window ก็ได้นี่หว่า อืมๆ

     
  • 27 เมษายน 2548 เวลา 22:01 , Blogger the ancient แถลง…

    right click 2 t di, first focus, second pop menu. or you can just right-click in titlebar instead (wmaker already act like that by default for example) I love left click to raise the win na.

     
  • 27 เมษายน 2548 เวลา 22:02 , Blogger the ancient แถลง…

    ความคิดเห็นนี้ถูกลบโดยผู้ดูแลระบบของบล็อก

     
  • 27 เมษายน 2548 เวลา 22:02 , Blogger the ancient แถลง…

    ความคิดเห็นนี้ถูกลบโดยผู้ดูแลระบบของบล็อก

     
  • 28 เมษายน 2548 เวลา 01:06 , Blogger the ancient แถลง…

    this shot shows what I mean by moving toolbar on the top of the screen. I don't know what your app menu means. but if it is the one that contains Quit command for each application then I see nothing wrong by putting it at the top edge of the screen. I just think that toolbar should be better in many cases. The question should be, if gnome apps should support global menu paradigm or not. By supporting this paradigm, every contextual menu item should have their entry in the top global menu too. This is very useful for defining the general meaning for short cut keys. It also make service menu idea natural. service menu is that you can export your own menu to other applications. like you can click on any object to select it and forward it through mail app for example. unless you want to exploit every existing contextual menu eeewww... By defining the global action for the application controller, it makes life much easier to make some amazing ideas possible

    sorry that I can't type thai now. please bear with my english :)

     
  • 28 เมษายน 2548 เวลา 01:06 , Blogger the ancient แถลง…

    ความคิดเห็นนี้ถูกลบโดยผู้ดูแลระบบของบล็อก

     

แสดงความเห็น (มีการกลั่นกรองสำหรับ blog ที่เก่ากว่า 14 วัน)

<< กลับหน้าแรก

hacker emblem