วันเสาร์, มกราคม 31, 2552

วิเคราะห์ Task bar ของ windows 7 (จากภาพ)

Task bar ของ Windows XP จะใช้ยากมากเมื่อเราเปิดโปรแกรมจำนวนมาก การแก้ปัญหาโดยการรวม task bar เข้ามาไว้ด้วยกันดูจะเป็นการสร้างปัญหามากกว่า ผมใช้วิธีไล่ click ไปทีละอันแทบทุกครั้ง เพราะการอ่าน Title ของแต่ละ Task ดูจะใช้สมองมากกว่าการสุ่มเปิดทีละอัน สุดท้าย Windows 7 ออกมาแก้ปัญหาได้อย่างฉลาดมาก ผมไม่ต้องสุ่มกดอีกแล้ว

 

 วิธีการนี้ไปไกลกว่าของ OS X สิ่งที่ OS X ทำคือการกล้าที่จะตัดตัวหนังสือบน traditional task bar ทิ้ง ทำให้ icon สามารถใหญ่ขึ้นได้อีก ซึ่ง Windows 7 รับแนวคิดนี้มาใช้แล้ว แถมยังประยุกต์ของเดิมของตนเองขึ้นไปอีก แต่สิ่งทำให้รู้สึกไม่ดีบน task bar ของ windows คือความยากในการแยกระหว่างโปรแกรมที่เปิดอยู่ กับ short cut

 

 ในรูปที่เอามาแสดงดูไม่มีปัญหาอะไร เพราะเราสามารถแยกโปรแกรมออกจาก short cut ได้โดยดูจากเส้นรอบโปรแกรม ดังรูป

 

 แต่ถ้า short cut อยู่ระหว่างโปรแกรม เส้นจะช่วยเราน้อยมาก

 

สิ่งที่ทำให้เราแยกออกคือการไล่สีของ background ที่อยู่ใต้โปรแกรม ซึ่งเห็นไม่ค่อยชัดนัก ตอนนี้ทางแก้ที่พอนึกออกคือ การเพิ่มความเข้มของโปรแกรมที่เปิดอยู่ หรือเลียนแบบ OS X โดยใส่สามเหลี่ยมลงไปใต้ icon

 

 การใส่สามเหลี่ยมก็ดูจะเป็นการลอก OS X มา การเพิ่มความเข้มต้องคำนึงถึงความสวยของ icon ด้วย การที่ Windows 7 เป็นแบบนี้อาจเป็นทางที่ดีที่สุดแล้ว ถ้าต้องการให้ดีกว่านี้คงต้องคิดนอกกรอบมากขึ้น เช่น task bar ไม่จำเป็นต้องเป็นเส้นตรง เป็นต้น Note. ที่ title เขียนว่า (จากภาพ) เพราะผมยังไม่ได้เล่นของจริง เลยครับ :p

วันพุธ, มกราคม 14, 2552

Web Technology จากมุมมองของคนออกแบบโปรแกรม

มีเรื่องต้องตัดสินใจเลือกเทคโนโลยีที่จะเอาไว้ใช้ในบริษัท ต่อไปในอนาคต เลยลองวาดแผนภาพออกมาช่วยในการตัดสินใจ แต่ไหนๆ วาดแล้วเลยเอามาใส่ไว้ในนี้ด้วยเลย ในภาพจะเทียบเรื่อง Thin Client กับ Rich Client เป็นแกน โดยเอาเรื่อง Open กับ Proprietary มาประกอบ Thin Client สุดขั้ว - ต้องสามารถเปิดได้โดย web browser ทั่วไป - ใช้ HTTP สำหรับการ Request/Response - ความปลอดภัยเต็มร้อย เพราะแทบไม่ทำอะไรบนเครื่องผู้ใช้เลย - เปิดได้เร็ว ใช้ cpu น้อย ใช้ band width น้อยเหมาะกับเครื่องลูกกระจ๊อก - ให้ Server ประมวลผลแทน Rich Client สุดขั้ว - มีลักษณะเหมือนโปรแกรมที่ไม่ผ่าน web ผู้ใช้รู้สึกว่าเป็น Application มากกว่า Web - มีการประมวลผลที่ Client หรือใช้ Hardware บนเครื่อง Client ช่วย เช่น กล้อง หรือ Graphic card เป็นต้น - สามารถทำงาน offline ได้ ผมให้พื้นที่ของ AJAX และ DHTML ไว้ใหญ่มากๆ เพราะสองตัวนี้มีเทคโนโลยีที่เอามาเสริมได้มากเช่นตัว ExtJs เป็นต้น ถ้ารวบรวมแล้วคงต้องทำแผนภูมิเฉพาะของสองส่วนนี้ออกมาอีกที สำหรับฝั่ง Rich Client มีคนเข้ามาแข่งเป็นตัวๆ อย่างชัดเจน เพราะจะทำทีนึงต้องทำใหญ่ๆ ถ้าทำกะจุ๊กกะจิ๊กก็ไม่เป็น Rich Client ทางฝั่งนี้ผู้พัฒนาสบายหน่อยเพราะทุกเจ้าจะมีเครื่องมีอมาให้ครบ ทั้งตาราง ทั้งฟอร์ม แทบจะไม่ต้องเขียนเอง จะติดก็ตรงที่ความยากในการย้ายข้าง เมื่อเลือกตัวใดแล้วจะเปลี่ยนเป็นอีกตัวก็เสียดายเวลา สำหรับเรื่อง ความเปิดเผย ผมแยกแบบนี้ครับ Open สุดขั้ว - สร้างโดยมีมาตรฐานเปิด - สามารถเข้าถึง API หรือ Code ภายในได้ - เปิด Code ดูได้ มนุษย์อ่านออก Proprietary สุดขั้ว - ไม่เปิดมาตรฐานในการพัฒนาให้คนทั่วไป - ไม่เปิด Code หรือเข้าถึงได้แค่ API - Code ที่ส่งให้ User คนทั่วไปไม่สามารถอ่านได้ ผมให้ Java อยู่สูงกว่าตัวอื่นเพราะ sun เอา java open source เลยถือว่าเปิดมากกว่าคนอื่นเขา หลังจากนี้ต้องลองเทียบดูว่าผู้ใช้ของเรามีข้อจำกัดอะไร และโปรแกรมที่เรากำลังจะพัฒนาต้องทำอะไรได้บ้าง แล้วลองให้คะแนนแต่ละ technology ดู

วันเสาร์, มกราคม 10, 2552

แบบนี้สิถึงจะเรียกว่าคู่แข่ง iPhone

ตั้งแต่ iphone ออกมาก็มีหลายโปรแกรมที่พยายามบอกว่าตัวเองเป็น iphone killer แต่คู่แข่งตัวจริงพึ่งจะออกมา palm ทำออกมาได้ประทับใจทีเดียว เก็บงานได้เรียบร้อย มีความคิดสร้างสรรค์ที่เป็นของตนเองหลายจุด แต่สิ่งที่สร้างความแตกต่างมากๆ น่าจะเป็นเรื่องการเปิดโปรแกรมหลายตัวพร้อมกันทำให้แนวคิดของ interface ตัวหลักต่างกันมากๆ ผมไม่แน่ใจว่ามันเป็น multitask จริงๆ หรือแค่ save สถานะไว้ แต่อย่างไรก็ตามผมชื่นชมที่ palm ที่แก้ปัญหาเรื่อง interface ของ multitask ได้ดีมากๆ แม้ว่าจะดูคล้ายๆ กับลอก iPhone Safari มาก็ตาม สิ่งที่ผมชอบอีกอย่างคือความต่อเนื่องของ Animation ที่ผู้ออกแบบให้ความใส่ใจมาก ส่วนนี้มีมากกว่า iPhone ซะอีก ความต่อเนื่องช่วยให้ผู้ใช้เห็นความเคลื่อนไหวของ Application ที่เปิดและปิด ไม่มีค่อยมีการแว๊บขึ้นมาเฉยๆ คล้ายการ minimize/maximize ของ OS X ที่ช่วยให้ผู้ใช้เห็นที่มาที่ไปของโปรแกรมอยู่ตลอด สิ่งที่ผมไม่ชอบในเชิง usability คือการปิด application ที่ใช้วิธีดีดขึ้นข้างบน ซึ่งไม่สื่อถืงการปิดโปรแกรมและอาจจะทำพลาดได้ง่ายเพราะมีดีดไปด้านข้างด้วย มันน่าจะดีกว่าถ้าใช้มีปุ่มกากบาทอยู่ที่มุมบนของโปรแกรม เพราะเป็นการสื่อสารที่มีความหมายว่าปิดมากกว่าการดีดทิ้งไป แก้ไข: Pre ทำ multitouch ได้ครับ :) สุดยอด

พฤติกรรมผู้ใช้ที่ย้ายจาก Application มาสู่ Web

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

ผู้ใช่ที่อายุน้อยสามารถประยุกต์ใช้ tab ของ browser ในการใช้งานได้ด้วย บางกลุ่มสามารถเข้าใจระบบ URL แล้วกระโดดไปหน้าต่างๆ ได้โดยไม่ต้องกด link บนหน้า web นับว่าได้ผลเกินคาด 

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


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

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

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

ผมอยากจะบอกว่า "เว็บมันทำไม่ได้" ก็พูดไม่ได้เต็มปาก เพราะถ้าเราเขียน Java Script ระดับเทพ ได้มันก็พอทำได้น่ะนะ เช่น ตารางแบบเดิมเป็น Grid ของ VB ส่วนของใหม่เป็นแค่ table กับ text field จะให้ย่อขยาย column ตามใจชอบก็ไม่ง่ายนัก เป็นต้น อยากจะเอา ExtJS มาทำให้อย่างยิ่ง 

ผมพบพฤติกรรมแปลกๆ เช่น ผู้ใช้กด double click มันทุกปุ่มเลย แม้ว่าบน Application จะกดทีเดียว แต่พอมาใช้ web ผู้ใช้ double click มันทุกครั้ง อันนี้ไม่รู้เพราะอะไร 

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

วันจันทร์, มกราคม 05, 2552

Panasonic พยายามแก้ปัญหาของ Remote Control

แม้ว่าจะไม่ได้แก้ปัญหา Remote หาย แต่น่าจะแก้ปัญหาเรื่องปุ่มมากมายบน remote ได้ เห็นถึงความพยายาม แต่ถ้าทำเป็น wii remote หรือไม่ต้องมีปุ่มเลยน่าจะดีกว่ามากทีเดียว ที่มา: งาน Japan CEATEC 2008

กลุ่มเป้าหมายของ KDE

KDE แบ่งกลุ่มผู้ใช้ออกมาแบบนี้ทำให้การสนทนาผ่าน Mailing list ง่ายขึ้นมากทีเดียว เพราะสามารถบอกได้ว่าข้อเสนอนั้นเหมาะกับ A และต้องแก้ไขอย่างไรเพื่อให้เหมาะกับกลุ่ม B ผมตามอ่าน Usability ของ Gnome มาพักใหญ่ ข้อถกเถียงทุกอันต่างมีเหตุผล และมีข้อดีข้อเสีย แต่การให้คะแนน หรือแบ่งกลุ่มข้อดีข้อเสียกลับทำได้ยากมาก ทำให้สุดท้ายต้องตัดสินใจด้วยความรู้สึก หรือให้คนที่มีผลงานมากที่สุดตัดสิน การที่ KDE ตั้งตุ๊กตาของกลุ่มเป้าหมายเป็น 5 กลุ่ม จะเหมือนการสร้างคำศัพท์ขึ้นมาเพื่อใช้อ้างอิงตอนคุยกัน นับว่าเป็นแนวคิดที่ฉลาดมากทีเดียว แต่ปัญหาใต้น้ำที่โผลออกมาทันทีที่ตั้งตุ๊กตา 5 ตัวนี้ขึ้นมา คือความแตกต่างอันมากมายของตุ๊กตาแต่ละตัว Office Worker ไม่ชอบความตื่นเต้น Student ของง่ายๆ ควรง่าย Recreational User ปรับแต่งได้ตามใจ Decision Maker ผมเลือกใช้ของดี Geek หงุดหงิดที่อยากลอง แต่ทำไม่ได้ การจะเอาใจ Office Worker และ Geek ไปพร้อมๆ ต้องใช้ความพยายามเป็นหลายเท่า เพราะต้องมีของอยู่บนหน้าจอให้น้อยที่สุดเพื่อให้ Office Worker เข้าใจการทำงานของระบบให้เร็วที่สุด แต่นั่นทำให้ Geek หงุดหงิดทันทีเพราะสิ่งที่เขาอยากให้มีจะไม่มี หรือต้องคอยเปิดขึ้นมาเมื่อต้องการใช้ เหมือนการเอา iPhoto ไปรวมกับ Aperture หนทางยังอีกยาวไกลสำหรับ KDE ถ้าให้ลองหาทางออกผมมองว่า iPhoto ไม่ควรรวมกับ Aperture ผู้ใช้ควรมีสิทธิ์เลือกที่จะใช้ iPhoto หรือ Aperture หน้าที่ของ XServer คือช่วยให้ผู้ใช้สร้าง iPhoto หรือ Aperture ได้เอง เอาให้ง่ายขนาดนั้นเลย :D :D ที่มา: KDE Vision

วันพฤหัสบดี, มกราคม 01, 2552

User Interface with out Interface

ไปเจอ video เรื่อง Multi-touch ของ Autodesk Labs ครับ เป็น Interface แบบไม่มีเครื่องมีใดๆ อยู่บนหน้าจอ ให้เอานิ้วลองจิ้มๆ เดาๆ เอาเอง ถ้ามี iPhone Jumbo ออกมา โลกคอมพิวเตอร์คงเปลี่ยนไปน่าดู ไม่รู้ว่าผู้ใช้จะรับได้หรือเปล่า แต่น่าจะช่วยให้งานหลายๆ อย่างง่ายขึ้นอย่างเหลือเชื่อเลยล่ะครับ เพื่อนๆ ที่เจอ video ดีๆ เอามา Review กันได้นะครับ เขียนอยู่คนเดียว เหงาน่าดู

ความหมายของปุ่มในตำแหน่งที่ต่างกัน

สวัสดีปีใหม่ครับ ขอให้ทุกคนมีความสุขในการออกแบบ Application ตลอดปี 2009 นะครับ ก่อนวันหยุดยาวปีใหม่ผมบังเอิญต้อง Update Host ให้กับ User ของ Mysql ผ่าน Mysql-Admin ทำให้เจอบางอย่างน่าสนใจเข้า



ผม Add New Host ให้กับ User คนหนึ่งในระบบ หลังจากที่ผมเห็น Host ปรากฏอยู่ใต้ชื่อ User ก็สบายใจปิดโปรแกรมไป แต่กลายเป็นว่า User คนนั้นยังไม่ได้รับสิทธิ์ มาตรวจสอบอีกทีกลายเป็นว่าต้องกดปุ่ม Apply ก่อน รูปด้านบนแสดงตำแหน่งของปุ่ม Apply ของ Mysql Admin Version Widows บังเอิญว่าลืมภาพ Version Linux ไว้ที่ office ขอเอาที่หาได้บน google มาแสดงไปก่อนนะครับ ปัญหาของปุ่ม Apply ใน Version Linux และ Windows คือมันสื่อความหมายไม่ครอบคลุมพื้นที่ด้านซ้ายมือ ดังนั้นผู้ใช้อย่างผม จึงเข้าใจไปเองว่าไม่ต้องกด Apply ก็ได้ ดังรูปด้านล่าง



พื้นที่ที่ผู้ใช้รู้สึกจะเป็นกรอบสีแดง ส่วนพื้นที่การ Apply จริง คือกรอบสีเขียวทางขวามือ ทางแก้มีหลายวิธีแต่สิ่งที่น่าสนใจกว่าคือ จริงๆ แล้วมีทฤษฏีให้เราใช้อ้างอิงหรือเปล่า เนื่องจากหาไม่เจอผมเลยคิดสูตรส่วนตัวขึ้นมา ผมแบ่งปุ่มออกเป็น 3 ประเภทตามจุดประสงค์ในการใช้งาน

1. ปุ่มสำหรับการเลือก (select button) ซึ่งมักแสดงในลักษณะ tab
2. ปุ่มสั่งงาน (action button) มักแสดงเป็น icon
3. ปุ่มเสร็จสิ้นการทำงาน (done button) ส่วนมากใช้คำว่า OK, Apple หรือ Save เป็นต้น

ผมตั้งสมติฐานว่าคนส่วนใหญ่มอง GUI จากบนลงล่าง ซ้ายไปขวา ตามการอ่านหนังสือ จากนั้นลองวาดรูปดู



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



ปุ่มประเภท Action ผู้ใช้จะต้องเลือก Object ในโปรแกรมก่อน จากนั้นจึงเลือก Active ที่จะทำกับ Object นั้น เช่น Copy หรือ Delete เป็นต้น ผมคิดว่าปุ่ม Action จะอยู่ด้านไหนก็ได้ เนื่องจากผู้ใช้ยังวนเวียนอยู่ในโปรแกรมอีกหลายรอบ จึงไม่จำเป็นต้องเรียงจากซ้ายไปขวา แต่อย่างไรก็ตาม ผมมองว่าตำแหน่งของ Action ในหนึ่งโปรแกรมควรอยู่ด้านเดียวกัน ถ้าอยู่ทั่วไปหมด อาจทำให้ผู้ใช้หาไม่เจอ



ปุ่มสุดท้าย คือปุ่ม Done ซึ่งเป็นปุ่มต้นเรื่องของเรา ผมเอาปุ่มนี้ไว้ด้านล่างสุด จะชิดซ้าย ขวา หรือกลาง ก็ได้ แล้วแต่สถานการณ์ แต่จะไม่เอาไว้ซ้ายมือของกล่อง เพราะไม่เป็นที่นิยม และทำให้เกิดช่องว่างเหนือปุ่มดูขัดตามาก ผมมองว่าพื้นที่ที่ปุ่ม Done จะกินความหมายไป จะต้องอยู่เหนือตัวมัน ไม่อยู่ระดับเดียวกัน หรืออยู่ใต้ปุ่ม กลับมาดู MySql Admin ปัญหาของปุ่ม Apply ได้ถูกแก้แล้วใน Version Mac OS X



ใน version นี้กล่องด้านซ้ายมือถูกยกขึ้นทำให้ปุ่ม Apply มีความหมายกว้างขึ้น กินพื้นที่ไปถึงรายชื่อผู้ใช้ด้วย ตามจุดประสงค์ของมัน แต่ก็ยังขัดๆ อยู่นิดหน่อย ถึงแม้ว่ากล่องจะอยู่เหนื่อปุ่ม Apple แต่มีองค์ประกอบของกล่องรายชื่อผู้ใช้ยาวลงมาระดับเดียวกับปุ่ม Apply ทางที่ดีน่าจะยกปุ่ม Add User, Delete User, Add Host, Delete Host และปุ่ม Refresh ขึ้นไปอยู่ในกล่องด้านบนด้วยเลย คล้ายปุ่ม + - ของ Preference Network ในรูปข้างล่าง



ต้องปรับกันอีกเล็กน้อย ไม่รู้ว่า MySQL GUI Tools เขียนด้วย Swing, QT หรือ GTK ได้แต่หวังว่า lib ที่เค้าเลือกใช้จะรองรับ