ออกแบบ 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