modal, transient (dialog)
Theppitak Karoonboonyanan
ว่ามี dialog สองชนิด คือ modal และ transient เราจะแปลว่ายังไงดี?
modal dialog เป็นกล่องโต้ตอบที่จะไม่ยอมให้โต้ตอบกับหน้าต่างหลัก
จนกว่าจะปิดกล่องโต้ตอบก่อน
transient dialog เป็นกล่องโต้ตอบที่สามารถเปิดทิ้งไว้ได้ ระหว่างทำงาน
กับหน้าต่างหลัก
ทั้งสองคำนี้ยังไม่มีคำแปลใน ossglossary
ขอบคุณครับ,
เทพ.
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
Samphan Raruenrom
> เจอคำนี้ระหว่างแปล GNOME User's Guide ครับ ตอนที่อธิบายเกี่ยวกับ dialog
> ว่ามี dialog สองชนิด คือ modal และ transient เราจะแปลว่ายังไงดี?
>
> modal dialog เป็นกล่องโต้ตอบที่จะไม่ยอมให้โต้ตอบกับหน้าต่างหลัก
> จนกว่าจะปิดกล่องโต้ตอบก่อน
>
> transient dialog เป็นกล่องโต้ตอบที่สามารถเปิดทิ้งไว้ได้ ระหว่างทำงาน
> กับหน้าต่างหลัก
>
> ทั้งสองคำนี้ยังไม่มีคำแปลใน ossglossary
>
> ขอบคุณครับ,
> เทพ.
>
transient dialog box หรือ modeless dialog box = กล่องโต้ตอบแบบไม่หยุดรอ
--
_/|\_ Samphan Raruenrom. Open Source Development Co., Ltd.
Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/
Theppitak Karoonboonyanan
> modal dialog box = กล่องโต้ตอบแบบหยุดรอ (ยาวจัง -_-')
> transient dialog box หรือ modeless dialog box = กล่องโต้ตอบแบบไม่หยุดรอ
เข้าทีครับ
หรือจะเป็น?
- modal dialog = กล่องโต้ตอบหยุดรอ
- transient/modeless dialog = กล่องโต้ตอบค้างจอ
ratchajob
Transient : Adj
ชั่วคราว
Transient Dialog Box : กล่องโต้ตอบแบบชั่วคราว
Modal : Adj.
ช่วย(มาลา)
Modal Dialog Box : กล่องโต้ตอบแบบช่วยเหลือ
ตอนนี้ผมไมู่รู้ว่าหน้าที่กับความหมายที่ คุณเทพ อธิบายไว้
สลับกันแล้วหรือเปล่า
Sira Nokyoongtong
Theppitak Karoonboonyanan
คำว่า "modal" ในที่นี้มาจากคำว่า "mode" นะครับ คือแทน dialog
แบบเปลี่ยนโหมดของโปรแกรม ทำให้หน้าต่างหลักเข้าสู่สถานะแช่แข็ง
จนกว่า dialog จะปิด
ส่วน transient เป็นศัพท์ของทางยูนิกซ์ ซึ่งจะตรงกับ "modeless" ของ
วินโดวส์ คือทางวินโดวส์มองว่าเป็นหน้าต่างที่ไม่ได้เปลี่ยนโหมดของ
โปรแกรมหลัก ในขณะที่ทางยูนิกซ์มองในแง่อายุขัยของ dialog ว่า
ต่างจากหน้าต่างหลักแค่เกิดทีหลัง ตายก่อนเท่านั้น นอกนั้นก็มีฐานะ
เป็นหน้าต่างเต็มที่เหมือนกันทุกประการ เลยใช้คำว่า transient
เพื่อสื่อความหมายนี้
Arthit Suriyawongkul
transient กล่องไม่รอตอบ (ไม่อยากใช้คำว่า ไม่ เท่าไหร่ แต่นึกไม่ออก)
Theppitak Karoonboonyanan
> modal กล่องรอตอบ
>
> transient กล่องไม่รอตอบ (ไม่อยากใช้คำว่า ไม่ เท่าไหร่ แต่นึกไม่ออก)
ทั้งสองคำเป็น adj. น่ะครับ คงไม่แปลว่า "กล่อง..." แต่คงเอาแค่คำว่า
"รอตอบ" สำหรับ modal
ส่วน transient.. นึกถึงอีกแนวคิดหนึ่งใน OpenLook ของ Sun
คือ pinned dialog โดยแทนที่จะใช้วิธีเปิด/ปิดตามปกติ OpenLook ก็ใช้
เข็มหมุดปักติดกับพื้นโต๊ะไว้
ถ้าคิดอย่างนี้ อาจจะยืมมาใช้เป็น "ปักหมุด" แต่คงยืมตรง ๆ ไม่ได้
เกิดเราได้ไปแปล OpenLook clone มั่ง คงตีกัน เพียงแต่เสนอเป็น
แนวทางหนึ่ง
เกี่ยวกับ transient ถ้าเข้าใจไม่ผิด ที่ยูนิกซ์ใช้คำนี้ ก็เพราะใน X Window
สมัยแรก ๆ ไม่มีแนวคิดของ modal เลย หน้าต่างทุกหน้าต่างเป็นอิสระจาก
กัน เปิดมาแล้วไม่กด OK ก็ไม่ปิด หน้าต่างหลักก็ยังทำงานต่อได้อีกต่างหาก
จำได้ว่าสมัยนั้น ใช้ X Window ไปแล้ว จะมี dialog ค้างอยู่ข้างหลังเต็มไป
หมด เพราะเหตุนี้ ก็เลยมีแต่หน้าต่างหลัก กับหน้าต่างชั่วคราว (transient)
ไม่มีแนวคิดเรื่อง modal/modeless
จนกระทั่งได้รับอิทธิพลจากวินโดวส์ จึงได้รับแนวคิด modal เข้ามา แต่ก็ยัง
ไม่ได้รับคำว่า modeless มาด้วย เพราะมีคำว่า transient ใช้อยู่ก่อนแล้ว
นั่นคือตามที่ผมเข้าใจเอาจากประสบการณ์การใช้นะครับ ซึ่งอาจจะผิดก็ได้
แต่ถ้าเป็นตามนี้ เราจะพยายามแปลคำว่า transient หรือ modeless ดี?
ถ้าพยายามแปลคำว่า "modeless" ก็อาจจะออกมาแบบที่อาทว่า คือ
"ไม่รอตอบ" หรือถ้าพยายามแปล "transient" ก็คงเป็นทำนอง "ชั่วคราว"
หรือไม่งั้น ก็แปลตามพฤติกรรมไปเลย ประเภท "ค้างจอ", "สถิต"
I'm latesleeper
การแปลบางฉบับในช่วงหลังๆ
ผมเกิดข้อสงสัยและอยาก
ตั้งคำถามครับ ว่า
ทั้งๆ ที่ Localisation ทำเพื่อ
สนับสนุน User Experience
แต่ทำไมเวลาคิดถึงยึดหลัก
การ "แปลให้ถูกความหมาย"
มากกว่า "แปลให้คนไทย
เข้าใจ" ครับ?
หรือว่าเรา localisation ไว้ให้คน
ที่เข้าใจภาษาอังกฤษอ่าน
กันเอง
เพื่อให้เราเปลี่ยนตัวเอง
ไปใช้ interface ภาษาไทยครับ?
คงไม่ใช่ไหมครับ?
ผมอ่านเจอหลายๆ คำที่มัน
สมกับการ "แปล" แต่มันไม่สม
กับ "การใช้"
และทั้งๆ ที่เราต้องเลือก
ที่จะแปลมันไปในทางใดทาง
หนึ่งข้างต้น
แต่เรากลับเลือกการ "แปล"
ให้ถูกความหมาย มากกว่าจะ
ส่งเสริม
"ประสบการณ์ด้านการใช้" ให้
เกิดขึ้นได้ง่ายโดยไม่
ต้องเรียนรู้เพิ่มเติม
ผมเข้าใจครับว่าการที่เรา
แปลความให้ใกล้เคียงกับ
ความหมายตามภาษาอังกฤษ
จะช่วยให้การอ้างอิง
ระหว่างภาษาง่ายดายขึ้น
แต่ผมคิดว่านั่นไม่ใช่
หลักการ
ของ localisation ที่แท้จริง ที่น่า
จะเกิดมาเพื่อ "ให้เราไม่
ต้องใช้ interface
ที่ไม่ใช่ภาษาแม่ของเรา"
นั่นหมายความว่าผู้ที่
ต้องพึ่ง localisation "ไม่จำเป็น
จะต้องกลับมาใช้ interface ใน
ภาษาอื่นๆ อย่างแน่นอน"
(กรุณาอย่านึกคำตอบโดยให้
geek experiences เข้ามาเป็น
บรรทัดฐาน
ในการตอบนะครับ)
ส่วนหนึ่งที่ผมเสนอข้อควร
คำนึงถึงเหล่านี้ เป็น
เพราะผมแค่หวังว่า
Firefox เวอร์ชั่นถัดไป ที่ Loc.
ลงตัวแล้ว น่าจะมี
ประโยชน์สำหรับแม่ของผม
"มากขึ้นกว่าเดิม" บ้าง
เท่านั้นเองครับ เพราะทุก
วันนี้แม้จะเปิดเวอร์ชั่น
ภาษาไทย
ให้แม่ผมใช้ ผมก็ยังต้อง
มาแปลความหมายคำภาษาไทย
เหล่านั้นให้แม่ผม
อยู่ดีครับ
ขอขอบคุณครับ
--
Lh • 롱 • pattaya upara
+66 8 0282 8687
Theppitak Karoonboonyanan
> หลังจากอ่านจดหมายเรื่อง
> การแปลบางฉบับในช่วงหลังๆ
> ผมเกิดข้อสงสัยและอยาก
> ตั้งคำถามครับ ว่า
> ทั้งๆ ที่ Localisation ทำเพื่อ
> สนับสนุน User Experience
> แต่ทำไมเวลาคิดถึงยึดหลัก
> การ "แปลให้ถูกความหมาย"
> มากกว่า "แปลให้คนไทย
> เข้าใจ" ครับ?
พูดกว้างอย่างนี้ ตอบไม่ถูกเหมือนกันครับ.. เพราะพิจารณากันไปหลายคำ
แต่ละคำก็มีประเด็นที่ต้องคำนึงถึงแตกต่างกันไป
แต่ถ้าจะให้ตอบกว้าง ๆ ผมก็คิดว่าเราได้คำนึงถึงทั้งสองด้านอยู่แล้วนะครับ
คำที่ตรงความหมายแต่ฟังไม่เข้าท่าก็ถูกแย้งตกไปเหมือนกัน แต่คำที่ฟังดู
เหมือนใช่ แต่เอาไปใช้กับโปรแกรมอื่นไม่ได้ ก็ต้องพยายามตกลงกัน เพื่อจะ
ให้ได้คำแปลที่สอดคล้องกัน ผู้ใช้จะได้ไม่ต้องงง ว่าคำนี้ในโปรแกรมนี้ กับ
คำนั้นในโปรแกรมนั้น หมายถึงสิ่งเดียวกันหรือเปล่า แล้วการที่จะเลือกคำ
ที่จะเหมาะสมจริง ๆ ก็ไม่ใช่ว่าต้องตรวจสอบความหมายในแง่ต่าง ๆ ให้
รอบด้านหรอกหรือครับ?
> ผมเข้าใจครับว่าการที่เรา
> แปลความให้ใกล้เคียงกับ
> ความหมายตามภาษาอังกฤษ
> จะช่วยให้การอ้างอิง
> ระหว่างภาษาง่ายดายขึ้น
ประเด็นคงไม่ได้อยู่ที่การอ้างอิงระหว่างภาษา แต่มันคือการอ้างอิง
"แนวคิด" ต่าง ๆ ที่ใช้ในโปรแกรมน่ะครับ ศัพท์แต่ละคำจะมีแนวคิด
บางอย่างของมันอยู่ ถ้าเราพยายามใช้คำเดียวกันอย่างสม่ำเสมอเวลาที่
อ้างถึงแนวคิดเหล่านั้น ก็จะทำให้ผู้ใช้เชื่อมโยงสิ่งต่าง ๆ ได้ง่าย เรียนรู้
โปรแกรมใหม่ได้ง่าย โดยไม่ต้องเดาใจผู้แปลที่แปลต่างโปรแกรม ว่าสื่อ
ถึงสิ่งเดียวกับผู้แปลอีกโปรแกรมหนึ่งหรือเปล่า
มองในภาพรวมอย่างนี้ เวลาที่อภิปรายเรื่องศัพท์เทคนิคต่าง ๆ เราจึงต้อง
สำรวจความหมายให้รอบด้าน ซึ่งอาจจะดูเหมือนพยายามแปลภาษา
อังกฤษให้ตรงความหมาย แต่มันคือการพยายามหาคำภาษาไทยให้กับ
"แนวคิด" ของคำศัพท์นั้น ๆ ผ่านการรวบรวมแง่มุมและบริบทต่าง ๆ
รอบ ๆ คำนั้น ๆ นะครับ
ถ้าเห็นใครวิเคราะห์รากศัพท์ของคำภาษาอังกฤษ ก็อย่าได้เข้าใจไปว่า
เขาพยายามจะแปลแบบถอดรากศัพท์เป๊ะ ๆ เสมอไป ผมมองว่ามันคือ
หนึ่งในวิธีการต่าง ๆ ที่จะสำรวจ "แนวคิด" โดยเป็นการย้อนรอยวิธีคิด
ของคนที่บัญญัติศัพท์ภาษาอังกฤษนั้นขึ้นมา
> แต่ผมคิดว่านั่นไม่ใช่
> หลักการ
> ของ localisation ที่แท้จริง ที่น่า
> จะเกิดมาเพื่อ "ให้เราไม่
> ต้องใช้ interface
> ที่ไม่ใช่ภาษาแม่ของเรา"
> นั่นหมายความว่าผู้ที่
> ต้องพึ่ง localisation "ไม่จำเป็น
> จะต้องกลับมาใช้ interface ใน
> ภาษาอื่นๆ อย่างแน่นอน"
> (กรุณาอย่านึกคำตอบโดยให้
> geek experiences เข้ามาเป็น
> บรรทัดฐาน
> ในการตอบนะครับ)
เหตุผลผมคงไม่ geek เกินไปนะครับ ประเด็นคือ ผมเองก็รู้สึกว่าคิดแบบ
เดียวกันอยู่แล้วน่ะครับ
> ส่วนหนึ่งที่ผมเสนอข้อควร
> คำนึงถึงเหล่านี้ เป็น
> เพราะผมแค่หวังว่า
> Firefox เวอร์ชั่นถัดไป ที่ Loc.
> ลงตัวแล้ว น่าจะมี
> ประโยชน์สำหรับแม่ของผม
> "มากขึ้นกว่าเดิม" บ้าง
> เท่านั้นเองครับ เพราะทุก
> วันนี้แม้จะเปิดเวอร์ชั่น
> ภาษาไทย
> ให้แม่ผมใช้ ผมก็ยังต้อง
> มาแปลความหมายคำภาษาไทย
> เหล่านั้นให้แม่ผม
> อยู่ดีครับ
"คำเหล่านั้น" ถ้ายกตัวอย่างเข้ามา เชื่อว่าทีมแปล firefox รวมทั้งทีมอื่น ๆ
ในที่นี้ คงรับพิจารณาครับ
I'm latesleeper
โดยรวมๆ เข้าใจมากขึ้น
ครับว่ามีการพิจารณา
"บริบท" และสถานการณ์ของการ
ปรากฏของคำนั้นข้ามา
เกี่ยวข้องด้วยครับ
แต่หลักๆ ผมยังติดใจอยู่
กับหลายๆ คำที่ส่วนใหญ่
อยู่บน interface แล้วก็ดูเหมือน
เป็นคำที่น่าจะเลือกใช้คำ
ที่ธรรมดา แต่บางทีหลัง
จากการหาข้อยุติในเมล์
เป็นเวลานานๆ ผมพบว่าคำ
นั้นกระเด็นกระดอนไปไกล
กว่าจุดหมายแรกที่มันควร
จะเป็นได้แบบไม่น่าเชื่อ
น่ะครับ เช่น ย่อยุบ ขยาย
กาง (หรืออะไรสักอย่างที่
สรุปเป็นคำว่า minimize กับ maximize)
เป็นต้น ซึ่งผมเห็นแย้ง
อยู่พอสมควรครับ ผมนึกไป
ถึงคำว่า ย่อจอ ขยายจอ แต่
ถ้าถามว่าอะไรผมก็ไม่มี
เหตุผลจะไปคัดง้างพอจะ
โน้มน้าวใจได้ นอกจากจะ
บอกว่าเวลาที่ผมบอก user คน
ไทยว่า กดปุ่มนี้เพื่อทำ
อะไร ผมก็เรียกแค่นั้นว่า
ย่อหรือขยายน่ะครับ แต่ดู
เหมือนว่าการแปลแค่ "ย่อ"
หรือ "ขยาย" เมื่อเรานั่ง
มองนานๆ เรากลับคิดว่ามัน
บอกความหมายของมันได้ไม่
ครบถ้วนด้วยซ้ำไป
ทั้งๆ ที่เรื่องของ ux มัน
ต้องมีประสบการณ์การใช้
งานของ user เข้ามาเกี่ยวข้อง
ด้วย กล่าวคือ ตัวปุ่มอาจ
บอกหน้าที่เรื่องการ "ย่อ"
ของมันได้ถึง 70% แต่ที่
เหลืออีก 30% ยูสเซอร์จำเป็น
จะต้อง "กดดู" เพื่อดู
ว่าการย่อ และขยายนั้นกิน
ขอบเขตแคบกว้างขนาดไหน
ด้วยตัวเอง อันจะทำให้
ความหมายของปุ่มๆ นี้
สมบูรณ์ได้จริงๆ น่ะครับ
และมันแทบจะเป็นไปไม่ได้
เลยที่ปุ่มดังกล่าวจะบอก
ความหมายของตัวมันเองได้
ทั้ง 100% แม้แต่ในภาษาอังกฤษ
ก็ตาม ผมขออนุญาตยก
ตัวอย่างเช่นคำว่า Send, Save, Submit
ซึ่งบ่อยครั้งเกิดอยู่บน
ปุ่มเดียวกัน แต่ความหมาย
ของมันนอกจากจะต้องประกอบ
ด้วยบริบทแวดล้อมแล้ว ยัง
ต้องเกิดจากการกดเพื่อรับ
ทราบผลหรือข้อผิดพลาดโดย
ตัว user เองด้วยครับ
อย่างไรก็ตามนี่เป็นแค่
ตัวอย่างเก่าๆ ซึ่งผมคิด
ว่าได้สรุปกันไปแล้วครับ
(ซึ่งผมคิดว่าไม่ใช่
เรื่องใหญ่อะไรครับ) และผม
ก็คิดว่าได้นำเสนอมุมมอง
อย่างที่ผมคิดว่าน่าจะ
เป็นอีกความเห็นที่ทำให้
การแปลสมบูรณ์ยิ่งขึ้นไป
แล้ว ก็จะร่วมอ่านและร่วม
เสนอความคิดเห็นต่อไปนะ
ครับ
ขอบคุณมากครับ
Lh • 롱 • pattaya upara
+66 8 0282 8687
Theppitak Karoonboonyanan
กรณีนี้ คงไม่ใช่เรื่องที่จะต้องจริงจังขนาดนั้นครับ ต้องเข้าใจว่า ใน
กระบวนการสร้างไอเดียใหม่ ๆ นั้น บางครั้งก็มาจากการสุ่มแบบนอกกรอบ
มีหลายครั้งในอดีตที่เราได้ไอเดียใหม่ ๆ มาจากการโยนความคิดนอกกรอบ
สุ่ม ๆ เข้ามา ขอให้มันไม่หลุดโลกเกินไป ผมก็มองไอเดียแนวนี้ว่าเป็น
ประโยชน์นะครับ จะใช้หรือไม่ใช้ก็อยู่ที่การพิจารณาร่วมกันครับ
บางครั้งไอเดียที่โยนเข้ามานั้นเองน่ะ ไม่ได้ใช้หรอก แต่มันช่วยขยาย
ขอบเขตความคิดออกไปหาสิ่งที่ใกล้เคียงได้
พอเข้าใจครับ แต่ระหว่างการพูดกับการเขียนก็มีส่วนต่างกันบ้าง
เวลาพูด เราเน้นกระชับ ไม่เข้าใจอะไรถามเพิ่มได้ แต่เวลาเขียน เราต้อง
เลือกใช้คำที่สื่อความให้มากที่สุด บางทีเราอภิปรายแบบไม่ลงตัวสักที
ก็มุ่งให้ได้คำที่สื่อได้ครบถ้วนเท่าที่จะเป็นไปได้โดยไม่เยิ่นเย้อเกินไป
และโดยเฉพาะสำหรับคำ maximize, minimize นี้ เนื่องจากเราเริ่มแปล
help แล้ว จึงทำให้เราได้พบแง่มุมใหม่ของการบัญญัติคำแปล คือเราต้อง
ใช้ในข้อความในเอกสารด้วย ซึ่งในเอกสารไม่ได้มีปุ่มให้ผู้ใช้ลองกด
จริงอยู่ว่าในเอกสารเราสามารถใช้คำรอบข้างอธิบายได้มากขึ้น แต่สำหรับ
ศัพท์เทคนิคที่ต้องอ้างถึงบ่อย ๆ บางครั้งก็อาศัยบริบทไปได้ไม่ตลอดครับ
การบัญญัติคำลงไปเลยจะทำให้ประโยคลื่นขึ้น รวมทั้งการอ้างอิงกับ
glossary ก็ทำได้สะดวกขึ้น
> อย่างไรก็ตามนี่เป็นแค่
> ตัวอย่างเก่าๆ ซึ่งผมคิด
> ว่าได้สรุปกันไปแล้วครับ
> (ซึ่งผมคิดว่าไม่ใช่
> เรื่องใหญ่อะไรครับ) และผม
> ก็คิดว่าได้นำเสนอมุมมอง
> อย่างที่ผมคิดว่าน่าจะ
> เป็นอีกความเห็นที่ทำให้
> การแปลสมบูรณ์ยิ่งขึ้นไป
> แล้ว ก็จะร่วมอ่านและร่วม
> เสนอความคิดเห็นต่อไปนะ
> ครับ
ขอบคุณมากครับ สำหรับข้อเสนอแนะ ซึ่งเป็นโอกาสให้ได้ทำความเข้าใจ
ซึ่งกันและกัน
Samphan Raruenrom
แทนที่จะคิดเรื่องความเข้าใจง่ายของผู้ใช้อย่างเดียว
เพราะคำแปลนั้นจะถูกใช้ในหลายที่มากเกินกว่าที่คนที่กำลังแปลอยู่จะจินตนาการได้
ถ้าแปลให้ได้ถูกใจในหนึ่งที่ พอไปอยู่ในที่อื่น เช่นโปรแกรมอื่น
อาจจะทำให้ผู้ใช้เข้าใจคนละเรื่องได้ง่ายมาก
ดูเหมือนวิธีที่ชุมชนนักแปลที่นี่ใช้กันจนเป็นประเพณีคือ conservative หรือ
play safe เอาให้ถูกต้องไว้ก่อน จะทำให้เข้าใจผิดได้ยาก
แต่เข้าใจง่ายที่สุดหรือเปล่านั่นอาจจะต้องยอมบ้าง
แน่นอนคำแปลที่ดีที่สุดคือเข้าใจง่าย ไม่ต้องคิด สื่อด้วยน้ำหนักที่เหมาะสมพอดี
และวางอยู่ในหลายๆ ที่ได้สะดวกปาก
แต่น้อยครั้งที่จะสามารถหาคำแบบนั้นได้ มีชุมชนช่วยกันคิดก็ดีขึ้นครับ
--
ratchajob
Dialog
ผมเองไม่เคยใช่ UNIX และไม่รู้ว่ามันใช้งาน
ตอนไหนบ้าง
จากที่อ่านคุณ เทพ มา ผมพอจะเข้าใจบ้าง
ดังนั้่นผมขอใส่ความเห็นผสมลงไปนิดนึง
ผมอาจอธิบายในทำนองของหลักภาษา
Modal : adj
mean Helping : n v adj
แต่มัน ช่วย กันคนละเรื่องคับ
Dialog มี 2 Mode
หน้าที่ของแต่ละโหมด
1.Modal
กล่องสนทนาแบบนี้ ทำหน้าที่ให้ความช่วยเหลืือเกี่ยวกับ คำแนะนำ
คำช่วยเหลือ หรือ คำอธิบายต่าง ๆ เมื่อเห็นว่าผู้ใช้จะกระทำการสำคัญ ๆ
ที่อาจส่งผลต่อโปรแกรม หรือ ระบบ หรือ ที่ไม่อาจย้อนกลับมาแ้ก้ไขได้
ดังนั้น ก่อนจะ ดำเนินการอะไรต่อไป
โปรแกรมจำเป็นต้องเตือนให้ผู้ใช้งานทราบก่อน และเพื่อให้แน่ใจว่า คุณ
ได้อ่านมันแล้ว คุณจำเป็นจะต้องปิดกล่องสนทนานี้ก่อนทุกครั้ง
ก่อนที่จะทำอย่างอื่นได้
2.Modaless, Transient
2.1 กล่องสนทนาแบบนี้ ทำหน้าที่แจ้งเตือนให้ผู้ใช้ทราบ
รายงานการเปลี่ยนแปลงต่าง ๆ หรือ การให้คำช่วยเหลือทั่ว ๆ ไป
สิ่งที่คุณควรจะรู้หากคุณเป็นมือใหม่
แต่ถ้าทราบแล้วก็ไม่จำเป็นจะต้องสนใจ
เว้นแต่ผู้เริ่มต้นใหม่ที่อาจจะสนใจอ่านก่อน
แต่เืนื่องจากเป็นการกระำทำที่ไม่สำคัญมาก สามารถทำย้อนกลับมาได้
คุณไม่จำเ็ป็นต้องปิดมัน ก่อนไปทำงานอื่น ๆ ที่สำคัญกว่า
2.2 เปลี่ยนการช่วยเตือนแบบ Modal มาเป็นแบบ Transient
ในกรณีที่คุณรู้หมดแล้ว หรือ คุณรู้สึกว่า "รำคาญ" และพร้อมจะเสียงทำ
คิดว่าคงไม่ทำผิดพลาด โดยไม่อ่านคำช่วยเตือนก่อน
แล้วสุดท้ายคุณค่อยปิดมันที่หลัง
ผมอธิบายตาม หน้าที่ ไม่ใช่ พฤติกรรม ที่แสดงออกนะครับ
ถ้าผมเข้าใจถูก แบบ UNIX ที่คุณ เทพ อธิบายแล้่ว ผมก็คิดว่า...
Modal ช่วยเตือน
Modaless, Transient ช่วยแจ้ง
หรืออะไรทำนองนี้ ผมเห็นด้วยหมดครับ
Theppitak Karoonboonyanan
> 2.Modaless, Transient
> 2.1 กล่องสนทนาแบบนี้ ทำหน้าที่แจ้งเตือนให้ผู้ใช้ทราบ
> รายงานการเปลี่ยนแปลงต่าง ๆ หรือ การให้คำช่วยเหลือทั่ว ๆ ไป
> สิ่งที่คุณควรจะรู้หากคุณเป็นมือใหม่
> แต่ถ้าทราบแล้วก็ไม่จำเป็นจะต้องสนใจ
> เว้นแต่ผู้เริ่มต้นใหม่ที่อาจจะสนใจอ่านก่อน
> แต่เืนื่องจากเป็นการกระำทำที่ไม่สำคัญมาก สามารถทำย้อนกลับมาได้
> คุณไม่จำเ็ป็นต้องปิดมัน ก่อนไปทำงานอื่น ๆ ที่สำคัญกว่า
> 2.2 เปลี่ยนการช่วยเตือนแบบ Modal มาเป็นแบบ Transient
> ในกรณีที่คุณรู้หมดแล้ว หรือ คุณรู้สึกว่า "รำคาญ" และพร้อมจะเสียงทำ
> คิดว่าคงไม่ทำผิดพลาด โดยไม่อ่านคำช่วยเตือนก่อน
> แล้วสุดท้ายคุณค่อยปิดมันที่หลัง
>
> ผมอธิบายตาม หน้าที่ ไม่ใช่ พฤติกรรม ที่แสดงออกนะครับ
> ถ้าผมเข้าใจถูก แบบ UNIX ที่คุณ เทพ อธิบายแล้่ว ผมก็คิดว่า...
ยังไม่ถูกเสียทีเดียวครับ ตามแนวคิดของไมโครซอฟท์แล้ว modeless
dialog ไม่ได้ใช้แจ้งข้อความอะไรทั้งสิ้นครับ แต่จะเป็น dialog ที่ค้างไว้
บนจอ เพื่อใช้ทำงานประกอบกับหน้าต่างหลัก
ตัวอย่างที่พบบ่อยคือพวก palette หรือ toolbox ทั้งหลายน่ะครับ
บางโปรแกรมเช่น GIMP, dia จะเปิดหลายหน้าต่าง มี toolbox, layer
อะไรพวกนี้ เป็นตัวอย่างที่คุ้นเคยที่สุดของ modeless dialog หรือ
transient dialog ในขณะที่บางโปรแกรมเริ่มจับพวก dialog เหล่านี้
กลับเข้าในหน้าต่างหลัก แล้วทำเป็นช่องไว้ในหน้าต่าง (เช่น inkscape,
glade-3, visio ฯลฯ) หรือกระทั่งทำให้ดึงเข้าดึงออกได้ (คือใช้วิธี dock,
tear-off)
เมื่อมีแนวคิด modal dialog เข้ามาแล้ว หน้าต่างแจ้งข้อความทั้งหลายบน
ยูนิกซ์ก็เปลี่ยนมาใช้ modal dialog กันหมดแล้วครับ (อย่างน้อยก็ GNOME)
จะเหลือการใช้ transient dialog ก็แต่ในแบบ modeless dialog ในภาษาของ
ไมโครซอฟท์เท่านั้น
> Modal ช่วยเตือน
> Modaless, Transient ช่วยแจ้ง
> หรืออะไรทำนองนี้ ผมเห็นด้วยหมดครับ
ว่ากันตามหน้าที่ modeless (ไม่ใช่ modaless) หรือ transient dialog
ไม่ได้ใช้ช่วยแจ้งอะไรในปัจจุบันครับ
Theppitak Karoonboonyanan
> 2008/10/19 ratchajob <ratc...@gmail.com>:
>> Modal ช่วยเตือน
>> Modaless, Transient ช่วยแจ้ง
>> หรืออะไรทำนองนี้ ผมเห็นด้วยหมดครับ
>
> ว่ากันตามหน้าที่ modeless (ไม่ใช่ modaless) หรือ transient dialog
> ไม่ได้ใช้ช่วยแจ้งอะไรในปัจจุบันครับ
เพิ่มเติมครับ modal ก็ไม่ได้ช่วยเตือนหรือแจ้งข้อความเสมอไปครับ
สามารถถามคำถาม เช่น ถาม username/password เพื่อ login ก็ได้
หรือแม้แต่ทำอะไรซับซ้อนอย่างเลือกตัวเลือกต่าง ๆ ก่อนทำคำสั่งก็ได้
(เช่น ตอนสั่งพิมพ์อาจให้ตั้งขนาดกระดาษ, จำนวนสำเนา,
portrait/landscape ฯลฯ ได้)
ratchajob
แต่ไม่นึกว่าคำ ๆ นี้ จะครอบคลุมถึงกล่องเครื่องมือด้วย
(ก่อนนี้ผมเข้าใจแยกกันของ Dialog Box กับ Tool Box)
งั่นเจ้า Dialog box ที่เราพูดถึงนี้ก็ครอบคลุมทั้งหมด
งั่นผมก็ต้องขอเวลาไปนึก คำก่อน
ratchajob
กรณีแรก
Dialog Box มี 2 โหมด
1 Modal Dialog Mode นี้ เป็นกล่องที่ทำหน้าที่เกี่ยวกับ แจ้งเตือน
อะไรแบบนี้หรือเปล่าคับ
2 Modeless Dialog Mode นี้เป็นกล่องที่ทำหน้าที่อื่น
ที่ไม่ใช่กล่องสนทนาแจ้งเตือน เหมือนอันบน ใช่หรือเปล่าคับ
ก็เลยกลายเป็น Modeless Dialog Mode --> Transient เหมือนกับว่า เอา
Modal Dialog มาดัดแปลงทำเป็นอย่างอื่น
ถ้าแปลตามเนื้อคำ งั่นลอง
Modal Dialog Mode กล่องแจ้งเตือน
Modeless Dialog Mode ไม่เป็นกล่องแจ้งเตือน ที่ไม่ใช่กล่องแจ้งเตือน -->
กล่องเอนกประสงค์
กรณีสอง
Dialog Box มี 2 ชนิด คือ
1 Modal กล่องร้องขอ กล่องปฏิสัมพันธ์ เนื่องจากว่า
เรียกร้องให้ผู้ใช้หันมาสนใจมัน หรือ ให้ข้อมูล หรือ ปฎิสัมพันธ์
กับมันด้วยก่อน
2 Transient กล่องเอนกประสงค์ กล่องเอนกประสงค์ชั่วคราว
คงต้องให้ คุณ เทพ หรือ ท่านอื่น มายืนยังก่อนว่า
ผมเข้าใจถูกมากน้อยเพียงใด
Theppitak Karoonboonyanan
> กรณีแรก
> Dialog Box มี 2 โหมด
> 1 Modal Dialog Mode นี้ เป็นกล่องที่ทำหน้าที่เกี่ยวกับ แจ้งเตือน
> อะไรแบบนี้หรือเปล่าคับ
> 2 Modeless Dialog Mode นี้เป็นกล่องที่ทำหน้าที่อื่น
> ที่ไม่ใช่กล่องสนทนาแจ้งเตือน เหมือนอันบน ใช่หรือเปล่าคับ
> ก็เลยกลายเป็น Modeless Dialog Mode --> Transient เหมือนกับว่า เอา
> Modal Dialog มาดัดแปลงทำเป็นอย่างอื่น
ไม่ใช่นะครับ การแจ้งเตือน เป็นแค่หน้าที่อย่างหนึ่งของ Modal dialog
เท่านั้น dialog ใด ๆ ที่แช่แข็งหน้าต่างหลัก เช่น print, save ล้วนแต่เป็น
modal dialog ทั้งนั้นครับ
> กรณีสอง
> Dialog Box มี 2 ชนิด คือ
> 1 Modal กล่องร้องขอ กล่องปฏิสัมพันธ์ เนื่องจากว่า
> เรียกร้องให้ผู้ใช้หันมาสนใจมัน หรือ ให้ข้อมูล หรือ ปฎิสัมพันธ์
> กับมันด้วยก่อน
> 2 Transient กล่องเอนกประสงค์ กล่องเอนกประสงค์ชั่วคราว
ความหมายนี้ใกล้เคียงครับ ติดแต่ว่า transient dialog ใด ๆ จะมีจุดประสงค์
เพียงอย่างใดอย่างหนึ่ง การใช้คำว่า "อเนกประสงค์" จึงกว้างเกินไปครับ
ratchajob
หน้าที่มันกว้างมาก คงต้องใช้เวลาหน่อยละครับ
ผมว่างั่น