ตอนที่ 1 เทียบการพัฒนาโปรแกรมกับอาหาร

ผมชอบเรื่อง interface design มานานแล้ว ก็เลยมีเอกสารพวกนี้มากอยู่เหมือนกัน แต่เอกสารที่ชอบที่สุดคงเป็น presentation ของ John Geleynse (Manager, Software Technology Evangelist & User Experience Evangelist from Apple) เป็น presentation ที่พูดในงาน WWDC ปี 2006

นาย John เปรียบเทียบ application กับอาหารสองแบบ คือ

ประสบการณ์ที่ได้จาก Fast Food

1. ใช้คนที่ไม่ใช่กุ๊ก เป็นแค่คนที่ทำอาหารได้ ส่วนเราก็จะกลายเป็นแค่คนที่กินได้ แค่ผักกับเนื้อมากๆ ก็พอ เหมือนกับโปรแกรมที่เน้นอัดโน่นนี่ลงไป ให้ทำอะไรได้มากๆ ในหน้าจอเดียว ไม่ได้
2. วัตถุดิบแบบโหล สิ่งที่เค้าเน่นคือเรื่องของราคา library ต่างๆ ที่นำมาใช้ก็เลือกที่ใช้ได้ ไม่คำนึงว่าต้องดีที่สุด แค่ทำงานได้ก็พอ
3. สารอาหารต่ำ หลายอย่างที่ผู้บริโภคมองไม่เห็น แต่เป็นสิ่งที่ได้มายกตัวอย่างเช่นโปรแกรม presentation บางตัวใช้งานแล้วอาจจะทำให้ผู้ใช้ ฉลาดน้อยลงก็ได้ (อยากให้ลองฟังบทความ โปรแกรมพลังจุด จาก dualgeek podcast
4. กินได้ กินบ่อยๆ ก็อร่อยเอง ยิ่งใช้มานานก็จะยึดติดมากขึ้นเรื่อยๆ สุดท้ายพอใช้ได้คล่องก็รู้สึกว่าทำอะไรได้ง่าย ถึงแม้ว่าจะมีของอร่อยกว่ามา แต่ของที่เคยกินที่บ้านเกิดก็อร่อยกว่าอยู่ดี
5. ไม่สวยงาม ไม่ใช่ว่าของที่ทำออกมาเร็วๆ แล้วจะไม่สวยแต่ ของที่เป็น fast food เค้าไม่สนใจความสวยงามเพราะไม่ใช่สิ่งที่เอาไปขายให้กับกลุ่มเป้าหมายของเค้า
6. ไม่ดีสำหรับคุณ แน่นอนว่าโปรแกรมแบบ fast food มันกินได้ แต่ดีหรือเปล่าคงต้องคิดให้หนักนะครับ

ประสบการณ์ที่ได้จาก Fine Dining

1. ใช้คนที่เป็นกุ๊กจริงๆ เค้าไม่ได้คิดแค่ให้เรากินเข้าไป แต่สิ่งที่คิดจะมากกว่านั้นทั้งรสชาติ และความรู้สึกอื่นๆ ในการบริโภค ลองนึกถึงโปรแกรมที่เราเขียนครั้งแรก กับตอนที่เราเขียนโปรแกรมนั้นอีกครั้ง หรือลองนึกถึงตอนอ่าน error ที่เขียนลวกๆ กับ error ที่เขียนดีๆ จะต่างกันมาก
2. วัตถุดิบ สด ผ่านการคัดสรรค์ ของดีวัตถุดิบต้องดีด้วย โปรแกรมที่มาเป็นองค์ประกอบของโปรแกรมหลักก็ต้องดีด้วย library ต่างๆ ที่นำมาประกอบกันก็ต้องผ่านการคัดมาอย่างดี ไม่ใช่แค่ทำงานได้ แต่ต้องทำงานได้อย่างดี
3. ได้สารอาหาร เวลาที่เราพัฒนาโปรแกรมนอกจากโปรแกรมจะช่วยตอบคำถามหลักของผู้ใช้แล้ว ยังต้องตอบคำถามอื่นๆ ที่ผู้ใช้ต้องการด้วย เช่นเราทำโปรแกรมเขียน CD สิ่งที่ต้องมีเพิ่มเติมเช่นสามารถตรวจดูได้ว่า CD ทำงานอยู่หรือเปล่า
4. ถูกปาก ดูโปรแกรมแล้วเข้าใจ work flow ของโปรแกรมกับ workflow ของการทำงานไม่ต่างกัน
5. สวยงามดึงดูดใจ แน่นอนว่าอาหาร fast food ความใสใจในความสวยงามต่างจากอาหาร fine dinning แน่ๆ
6. ดีต่อสุขภาพ อย่างน้อยถ้าโปรแกรมไม่งี่เง่า คนใช้ก็ไม่หงุดหงิด

การออกแบบโปรแกรม ก็ไม่ต่างจากการทำอาหารขึ้นอยู่กับว่าเราต้องการเขียนโปรแกรมแบบ fast food หรือโปรแกรม Fine Dining ทั้งสองแบบก็มี business model ที่ไม่เหมือนกัน แต่ถ้าเราต้องการสร้างโปรแกรมที่ดี ให้กับกลุ่มเป้าหมายของเรา สิ่งที่เราต้องการคือการออกแบบ

john แบ่งสิ่งที่ต้องคิดตอนที่ออกแบบโปรแกรมเป็น 5 อย่าง

1. การวางแผน ที่ต้องเข้าใจ ผู้ใช้, เข้าใจสิ่งที่โปรแกรมต้องทำ, เข้าใจตลาด, เรียงลำดับความสำคัญของตลาด
2. การเห็นหน้ากันครั้งแรก สำคัญมาก การเห็นโปรแกรมครั้งแรกก็เป็นส่วนสำคัญ เราต้องดูกันตั้งแต่ packaging, การ setup โปรแกรม, การ configulation สิ่งเหล่านี้ควรจะถูกคิดไว้ตั้งแต่แรก
3. พื้นฐานของระบบ รวมถึงผู้ใช้ สิ่งที่ผู้ใช้คุ้นเคยอยู่แล้ว การออกแบบที่รองรับผู้ใช้ที่ไม่สมบูรณ์ (ส่วนมากใน apple จะเตรียมไว้ให้แล้ว เราแค่ใส่ข้อมูลให้ เช่นระบบ text to speech) การทำให้รองรับได้หลายภาษา เป็นต้น
4. ออกแบบให้เข้ากับ OS X ส่วนใหญ่อยู่ใน HIG แล้วเช่น การออกแบบ icon
5. ประสิทธิภาพ Apple มีเครื่องมือหลายตัวเพื่อช่วยให้เราดึงศักยภาพของระบบออกมาอย่างเต็มที่ เราก็ควรที่จะใช้มัน

สำหรับรายละเอียดในแต่ละตัว ผมจะค่อยๆ เล่าผ่านทางนี้ไปเรื่อยๆ นะครับ

ผมจะมีเว้นวรรคมากหน่อย เพราะน่าจะมีหลายคนที่อ่านด้วย browser ที่ไม่ตัดคำภาษาไทย ถ้าเห็นว่าอันไหนไม่เหมาะสมก็แก้ไขกันได้เลยนะครับ

ตอนที่ 2 วางแผนก่อนการพัฒนา

สิ่งแรกที่ต้องเริ่มสำหรับการออกแบบคือการ plaining โดยเน้นว่าจะสร้างไปทำไม และจะสร้างไปเพื่อใคร

เราต้องบอกได้ว่ากลุ่มผู้ใช้มีพื้นฐานอย่างไร มีประสบการณ์อย่างไร เคยใช้งานคอมพิวเตอร์หรือเปล่า มีความรู้ความเชียวชาญในสายงานใด มากน้อยแค่ไหน ยกตัวอย่างเช่น โปรแกรม iphoto ออกแบบมาสำหรับคนทั่วไป ไม่ได้มุ่งเน้นไปที่กลุ่มผู้เชียวชาญ (pro) ดังนั้นคำศัพท์ที่ใช้ ขนาดของ icon รูปร่างและสีสัน จะไม่เหมือนกับ aperture ที่ออกแบบสำหรับ pro

Aperture

iPhoto

จะเห็นว่าหน้าจอปกติของ iphoto ไม่ได้เป็นสีดำโดยพื้นฐาน และไม่มี menu ที่ใช้งานได้เอนกประสงค์แต่เน้นว่าทำความเข้าใจได้ง่ายๆ

ถ้ามาดูว่าสิ่งที่ต้องคำนึงในการวางแผนมีอะไรบ้าง ก็คงเรียงออกมาตามนี้

1. เข้าใจผู้ใช้ของเรา
2. เข้าใจโปรแกรมของเรา
3. เข้าใจความต้องการของตลาด (market’s need)
4. เข้าใจลำดับความสำคัญของตลาด (market’s priority)
5. Final steps

เข้าใจผู้ใช้ของเรา

เข้าใจคนที่จะใช้ว่าอะไรที่เค้าให้ความสำคัญ

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

ไม่มีประสบการณ์

• BECOME กำลังจะเป็นผู้ชำนาญเฉพาะทาง
• GRADUATE ทำงานที่ซับซ้อนได้มากขึ้น

มีประสบการณ์มาก่อน

• MASTER เป็นผู้เชียวชาญ
• NOVICE เป็นผู้เชียวชาญสาขาอื่น
• FRUSTRATED เคยใช้โปรแกรมแล้วไม่ได้ดั่งใจ

เข้าใจโปรแกรมของเรา

เข้าใจว่าโปรแกรมของเราเอาไว้แก้ปัญหาอะไรเป็นสำคัญ โดยให้วิเคระห์สิ่งที่เราช่วยผู้ใช้ เอาสิ่งที่เป็น value-add และเป็นจุดเข็งของโปรแกรมของเรา (core strength) ออกมาชัดๆ จากนั้นก็ออกแบบให้เหมาะกับการใช้งาน โดยคำนึงถึงการใช้งาน (Design for usability)

• workflow ว่ากระบวนการคิดของผู้ใช้เป็นอย่างไร โปรแกรมก็ควรจะช่วยลดเวลา หรือเพิ่มประสิทธิภาพแต่ไม่ใช่พยายามไปเปลี่ยน flow

• การเชื่อมต่อกับโปรแกรมอื่นๆ (ผ่าน file, ผ่าน framework) เพราะไม่มีโปรแกรมรองรับความต้องการได้ทุกรูปแบบ แต่โปรแกรมจะสามารถรองรับได้มากขึ้นถ้าสามารถคุยกับโปรแกรมอื่นได้ เช่นการเปิด web services ของ google map หรือ การที่เรา เรียกใช้ totem ผ่านทาง command line ได้ หรือการที่โปรแกรมมากมายบน apple พยายามให้สร้าง function ให้โปรแกรมอื่นๆ เรียกผ่าน automator หรือ apple script เป็นต้น

ให้นำเสนอ solution แทนที่จะเป็น feature

• บอกให้ชัดเจนว่าโปรแกรมทำออกมาเพื่อแก้ปัญหาอะไร แล้วนำเสนอ solution ในการแก้ปัญหา
• ระลึกว่าไม่ควรทำให้ผู้ใช้สับสนเพราะฟังก์ชันที่ไม่สำคัญ (ถ้าใส่แล้วสับสนก็ตัดทิ้งเลยดีกว่า) ดูตัวอย่างชัดๆ จาก MS Power point ที่มี icon มากมายจนเราหาปุ่ม start presentation ไม่เจอ
• ผู้ใช้ไม่สามารถแยกออกว่า feature ไหนสำคัญกว่ากัน อย่าไปถามเค้าเพราะทุกอย่างดูจะสำคัญหมด ดังนั้นตอนที่เราเก็บ requirement ต้องถามหาปัญหาและนำเสนอ solution เมื่อเรามี solution เราก็รู้ได้ว่า feature ใดสำคัญและอะไรตัดทิ้งได้
• Simplify then simplify again — less is more

พึงระลึกว่า โปรแกรมที่ดีจะทำให้เราไม่รู้สึกว่ากำลังต้องใช้โปรแกรมอยู่

เข้าใจความต้องการของตลาด (market’s need)

เข้าใจความต้องการของตลาด (market’s need) รู้ว่าผู้ใช้ต้องการใช้โปรแกรมของเราไปทำแก้ปัญหาอะไร และอะไรเป็นปัญหาที่เราต้องการจะแก้ให้เค้า ถ้าโปรแกรมของเราทำออกมาสำหรับตกแต่งภาพทางการแพทย์ ก็ต้องเข้าใจว่าปัจจุบันผู้ใช้มีปัญหาอะไรที่ photoshop, gimp, acdsee แก้ให้เค้าไม่ได้

เข้าใจลำดับความสำคัญของตลาด (market’s priority)

เข้าใจลำดับความสำคัญของตลาด (market’s priority) การพยายามเขียนโปรแกรมที่สามารถแก้ได้ทุกปัญหาจะทำให้โปรแกรมซับซ้อน หรืออาจใช้งานไม่ได้เลย ถ้าอยากให้โปรแกรมขายออกก็ให้แก้ปัญหาใหญ่ที่สุดที่คนส่วนมากเจอก่อน

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

Final steps

ก่อนเริ่มพัฒนาให้พิจารณาแล้วสำรวจตัวเองเป็นข้อๆ

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

ตอนที่ 3 First impression สำคัญมากๆ

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

ตอนนี้เราจะพูดเรื่องการออกแบบประสบการณ์ครั้งแรกให้ประทับใจคนใช้ ที่ใช้คำว่าออกแบบประสบการณ์เพราะเราเป็นคนดำเนินเรื่องครับ ต้องรับบทผู้กำกับที่ทำให้ผู้ใช้ประทับใจให้ได้

ความสวยงาม เป็นเรื่องหนึ่งที่สร้างความประทับใจได้มาก พยายามให้เค้ารู้สึกว่าโปรแกรมของเราสวย ตรงนี้จะเริ่มทำให้เค้ามีความพยายามที่จะสนใจโปรแกรมของเรา จากนั้นก็ต่อด้วยความ ง่าย สามารถเริ่มต้นกับโปรแกรมของเราได้ทันที ผมเคยติดตั้ง driver สำหรับ scaner ตัวนึ่ง (บน windows) หลังจากการติดตั้งที่ยาวนาน ผมเจอโปรแกรมประมาณ 5 ตัว อยู่บน desktop ของเครื่อง สิ่งนี้ไม่ได้สร้างความประทับใจให้ผมเลย แต่กลับสร้างความสับสนให้อย่างมาก ผมไม่รู้ว่าจะใช้โปรแกรมไหนสำหรับการ scan รูปและผมก็ไม่ได้ขอให้ติดตั้งโปรแกรมเหล่านี้ลงไป สิ่งที่ผมต้องการจากการติดตั้ง driver คือโปรแกรมง่ายๆ ที่ติดตั้งไปแล้วทำให้เครื่อง scaner ใช้งานได้ ไม่จำเป็นต้องสร้างความสับสนให้ผู้ใช้

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

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

สิ่งที่ควรคำนึงถึงในการสร้างความประทับใจแรก

1. หึบห่อ (Packaging)
2. การส่งโปรแกรมให้ผู้ใช้ (Distribution)
3. การติดตั้ง (Installation)
4. ปรับแต่ง (Setup & Configuration)

เรามาดูรายละเอียดในแต่ละตัว

หึบห่อ (Packaging)

เริ่มกันตั้งแต่กล่องเลยครับ

• พยายามทำให้กล่องดูมีเสน่ห์ดึงดูง (Attractive!) และเข้าใจง่าย
• ทำให้เปิดง่ายๆ กล่องเกมส์ DOOM เปิดยากมากๆ (เป็นเหล็กทั้งกล่อง)
• บอกความต้องการของระบบอย่างชัดเจน system requirement
• ให้แน่ใจว่าผู้ใช้มีทุกอย่างที่ต้องการสำหรับใช้งานโปรแกรม (ถ้าโปรแกรมต้องการใช้ quicktime เวอร์ชันใหม่ก็ควรแนบไปให้เค้าด้วย)
• ศึกษาการติด logo และสิ่งที่เป็นมาตรฐานของ platform นั้นๆ เช่นในกรณีที่เราขายโปรแกรมกับเครื่อง Apple ก็ควรอ่าน product development ในนี้จะมีหลักในการติด logo และเครื่องหมายการค้าต่างๆ ให้ รวมทั้งเงื่อนไขในการติดสัญลักษณ์ต่างๆ เพื่อให้ผู้ใช้เข้าใจใน product ของเราง่ายที่สุดจนถึงไม่รู้สึกว่าต้องทำความเข้าใจ

ของ windows หาไม่เจอ ใครรู้ช่วยเพิ่มเติมเลยนะครับ

การส่งโปรแกรมให้ผู้ใช้ (Distribution)

• ถ้าเป็นโปรแกรมบน mac ก็ควรใช้ Disk images (.dmg) เพราะเป็นรูปแบบที่ผู้ใช้ mac คุ้นเคย ถ้าเป็นบน windows ก็ควรเป็น setup.exe ให้ผู้ใช้ double click
• ควรย่อขนาดไฟล์ให้เรียบร้อยภายใน Disk images หรือ setup.exe ไม่ควรให้ผู้ใช้มาขยายเองอีกที
• อย่าให้มีขั้นตอนมากมายสำหรับผู้ใช้ เช่น ต้อง unzip .hqx ก่อน จากนั้นก็ .sea ก่อนจะได้ .dmg เพื่อเอาไฟล์ .pkg แล้วตอนลงก็ต้องผ่าน authentication แล้วไปหน้า registration … (อยากบอกว่ามีคนที่ทำแบบนี้จริงๆ นะครับ)

การติดตั้ง (Installation)

• ทำให้ simple และ ง่าย
• ใช้วิธี drag & drop เพื่อการ install หรือให้เป็นแค่ double click ทีเดียว
• ถ้าจำเป็นต้อง setup ก็ให้ใช้ระบบ setup แบบเดียวกับที่ผู้ใช้คุ้นเคย (ลองดูโปรแกรม PackageMaker หรือ setup
• ให้ผู้ใช้กำหนดตำแหน่งที่จะติดตั้งได้
• ให้ใส่ใจกับการเปิดโปรแกรมครั้งแรก ทั้งในเรื่องการติดตั้ง และการปรับแต่งระบบ อย่าให้ผู้ใช้จากเราไปตั้งแต่ยังไม่ได้ลองโปรแกรมเรา

ยังไงก็ต้องให้เค้าได้ลองใช้โปรแกรมของเราให้ได้ก่อน หลังจากนั้นกระบวนการ register หรือการจ่ายเงินค่อยตามๆ กันมา

การปรับแต่ง (Setup and Configuration)

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

สุดท้ายหัวใจของ first impression คือทำอย่างไรก็ได้ให้ผู้ใช้เริ่มใช้งานโปรแกรมของเราให้เร็วที่สุด โดยมีปัญหาน้อยที่สุด

ตอนที่ 4 เข้าเมืองตาหลิ่วต้องหลิ่วตาตาม

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

โปรแกรม Adobe Photoshop แสดงแบบหน้าต่างเดียวบน windows แต่เมื่อทำงานบน mac ที่ผู้ใช้คุ้นเคยแบบหน้าหน้าต่าง

โปรแกรม Adobe Photoshop ก็จะแสดงเป็นแบบหลายหน้าต่าง

เพราะในสภาพแวดล้อมที่ผู้ใช้คุ้นเคย ผู้ใช้จะนำประสบการณ์ของเค้ามาตีความโปรแกรมของเรา และพยายามทำในสิ่งที่คุ้นเคยเสมอ ยกตัวอย่างโปรแกรม Adobe Photoshop บนระบบ Windows ผมจะคุยคุยที่จะย่อขนาดจอทีเดียวแล้วทุกอย่างหายไปหมด ถ้าโปรแกรมแสดงเป็นหน้าต่างๆ และไม่สามารถปิดได้ในทีเดียว ผมจะรู้สึกไม่ดีแน่ๆ ตรงข้ามกันถ้าทำงานบน OS X พฤติกรรมปกติคือผมจะเปิดโปรแกรม Finder ไว้อีกตัวเพื่อใช้ดึงรูปที่ต้องการมาเปิดใน Photoshop และคงรู้สึกไม่ดีถ้ามีฉากมาบังไว้

เข้าเมืองตาหลิวก็ต้องหลิ่วตาตามครับ มันจะดีหรือไม่ดีอย่างน้อยคนรอบข้างก็เข้าใจเราได้ง่ายขึ้น หลังจากนั้นถ้าผู้ใช้เห็นว่าแบบไหนง่ายกว่า ก็ให้แก้ property เอา

ในแต่ละ platform ก็มีสิ่งที่ต้องคิดไม่เหมือนกัน การได้ลองเปรียบเทียบหลายๆ แบบน่าจะทำให้เราเข้าใจใน platform ที่เราจะสร้างมากขึ้น

menu bar

ผู้ใช้ mac คุ้นเคยกับการที่ menu ของโปรแกรมอยู่ด้านบนของจอภาพ

ผู้ใช้ windows คุ้นเคยกับการที่ menu อยู่ติดกับโปรแกรม ใต้ title bar

ใช้วิธีแสดงหลายๆหน้าต่างซ้อนๆ กัน

เหมือนในตัวอย่าง Adobe Photoshop ถ้าเป็น mac จะเน้นให้ทุกอย่างเป็นหน้าต่างย่อยๆ ถ้ากดย่อก็จะย่อเฉพาะหน้าต่างนั้นๆ และขณะที่โปรแกรมไม่ Active จะแสดงเฉพาะหน้าต่างหลักเท่านั้นพวก tools bar จะหายไป ในส่วนของ windows จะให้หนึ่งโปรแกรมเป็นหนึ่งหน้าต่างถ้าย่อก็จะย่อหมด

การใช้ Dock หรือ Title bar

ผู้ใช้บน mac จะสังเกตุ message ที่เกิดขึ้นบน dock เช่นการกระโดษ หรือการที่มีตัวเลขบน icon โปรแกรมที่ดีจะสื่อสารกับผู้ใช้ผ่านทาง Dock หรือ Title bar ในแบบที่ผู้ใช้บน platform นั้นคุ้นเคย

ระบบ mac ออกแบบให้ไม่ต้องปิดระบบ (shutdown) ในขณะที่ Windows ออกแบบให้ปิดทุกครั้งที่เลิกใช้งาน

ดังนั้นถ้าคุณพัฒนาโปรแกรมบน mac

• อย่าให้ผู้ใช้ต้อง rebooting เพื่อล้างหน่วยความจำ หรือไฟล์สำรอง ทั้งตอนใช้งานและตอนติดตั้งโปรแกรม
• อย่าแม้แต่ให้ผู้ใช้ต้อง login ใหม่

ถ้าคุณพัฒนาโปรแกรมบน windows ก็พยายามอย่าให้ผู้ใช้ต้อง reboot แต่ถ้าจำเป็นผู้ใช้ก็ให้อภัยได้เพราะทำอยู่เป็นประจำ

ระบบสามารถเปลี่ยนแปลง/เชื่อมต่อได้อยู่ตลอดเวลา

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

อุปกรณ์สำคัญๆ ก็เช่น

• ส่วนแสดงผล เช่น ผู้ใช้สามารถเสียบ ถอดจอภาพที่สอง ได้ตลอด ถ้าเราต้องออกแบบโปรแกรม presentation เวลาที่ผู้ใช้เสียจอที่สองขณะที่ present โปรแกรมก็ควรตอบสนองทันที
• อุปกรณ์เสริม เช่น mouse join stick ถ้าเขียนเกมส์ที่ใช้ join stick บังคัยแล้วผู้ใช้ถอดหรือเสียบ join stick เข้ามาเกมส์ก็ควรตอบสองทันที
• ปรับแก้ network เช่น การเปลี่ยน network location ผู้ใช้สามารถเปลี่ยน network connection ได้ตอลดเวลาดังนั้นโปรแกรมควรจะตรวจสอบค่า configuration อยู่เสมอ

รองรับระบบผู้ใช้หลายคน

เดี๋ยวนี้ OS เป็นระบบผู้ใช้หลายคนกันหมดแล้ว แถมยังสามารถเปลี่ยนผู้ใช้ได้ on the fly อีกต่างหากดังนั้นเราจึงควร

• ใช้ session ID เพื่อแบ่งปันทรัพยากร
• อย่าให้สิทธิพิเศษกับผู้ใช้บางคนเพื่อจองทรัพยากร เช่น CD,DVD
• ใช้ CFPreferences เพื่อกำหนดตำแหน่งไฟล์ (ใช้บน Cocoa สำหรับบน Windows ไม่แน่ใจ)
• ให้ใช้ค่า Default เป็น user’s home directory โดยดูว่า OS นั้นๆ กำหนดตำแหน่งของ user อย่างไร

OSX = /Users/apirak

Windows = C:\Documennt&Setting\apirak

Linux = /Home/apirak

ใช้ Documents folder

ทำให้ความคุ้นเคยเดิมๆ ของผู้ใช้ยังคงทำได้

ให้โปรแกรมของเราสามารถทำได้เหมือนโปรแกรมอื่นๆ บน platform นั้นๆ เช่น Drag and Drop ผู้ใช้สามารถเปิด Address book แล้วลากชื่อผู้ใช้มาใส่ในโปรแกรมเราได้, ใช้ panel ที่ผู้ใช้คุ้นเคย เช่นตัวเลือก font หรือตัวเลือกสี ยกเว้นว่าโปรแกรมของเราสามารถทำได้ดีกว่า

เทคนิค.. พยายามใช้ของที่ platform นั้นๆ มีมาให้อยู่แล้วเพื่อประหยัดเวลาในการพัฒนาและทำให้ผู้ใช้คุ้นเคยกับโปรแกรมของเราได้ง่ายขึ้นด้วย

สิ่งที่เราควรออกแบบคือตัว core value ของโปรแกรม ไม่ต้องเสียเวลาออกแบบ color panel ใหม่ถ้ามันไม่ใช่ core value ของเรา

Accessibility and Spoken Interface

OS X และ Windows ต่างเตรียมระบบที่ทำให้โปรแกรมของเราสามารถรองรับผู้ใช้ได้ตามข้อจำกัดของเค้า โดยนักพัฒนาเพียงแค่ใส่ใจในรายละเอียดของโปรแกรม เช่นกำหนดชื่อให้กับรูปภาพและช่องกรอกข้อมูล เพื่อให้ OS อ่านตัวหนังสือดังกล่าวกับให้ผู้ใช้ที่มีปัญหาทางสายตา เป็นต้น ระบบที่มีมาให้ไม่ต้องการ การติดตั้งเพิ่มสามารถใช้งานได้เลย

นักพัฒนาโปรแกรมสามารถทำให้โปรแกรมรองรับได้หลายภาษาโดยอาศัย framework ที่มีอยู่แล้วใน International Technology ทำให้นักพัฒนาไม่ต้องเขียนโปรแกรมเพื่อวาดตัวอักษรเอง สามารถใช้งาน Unicode ได้ทันที และสามารถใช้กับหลายๆภาษาได้โดยไม่ต้องแก้โคต

นักพัฒนาควรใช้พลังของ Spotlight ให้เต็มที่โดยการใส่ Metadata ให้กับเอกสาร หรือสร้าง plugin ให้ Spotlight เพื่อให้มันสามารถค้นหาเอกสารของโปรแกรมให้กับผู้ใช้ได้ ซึ่งทาง Apple ได้จัดเตรียมเครื่องมือในการทำให้แล้ว (ใน Vista ไม่รู้ว่ามี feature นี้มาด้วยหรือเปล่า ถ้าทำให้ compatible กับ google desktop แทนละกัน)

ตอนที่ 5 หลักการออกแบบโปรแกรม

เราใช้ตัวอย่างการออกแบบจาก OS X นะครับ สำหรับ Gnome, KDE, Vista, XP etx. ไว้ค่อยๆ เขียน

การออกแบบ GUI ของเค้ามีแนวคิดในการออกแบบที่เหลือเชื่อมากครับ เก็บรายละเอียดตามทฤษฏีได้ครบมากๆ ตอนที่ไป WWDC เค้าบอกว่า John Geleynse นี่เหมือนพ่อมดเลย สามารถเสกโปรแกรมที่ดูใช้งานยากๆ ให้กลายเป็นโปรแกรมชั้นดีได้เลย ในบทนี้เราจะมาดูกันละส่วนๆ เลยครับ

การออกแบบบน Aqua มีหลักอยู่ 5 อย่าง

• ศึกษา design principle กันก่อนที่จะเริ่มออกแบบ
• จัดระเบียบให้ application ของเราไปในแนวเดียวกับ application อื่นๆ
• เตรียมรับ feedback และสร้าง community ของโปรแกรม เพราะ Help ของเราตอบได้ไม่ครบทุกอย่าง และสำหรับคนออกแบบโปรแกรม feedback ก็เหมือนขุมทรัพย์ทีเดียว
• ใช้ระบบ panel ของ OS X เพราะผู้ใช้คุ้นเคยและเราไม่เสียเวลาเขียน
• ออกแบบฟอร์มให้เป็นมาตรฐาน แล้วผู้ใช้จะเข้าใจโปรแกรมของเรา

Ageless Design Principles

วันนี้ก็พูดถึงตอนแรกสุดครับ คือ design principle จริงๆ พวกนี้มีอยู่ในหนังสือเรียน Application Design อยู่แล้วผมก็คัดเอาที่สำคัญๆ มาบอกให้ฟังว่ามีอะไรที่เราต้องใส่ใจบ้าง

อย่างที่บอกตอนแรกว่า Apple เก็บรายละเอียดดีมากๆ ก็หมายถึงเค้าเก็บรายละเอียดตาม Design Principle ได้ดีมาๆจริง ถ้าเราต้องการให้ผู้ใช้เข้าใจโปรแกรมของเราง่ายๆ ก็ห้ามลืมพื้นฐานเหล่านี้เด็จขาด

Metaphors

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

ใช้สื่อว่าเป็นที่ทิ้งขยะ สามารถนำไฟล์ต่างๆมาใส่ในนี้ และรูปถังขยะเต็มแทนความหมายอีกนัยว่าถ้าเราเผลอทิ้งอะไรลงไปมันจะยังอยู่ในถังขยะ ซึ่งคล้ายๆกับ Recycle bin ของ Windows

บน Windows ไม่ได้ใช้คำที่หมายถึงที่ทิ่งขยะ แต่ให้ความหมายว่าที่กู้ข้อมูลแทน น่าจะเพราะใน windows รุ่นแรกๆ ไม่ได้มี concept ของถังขยะดังนั้นคนจึงไม่ได้ใช้ Recycle bin ในการลบ แต่ใช้ในการกู้ข้อมูลมากกว่า หรือไม่ช่วงแรกอาจจะใช้ชื่อว่า bin แต่กลัวซ้ำกับคำว่า binary ก็เลยใส่ Recycle เข้าไป :D (ส่วนตัวผมว่าตั้งชื่อ garbage น่าจะง่าย)

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

See and Point

ระบบที่ใช้ Mouse จะอยู่บนพื้นฐานสองอย่าง โดยมีสมติฐานว่าผู้ใช้ต้องเห็นทุกสิ่งที่ตัวเองทำบนจอตลอดเวลาและสามารถใช้ mouse ชี้ได้ทุกอย่างที่เห็น (ไม่ใช่ว่าบางบริเวณเลื่อน mouse เข้าไปไม่ได้)

พื้นฐานแรกคือ การเรียงลำดับการสั่งงาน ผู้ใช้เลือกจะเป็นประธาน (the noun) ก่อนจากนั้นจึงเลือกกริยา (the verb) ให้กับประธาน เช่น ในโปรแกรม iTune ผู้ใช้จะต้องเลือกเพลงก่อน จากนั้นจึงกดปุ่มเล่นเพลง ไม่ใช่กดปุ่มเล่นเพลง แล้วค่อยเลือกเพลง เป็นต้น เมื่อผู้ใช้เลือกสิ่งที่ต้องการ ฟังก์ชั้นที่สามารถใช้งานได้ก็จะเปิด (enable) และที่ไม่ใช่ก็จะปิด (disable) ผู้ใช้แค่ดูไปรอบๆ ว่าทำอะไรกับสิ่งนี้ได้บ้าง และเลือกเฉพาะฟังก์ชันที่เปิดอยู่ แทนที่จะต้องจำว่าใช้อะไรได้บ้าง

อย่างที่สองคือ การเลือกประธาน และกริยา สามารถทำได้ในขั้นตอนเดียว เช่น การการลากเอกสารไปใส่ใน folder เป็นต้น ในกรณีนี้ผู้ใช้ไม่ได้เลือก copy paste จาก menu แต่ใช้วิธีสั่งงานโดยตรงซึ่งตรงไปตรงมากว่า แต่ในกรณีนี้ผู้ใช้ต้องจำได้ว่าสิ่งที่กำลังลากไปจะทำอะไรกับสิ่งที่รออยู่ เช่นเมื่อลากไฟล์ไปใส่ถังขยะหมายถึงลบไฟล์ หรือเมื่อลากรูปภาพไปใส่ printer มันจะ print ให้ หรือลาก ไฟล์ไปใส่ใน Terminal มันจะแปลงเป็น part ของไฟล์นั้นๆ เป็นต้น

Direct manipulation

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

พยายามเขียนโปรแกรมให้รองรับการทำ Direct manipulate เช่นถ้าเราพัฒนาโปรแกรม fax เมื่อผู้ใช้ลาก เอกสามาใส่ในโปรแกรมของเราบน dock (task bar) โปรแกรมก็ควรเริ่มกระบวนการส่ง fax แทนที่ผู้ใช้จะต้องเปิดโปรแกรมแล้วกดปุ่ม Fax

User control

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

ตัวอย่างเช่นโปรแกรม MS Excel

ออกแบบตัวเลือกสีเป็น computer control โดยบังคับให้เลือกสีเท่าที่มี น่าจะเป็นความพยายามของ excel ที่เลือกสีที่ควรเหมาะสมให้กับผู้ใช้ หรือช่วยให้ผู้ใช้เลือกสีให้เหมือนกันได้ง่ายๆ

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

ตัวอย่างโปรแกรมที่เป็น user control จะแนะนำผู้ใช้และเปิดให้ผู้ใช้เลือกสิ่งที่ต้องการ

อีกหนึ่งตัวอย่างที่เป็น user control และแนะนำผู้ใช้เมื่อทำผิดพลาดแต่ถ้าต้องการทำจริงๆ ก็สามารถทำได้ด้วย

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

Feedback and communication

การให้ Feedback และ communication เป็นอะไรที่มากกว่าการส่ง error message ให้กับผู้ใช้ จริงๆแล้วมันคือการที่ให้ผู้ใช้ได้รับรู้ถึงสิ่งเกิดขึ้นและเริ่มที่จะสื่อสารกับโปรแกรมของเรา

เมื่อผู้ใช้เริ่มต้นทำอะไรซักอย่าง โปรแกรมจะต้องสื่อสารว่าได้รับรู้การกระทำนั้นๆ แล้วและแสดงให้เห็นว่ากำลังดำเนินการอยู่ ผู้ใช้จะได้รู้ว่าสั่งแล้วโปรแกรมรับรู้หรือเปล่าหรือว่าต้องสั่งใหม่ การใช้ภาพแสดงการทำงานของโปรแกรมเป็นวิธีที่ดี ที่จะทำให้ผู้ใช้รู้ว่าโปรแกรมรับรู้การสั่งการแล้ว และกำลังดำเนินการอยู่ (โปรแกรมส่วนมากจะเงียบและบอกผู้ใช้อีกทีเหมือนทำเสร็จแล้ว โดยเฉพาะ web application) ตัวอย่างที่ดีอย่างหนึ่งคือตอนที่ double click บน application แล้ว icon กระโดดขึ้นลงแสดงให้เห็นว่ากำลังเปิด application นี้อยู่

ผู้ใช้ส่วนใหญ่ไม่ชอบรอถ้าไม่เห็น feedback จากโปรแกรม จะเริ่มบ่นและอาจจะปิดโปรแกรมไปเลยก็ได้ อย่างน้อยถ้ามี animation ว่ากำลังทำงานอยู่ น่าจะดีกว่า

Consistency

WYSIWYG

Forgiveness

Perceived stability

Aesthetic integrity

Modelessness

Reflect the User’s Mental Model

Explicit and Implied Actions

Managing Complexity in Your Software

ช่วยๆ กันเติมเต็มได้นะครับ ผมคนเดียวคงนานเลย

ทุกข้อมีความสำคัญในตัวเอง ถ้าใครอยากจะศึกษาการออกแบบโปรแกรมบน Aqua ก็แนะนำให้อ่านที่นี่ครับ Human Interface Design Principles ในนี้มีหลักการคิดของแต่ละหัวข้ออยู่ครบเลย ถ้าสงสัยตรงไหนก็คุยกันได้ครับ คิดว่า อ.เดฟ สอนวิชานี้อยู่น่าจะช่วยให้คำตอบชัดๆ กับเราได้

ตอนที่ 6 จัดระบบให้เป็นระเบียบ

โปรแกรมที่จะพยายามตอบสนองผู้ใช้ส่วนใหญ่ให้ได้ก่อน การที่เราพยายามออกแบบให้รองรับกับความต้องการของทุกคน จะทำให้ผู้ใช้ส่วนใหญ่ลำบากไปด้วย ยกตัวอย่าง toolbar ของโปรแกรม MS Word เครื่องมือส่วนมากเป็นเครื่องมือที่ผู้ใช้ส่วนมากไม่ได้ใช้ แต่กลับมีอยู่บน tools bar เพราะต้องการให้โปรแกรมรองรับการทำงานของทุกคน

ผู้ใช้ส่วนใหญ่จะเคยชินกับการใช้งานโปรแกรมอื่นๆ อยู่แล้ว ไม่ได้เริ่มต้นจากศูนย์ การจัดระเบียบโปรแกรมให้ทุกไปในแนวเดียวกันกับโปรแกรมอื่นๆ เป็นสิ่งหนึ่งที่ทำให้ผู้ใช้ส่วนใหญ๋เข้าใจโปรแกรมของเราทันทีจากจิตใต้สำนึก สิ่งเล็กๆ น้อยๆ อย่าง ลำดับบน Menu, การจัดวาง layout ของหน้าต่างหลัก, Toolbars หรือ Utility windows เป็นสื่งที่ผู้ใช้ไม่ได้คิด แต่ผู้ใช้รู้สึกได้

สิ่งที่ต้องคิดไว้ในใจเสมอตอนที่ออกแบบโปรแกรม (บน OSX)

• Affordances: ให้ใส่คำบอกใบ้ในการใช้งานส่วนต่างๆ ในโปรแกรม ไม่ว่าจะเป็นรูปใน icon การเคลื่อนที่ของมัน ลองนึกถึง genie effect ที่โปรแกรมของเราถูกสูบลงไปบน dock แทนที่จะหายไปอยู่บน dock เฉยๆ ทำให้คนมองตามแล้วรู้ว่าโปรแกรมของเค้าไปอยู่ที่ไหน และสามารถคาดหวังได้ว่าถ้ากดที่ dock แล้วโปรแกรมจะกลับมาเหมือนเดิม

• Simplicity: มีให้ใช้ตอนที่ต้องใช้มัน เช่นปุ่ม stop บน safari หรืออย่างโปรแกรม driver ทันทีที่ผมติดตั้งโปรแกรมก็หายไป และผมก็สามารถใช้งานอุปกรณ์ของผมได้เลย driver ไม่ควรทิ้งอะไรไว้บน Desktop ไม่ควรติดตั้งโปรแกรมที่เราไม่ต้องการ

• Familiarity: ความรู้สึก หรือแนวคิดของคนมีพื้่นฐานมาจากประสบการณ์ในอดีต ผู้ใช้เคยใช้โปรแกรมอย่างไรก็จะใช้อย่างนั้น พยายามใช้สิ่งที่ OS X มีใว้ให้แล้วเพราะผู้ใช้จะคาดหวังอย่างนั้นเช่นระบบ text to speech หรือการพิมพ์แล้วสั่งบันทึกเป็น pdf ได้ ผู้ใช้คาดหวังจะได้รับสิ่งเหล่านี้จากโปรแกรมของเรา

• Availability: ให้สิ่งที่ผู้ใช้ต้องการจะใช้อยู่บนหน้าจอ หรืออยู่บน toolbar ซึ่งง่ายแก่การใช้งานมากกว่าที่จะอยู่ใน menu ที่ต้องจำถึงสองต่อ (File -> Save) แต่ต้องแน่ใจว่าเป็นสิ่งที่ผู้ใช้ต้องการใช้อยู่บ่อยๆ จริงๆ

• Feedback: ให้ผู้ใช้รู้ว่าตัวเองได้ทำไปแล้วไม่ใช่ทำแล้วนิ่งไปเลย เช่น progress bar, แสดงความเปลี่ยนแปลงที่เกิดขึ้น เป็นต้น เราจะสังเกตว่า OS X มีสิ่งเหล่านี้อยู่ตลอดเช่นตอนที่กดโปรแกรมบน dock ก็ไม่ใช่ว่าหน้าจอจะอยู่นิ่งๆ ไม่มีอะไรเกิดขึ้น แต่ icon บน dock จะกระโดดขึ้นลงตอบสนองต่อการกดของเรา หรือตอน double click บน icon แล้วรูป icon ขยายขึ้นจนหายไปก็เป็นการให้ Feedback กับผู้ใช้เช่นกัน

จะยกตัวอย่างให้ดูนะครับ

ตัวอย่างอันแรก อันแรกก็เป็น itune จุดประสงค์ของมัน (สิ่งที่ผู้ใช้ส่วนใหญ่ต้องการ) คือเป็นโปรแกรม music management ทำอย่างไรให้ผู้ใช้สามารถบริหารจัดการเพลงของตัวเองได้

เราแบ่งส่วนประกอบหลักๆ ของโปรแกรมได้เป็น

• ส่วนแรกคือ song ที่เป็นส่วนที่ใหญ่ที่สุดในโปรแกรม
• collection ที่ใช้ใส่ playlist
• playback ที่ใช้ควบคุมการเล่นเพลง ซึ่งออกแบบมาให้มีขนาดใหญ สามารถเข้าใจได้ทันที (ลองเทียบกับ winamp ดู)
• ส่วนของการค้นหา search

ผู้ใช้ส่วนใหญ่สามารถที่จะใช้งานโปรแกรมได้อย่างรวดเร็ว แทบจะไม่ต้องเรียนรู้อะไรเลย “Just get it” ในขณะที่คนที่มีความต้องการเฉพาะก็จะต้องเรียนรู้เพิ่มเช่น หน้าต่าง equalizer ไม่ได้ขึ้นมาในหน้าแรก เพราะผู้ใช้ส่วนใหญ่ไม่ได้ใช้ ถ้าต้องการก็ต้องเลือก menu bar กลับกันถ้าไม่ใช่โปรแกรม iTune แต่เป็นโปรแกรม pro logic ซึ่งที่คนส่วนใหญ่ต้องการกำหนดคุณภาพเสียงอย่างละเอียด ก็ควรมี equalizer ขึ้นมาบนหน้าจอเลย ไม่ต้องให้ผู้ใช้กลุ่มใหญ่ของโปรแกรมต้องศึกษา

ตัวอย่างอันที่สอง เป็นโปรแกรม Unison เป็นโปรแกรมที่ใช้ในการดึงข้อมูลจาก uninet แหล่งความรู้ขนาดใหญ่เลยละครับ

ทันทีที่เห็นโปรแกรมเราก็เข้าใจถึงการเก็บข้อมูลเป็นชั้นๆ ได้ทันทีโดยอาศัยว่าผู้ใช้คุ้นเคยกับการใช้ file & folder ใน Finder อยู่แล้ว (เมื่อดูความสัมพันธ์ของ menu ก็ทำให้เราเข้าใจโปรแกรมได้มากขึ้นและพอจะคาดได้ว่ากด group แล้วจะมีอะไรออกมา) เราจะสังเกตุว่า icon ที่อยู่ในแต่ละกลุ่มแสดงให้เราเห็นว่าจะมีอะไรอยู่ด้านในบ้าง เมือเรา double click ไปที่ icon นั้นๆ

โปรแกรมก็แสดงอย่างชัดเจนว่าคนดูสามารถดูอะไรได้บ้าง (Message, File, Image, Music) และแน่นอนเราจะเห็นถึงความสัมพันธ์กับ menu ด้านบน

ตัวอย่างต่อไปเป็นโปรแกรมบริหารจัดการ RAID ซึ่งใช้ในการดูว่า Harddisk แต่ละก้อนของเราถูกเชื่อมกันอย่างไร และช่วยกันทำงานอย่างไร

จะเห็นว่าโปรแกรมพยายามสื่อสารให้ผู้ใช้เข้าใจการทำงานของโปรแกรม RAID พอเรามองเราก็จะพอเดาได้ว่า Harddisk สามก้อนที่เชื่อมกันด้วยสีแดงมันทำงานร่วมกันโดยมีข้อมูลการทำงานของมันอยู่ที่ด้านขวามือ และแน่นอนเราจะสังเกตุเห็นว่า menu ด้านบนมีความสัมพันธ์กับตัว application ด้วย (ส่วนนี้หลายๆ คนอาจจะไม่สังเกตุแต่มันช่วยในการใช้งานจริงๆครับ)

ตัวอย่างต่อไปเป็นโปรแกรม Bike Route เราสามารถ load แผนที่ขี้นไปได้เองแล้วสร้าง route map ของตัวเองขึ้นมาถ้าในชอบขี่จักรยานที่นั้นโปรแกรมนี้คงโดนครับ

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

ตอนที่ 7 จัดระบบให้เป็นระเบียบ 2

ตอนที่ 6 เราพูดถึงการจัดลำดับของ menu จึงขอยกตัวอย่างอีกสักตัว

โปรแกรม Mac Journal ที่เคยได้รับรางวับ Apple Design award แต่ก็ยังมีความผิดพลาดเล็กๆ ในเรื่อง menu

โปรแกรมนี้เป็นโปรแกรมสำหรับเขียนบทความดังนั้นส่วนที่เป็น “Journal” จึงเป็นส่วนที่อยู่บนสุดของ Hierarchy (ความสัมพันธ์แบบแผนภูมิต้นไม้) แล้วมี “Entry” ต่างๆ เป็นเนื้อหาอยู่ด้านใน

Journal เป็น parent controler object และ มี Entry เป็น sub class ดังรูปด้านล่าง

จากตัวอย่างที่ผ่านๆ มาในตอนที่ 6 จะเห็นว่า menu ควรจัดวางตามลำดับชั้นของความสัมพันธ์ของ Object ในโปรแกรม แต่โปรแกรม Mac Journal กลับนำเอา Entry มาไว้ด้านหน้า Journal ก็ควรที่จะจัดการสลับที่กัน

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

เคยคิดเหมือนกันว่า windows user จะรู้สึกแบบนี้หรือเปล่า เพราะ menu บน windows ไม่ได้อยู่ที่เดิมตลอดเวลา และโปรแกรมส่วนมากก็เรียง menu กันตามใจชอบ ทำให้ผู้ใช้ไม่เกิดระบบการคิดแบบนี้ในหัว (mental model) แต่จริงๆ ไม่ใช่ครับ แทบทุกระบบปฏิบัติการจะมี File Edit … อยู่และนี่เป็นจุดเริ่มต้นของการเรียงลำดับ ถ้าโปรแกรมเน้นจัดการกับไฟล์ ก็จะเอาไฟล์ไว้ด้านหน้า แต่ถ้าไม่มี File ในกรณีของ MacJournal ก็ควรจะเป็น journal แทน เพราะเมื่อผมต้องการเปิดไฟล์ Journal อื่นๆ ผมควรจะกด Journal -> Open ไม่ใช่ Extry -> Open

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

ตัวอย่างต่อไปเป็นโปรแกรมบริหารจัดการ todo list

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

แต่!!!

ลองนึกดูดีดีว่าเราต้องการอะไรจากโปรแกรม todo list คืออะไร สิ่งที่เราต้องการน่าจะเป็นโปรแกรมเล็กๆ ทำงานเร็วๆ

“be there when i need and go away when i don’t need it”

ไม่ต้องมี feature มากมายเพราะ todo เป็นสิ่งที่เราต้องเรียกใช้บ่อยๆ และ ไม่ต้องการเปิดให้มันใหญ่มากๆ เพราะบางทีเราก็ต้องการเปิดมันทิ้งเอาไว้ (สุดท้ายกลายเป็น dashboard) ใครคันไม้คันมือจะหยิบ Photoshop หรือ OmniGraffle มาออกแบบโปรแกรม todo list แบบใหม่ แล้วส่งมาให้ดูกันบ้่างก็ได้นะครับ :)

ตอนที่ 8 สื่อสารกับผู้ใช้

ตอนที่ 8 สื่อสารกับผู้ใช้

ถ้าโปรแกรมที่ออกแบบมาไม่สอดคล้องกับความเข้าใจของผู้ใช้ ขอให้กลับไปดูว่าเรามัวกังวลเรื่อง feature หรือเปล่า สิ่งที่เราจะต้องใส่ลงไปในโปรแกรมคือ solution ไม่ใช่ feature เพราะสิ่งที่ผู้ใช้ 80% ต้องการคือสิ่งที่เป็นตัวหลักของโปรแกรม ไม่ใช่ feature ถ้าโปรแกรมของเราเต็มไปด้วย feature มันยิ่งจะทำให้ผู้ใช้สับสนว่าจริงๆ แล้วโปรแกรมของเราเข้ามาช่วยลูกค้าแก้ปัญหาอะไร เช่น โปรแกรมสำหรับ ftp ควรจะเป็นโปรแกรมที่ส่งไฟล์หรืออ่านไฟล์ที่ server ได้ง่ายที่สุด การที่เราใส่ text editor ลงไปในโปรแกรม ftp อาจจะเป็นเรื่องดีเพราะมีคนต้องการ แต่ถ้าโปรแกรมนั้นทำให้ขั้นตอนของการใช้งานยุ่งยากขึ้นหรือ ทำให้หน้าจอดูสับสน เราควรจะพิจารณาใหม่ เพราะผู้ใช้ 80% ไม่ได้ใช้ feature “text editor”

การสื่อสารกับผู้ใช้ มีสิ่งที่ต้องคำนึงถึงดังนี้

• Parallel with good human interactions ระหว่างที่ผู้ใช้กำลังใช้งานโปรแกรมของเรา โปรแกรมควรที่จะสื่อสารกับผู้ใช้อยู่ตลอดเวลา เช่นระหว่างการ search บนหน้าจอควรมี icon ที่เคลื่อนไหวเพื่อบอกกับผู้ใช้ว่า “ฉันกำลังพยายามอย่างเต็มที่เพื่อคนหาข้อมูลให้คุณ” อาจเป็น icon เล็กๆ หรือเป็น progress bar ก็ยังดีกว่าการนิ่งไปเฉยๆ เพราะนั่นคือการปลอยให้ผู้ใช้เดาเอาเองว่าโปรแกรมพังไปแล้ว หรือว่าผู้ใช้ยังไม่ได้สั่งงาน

• Be non-intrusive, non-interruptive เช่น error message ของ safari ก่อนหน้านี้ทุกครั้งที่มี error มันจะแสดงหน้าต่างขึ้นมาแจ้งปัญหา และมีปุ่ม OK ให้เรากดเพื่อรับทราบ มันขัดจังหวะการใช้งานมากๆ ครับ เมื่อผมทราบในสิ่งที่ผิด สิ่งที่ผมต้องการทำต่อคือการแก้ไขความผิดพลาด แต่โปรแกรมดันขึ้นมาขัดจังหวะโดยการให้ผมกด OK ก่อนทั้งๆ ที่การกด OK ของผม ไม่ได้มีผลอะไรกับโปรแกรมเลย ตอนนี้ดีแล้วครับที่เค้าปรับปรุงให้ไม่มีหน้าแต่งแจ้งความผิดพลาดขึ้นมา แต่จะแสดงความผิดพลาดลงไปบนหน้าจอ ให้เรารับทราบอย่างเดียว ลดขั้นตอนไปได้อีกหนึ่งขั้นตอน สำหรับนักออกแบบทุกคนอย่าคิดว่านี่เป็นแค่ขั้นตอนเดียวลูกค้าน่าจะรับได้ ลองนึกถึงว่าลูกค้าต้องใช้โปรแกรมนี้ทั้งวัน เข้าจะต้องกด OK กี่รอบ

• Only communicate status that matters ไม่ต้องแสดงสถานะไปซะทุกอย่างครับ เพราะอย่าลืมว่าทุกข้อความที่แสดงบนหน้าจอ ผู้ใช้จะต้องใช้สมองในการทำความเข้าใจ และถ้ามันมันหลายอย่าง สุดท้ายเค้าจะไม่พยายามทำความเข้าใจกับอะไรเลย ทำให้การสื่อสารกับผู้ใช้ล้มเหลว นอกจากนี้พยายามให้ข้อความแสดงสถานะอยู่ที่เดียวกันตลอดผู้ใช้จะได้ไม่ต้องหา

ในตอนนี้เราจะพูดถึงสองเรื่องสุดท้าย คือการสื่อสารผ่าน error message เราควรแสดง error ครับ แต่ไม่ใช่แบบนี้แน่นอน

หรือแบบนี้

การที่บอกผู้ใช้ว่า feedbag error 0 ไม่ได้ช่วยให้ชีวิตของผู้ใช้ดีขึ้นเลยครับ ไม่บอกน่าจะดีกว่า อย่างน้อยก็อ่านน้อยลง (และต้องตรวจสอบคำผิดด้วย อันนี้โดน… ใน blog ผมก็นั่งแก้คำผิดในกระทู้เก่าๆ อยู่เหมือนกัน)

ลองมาดูอีก error นึงครับ error อันนี้เกิดขึ้นตอนที่ drag รูปต้นฉบับจากด้านซ้ายมือมาใส่โปรแกรมด้านขวามือแล้ว แล้วโปรแกรมแจ้ง error ว่าไฟล์ของรูปใหญ่เกินไป

ผมแค่ต้องการเลือกรูปมาใส่ในโปรแกรม และผมไม่ต้องการ Extend ไม่ได้ต้องการ crop เพราะไม่รู้ว่าจะมีผลกับรูปต้นฉบับของผมหรือเปล่า แล้วก็ไม่รู้ว่าเมื่อกด Distort แล้วโปรแกรมจะทำอะไร ที่สำคัญคือผมเลือกได้แค่ 3 อย่าง!! ซวยเลยทีนี้ cancel ก็ไม่ได้ด้วย

error message ควรบอกปัญหาที่เกิดขึ้น และอย่าให้มีตัวเลือกที่น่าสงสัยเกิดขึ้น วิธีการรายงานปัญหาที่เกิดขึ้นให้มีประโยชน์สูงสุดควรบอกตามลำดับดังนี้

• เกิดอะไรขึ้น
• เกิดขึ้นเพราะอะไร
• จะแก้ปัญหาได้อย่างไร

หลีกเลี่ยงปุ่ม Yes/No เพราะผู้ใช้จะสับสนไม่รู้ว่าควรทำอะไร ให้เราดูว่า error ที่เราเขียนมี keyword อะไร แล้วใช้ keyword นั้นในปุ่มที่จะให้ผู้ใช้กด แบบนี้จะเข้าใจง่ายกว่าเพราะผู้ใช้พยายามหาทางแก้ปัญหาจากข้อความของเราอยู่แล้ว

ดู error อันตอนไปนะครับ

error อันนี้ดูเหมือนจะดีเพราะอ่านรู้เรื่อง แต่ไม่ได้บอกสาเหตุของปัญหา

อันนี้ปรับปรุงขึ้น โดยบอกปัญหาและสาเหตุ แต่ก็จังไม่ได้บอกทางแก้ให้กับผู้ใช้

อันนี้สมบูรณ์ครับ บอกสิ่งที่เกิดขึ้นอย่างชัดเจน บอกสาเหตุของปัญหาอย่างเฉพาะเจาะจง แถมบอกวิธีแก้ปัญหาให้ผู้ใช้อีกด้วย

The document “Trip Request” could not be saved บอกว่าเกิดอะไรขึ้น โดยระบุให้ชัดเจนว่าเกิดที่เอกสาร Trip Request

because the disk “Work Stuff” is full. เกิดขึ้นเพราะ disk เต็ม และรบุไปเลยว่า disk ที่ชื่อ Work Stuff เต็ม

Try deleting document from “Work Stuff” or saving the document on another disk ชี้ทางสว่างให้กับผู้ใช้ว่าควรแก้ปัญหาที่เกิดขึ้นอย่างไร

สิ่งเหล่านี้จะเพิ่มงานให้กับนักพัฒนาโปรแกรมแต่ขอบอกเลยครับ ว่ามันจะสร้างประสบการณ์ที่ดีให้กับผู้ใช้(ลูกค้า) ของโปรแกรมของเรา

สุดท้ายให้เราพยายามป้องกันก่อนที่ปัญหาจะเกิด

ตัวอย่างนี้บอกว่า “เราไม่สามารถ print ได้ถ้ายังไม่ได้เลือก student ซักคน” วิธีที่ดีกว่าการทำ error message คือการปิดไม่ให้ผู้ใช้ click ปุ่ม print ก็จะไม่มี error เกิดขึ้นครับ และผู้ใช้ไม่ต้องเสียเวลาอ่าน error ด้วย

เรื่อง feedback เป็นเรื่องสำคัญที่นักพัฒนาโปรแกรมควรจะให้ความสำคัญ ไม่เฉพาะเจาะจงว่าต้องเป็นบน OS X เท่านั้น เราควรให้ความสำคัญกับโปรแกรมของเราในทุก platform แม้แต่บน web ก็ตาม

ตอนที่ 9 การจัด layout

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

บน OS X มีการกำหนดนโยบายว่าแต่ละ form ควรออกแบบมาอย่างไร ใครที่พัฒนาบน platform อื่น สามารถนำไปประยุกต์ใช้ได้นะครับ

Center Equalize ไม่ได้หมายความว่าจะจัดทุกอย่างให้อยู่ตรงกลาง ถ้าเราพิจารณาจากรูปจะเห็นว่า layout ที่จัดขึ้นจะออกแบบให้สมดุลกันระหว่างด้านซ้ายและด้านขวาดังรูป

เมื่อเราใส่สีลงไปจะยิ่งทำให้ดูชัดมากขึ้น

ลองดูตัวอย่างต่อมา

แล้วลองระบายสีลงไป จะเห็นถึงความสมดุลย์

การจัด Labels ชื่อกลุ่ม โดยยึดเส้นด้านขวา

การจัด Control โดยยึดเส้นด้านซ้าย

จัดข้อความด้านหลัง Control ให้เท่ากัน

จัดขอบด้านข้าง และระยะห่างของ Control ทุกตัวให้เป็นระบบเดียวกัน ไม่อึดอัด

สุดท้ายเป็นส่วนของ Action Buttons จะต้องอยู่ด้านขวามือเท่านั้น ปุ่ม OK จะต้องอยู่ด้ายขวามือด้วย และจะต้องเขียนด้วยคำว่า OK ไม่ใช่ Okey หรือ Ok

หลัง Checkbox/Radio ควรตามด้วยคำกริยา เพื่อให้ง่ายแก่การทำความเข้าใจ และลดความผิดพลาดต่างๆ ที่อาจจะเกิดขึ้น

นอกจากนี้ยังมีอีกหลายส่วนที่ควรจะดูแต่คงไม่ได้รวมอยู่ในบทความนี้ อย่าง

• “Quality icons”:http://www.thaimacdev.com/?q=node/39 <- อันนี้เขียนไปแล้ว
• Quality graphics
• File Display Names
• Minimal toolbars
• File Name Extensions
• Reserved keyboard shortcuts

สามารถหาอ่านได้จาก Human interface guideline ของ apple ครับ

เป็นอันจบเรื่อง Designing for Aqua หากเราสามารถออกแบบได้ตามนี้อย่างน้อยโปรแกรมของเราก็จะเป็นโปรแกรมที่แตกต่างจากโปรแกรมของคู่แข่งแน่นอน

ตอนที่ 10 พลังนั้น สำคัญไฉน

เรื่องประสิทธิภาพการทำงาน (Performance) เป็นเรื่องที่ผู้ใช้ให้ความสำคัญโดยไม่รู้ตัวแต่รู้สึกได้ โดยเฉพาะผู้ใช้กลุ่ม Pro เพราะเป็นกลุ่มที่ต้องใช้โปรแกรมของเราซ้ำๆ ไม่ใช่นานๆ ที ดังนั้นสิ่งที่ผู้ใช้ต้องการคือการตอบสนองที่รวดเร็ว และ/หรือ การประมวลผลที่รวดเร็ว

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

Apple เตรียมเครื่องมือต่างๆ ให้เราใช้มากมาย เพื่อช่วยตรวจสอบว่าโปรแกรมของเราทำงานได้ดีหรือยัง มีส่วนไหนที่สามารถปรับแก้ได้อีก เราสามารถตรวจสอบการจอง memory ได้เลยว่าแต่ละ process ของโปรแกรมเราจองหน่วยความจำอย่างไร และมีขั้นตอนไหนที่มีการเรียกใช้บ่อยที่สุด เพื่อให้เรารู้ว่าส่วนไหนที่ควรปรับแต่งก่อน

สำหรับการพัฒนาบนภาษาอื่น ผมคิดว่าชุมชนนักพัฒนาสำหรับภาษานั้นๆ น่าจะมีเครื่องมีเหล่านี้อยู่แล้ว อยากให้ลองหามาใช้กันครับ เพื่อผู้ใช้ของเรา

เคล็ดลับการปรับแต่งประสิทธิภาพ

1. Be event driver: แทนที่จะให้โปรแกรมคอยตรวจสอบว่าสถานะของระบบเป็นอย่างไร ควรให้เป็นการทำงานเมื่อมี event เกิดขึ้นมากกว่า
2. Be lazy : ทำเท่าที่ควรทำครับ ไม่ควรอยากทำอะไรที่วุ่นวายและซับซ้อน เพราะมันมักจะเป็นสิ่งที่ไม่ดีและมักต้องกลับมาลื้อส่วนนั้นใหม่
   • Reduce your memory footprint
   • Improve perceived performance
3. Use the Mach-O binary format
4. Prebind
5. Thread
6. Use accelerated libraries
7. Use the Velocity Engine

ข้อที่เหลือคงทิ้งไว้แค่หัวข้อให้ลองไปศึกษาดูครับ แต่อยากให้คนที่จะพัฒนาโปรแกรมบนแต่ละ platform คิดถึงการปรับแต่งตัวโปรแกรมให้มาก โดยเฉพาะส่วนที่เป็นจุดเด่นของโปรแกรมเราจะต้องทำงานได้เร็วที่สุด และในจุดที่ไม่ใช่จุดเด้นของโปรแกรม ถ้าให้ดึงเอา lib ที่มีคนพัฒนาไว้แล้วมาใช้ได้จะดีกว่า

สิ่งเหล่านี้ (ทั้ง 10 ตอนที่ผ่านมา) คือส่วนประกอบสำคัญในการพัฒนาโปรแกรมของเราให้ดี คุณอาจจะคิดว่าโปรแกรมของเราตอนนี้มีส่วนแบ่งการตลาดน้อยมาก ไม่น่าจะต้องคิดอะไรให้วุ่นวายแต่อยากให้รู้ไว้เลยว่าทันทีที่โปรแกรมของเราตอบปัญหาให้ผู้ใช้คนหนึ่งได้ดี คนที่มีปัญหาแบบเดียวกันจะมี network ของเค้าอยู่แล้ว ซึ่งช่วยให้โปรแกรมของเรากระจายได้เร็วกว่าที่คุณคาดไว้

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

เอกสารอ้างอิง — Apple User Experience