ออกแบบ Tab บน Android (ตอนที่ 3)

ตอนที่ 1 และ ตอนที่ 2 เราพูดถึงเรื่องตำแหน่ง และ Style ในการออกแบบ Tab บน Android มาถึงตอนที่สามเราจะมาเก็บรายละเอียดกัน บางทีสิ่งที่อยู่ในตอนที่สามนี่ละ ที่เป็นหัวใจของ UX ที่สามารถนำไปใช้ได้ในทุก Platform

ข้อแรก Tab มีไว้ใช้สำหรับนำทาง (Navigation) ไม่ใช่การกระทำ (Action)

Tab ทั้ง Android และ iPhone ต่างเอาไว้สำหรับการนำทาง (navigate) ไปยังหน้าจอต่างๆ ใน App ดังนั้นไม่ควรนำปุ่มสั่งงานมาไว้ที่ Tab

ตัวอย่างการใช้ Tab ที่ผิด

ในภาพตัวอย่างจะเห็นว่านักพัฒนาเอา  Action มาปนอยู่ใน Navigation  บาง Tab ทำให้หน้าจอเปลี่ยน บาง Tab เป็นการสั่งงานไม่ได้พาผู้ใช้ไปหน้าจอไหนเลย ลักษณะนี้จะสร้างความสับสับให้ผู้ใช้ได้ครับ

Tab ต้องถูกเลือกอยู่ตลอดเวลา

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

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

การใช้ Back กับ Tab

การเปลี่ยน Tab ไม่ถือว่าเป็นการเปลี่ยนหน้าสำหรับ android ถ้าผู้ใช้กดปุ่ม Back โปรแกรมจะนำผู้ใช้ออกไปจากโปรแกรมหรือกลับไปที่หน้าก่อนหน้าที่มี Tab นี้อยู่

ที่เป็นแบบนี้เพราะว่าแนวคิดของปุ่ม Back ของ Android คือการกลับจากหน้ารองไปสู่หน้าหลัก ดังนั้นการเปลี่ยน Tab ไม่ได้ไปสู่หน้ารอง แต่เป็นการไปอีก tab หนึ่งและสามารถกลับมาหน้าเดิมได้ด้วยการกดบน Tab ไม่จำเป็นต้องใช้ปุ่ม Back

การเปลี่ยน Tab ด้วย Swipe!

บน Android 4.x ผู้ใช้สามารถเปลียน Tab ได้ด้วยการลากนิ้วมือไปทางซ้าย/ขวา จะเป็นการเปลี่ยน Tab ได้ ดังนั้นนักพัฒนาจะต้องระวังเรื่อง Transition ให้ดี ในกรณีของ iPhone เมื่อผู้ใช้กดบนหัวข้อจะเกิด Transition ว่าหน้าจอเนื้อหาไหลจากทางซ้ายเข้ามา แต่บน Android ถ้าทำแบบนั้นผู้ใช้อาจจะรู้สึกว่าอีก Tab นึงมันเลื่อนเข้ามา ซึ่งทำให้การรับรู้ผิดไป

เขียนครั้งเดียวใช้ได้ทั้งจอเล็ก จอใหญ่

เมื่อเป็นจอเล็ก Tab จะลงมาเป็นบรรทัดที่สอง แต่ถ้าเป็นจอใหญ่เนื้อที่ด้านบนมีมาก ให้เอา Tab ขึ้นไปอยู่ด้านบน นอกจากนั้นสำหรับจอใหญ่ให้เอาเนื้อหาในหน้าที่สองมาไว้ข้างขวาบนหน้าแรกได้เลย

ตัวอย่าง App ในงาน google IO

สรุปว่า

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

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

ที่มา: www.androiduipatterns.com/2012/08/tips-for-android-tabs.html

ออกแบบ Tab บน Android (ตอนที่ 2)

ตอนที่ 1 เราคุยกันเรื่องตำแหน่งของ Tab และที่มาที่ไปของแนวคิด แต่นอกจานั้นยังมีเรื่องของรูปแบบ (style) ในการออกแบบด้วย ใครที่เคยทำ Application บน Android ต้องลองย้อยกลับมาดูว่ามันยังถูกต้องอยู่หรือเปล่า ยิ่งถ้าต้องการย้ายมาอยู่บน Android 4.x ยิ่งต้องดูให้ดี

แนวทางในการออกแบบมีหลักๆ 3 ข้อ

1. Tab บน Android ไม่นิยม Icons จะใช้ Text เพื่อบอกไปเลย เหตุผลเพราะว่า การหา icon ให้ตรงกับสิ่งที่ต้องการสือให้ครบมันยากมาก ดังนั้นใช้ Text ไปเลยจะดีกว่า
2. Tab บน Android ไม่เป็นสี่เหลี่ยมจัตุรัสเพราะมันใช้ Text เท่านั้นเลยประหยัดกว่าถ้าเป็นสี่เหลี่ยมผืนผ้า
3. แนวทางของ Android จะเน้นแบนๆ ดังนั้นจึงไม่มีการใส่เงาวิ้งๆ หรือใส่แสงสะท้อน

ยกตัวอย่าง App สองตัวคือ Phone และ Foursquare สองตัวนี้มี Tab เรียบๆ แบนๆ และใช้ขีดบอกว่าตอนนี้ผู้ใช้อยู่ Tab ไหน

ตัวอย่าง Tab ที่ถูกต้องบน Android

จะเห็นว่าในโปรแกรม Phone  จะใช้ icon แทนที่จะเป็น Text อันนี้เป็นกรณีพิเศษเนื่องจากเราสามารถหา icon ที่สื่อได้ตรงและได้ครบทุก Tab จึงสามารถใช้ icon ได้

ตัวอย่างการใช้ Tab ที่ไม่เหมือนโปรแกรมบน Android

โปรแกรมตัวอย่างทั้งสองตัวนี้ทำ Tab อออกมาในลักษณะของ iPhone ทำให้ผู้ใช้ที่คุ้นเคยกับ Platform Android สับสนได้ แต่ถ้าอยากคง Brand ไว้ก็สามารถทำได้ด้วยสีของ Tab และรูปแบบการนำเสนอก็ได้ครับ ไม่จำเป็นต้องทำรูปแบบ Tab ให้เหมือนกัน

ที่มา: androiduipatterns.com

ออกแบบ Tab บน Android (ตอนที่ 1)

การออกแบบ Tab บน Android มีปัญหาอยู่หลายประเด็นมากครับ เริ่มตั้งแต่นักพัฒนาไม่ทำตาม Guideline ของ Android แต่เอา Tab ไปไว้ด้านล่างตาม iPhone หรือประเด็นว่า Tab ของ Android เปลี่ยนไป เมื่อก่อนเป็น  Tab ใหญ่ๆ เดี๋ยวนี้เป็นแบบเล็กๆ มีแต่ตัวหนังสือไม่มีรูปอย่างเดียว หรือปัจจุบัน Guide line บอกให้สามารถใช้การลากนิ้วเพื่อเปลี่ยน Tab ได้ แต่เมื่อก่อนทำไม่ได้

ตัวอย่าง Tab ในปัจจุบัน

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

ทีนี้เราลองมาดูที่มาที่ไปของ Guideline ของ Android กัน

เริ่มจากทำไม Tab ต้องขึ้นไปอยู่ด้านบน สามารถอ่านรายละเอียดได้ที่บทความ tabs-top-or-bottom โดยผมสรุปออกมาได้ 3 ข้อ

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

ตัวอย่างเปรียบเทียบงานปรับแก้ของ eurosport ที่เคยเอา Tab หลักไว้ด้านล่าง และมี Tab รองอยู่ด้านบน ทำให้ผู้ใช้ลำบากในการคาดเดาว่าตัวใดคือ Menu หลัก

 

Application eurosport เปลี่ยนจากแบบเก่าทางซ้ายไปเป็นแบบใหม่ทางขวา

หลังจากการปรับแก้ทำให้ Tab ไปอยู่ด้านบน และแปลง Menu รอง ให้กลายเป็น Filter บน Titile Bar ทำให้โปรแกรมดูง่ายขึ้น ไม่สับสนระหว่า Tab ด้านบนและ Tab ด้านล่าง

เพิ่มเติม: สำหรับคนที่พัฒนาโปรแกรมบน iPhone โดยมี Tab อยู่ด้านล่างก็ไม่ควรมี Tab ไว้ทั้งข้างบนและข้างล่างแบบ eurosport ตัวเก่านะครับ ควรจะแปลง Tab รองที่อยู่ด้านบนให้เป็น Filter บน Title bar แทน แล้วคง Tab ให้อยู่ด้านล่างแบบเดิมครับ เท่านี้ก็จะลดความสับสนได้แล้ว

ที่มา: androiduipatterns.com

ควรใช้คำว่า My Account หรือ Your Account

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

ตัวอย่าง UI ที่บางครั้งใช้ My บางครั้งใช้ Your

ถ้าดูตาม User Experience Guideline : style and tone ของ Microsoft จะบอกเรื่องบุคคลไว้ว่า ให้ใช้สรรพนามบุรุษที่สอง (you, your) เมื่อต้องการบอกผู้ใช้ว่าจะต้องทำอะไร หรือกรณีที่ละบุคคลที่สองไว้ เช่น

• Choose the pictures you want to print.
• Choose an account. (implied)

ใช้สรรพนามบุรุษที่หนึ่ง (I, me, my) เมื่อต้องการให้ผู้ใช้บอกว่าโปรแกรมต้องทำอะไร เช่น

• Print the photos on my camera.

ปัญหาของ MS Guideline คือบางกรณีจะมีทั้ง My และ Your อยู่ในหน้าเดียวกัน เช่น ในหน้าดูรายการรูป มี Label ว่า "Your photo" และมีปุ่มด้านล่างเขียนว่า "Publish my photo" ทำให้งงๆ ว่าตกลงมันเป็นของฉันหรือของคุณกันแน่ (ใครยังใช้ XP หรือ 95 อยู่ ลองสังเกตดูหน่อยครับ ว่าเค้าทำตาม Guideline นี้หรือเปล่า)

ทางที่ดีเราพยายามอย่าใช้คำว่า My หรือ Your ไปซะเลยครับ ในหน้า page นั้นๆ เราถือโดยปริยายว่า เราจะพูดกับผู้เปิดเว็บอยู่แล้ว ดังนั้นถ้าเราเขียนคำว่า Account ก็จะหมายถึง Account ของผู้อ่าน หรือถ้าเราเขียนว่า Photo ก็จะมีความหมายถึง Photo ของผู้อ่านอยู่แล้ว จะยกเว้นในกรณีที่เราต้องการแยกเนื้อหาของผู้อ่านออกจากเนื้อหาของผู้อื่น ในกรณีนั้นก็ต้องพยายามเลือกใช้คำว่า My และ Your ให้เหมือนกันทั้งหน้า หรือเลี่ยงไปใช้ชื่อไปเลยครับ เช่น Bob's photo  เป็นต้น

ถ้าให้สวย หัวข้อต่างๆ ในเว็บของเราควรเป็นหัวข้อที่สั้น กระชับ ขึ้นต้นด้วยคำที่สื่อความหมายตรงไปตรงมา เช่น Document หรือ Photos น่าจะทำให้ผู้ใช้กวาดตามองได้อย่างรวดเร็วกว่า ดังนั้นคนทำ UX ต้องคอยชั่งน้ำหนักระหว่างความยาวของคำที่เพิ่มขึ้นเทียบกันความหมายที่เพิ่มขึ้นมา บางทีคำอย่าง My หรือ Your หรือ View หรือ Manage แทนที่จะช่วยให้เข้าใจชัดขึ้น กลับสร้างประสบการณ์ที่ยากลำบากให้ผู้ใช้แทนนะครับ

ดังนั้นสำหรับการเลือก My Account หรือ Your Account ผมเสนอใช้ใช้แค่ Account และถ้ามันไปอยู่ข้่างๆ กับ Account คนอื่นผมเสนอให้ใช้ชื่อไปเลย เช่น Bob's Account เป็นต้น ครับ

เพิ่มเติม: msdn และ yahoo

แนะนำ Link: 10 must see usability videos

บน facebook.com/uxinthai คุณ Viriya Reungwai ได้แนะนำ link 10 วิดิโอเกี่ยวกับการทำ Usability Testing ครับ

หนึ่งในวิดิโอจาก 10-must-see-usability-videos

ในนั้นจะมีเรื่อง UI/UX Test ตั้งแต่ของ Google ของ Ted และอีกหลายตัวที่น่าจะเข้าไปดูครับ

คิดให้หนักถ้าจะบังคับผู้ใช้ให้ Register

วันนี้ได้ลอง App ของคนไทยตัวนึง แล้วทำให้นึกถึงวีดีโอในงาน WWDC 2012 ที่พึ่งดูมาครับ มีอยู่ตอนนึงเค้าพูดถึงการออกแบบ Application บน iPhone โดยในนั้นจะมีคำแนะนำอยู่หลายข้อ ข้อที่ผมยกมาคือ ให้ระวังเรื่องการ "Force Register" คือ การที่พอผู้ใช้เปิด App เข้ามาก็เจอปุ่ม Sign Up!  ปุ่ม Sign In เลย แทนที่จะเจอเนื้อหาที่เค้าสนใจ

ภาพตัวอย่างหน้าแรกจาก WWDC 2012

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

เพราะว่าผู้ใช้ยังไม่ได้รู้จักว่า App นี้ดีแค่ไหน เห็นใน App Store ว่าน่าสนใจก็ Download มา ถ้ามันเริ่มต้นก็ทำให้รำคาญ มันก็น่าจะหนีอยู่นะครับ

แต่เค้าก็ไม่ได้บอกว่าทุก App ไม่ควรมี Force Register เพราะ App ของงาน WWDC ก็บังคับ Login หรือพวก App ที่เป็น Client ชัดเจนถ้าไม่ Login จะใช้งานไม่ได้เลยพวกนี้ก็ต้องให้ Login ก่อน 

ผมมองว่าถ้าเค้ามีฝั่ง Server ชัดเจนอยู่แล้วเช่น Facebook, Twitter พวกนี้จะบังคับให้ผู้ใช้ Login ก่อน ก็ไม่แปลก หรือพวก Line, Path จะบังคับ Register ก่อนก็เป็นเรื่องจำเป็น แต่จะมีบาง App เช่น Fondu เป็นต้น

Fondu: Dining Journal

First launch user experience

Fondu เป็น App Social Network ด้านอาหาร มีหน้าให้ Login ก่อน ด้วย Facebook ตั้งแต่เปิดมาครั้งแรก แต่คนทำเค้ารู้ว่าจริงๆ แล้วผู้ใช้ไม่จำเป็นต้อง Login ก็สามารถอ่าน Review อาหารของคนอื่นๆ ได้ โดยกดที่คำว่า "Get a taste >" โปรแกรมก็จะนำผู้ใช้ไปที่หน้ารายการอาหาร 

ไว้ตอนที่ผู้ใช้ต้องการจะ Share หรือ Review ตอนนั้นค่อยมา Register อีกที ตอนนั้นผู้ใช้จะมีกระใจที่จะ Register แล้ว เพราะรู้จัก App นี้แล้วและมีความต้องการจะทำอะไรบางอย่างอีกต่างหาก

ทีนี้กลับมาที่ App ที่เป็นต้นประเด็นของ Post นี้

หน้าแรก และ หน้า Sign in ของ Shop*Spot

Shop* Spot เป็น App personal e-commerce ซึ่ง concept ดีมากๆ ผมแนะนำให้ทุกคน Load มาใช้ครับ แต่มันมีประเด็นเรื่อง UX นิดหน่อยตามนี้ครับ

ในหน้าแรกของโปรแกรมจะมีแถบริบบิ้นเขียนว่า Sign in ก่อน อันนี้เป็นด่านแรก ถ้าผมยังไม่มี Account อาจจะคิดว่า App นี้เป็นแบบ Member only หรือเปล่า เพราะไม่มีปุ่มให้ register และผมอาจจะกดปุ่ม Home หนีไปเลยก็ได้ 

อีกปัญหาคือตัวริบบิ้นมันไม่ได้สื่อว่ากดได้ อาจจะเป็นการบอกว่าหน้านี้คือหน้า Sign in หรือจะให้ดึงริบบิ้น ไม่ได้ให้กด สมมุติว่าเดาถูกแล้วกด Sign in เข้ามาได้ ผมจะเจอหน้า Sign in ซึ่งแบ่งหน้าจอเป็นสองส่วน ส่วนบนจะมีช่องให้ใส่ Username และ Password พร้อมปุ่ม Create account ส่วนด้านล่างเป็น Sign in ด้วย Facebook พร้อมคำอธิบายว่าไม่ต้องกลัว

หน้าจอตอน Sigin in

ผมทดลอง Sign in แต่แทนที่ผมจะกดปุ่ม Done ด้านบน ผมกลับกดปุ่ม Create account ด้วยความเคยชินว่า Form มักจะมีปุ่ม Submit อยู่ด้านล่าง มันเลยกระโดดเข้าไปหน้า Create account ต้องกดปุ่มกลับมา ถึงมามองดูว่ามีปุ่ม Done ด้านบนให้กดเมื่อพิมพ์ username และ password แล้ว

ถึงตอนนี้ผมไม่อยาก Sign in ละ เลยตัดสินใจระหว่างหนี กับ login ด้วย facebook แทน ตรงจุดนี้ในส่วนของข้อความอธิบาย Facebook ผมมองว่าควรเน้นประโยคว่า "No worry...." มากกว่า "Use Facebook account" เพราะบนปุ่มก็เขียนว่า "Sign in with Facebook" อยู่แล้ว (ลองย้อนกลับไปดูภาพด้านบน)

หลังจากเข้ามาได้ผมกลับพบว่า App ไม่ได้ใช้ข้อมูลบน Facebook ของผมมากนัก จะมีก็ Location ซึ่งอาจจะหาเอาจาก GPS แทนได้

หน้าจอหลังจาก Login

ผมจึงมองว่าน่าจะเข้ากรณีเดียวกับวีดีโอของ WWDC ว่าถ้าข้ามขั้นตอน Login/Register ไปได้ก็ดี แล้วตอนที่เค้าต้องการ Sale หรือต้องการซื้อ ค่อยมา login อีกทีก็ยังทันครับ

นอกเรื่องอีกนิดสำหรับ

นอกจากนั้นจะมีเรื่อง "ตำแหน่งของปุ่มค้นหา" "ปุ่ม Filter" "ตัว Title ของ App" "การใช้ Header ของ Table"   icon บน tab bar ที่ทำให้ผมนำไปเทียบกับปุ่มที่เป็น Disable ตอนแรกก็งงๆ ว่ามันกดได้หรือเปล่า หรือต้องกรอกข้อมูลอะไรเพิ่มก่อนหรือเปล่าจึงจะสามารถกดได้

ถ้ามีโอกาสน่าจะได้ยกขึ้นมาเป็นกรณีศึกษาอีก ผมคิดว่าการออกแบบของเค้าน่าจะมีเหตุผลรองรับอยู่แล้ว ต้องขอขอบคุณที่ทำ App ดีๆ ขึ้นมานะครับ และต้องขออภัยที่นำมาเป็นกรณีศึกษาโดยไม่ได้ขออนุญาติก่อนครับ

UX ของ Olympic 2012

Nick Haley ซึ่งเป็น Head of User Experience and Design for Sport & London 2012 ที่ BBC Future Media ได้เขียน Blog เผยเบื้องหลังการพัฒนาและออกแบบ Application และ เว็บไซต์ ทั้งบน iPhone Android และ Desktop Browser ไว้อย่างน่าสนใจ

บรรยากาศการทำงาน

Nick เล่าให้ฟังว่า Vision สำหรับ 2012 คือ "Never miss a moment" ซึ่งตอนแรกเค้าคิดจะทำเฉพาะส่วน Live Interactive Video Player แต่สุดท้ายมันขยายครอบคลุมทั้ง Olympic เลย

ตลอดเวลาที่เค้าออกแบบเว็บ Sport ของ BBC ขึ้นมาใหม่ เค้าจะมีประโยคที่เป็นแนวทางคือ "Live Beyond Live" ซึ่งในบทความไม่ได้บอกว่าเค้าทำอย่างไร แต่เค้าบอกว่าเค้าพยายามหาทางที่จะสื่อให้คนรู้ว่า content ไหนเป็น Live ตัวไหนไม่เป็น Live

สีฟ้าแสดงว่าเป็น Live

สุดท้ายเค้าเช้าสี ในการแยก โดยถ้าส่วนไหนที่มีสีฟ้า แสดงว่ามันเป็น Live และ เราแนวทางนี้ไม่ได้ใช้มันเฉพาะใน Web Desktop นะ แต่เราใช้มันบนมือถือและทีวีด้วย

Branding ของ Web Desktop, Web Mobile, iPhone, Android

รูปด้านบนแสดงให้ดูว่าแต่ละ Platform จะมีตัว Navigation ที่ใหม่เหมือนกัน ขึ้นอยู่กับแนวทางของ Platform นั้นๆ แต่ทุกตัวยังคงรักษา Branding เป็นชุดเดียวกันเสมอ นี่ก็เป็นหนึ่งในความใส่ใจของคนออกแบบ

ผมมองว่านี่เป็นอีกหนึ่งตัวอย่างของการออกแบบที่คิดมามาก และถ้าเราเข้าไปศึกษา เราจะได้ความรู้จากงานออกแบบนี้แน่นอน ดังนั้นสำหรับคนที่สนใจ สามารถเข้าไปดูได้ที่ BBC Olympic design ครับ

 ที่มา: http://www.bbc.co.uk/blogs/bbcinternet/

หน้าจอสัมผัส: แตะกับแตะค้าง

อันนี้เน้นการประยุกต์และธรรมชาติการใช้งานการแตะกับแตะค้างบนหน้าจอของ app บน iOS ชื่อ Wikipanion ไม่ได้ค่าโฆษณานะ แต่ใช้อยู่ :-P

Wikipanion เป็นโปรแกรมอ่าน วิกิพีเดีย มีความสามารถหลายอย่าง เรื่องทำไมต้องใช้ app อ่านวิกินั้นไม่ใช่ประเด็นหลัก :-P แต่สิ่งที่น่าสนใจคือตัว app เองมีการประยุกต์การแตะกับการแตะค้างไว้อย่างน่าสนใจ

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

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

แสดงการเปิดลิงก์ที่อยากอ่านในวิกิพีเดียไปยังแท็บใหม่ รอไว้อ่านทีหลัง

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

• แตะลิงก์เพื่อไปยังเนื้อหานั้น
• แตะลิงก์ค้างเพื่อเก็บลิงก์นั้นเข้าคิว

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

• แตะลิงก์เพื่อเก็บลิงก์นั้นเข้าคิว
• แตะลิงก์ค้างเพื่อไปยังเนื้อหานั้น

แตะลิงก์ Gale Crater เพื่อเก็บเข้าคิว

แตะค้างลิงก์ Gale Crater เพื่อไปยังเนื้อหาทันที

สิ่งที่น่าสนใจคือทำไม Wikipanion ถึงเลือกที่จะเปลี่ยนพฤติกรรมของผู้ใช้?

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

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

หากจะโต้วาทีเรื่องนี้ก็อาจจะต้องย้อนไปว่า พฤติกรรมการอ่านวิกิพีเดียควรจะเป็นแบบไหนถึงจะได้ความรู้สูงสุด อ่านให้จบเป็นชิ้นๆ หรืออ่านกระโดดไปกระโดดมา?

ภูเขาน้ำแข็งของ Web Usability

ก่อนที่จะเริ่มทำงานด้าน UX เราควรมีความเข้าใจในเรื่อง Usability ก่อน แล้ว Usability คืออะไร?

Usability คือการออกแบบสิ่งใดๆ ให้มนุษย์คนอื่นๆ เข้าใจมันได้ง่ายๆ

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

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

ภูเข้าน้ำแข็งของ Web Usability

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

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

สมมุติว่าเราต้องการทำ Dictionary สำหรับเด็ก เราอาจจะ Scope งานของเราไว้ที่คำไม่เกิน 300 คำ และเป็น Dictionary เรื่องของใช้ภายในบ้านเท่านั้น เป็นต้น

ตอนนี้เราจะเริ่มเห็นภาพคร่าวๆ ในหัวแล้ว แต่ยังไม่ต้องรีบวาด UI ยังมีอีกหนึ่งอย่างที่เราต้องคิด นั้นก็คือ Structure การกำหนด Structure จะต้องเริ่มจากการกำหนดองค์ประกอบในเว็บ ว่าจะมีอะไรบ้าง โดยอาศัยสิ่งที่เราคิดไว้ใน Strategy และ Scope เป็นตัวกำหนด จากนั้นนำมาวางเป็นแผนภูมิต้นไม้ โดยคำนึงถึง common sense ของกลุ่มเป้าหมายให้มากที่สุด เพื่อให้กลุ่มเป้าหมายของเราเดาได้ถูก

ที่สำคัญต้องไม่ลืมว่า Structure ไม่ใช่ Flow !!

เมื่อเราได้โครงสร้างแล้ว ก็ให้ลองวาด Skeleton กัน โดยเป้าหมายคือต้องการให้ทีมรับรู้ว่า หน้าตาหลักๆ ของเว็บจะเป็นอย่างไร แบ่งสัดส่วนอย่างไร เน้นให้ความสำคัญในส่วนไหนของหน้าจอบ้าง และแต่ละหน้าจะส่งข้อความอะไรให้กับผู้ใช้ จะใช้วิธีการวาด Storyboard, Wireframe หรือทำ Prototype ออกมาก็ได้ แต่สำคัญต้องพยายามไม่ใส่งานออกแบบ (งานด้านความสวยงาม) ลงไปในขั้นตอนนี้ ไม่อย่างนั้นเราอาจจะโดนความสวยงามหลอกเอา หรือไม่ก็โดนความสวยงามทำให้เสียดาย จนยอมลด Usability ลงก็ได้

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

ถ้าเราทำได้ตามลำดับขั้นตอนทั้ง 5 ก็มองได้ว่าเราได้ทำ web ที่มี usability ที่ดีแล้ว แต่นั้นยังไม่ใช่ User Experience ที่ดีนะครับ เพราะมันตอบโจทย์แค่สามารถเรียนรู้ได้เร็ว แต่ยังไม่ตอบโจทย์เรื่องความรู้สึก หรือ ความคาดหวังของผู้ใช้ 

แล้วถ้าต้องการให้ครอบคลุม UX เราต้องทำอย่างไร? คำตอบนี้ขอให้ติดตามใน blog นี้ต่อไปนะครับ