วันเสาร์, พฤศจิกายน 29, 2551

BAD Application Design ตอน 4

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

   

สำหรับโปรแกรม Remote Desktop ผมมองว่าสิ่งที่สำคัญที่สุดคือการแสดงผลหน้าจอของเครื่องที่เรา remote ไปให้ครบถ้วนมากที่สุดเพราะเป็นสิ่งที่ผู้ใช้ต้องการทำมากที่สุดในโปรแกรม แต่ผู้พัฒนากลับแลกพื้นที่ทำงานกับ shortcut อย่าง URL, TAB และ Bookmark ซึ่งใช้น้อยมากเมื่อเทียบกับการทำงานทั้งหมด

   

การมี feature เพิ่มเป็นสิ่งที่ดี แต่ถ้ายังไม่สามารถแก้ปัญหาหลักๆ ได้หมดก็ไม่ควรรีบเปิดเป็นค่า default ทีนี้สมติว่าเราเป็นคนออกแบบ KRDC เราจะแก้ปัญหานี้อย่างไร

1. ตัดส่วนเกินออกให้เหลือเท่าที่จำเป็น ผมเลือกตัด URL, Tab และตัวบอกชื่อ panel ออก สวน Title bar และ Menu คงตัดไม่ได้เพราะจะผิด HIG ของ Windows manager

   

2. อย่ายอมแพ้... ต้องเอาส่วนที่ตัดออกไปกลับมาให้ได้ และต้องไม่เสียคุณสมบัติสำคัญของโปรแกรมด้วย

   

 ผมลองจัดแบบนี้ดู

1. ผมเอา Section name ไว้เหนือ favorite เหมือนเดิม แต่กด favorite กับ short cut ลงมา เพราะยังมีพื้นที่เหลือด้านล่างอีกเพียบ
2. ผมแก้ปัญหา url โดยให้มันขึ้นมาเฉพาะตอนเราสร้าง new connection หรือให้กด short cut เพื่อแสดง url
3. ส่วน tab ผมคิดว่ามันซ้ำซ้อนกับ favorite เลยตัดสินใจรวมมันเข้ากับ favorite ซะเลย favorite อันไหนที่ถูกเชื่อมต่อ connection แล้วจะย้ายมารวมอยู่ด้านบน ในลักษณะ tab แบบนี้ช่วยให้ favorite เหลือน้อยลงด้วย
4. ส่วน status bar เราคงแก้ปัญหาแบบเดียวกับ chrome ไม่ได้ เพราะมันจะไปทับ Start button ของ windows เลยจับมาไว้มุมซ้ายล่าง ให้มีเนื้อที่เหลือเฟือสำหรับแสดงสถานะอะไรก็ได้ แม้แต่ กราฟยังแสดงได้เลย

จบการออกแบบแค่นี้ ต่อจากนั้นก็ส่งให้ Programmer ดูว่า QT สามารถทำได้หรือเปล่า ถ้าเป็นไปได้ อยากตัด menu ทิ้งด้วยเพราะ short cut ด้านซ้ายมือน่าจะช่วยได้มากอยู่แล้ว

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

วันศุกร์, พฤศจิกายน 28, 2551

วิเคราะห์พื้นที่ใช้งาน Firefox Safari และ Chrome

ผมแบ่งพื้นที่ของ Browser ออกเป็นสองส่วนคือส่วนของ เครื่องมือ เช่น ปุ่ม back ช่องใส่ URL หรือช่อง Search เป็นต้น อีกส่วนหนึ่งคือส่วน เนื้อหา ที่อยู่ตรงกลาง อยากให้สังเกตว่าแต่ละ Browser ให้ความสำคัญกับความสมดุลของพื้นที่ทั้งสอองไม่เท่ากัน ก่อนหน้านี้พฤติกรรมการใช้ web ของเราจะเน้นการอ่านเอกสาร หรือค้นหาเอกสาร เป็นหลัก การแบ่งพื้นที่ให้กับเครื่องมือยังมีมากอยู่ จนถึงปัจจุบันการใช้งานเว็บจะเป็น Web Application มากขึ้น คนอยู่กับเว็บหน้าเดียวนานขึ้น เช่น หน้า yahoo mail หรือ google docs เป็นต้น ทำให้ความสำคัญของพื้นที่เครื่องมือจึงลดลง จนเป็นประเด็นให้เราต้องมาพูดถึงกัน ทีนี้ลองมาเปรียบเทียบการจัดสมดุลย์ของพื้นที่แต่ละ Browser กัน Firefox และ Safari เกิดมาโดยมีจุดประสงค์เดียวกันคือการท่องเว็บ ดังนั้นถ้าเทียบตามสัดส่วนนี้จะเห็นว่าพื้นที่ครึ่งหนึ่งจะเป็นของส่วนเครื่องมือ แต่เมื่อพฤติกรรมการใช้งาน Browser เปลี่ยนไปจากที่เราเคยใช้โปรแกรมซึ่งมีพื้นที่ให้เราใช้งานถึง 9 ส่วน ถ้าดูย้อนไปที่ Firefox และ Safari จะเห็นว่าพื้นที่ส่วนตารางเหลือแค่ครึ่งหน้าจอเท่านั้น ถ้า Google ต้องการแก้ปัญหานี้มีทางเดียวคือการสร้าง Chrome ขึ้นมา ส่วนตัวผมว่าที่สร้าง Chrome มีเหตุผลเรื่อง Usability เป็นหลักเลยล่ะครับ เทคโนโลยีอื่นๆ อย่าง V8 หรือ Gear คงไม่ใช่เหตุผลที่หนักเท่า ยิ่งตอนที่ขยายเต็มหน้าจอสัดส่วนของ browser จะขยายไปถึง 8 ส่วน เกือบเท่า Application เลยทีเดียว ถ้าลองสังเกต Firefox กับ Safari จะเห็นว่าพื้นที่ส่วน Title bar มีพื้นที่ว่างอย่างมาก และมีข้อความซ้ำกับข้อความใน tab ด้วย ตรงนี้คือจุดที่ Chrome เอามาใช้ลดเนื้อที่ไปได้ 1 ส่วน กับอีกจุดหนึ่งคือ Bookmark bar ที่ถูกเปลี่ยนเป็น Speed dial เหมือนของ Opera ซึ่งพอเริ่มชินจะลืม Bookmark bar ไปเลย บน firefox จะมี Add-ons ชื่อ Fast Dial หามาใช้ได้ครับ แต่หวังว่าคนพัฒนาจะหาทางเพิ่มความเร็วให้ Fast Dial หน่อยเพราะตอนนี้ผมเปิด tab ได้ช้าลง ทำให้การใช้ Fast Dial ไม่ได้ตามจุดประสงค์ ความเร็วเป็น key success ของ feature นี้เลยครับ สิ่งที่ผมชื่นชมคือ Chrome พยายามแก้ปัญหาโดยการหาทางออกใหม่ๆ ที่ตอบโจทย์มากขึ้น ไม่ใช่แค่ตัดหรือเพิ่ม feature เข้าใป

วันจันทร์, พฤศจิกายน 24, 2551

BAD Application Design ตอน 3

โปรแกรม Picasa Web Album Uploader ใช้สำหรับ upload ภาพจากเครื่องไปใส่เว็บ picasaweb.com ทีละหลายๆ รูป แทนที่จะต้องเลือกผ่าน web ทีละรูปๆ ผู้ใช้ลากไฟล์ที่ต้องการมาใส่ในช่อง "Drag Photos and Videos Here" จากนั้นใส่ชื่อ album พร้อมคำอธิบายที่ช่องด้านขวา หรือเลือก album ที่มีอยู่แล้วในอีก tab หนึ่ง เสร็จแล้วกด upload เป็นอันเรียบร้อย ที่นี้ลองคิดใหม่ทำใหม่ 1. ปัญหาที่ทำให้ต้องมีโปรแกรมนี้คืออะไร ปัญหาอันดับหนึ่ง การ upload บน web ต้องเลือกทีละไฟล์ ทำให้ช้า อันดับสองบางครั้งถ้า internet ไม่เร็ว หรือบางคนต้องการประหยัดพื้นที่บน web ทำให้ต้อง copy รูปออกมา เพื่อresize ทุกรูป หลังจากนั้นก็ลบรูปที่ upload แล้วทิ้งไป 2. สิ่งที่โปรแกรมจะเข้ามาแก้ปัญหา สามารถเลือกไฟล์ทีละหลายๆ ไฟล์ได้ และสามารถปรับขนาดของไฟล์ก่อนการ upload พร้อมจัดการไฟล์ที่ resize แล้วทิ้งไป 3. กลุ่มผู้ใช้คือใคร เป็นผู้ใช้แบบครั้งคราว (Home use) หากเป็นโปรแนะนำให้ใช้ plugin บน iphoto หรือ aperture แทน 4. สิ่งที่ต้องมีในโปรแกรมคืออะไร เรียงตามการใช้งานประจำวัน ไม่ใช่การใช้งานครั้งแรก
  • เลือกรูปสำหรับ upload: เราสร้างปุ่ม + ไว้ใส่รูป และ - สำหรับลบรูป ถ้าอยู่ด้านบนได้จะดี เพราะเป็นเหมือน tool bar และช่วยให้คนใช้โปรแกรมของเราจากบนลงล่าง
  • เตรียมรูป เราต้องแสดงรูปทั้งหมดที่จะ upload ขึ้นมาให้ผู้ใช้ดู ช่องนี้ยิ่งใหญ่ยิ่งดี และจะดีมากถ้าสามารถ ลากรูปที่ต้องการจาก Finder หรือ explorer มาใส่ได้เลย
  • เลือก album ที่ต้องการ พร้อมสร้าง album ใหม่ เวลาผม upload มักจะใส่ใน folder เดิมๆ ตรงนี้ต้องลอง survey อีกทีว่าคนส่วนใหญ่สร้าง folder ใหม่ตลอด หรือใส่ในของเดิม
  • ดูพื้นที่ ที่เหลือว่ารูปที่กำลังจะ upload ใหญ่กว่าขนาดที่เหลือหรือเปล่า
  • ตั้งค่าขนาดกว้างยาวของรูปที่ต้องการ upload ส่วนนี้น่าจะเหมือนๆ กันในแต่ละครั้ง
  • กำหนดว่าจะ Public หรือไม่
  • ใส่คำอธิบาย ไฟล์
  • บอกว่า เราใช้ account ไหนอยู่
เมื่อคิดได้ดังนี้ ก็มาถึงขั้นตอนการออกแบบครั้ง . . . . ... ส่วนนี้ใครอยากออกแบบไปด้วย ยังไม่ต้องดูของผมก็ได้นะครับ ลองวาดๆ เองดูก่อน ... . . . . ผมเริ่มจากวางสี่เหลี่ยมไปตามลำดับ โดยเริ่มจากวาง +, - ไว้บนสุด และตัด 3 ข้อสุดท้ายมาไว้ใน setup link จากนั้นลงพื้นที่ สำหรับแสดงรูป เอาแบบยิ่งขยายขนาดหน้าจอก็จะยิ่งใหญ่ขึ้น ส่วนด้านล่างของกล่องเอาไว้เลือก album พยายามเอาไว้ด้านในเพื่อสื่อว่าภาพด้านบนจะอยู่ใน Album นี้ทั้งหมด Note. ที่ไม่เอา explorer มาใส่ในหน้าจอนี้เลย เพราะต้องการป้องกันความต้องการที่จะเลือก folder ทั้ง folder มาทีเดียวซึ่งทำให้โปรแกรมของเราเขียนจากขึ้น ไหนจะต้องวิ่งไปใน folder ย่อยๆ เลือกเฉพาะไฟล์ที่ upload ได้ แล้วจะมีความต้องการว่าจะ upload หลาย album ทีเดียวเพราะแยก folder ไว้แล้ว และอีกหลายๆ อย่าง ดังนั้นจึงใส่ช่องสี่เหลี่ยมไว้เฉยๆ แสดง thumbnail อย่างดียว สุดท้้ายผมแทนที่ตัวอักษรเรื่องพื้นที่ ด้วยกราฟแท่ง ซึ่งแสดงพื้นที่ทั้งหมด พื้นที่ที่ใช้ไปแล้ว และพื้นที่กำลังจะใช้ บางทีอาจจะ recycle ไปใช้แสดงสถานนะตอน upload ได้ด้วย จะเห็นว่าเราสามารถ simplify โปรแกรม Uploader ได้อีกมาก ช่วยลดเวลาในการเรียนรู้โปรแกรมได้ด้วย ทีนี้ลองเทียบกับของเก่าดูนะครับ ส่วนที่ยากสุดของงานคือตอนที่เราไม่ใช่คนออกแบบเอง แต่ต้องไปบอกคนออกแบบว่าสิ่งที่เค้าออกแบบมามันไม่ดีอย่างไร

วันพุธ, พฤศจิกายน 19, 2551

ตุ๊กตา model

เปิดเว็บเล่นๆ ไปเจอตุ๊กตาชุดนี้เข้า ตอนเด็กๆ ชอบปั้นดินสงสัยต้องกลับมาลองปั้นอีกครั้ง กรุงเทพหาดินดีๆ ไม่ค่อยได้ สงสัยต้องใช้ดินญี่ปุ่นตามห้างไปก่อน :(

วันจันทร์, พฤศจิกายน 17, 2551

คำแนะนำเรื่อง 80:20 จาก Apple HIG

ใน Human Interface Guidelines ของ Apple มีพูดเรื่อง "Apply the 80 Percent Solution" ไว้สั้นๆ ประมาณ 5 บรรทัด แต่สำหรับผมมันคือหัวใจของการออกแบบทีเดียว HIG พยายามบอกว่าให้เราออกแบบ Application ที่ตอบสนอง 80% ของผู้ใช้ของเราเป็นหลัก แทนที่จะออกแบบให้ครอบคลุมทั้ง 100% ดูเหมือนง่าย ผมเลยลองวาดรูปมาประกอบ สมติว่าทุกคนในรูปเป็นกลุ่มเป้าหมายของเรา แน่นอนว่าแต่ละคนมีความต้องการใช้งานไม่เหมือนกัน กลุ่มสีเหลืองเป็นกลุ่มใหญ่สุด คือ 80% ของผู้ใช้ กลุ่มสีแดงเป็นผู้ใช้ส่วนน้อย ซึ่งมักจะเป็น power user หรือผู้ใช้ที่ใช้โปรแกรมของเราอย่างจริงๆ จังๆ โดยมีกลุ่มผู้ใช้สีส้มมาทำให้ความแตกต่างระหว่างสีแดงและสีเหลืองลดลง ทำให้งานออกแบบของเรายากขึ้น ในการออกแบบเราจะเห็นสีแดงเด่นกว่าสีเหลือมาก จนบางครั้งเรามองว่ากลุ่มสีแดงมีขนาดใหญ่พอๆ กับกลุ่มสีเหลือง ซึ่งไม่เป็นความจริง!! กลุ่มสีแดงเป็นกลุ่มที่เรียกร้อง feature มาที่เรามากที่สุด ดังที่สุด ชัดที่สุด และเมื่อเราพลาด เค้าจะทำให้เราเสียคนและเวลาในการพัฒนา ไปอย่างมากทีเดียว พวกนี้ชอบขอของยากและท้าทายดึงดูดให้พัฒนาเป็นอย่างยิ่ง ส่วนพวก 80% ชอบขอของง่าย ช่างไม่ท้าทายเอาซะเลย แต่ถ้าต้องการทำให้คนส่วนใหญ่เราต้องชัดเจนครับ อย่าสร้างภาพโดยไม่มีข้อมูลที่แท้จริง ลองนึกถึงตัวอย่างก่อนๆ กำหนดกลุ่มเป้าหมาย ถ้าเราทำ iPhoto ให้กลายเป็น aperture กลุ่ม power user ของเราที่เคยเป็น 20% จาก 100 คน จะกลายเป็น 100% ใน 20 คนทันที และยิ่งเราเพิ่ม feature ไปเรื่อยๆ กลุ่มเป้าหมายของเราก็ยิ่งหดลงๆ เป็นวงจรที่ไม่ดีเลย มาคิดดู ผมว่ามันเป็นปัญหาสำคัญของ opensource ทีเดียวครับ เพราะคนที่รายล้อม นักพัฒนามักเป็น Hard core user ซะมาก คนช่วยแนะนำด้านการตลาดก็มีน้อย ดังนั้นถ้าพวกเราอยากได้ software ดี และอยากหยุดวงจรนี้ ต้องอย่าเงียบครับ แสดงพลังของ 80% ออกมาให้ผู้พัฒนาเห็น อยากยอมแพ้พวก power user เทคนิคหนึ่งของคนออกแบบคือ ให้เตือนตนเองเสมอว่า "อย่ายอมแลกความสะดวกของผู้ใช้กลุ่มใหญ่ เพื่อผู้ใช้กลุ่มเล็กที่ใกล้ชิดคุณ" ใช้ Design process ให้เป็นประโยชน์เพื่อตามหา 80% solution ให้ได้ เรื่องนี้ยาวไว้เอามาเล่ากันอีกทีนะครับ ที่มา -- Apple HIG ปล.1 ขออภัยที่ใช้สีนี้นะครับ ผมไม่มีเจตนาทางการเมืองจริงๆ ปล.2 สมัยก่อน MS Office เค้าซ่อน feature พวกนี้ไว้ใน menu ครับ พอมี ribbon ถึงค่อยเผยออกมาได้บ้าง

วันเสาร์, พฤศจิกายน 15, 2551

ออกแบบ Business form จากเอกสารจริง

ถึงเราจะพัฒนาโปรแกรม เพื่อทำทุกอย่างในบริษัทให้เป็น electronic หมดแล้ว แต่สุดท้ายแล้ว เราก็ต้องพิมพ์เอกสารบางอย่างออกมาอยู่ดีทำให้เราต้องออกแบบโปรแกรมตามกระดาษ แถมผู้ใช้ยังมีความเชื่อฝังหัวว่า ถ้าไม่เห็นทุกอย่างอยู่บนหน้าจอจะไม่สบายใจ ทำให้ฟอร์มของเราใหญ่โตมาก อันนี้ถ้าเราทำกันตรงๆ มันก็คงออกมาใหญ่โตจริงๆ แต่ถ้านำความจริงว่า "คอมพิวเตอร์มันไม่นิ่งเหมือนกระดาษ" มาประกอบการใช้สมอง ก็จะช่วยให้พอเห็นทางสว่างอยู่บ้าง มาถึงตอนนี้เลยเริ่มคันไม้คันมือ เข้า google แล้วหาใบ Quotation มาออกแบบกัน ฟอร์มนี้เป็น Quotation ของร้านตัดเสื้อ ซึ่งน่าจะมีอะไรเฉพาะตัวอยู่เล็กน้อย เช่นมีรายละเอียดสินค้าอยู่ในฟอร์ม ในแบบที่บันทึกไว้เป็นข้อๆ ได้ยาก แทบจะต้องเขียนใหม่ซะทุกครั้ง นอกจากนี้ฟอร์มยังดูเหมือนออกแบบมาให้ใช้ร่วมกับปากกา คือพิมพ์เสร็จสามารถนำออกมาเขียนเพิ่มเติมได้ด้วย ดังนั้นโปรแกรมต้องทำให้แก้ง่ายๆ ให้ได้ พอได้ตัวอย่างยากพอสมควร ไม่ซับซ้อนจนเกินไป เมื่อพิจารณาแล้วผมแบ่งข้อมูลในฟอร์มออกเป็นสามประเภท 1. ส่วนที่กรอกครั้งเดียว ใบอื่นๆ สามารถมาลอกเอาไปได้ หัวกระดาษ เงื่อนไข ผู้เสนอราคา กรรมการผู้จัดการ ท้ายกระดาษ 2. เปลี่ยนตามลูกค้า เรียน บริษัท ที่อยู่ โทร 3. ส่วนที่ต้องกรอกใหม่ทุกครั้ง จำนวนตัว รายการ n บรรทัด ผ้า, สี, ปัก - กระเป๋า, แขนขวา, ใต้คอหลัง ไซต์ผู้ชาย - S, M, L, XL ไซต์ผู้หญิง - S, M, L, XL ส่วนลด หมายเหตุ เมื่อแบ่งได้ดังนี้ ขั้นตอนต่อไปคือการออกแบบ 1. ผมตัด ส่วนที่กรอกครั้งเดียวออกไปจากฟอร์มก่อน พวกนี้เอาไปกรอกใน corporate information 2. ผมเปลี่ยนส่วนที่สอง จะเป็นการใช้ซ้ำ เลยตัดให้แก้ไขได้ในฟอร์มอื่น 3. ส่วนรายการ คือ รายละเอียดของงาน, ผ้า, สี และการปัก ผมจะรวบบันทึกเอาไว้เพราะคิดว่า โรงเรียน หรือหน่วยงานน่าจะตัดผ้าซ้ำๆ กันเป็นส่วนมาก ขั้นตอนไปก็ลองร่างแบบของ form ออกมา ผมเอาทุกอย่างที่ต้องพิมพ์ในการออกฟอร์มแต่ละครั้งมารวมกัน ส่วนของลูกค้าผมจะให้เลือกเอาจาก dropdown หรือจะทำเป็น live search ก็สะดวกดี ถ้ากด edit ก็จะเปิดฟอร์มให้แก้ หรือ new ได้ หรือจะกดแล้วเปิด address book มาเลือกก็ดูหรูดี ด้านซ้ายมือเป็นรายการที่ออกในแต่ละวัน ทำเหมือน blog ส่วน search ด้านบน ถ้าเจอแค่อันเดียวก็ออกมาเลย ถ้าเจอหลายอัน ก็จะออกมาให้เลือกในด้านซ้ายมือ ผมมีสมติฐานว่า ร้านตัดเสื้อน่าจะรับ order ซ้ำๆ กันบ่อยๆ เพราะชุดข้าราชการ หรือชุดนักเรียนคงไม่เปลี่ยนกันบ่อยนัก เราสามารถซ่อนส่วน รายการได้ ทำให้ฟอร์มโล่งขึ้นมากทีเดียว สุดท้ายกลับมาตอบโจทย์ข้างต้นว่า ถ้าไม่เห็นฟอร์ม จะไม่สบายใจ เราก็ทำให้ pre print form มันดูง่ายๆ ไม่ใช่ไปซ่อนอยู่ใน menu file ทุกครั้งที่ดูต้องกดกันหลาย click เลยเปลี่ยนมาเป็นอีก tab ซะเลยดูง่ายดี แถมให้อีกสอง tab คือ shirt 3D เป็นตัว preview เสื้อแบบสามมิติ ถ้าเครื่องมือที่ใช้อำนวยน่าจะทำให้เขียนได้ง่าย เช่น core image น่าจะช่วยได้มาก อีกตัวคือ Follow up เอาไว้ดูว่าจ่ายหรือยัง ตกลง quotation หรือยัง หรืออาจจะเชื่อมไปยัง module billing ก็ได้ สิ่งหนึ่งที่แฝงมากับการออกแบบคือ ถ้าผู้ใช้ไม่เห็นฟอร์มตัวจริง ยังไงก็อยากจะพิมพ์ออกมา แต่ถ้าเห็นแล้วแถมรู้สึกว่าโปรแกรมเก็บกระดาษแผนนี้เอาไว้ให้แล้ว ความรู้สึกว่าต้องพิมพ์จะลดลง ถ้าผู้ใช้ไม่ขอก็ไม่ต้องพิพม์ออกมา ใช้วิธีส่ง mail confirm แทน สุดท้ายองค์กรอาจจะไม่ใช้กระดาษเลยก็ได้ คนที่เคยเขียนโปรแกรมทางธุรกิจ จะรู้ว่าการไม่ใช้กระดาษทำได้ยากมาก เราเป็นนักออกแบบ ต้องใช้การออกแบบทำให้การย้ายมาใช้ของใหม่มันราบรื่นที่สุด

Real Photoshop

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

กำหนดกลุ่มเป้าหมาย

การกำหนดกลุ่มเป้าหมายเป็นบทแรกๆ ตอนที่เรียนวิชา Marketing เรียนไปก็เหมือนง่าย แค่บอกว่าลูกค้าของเรา เป็นผู้หญิง ผู้ชาย เด็ก หรือแก่ เงินเดือนเท่าไหร และอื่นๆ ต่อจากนั้นก็มาวางแผน ทำวิจัยว่า กลุ่มเป้าหมายของเรามีพฤติกรรมอย่างไร ชอบเดินสยามหรือเปล่า หรือว่านั่ง starbuck ต้องดูว่าเค้าชอบใช้ Windows หรือ Mac และอะไรเป็นเหตุจูงใจให้เค้าชอบแบบนั้น เพื่อออกแบบสินค้าให้ตรงกับความต้องการมากที่สุด อันนี้เริ่มยาก การออกแบบ interface ก็ต้องรู้ว่ากลุ่มเป้าหมายเช่นกัน ผมลองแบ่งกลุ่มเป้าหมายง่ายๆ เป็น Home user กับ Pro user Home user ของผมหมายถึงคนที่ไม่มีเวลามาเรียนรู้โปรแกรมของเรา ผู้ใช้มีความต้องการของเค้าอยู่แล้ว เป็นอะไรซื่อๆ ถ้าออกมาดีมากก็ดี ไม่ดีมากก็ไม่เป็นไร อย่าเสียเวลาก็แล้วกัน โปรแกรมประเภทคนี้ก็เช่น iPhoto ผมถือว่าโปรแกรมนี้เป็น fast food ชั้นเยี่ยม มีคนยอมจ่ายราคาแพงแลกอาหารชุดชั้นเลิศ สั่งง่าย กินง่าย ไม่ต้องกังวลเรื่องไขมัน หรือความสะอาด แถมทำออกมาสวยด้วย แต่จะมาสั่งสุกปานกลาง หรือสุกมาก ไม่ได้นะ มีให้แค่นั้น ถ้าลูกค้าเริ่มจุ๊กจิก อาจจะเพราะเค้าต้องเอาอาหารไปขายต่อ หรือลูกค้าเริ่มต้องการสะดวกในการปรุงอย่างมาก หรือเค้าต้องทำมันทุกวัน วันละมากๆ ตอนนั้นลูกค้าเริ่มรู้สึกคุ้มค่าที่จะเรียนรู้โปรแกรมของเรา แบบว่า "ลองเรียนการใช้งานมันซักอาทิตย์ น่าจะเพิ่มคุณภาพงาน หรือประหยัดเวลาได้" คนกลุ่มนี้ผมเรียกว่า Pro user ครับ โปรแกรมของคนประเภทนี้คือ Aperture โปรแกรมทั้งสองตัวเป็นโปรแกรมสำหรับจัดการรูปภาพเหมือนกัน แต่กลุ่มเป้าหมายต่างกันมาก จะเห็นว่า iPhoto จับกลุ่มตลาด Home user ทั้งหน้าจะมีองค์ประกอบน้อยมาก เวลาเรียนรู้แทบจะเป็นศูนย์ พวก advance feature ถูกซ่อนเอาไว้หมด เพราะคนกลุ่มนี้ไม่ได้ใช้บ่อย แต่!! ไม่ใช่ว่ากลุ่มเป้าหมาย Home user แล้วจะพัฒนาโปรแกรมได้ง่ายนะครับ โปรแกรมต้องตอบสนองความงี่เง่าทุกรูปแบบ และจำกัดความคิดของผู้ใช้ให้ได้ และทำ feature ที่มีได้เพียงน้อยนิดให้ดีที่สุด อย่างของ iphoto ผมชอบที่มันจัดการรูปเยอะๆ ได้ดีมากๆ (แต่ผู้ใช้แทบไม่รู้สึกว่ามันเป็นข้อดี จนกว่าจะได้ใช้โปรแกรมอื่น) อีกอย่างที่ชอบคือเวลาแต่งรูปมันทำให้สวยง่ายดี ผมพยายามปรับสีใน Aperture อยู่นานมาก สุดท้ายสรุปว่าปรับบน iphoto ทำให้สวยง่ายกว่า สำหรับโปรแกรม Aperture จะเห็นว่าเค้าอุทิศหน้าจอให้กับเครื่องมือตกแต่งรูปภาพล้านแปด แถมยังแสดงรูป thumbnail ไปพร้อมๆ กันด้วย ถึงขนาดยอมให้รูป preview มีขนาดเล็กลงอย่างที่เห็น ที่ต้องเป็นแบบนี้เพราะกลุ่มเป้าหมายคือคนที่แต่งรูปเป็นประจำ และคนกลุ่มนี้คงรำคาญมากถ้าต้องกดปุ่มปิด/เปิดหน้าต่างทุกครั้งที่ต้องการแต่งรูป ผมสรุปว่า "Pro คือกลุ่มคนที่ยินดีที่ ยอมเสียเวลาเรียนรู้โปรแกรมเพื่อให้ผลงานออกมาดีขึ้น" จากข้อสมติฐานนี้ผมอยากบอกว่า นักบัญชีที่ใช้โปรแกรมบัญชี ผ่ายการเงินที่ใช้โปรแกรมออกใบเสนอราคา พวกนี้ถูกจับเข้ากลุ่ม Pro ทั้งนั้นครับ... มีคนบอกผมว่าโปรแกรมสำหรับคนพวกนี้ต้องง่ายๆ โง่ๆ ส่วนหนึ่งก็จริง ยิ่งโปรแกรมง่ายก็ยิ่งดี แต่เวลาเราออกแบบต้องไม่ลืมว่าคนกลุ่มนี้จะใช้โปรแกรมของเราทุกวัน ออกใบเสร็จวันละหลายใบ ปรับแต่งตัวเลขเป็นว่าเล่น แค่ใช้โปรแกรมของเราไปเดือนนึงก็รู้แทบหมดทุกปุ่มแล้ว ถึงช่วงแรกๆ จะยากหน่อย แต่พอใช้ไปเค้าจะเริมคน แล้วเริ่มเรียกร้องมากขึ้น อย่าเอา iPhoto ไปให้ Pro ใช้เชียวนะครับ ถึงตอนแรกเค้าจะคิดว่าง่าย แต่ใช้ไปซักพักคนที่เดือดร้อนคือคนที่พัฒนาโปรแกรม เพราะต้องยัด feature ต่างๆ ลงไปในโปรแกรมที่ไม่ได้ออกแบบไว้สำหรับให้มี feature ขนาดนั้น ใครบอกว่าโปรแกรมของเราใช้ยาก ก็บอกไปเลยครับว่าโปรแกรมของผมมันของ Pro เค้าใช้กัน :p

ติดตั้ง Rails ด้วย Nginx -> 3xMongrel <- Monit

ใน blog ก่อนหน้านี้พูดถึง Nginx -> Mongrel cluster <- Monit ปรากฏว่า monit มันไม่สามารถไปคุมเจ้า mongrel cluster ได้ คาดว่าเป็นเพราะ Mongrel cluster มันเป็น cluster จึงไม่ได้แยกแต่ละตัวออกเป็น process เดี่ยวๆ แบบที่ monit ชอบ ดังนั้นเลยลองวิธีใหม่ แยกมันเป็น 3 ตัวซะเลย ตอนนี้เจ้า monit ควบคุม mongrel อยู่หมัด ผมลอง kill process ดู เจ้า monit ก็ start ขึ้นมาให้ ตอนนี้สั่งปิด/เปิด mongrel จาก monit ได้เลย ขั้นตอนการติดตั้งจะซ้ำกับของเดิมเยอะหน่อย แต่อยากเขียนให้เต็มๆ ครับ เริ่มจาก 1. ติดตั้ง project ของเรา Add new user # สำหรับ ubuntu sudo /usr/sbin/adduser mongrel # สำหรับ redhat ที่ใส่ -r เพราะไม่ต้องสร้าง home ให้ user sudo /usr/sbin/adduser -r mongrel Deploy application sudo mkdir /var/www sudo mkdir /var/www/project sudo chown -R mongrel:mongrel /var/www/project cd /var/www/project su mongrel svn checkout svn://host.com/project/trunk/ --username xxx --password xxx . rake db:create:all rake db:migrate rake db:migrate RAILS_ENV="production" #ทดสอบว่าติดตั้งเรียบร้อยหรือเปล่า ก่อนเริ่มขั้นตอนต่อไป ./script/server 2. ให้แก้ไฟล์ mongrel_rails ให้ลบ PID ออกถ้ามี PID อยู่แล้ว เพราะถ้าไม่ทำเจ้า mongrel_rails จะ error ตอนที่ process ของเราตายโดยทิ้ง PID เอาไว้ แล้วเราพยายาม start mongrel ขึ้นมา มันจะฟ้องว่ามี PID อยู่แล้ว และไม่ยอม start ให้เรา สั่ง edit mongrel_rails ใครถนัด editor ตัวไหนก็ใช้ตามสะดวกนะครับ sudo vi /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails #บางทีก็อยู่ที่นี่ sudo /var/lib/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails แทนที่บรรทัดนี้ if File.exist? defaults[:pid_file] log "!!! PID file #{defaults[:pid_file]} already exists. Mongrel could be running already. Check your #{defaults[:log_file]} for errors." log "!!! Exiting with error. You must stop mongrel and clear the .pid before I'll attempt a start." exit 1 end ด้วยบรรทัดนี้ if File.exist? defaults[:pid_file] # mongrels that crash can leave stale PID files behind, and these # should not stop mongrel from being restarted by monitors... pid = File.new(defaults[:pid_file]).readline unless `ps -ef | grep #{pid} | grep -v grep`.length > 0 # use "ps ax" for freebsd log "!!! PID file #{defaults[:pid_file]} exists, but is stale, and will be deleted so that this mongrel can run." File.delete(defaults[:pid_file]) else log "!!! PID file #{defaults[:pid_file]} already exists and the process id referred to in it is running. This mongrel is probably already running. #{defaults[:log_file]} for errors. EXITING." exit 1 end exit 1 end 3. เตรียม config สำหรับ mongrel ทั้ง 3 ตัว sudo vi /var/www/project/config/mongrel_8000.yml --- user: mongrel cwd: /var/www/project log_file: log/mongrel.8000.log port: "8000" environment: production group: mongrel address: 127.0.0.1 pid_file: tmp/pids/mongrel.8000.pid daemon: true สร้างไฟล์นี้อีกสองไฟล์ แต่เปลี่ยนจาก 8000 เป็น 8001 และ 8002 สำหรับคนที่ลง mongrel cluster ไปแล้ว แถมสั่งให้มัน start ตอน boot ด้วย ต้องไปเอาออกก่อนครับ เพราะต่อไปเราจะให้ monit เป็นคน start ให้ทั้งหมด ผมใช้วิธีลบ ไฟล์ /etc/mongrel_cluster/application_name.yml ออกไป ทดสอบว่า server ของเราทำงานโดยสั่ง sudo /usr/bin/mongrel_rails start -C /var/www/project/config/mongrel_8000.yml จากนั้นทดลองสั่ง ps -aux | grep mong ถ้ามี process 8000 ของเราขึ้นมาแสดงว่าเรียบร้อย ถ้าไม่ขึ้นให้ลองไปดู log ที่ /var/www/project/log/mongrel.8000.log จากนั้นลองสั่ง stop ดูด้วยคำสั่ง sudo /usr/bin/mongrel_rails stop -P /var/www/project/tmp/pids/mongrel.8000.pid ถ้าไม่ได้ให้ลองดู log เหมือนเดิม ถ้าได้ก็ไปขั้นตอนต่อไปได้เลย 4. ติดตั้ง Watch dog ที่ชื่อ monit ติดตั้ง monit (ถ้าใครไม่มี apt-get ใช้ก็ลองประยุกต์ใช้ทางอื่นดูนะครับ) sudo apt-get install monit จากนั้นตั้งค่าให้ monit sudo mkdir /etc/monit.d sudo vi /etc/monit.d/mongrel.monitrc ใส่ config ตามนี้ check process mongrel_8000 with pidfile /var/www/project/tmp/pids/mongrel.8000.pid group mongrel start program = "/usr/bin/mongrel_rails start -C /var/www/project/config/mongrel_8000.yml" stop program = "/usr/bin/mongrel_rails stop -P /var/www/project/tmp/pids/mongrel.8000.pid" if failed host 127.0.0.1 port 8000 protocol http and request "/" then alert if totalmem is greater than 110.0 MB for 4 cycles then restart if cpu is greater than 80% for 4 cycles then restart if 3 restarts within 5 cycles then timeout check process mongrel_8001 with pidfile /var/www/project/tmp/pids/mongrel.8001.pid group mongrel start program = "/usr/bin/mongrel_rails start -C /var/www/project/config/mongrel_8001.yml" stop program = "/usr/bin/mongrel_rails stop -P /var/www/project/tmp/pids/mongrel.8001.pid" if failed host 127.0.0.1 port 8001 protocol http and request "/" then alert if totalmem is greater than 110.0 MB for 4 cycles then restart if cpu is greater than 80% for 4 cycles then restart if 3 restarts within 5 cycles then timeout check process mongrel_8002 with pidfile /var/www/project/tmp/pids/mongrel.8002.pid group mongrel start program = "/usr/bin/mongrel_rails start -C /var/www/project/config/mongrel_8002.yml" stop program = "/usr/bin/mongrel_rails stop -P /var/www/project/tmp/pids/mongrel.8002.pid" if failed host 127.0.0.1 port 8002 protocol http and request "/" then alert if totalmem is greater than 110.0 MB for 4 cycles then restart if cpu is greater than 80% for 4 cycles then restart if 3 restarts within 5 cycles then timeout ถ้าเจ้า monit เจออะไรผิดพลาด ตามที่เขียนใน config มันจะ restart ให้ทันที อันนี้ชอบมั๊กๆ แต่เปิดใช้มาหลายวัน มันยังไม่เคย restart เองเลยครับ เสถียรมาก มีแต่ผมสั่งมัน restart เอง คงเพราะ ผู้ใช้ยังไม่คุ้นเลยยังยิงกันไม่ถึงตาย แก้ไฟล์ monit ให้มัน start ตอน boot เครื่อง sudo vi /etc/default/monit startup=1 จากนั้นเอา comment ของไฟล์ monitrc ออกตามนี้ sudo vi /etc/monit/monitrc set daemon 120 set logfile syslog facility log_daemon set httpd port 2812 and allow localhost # allow localhost to connect to the server and include /etc/monit.d/* ทดสอบการทำงานของ monit ตามนี้ครับ สั่ง restart, sudo shutdown -r now เมื่อเปิดมาตอนแรกให้รอ 5-10 นาที จากนั้นลอง sudo monit status ตัว monit ควรจะ start mongrel ให้เราทั้งสามตัว ทดลอง ps -aux | grep mong ดู process ทั้งหมดของ mongrel ทดลอง kill 1 process รอ 5-10 นาที ทดลอง ps -aux | grep mong ดูว่า mongrel start ขึ้นมาให้เราหรือเปล่า แล้วสั่ง sudo monit status ดูว่า monit รับรู้การขึ้นมาหรือยัง ถ้าขึ้นมาครบทั้ง 3 ตัวเป็นอันว่าติดตั้ง mongrel และ monit สำเร็จ คำสั่งที่ใช้บ่อยบน monit มีดังนี้ครับ # restart monit ถ้ามันหือ sudo /etc/init.d/monit restart #restart mongrel ยกฝูง sudo monit restart all -g mongrel #start/stop บางตัว sudo monit stop mongrel_8000 sudo monit start mongrel_8000 #ดู status sudo monit status #force ให้ monit ตรวจสอบการทำงานของ process ที่มันดูอยู่ sudo monit validate 5. ติดตั้ง NGiNX sudo apt-get install nginx แก้ config ของไฟล์ sudo vi /etc/nginx/nginx.conf #user deploy; worker_processes 1; error_log /var/log/nginx/error.log; #error_log logs/error.log debug; #pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; #tac_nonpush on; tcp_nodelay on; #access_log /var/log/nginx/access.log; sendfile on; #tcp_nopush on; #keepalive_timeout 0; #keepalive_timeout 65; gzip on; gzip_min_length 1100; gzip_buffers 4 8k; gzip_types text/plain; #include /etc/nginx/sites-enabled/*; upstream mongrel { server 127.0.0.1:8000; server 127.0.0.1:8001; server 127.0.0.1:8002; } server { listen 80; server_name project.com; root /var/www/project/public; index index.html index.htm; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect false; if (-f $request_filename/index.html) { rewrite (.*) $1/index.html break; } if (-f $request_filename.html) { rewrite (.*) $1.html break; } if (!-f $request_filename) { proxy_pass http://mongrel; break; } } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } } restart NGiNX ด้วยคำสั่ง sudo /etc/init.d/nginx restart จากนั้นลองเข้าผ่าน web ดูครับ ว่าเปิดได้หรือเปล่า ถ้าได้ก็จบครับ ขั้นต่อไปเป็นของแถม ทำเผื่อเอาไว้ตอนมีปัญหาจะได้เข้ามาดู 6. ติดตั้งตัว monitor ให้ NGiNX sudo apt-get install rrdtool librrds-perl -y sudo vi /etc/nginx/nginx.conf เพิ่ม location status ลงไประหว่าง http และ server http { ... server { listen SOME.IP.ADD.RESS; ... location /nginx_status { stub_status on; access_log off; allow SOME.IP.ADD.RESS; deny all; } ... } ... } ทดสอบว่า script NGiNX ของเรายัง ok อยู่ # sudo /usr/sbin/nginx -t 2006/04/29 04:24:36 [info] 31676#0: the configuration file /opt/nginx/conf/nginx.conf syntax is ok 2006/04/29 04:24:36 [info] 31676#0: the configuration file /opt/nginx/conf/nginx.conf was tested successfully สร้างที่อยู่ให้ output file sudo mkdir /opt/rrd sudo mkdir /opt/rrd/html sudo vi /etc/nginx/rrd_nginx.pl ไฟล์ rrd_nginx.pl เอาได้ที่ apirak.com/downloads/rrd_nginx.pl อย่าลืมสั่งให้ rrd_nginx.pl กลายเป็น execute file ด้วย chmod +x /etc/nginx/rrd_nginx.pl จากนั้น edit ให้ cron เรียก rrd_nginx.pl ทุกๆ นาที sudo crontab -e # m h dom mon dow command * * * * * /etc/nginx/rrd_nginx.pl เมื่อโปรแกรมทำงานจะมีรูปขึ้นมาที่ /etc/opt/rrd/html สามารถเข้าไปดูได้ วินาทีนี้ผมยังไม่ได้สร้าง HTML สำหรับดู เลยทำแค่ ใช้ feh ในการดู sudo apt-get install feh -y feh /opt/rrd/html/*.png ถ้ามีกราฟขึ้นก็แสดงว่าโปรแกรมทำงานได้แล้ว และถ้ากราฟมีขึ้นๆ ลงๆ ก็แสดงว่าสมบูรณ์ละแล้วครับ :) Reference ( บางแหล่งก็ลืมไปแล้วครับ จดไว้ประมาณนี้) http://codesnippets.joyent.com/tag/mongrel http://www.howtoforge.com/server_monitoring_monit_munin http://www.circlingminds.com/advanced-rails/using-nginx-mongrel-rails-on-ubuntu/ http://wiki.codemongers.com/NginxInstall http://groups.google.com/group/thinking-sphinx/browse_thread/thread/a7a11ab1c98f5593 http://mkaz.com/ref/unix_cron.html

วันพฤหัสบดี, พฤศจิกายน 06, 2551

ออกแบบ GUI ให้จำกัดความคิดของผู้ใช้

ก่อนหน้านี้มีความคิดฝังหัวว่า GUI ที่ดีคือรูปแบบที่ทำให้ผู้ใช้ทำงานได้มากที่สุด สะดวกที่สุด ให้ผู้ใช้ทำอะไรได้ทุกอย่างโดยใช้ความคิดน้อยที่สุด

วันนี้ความคิดนี้เริ่มถูกทำลายเมื่อเห็น Nautilus + ZFS สำหรับคนที่ไม่ได้ใช้ Gnome เจ้า Nautilus เปรียบเหมือน File manager หลักของ Gnome ซึ่ง Sun เอามาใช้กับ Solaris ของ Sun และได้เพิ่ม plugin ให้กับ Nautilus เพื่อให้สามารถใช้ Feature หลายๆ อย่างของ ZFS (File system ของ sun) เช่นความสามารถในการย้อนเวลา กลับไปเอาไฟล์ที่เคยย้ายไป ลบไป หรือเขียนทับไปแล้ว กลับมาได้

 ส่วนนี้น่าสนใจที่สุด เพราะผมไม่เคยเห็น feature ย้อนเวลามาอยู่บน GUI ของ File manager เลย

   
ห่วงยางช่วยชีวิต


 ในรูปเมื่อผู้ใช้กดปุ่ม "ห่วงยางช่วยชีวิต" เจ้า Nautilus จะแสดง แถบสำหรับย้อนเวลาออกมา

   
ย้อนเวลา

เมื่อเลื่อนแถบไฟล์ต่างๆ ที่อยู่ด้านล่างจะย้อนเวลาไปยังช่วงที่เราเลือก อย่างในรูปพอเลื่อนไปเมื่อ 10 วันก่อน ไฟล์ Screenshort-3.png จะปรากฏออกมา พร้อมบอกว่าไฟล์นี้ขนาดเล็กกว่าไฟล์ปัจจุบันนะ ถ้าเราสนใจจะเอากลับมาก็ click ขวาแล้วเลือกให้กลับมา 

ปัญหาที่เกิดขึ้นคือ GUI มันเปิดกว้างมากทีเดียว ผมสามารถจิตนาการว่า ถ้าย้อนเวลาแล้วลากไฟล์จากที่อื่นมาใส่ จะเป็นการแก้ไขอดีตหรือเปล่า หรือผมสามารถลากไฟล์ในอดีตออกมาใส่บน desktop เลยได้หรือเปล่า แล้วถ้าผมลากไฟล์ Screenshort-3.png ออกมานอก folder image มันจะมีผลต่อไฟล์ปัจจุบันของผมมั้ย

เมื่อคิดถึงตรงนี้ ผมก็นึกถึง GUI โง่ๆ ของ TimeMachine (OSX) ขึ้นมาทันที

   
Time machine

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

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

วันพุธ, พฤศจิกายน 05, 2551

บ้านที่อุตรดิตถ์

บ้านผมเองครับ อยู่ที่อุตรดิตถ์ เป็นบ้านที่พ่อกับแม่ปั้นขึ้นมา ลูกๆ เห็นแล้วก็ภูมิใจ ตอนแรกๆ ก็ไม่คิดอะไรบ้านใหญ่ดูแลยาก ค่าใช้จ่ายสูง แต่พอคิดว่าต้องขายก็ใจหาย อยากให้มีคนมาอยู่มากกว่า
From Bank & Home
ดู homepage ได้ที่ http://www.apirak.com/home/index.html คิดแล้วอยากกลับบ้านจังเลย

วันอังคาร, พฤศจิกายน 04, 2551

ความใส่ใจในรายละเอียด ยิ่งทำยิ่งมองไม่เห็น

โปรแกรมที่ออกแบบมาดีคือโปรแกรมที่ทำให้ผู้ใช้รู้สึกเหมือนไม่ได้ใช้โปรแกรมอยู่ ตัวอย่างเช่น "Browser ที่ดี" คนจะไม่เสียเวลาเรียนรู้การใช้งาน ไม่เสียอารมณ์ในการตอบคำถามจุกจิก คนจะใส่ใจในการทำงานของตนให้เสร็จ สนใจที่จะหาข้อมูลบน web สนใจที่จะอ่าน email โดยแทบไม่ได้สังเกตุว่าตนเองใช้งาน Web Browser อยู่ จนกระทั้ง Browser มันมีปัญหาเช่น เตือนเรื่อง security หรือเมื่อหาปุ่ม stop ไม่เจอ หาก browser สามารถจัดการเรื่อง security ให้เราได้ สามารถแสดงปุ่ม stop ให้เราเห็นเมื่อเราต้องการใช้ นั่นจะทำให้ผู้ใช้ลืม browser ไปเลย และจะโหยหาโปรแกรมของเราเป็นสามเท่าเมื่อเค้าขาดมันไป "แสดงสิ่งที่ผู้ใช้หา เมื่อผู้ใช้ต้องการ" พูดง่ายครับ แต่เอาเข้าจริงทำได้ตั้งแต่ แบบมักง่าย จนถึงแบบที่คิดกันหัวปูด วันนี้ผมขอยกตัวอย่างหนึ่ง "เรื่องวันที่ในตาราง ของ Finder" หากใครได้สังเกตุจะเห็นว่า คนออกแบบเค้าใส่ใจในรายละเอียดอย่างเหลือเชื่อทีเดียว ลองดูวันที่ในตารางของ Windows XP กันก่อน รูปบนสุดคือการแสดงวันที่แบบเต็มๆ ตอนที่ตารางกว้างที่สุด และรูปล่างลงมาเป็นการลดขนาดของตาราง ซึ่ง Windows XP จะแสดง "..." เป็นการบอกว่าข้อความยังไม่จบ สามารถปรับขนาดของตารางเพื่อดูข้อความเต็มได้ ตรงนี้จะเห็นว่า Windows XP ก็คิดให้ผู้ใช้ระดับหนึ่งแล้ว แต่ถ้าเป้าหมายของเราคือ ไม่ต้องการให้ผู้ใช้รู้สึกว่าใช้โปรแกรมอยู่ ต้องหาทางลดงานของผู้ใช้ให้มากที่สุด ผมอยากให้ดูอีกตัวอย่างหนึ่ง Mac OS X คิดต่อจาก Windows XP ไปอีก การแสดงวันที่บน Finder จะมีประมาณ 5 ระดับ เริ่มจากสองแบบแรกที่มีครบทั้งวัน เวลา และวันในสัปดาห์ และเมื่อขนาดของช่องลดลง แทนที่จะแสดง วันในสัปดาห์ ตัว Finder จะตัดออก แล้วแสดงเฉพาะ วันและเวลาแทน ผู้ใช้จะเริ่มคิดน้อยลง เพราะโปรแกรมทำให้ผู้ใช้มีโอกาสเห็นข้อมูลที่ตนเองต้องการมากขึ้น โดยไม่ต้องขยายขนาดของช่อง สังเกตุง่ายๆ ว่าพวกเราหลายคนคงไม่เคยรู้สึกว่ามี feature นี้บน finder มาก่อนเลยนี่ถือเป็นความสำเร็จในการออกแบบนะครับ ระดับเล็กสุดจะแสดงแค่ วันเดือนปี เป็นแค่ตัวเลขอย่างเดียว มองแบบนี้คนออกแบบเหมือนเป็นพวกปิดทองหลังพระ ทำดีคนก็ไม่เห็น ทำไม่ดีคนก็ด่า แต่ Application ก็เหมือนคู่ชีวิตครับ ขาดเมื่อไหรถึงจะรู้สึก ตอนผมย้ายไปใช้ Linux ที่ไม่มีโปรแกรม Omnigraffle แทบจะขาดใจ กลายเป็นทำอะไรไม่ได้เลย productivity ตกฮวบ สิ่งเล็กๆ น้อยเหล่านี้ต้องอาศัยประสบการณ์ ต้องคอยสังเกตุอย่าปล่อยให้ผ่านตาไปเฉยๆ เพราะทุกอย่างล้วนกลั่นมาจากสมองนักออกแบบนั้นทั้งนั้น ต้องเอามาใช้ให้คุ้มครับ

วันอาทิตย์, พฤศจิกายน 02, 2551

การเลือกรูปแบบของฟอร์มในโปรแกรม

ช่วงแรกขอการออกแบบ application ผมมองการออกแบบฟอร์มเป็นเรื่องเล็กมากๆ ยิ่งในยุกต์ของเว็บที่ฟอร์มไม่ได้มีข้อมูลให้กรอกมากมายนัก ยิ่งไม่มีปัญหา แต่ล่าสุดผมออกแบบ Online ERP ซึ่งใช้ฟอร์มกันอลังการ งานนี้เลยต้องศึกษาข้อดีข้อเสียของฟอร์มแต่ละแบบกันนิดหน่อย ผลจากการทดลองได้ออกมาสามแบบ classic ดังนี้ครับ แบบที่หนึ่ง ตัวหนังสือกับกล่องข้อความเป็นบรรทัดเดียวกัน แบบนี้ช่วยประหยัดเนื้อที่แนวตั้งได้ ทำให้ผู้ใช้ scroll น้อยลง หรือบางทีสามารถเห็นทั้งฟอร์มได้ในหน้าเดียว ข้อเสียคือปัญหาเรื่องความยาว เราจะกะความยาวยากเพราะหากมี label ตัวใดตัวหนึ่งมันจำเป็นต้องยาว จะทำให้ทั้งฟอร์มต้องยาวไปหมด ซึ่งทำให้ label ที่สั้นๆ อยู่หางจากกล่องข้อความมาก สร้างความลำบากให้ผู้ใช้ต้องเล็งเอาเอง หากยาวมากๆ บางทีถึงขนาดต้องเอาหน้าต่างอื่นมาทาบ เพื่อให้รู้ว่าเป็น label ของกล่องไหน แบบที่สองเหมือนแบบแรก คือตัวหนังสือกับกล่องข้อความเป็นบรรทัดเดียวกัน แต่ตัวหนังสือชิดขวาหมด จะเห็นว่าแบบที่สองเข้ามาแก้ปัญหาเรื่องระยะห่างระหว่ากล่องข้อความ กับ label โดยแลกกับความเป็นระเบียบเรียบร้อยในฟอร์ม โดยเฉพาะอย่างยิ่งในเมืองไทย ที่คนอ่านหนังสือจากซ้ายไปขวา เราจะเห็นอะไรๆ ชิดซ้ายไปหมดมาตั้งแต่เด็ก พอเห็นฟอร์มแบบนี้จะรู้สึกว่ามันไม่เป็นระเบียบทันที แบบสุดท้ายคือให้ตัวหนังสืออยู่บนกล่องข้อความ ให้ตัวหนังสือชิดซ้าย แบบนี้ช่วยประหยัดเนื้อที่แนวกว้าง แก้ปัญหาความยาวของ label และช่วยผู้ใช้ในการกรอกให้ตรงฟอร์ม เพราะเรียงจากบนลงล่าง ถ้าเราไม่สนใจว่าฟอร์มของเราจะยาวมาก จนต้อง scroll ลงมาหลายหน้า ฟอร์มนี้ก็เหมาะทีเดียวครับ (ค่า default ของ wufoo.com ใช้แบบนี้) บทความนี้ไม่สามารถสรุปได้ว่าฟอร์มแบบไหนดีที่สุด แต่อยากตั้งข้อสังเกตุให้กับคนที่กำลังออกแบบ Application ให้พิจารณาข้อดีข้อเสีย เพื่อหาฟอร์มที่เหมาะกับโปรแกรมของตนมากที่สุด สำหรับบางท่านอาจจะใช้โครงนี้เป็นต้นแบบความคิด แล้วเสริมแนวทางของตนเองลงไป เช่น OSX ใช้ฟอร์มแบบที่สอง แต่แก้ปัญหาความไม่เป็นระเบียบโดยทำให้ทั้งฟอร์มอยู่ตรงกลางก่อน แล้วค่อยจัดให้ตำแหน่งระหว่างตัวหนังสือกับกล่องข้อความตรงกัน ช่วยลดความรู้สึกว่าต้องชิดขวาออกไป (อันนี้ดูได้ใน HIG ของ Apple) **รู้สึกว่า Firefox ยังไม่ยอมทำตาม HIG นะเนี่ย เอาเข้าจริงเวลาเราออกแบบ Application จะมีปัจจัยอื่นอีกมากมาย ที่บีบให้เราต้องออกแบบไปในทางอื่น แต่ผมคิดว่าถ้าเรามีหลักไว้ยึดจะทำให้เราออกแบบได้เร็ว และประยุกต์ได้ง่าย เอาเข้าจริงในโปรแกรม Online ERP ของผมก็ไม่ได้ใช้สามฟอร์มนี้ แต่ใช้หลักการของทั้งสามแบบแน่นอน