ทำไม NEXUS ถึงไม่มีช่องให้ใส่ SD

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

หน้าตาของ NEXUS7

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

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

แต่พื้นที่มันมีจำกัดนี่นา ถ้าไม่มี SD แล้วจะเก็บข้อมูลไว้ที่ไหน คำตอบก็ไม่ยากครับ บริการ Cloud ไงละ บริการมากมายทั้ง ของ Google ของ Amazon ของ Box หรือที่อื่นๆ สามารถเก็บภาพได้แนบเนียนกว่า SD มากๆ ยิ่งเป็นของ Google+ ผู้ใช้แทบไม่ต้องรู้จักเรื่อง File หรือ Folder เลย อย่างมากก็คือภาพนี้อยู่บน Internet แล้ว หรืออาจมองข้ามไปว่า "รูปอยู่ในอัลมับครอบครัว บน Google แล้ว"

การที่ NEXUS 7 ไม่มีช่องใส่ SD แสดงให้เห็นกลายๆ ว่าอาณาจักรของ Android เริ่มขยับออกจากการขาย Feature มาเป็นการขาย User eXperience แล้ว

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

UX ใหม่ของ Android ผ่าน Sharp

ไม่ใช่ข่าวใหม่ครับ แต่ช่วงนี้ผมกลับมาศึกษา UX ของ Android มากขึ้น เลยลองไล่ดู Android รุ่นต่างๆ จนมาถึงของ Sharp

Video อธิบาย UX ของ Sharp เป็นภาษาอังกฤษ

ตัว UX ของ sharp น่าสนใจมากครับ แก้ปัญหาหลายอย่างของ Android ได้เลยครับ แม้ว่าพอมาถึง Android 4 จะต้องคิดกันใหม่ก็ตาม แต่สิ่งที่อยากจะให้ดูไม่ใช่ตัว UX ใหม่ครับ ผมอยากให้ลองดูตัว Video ที่ใช้นำเสนอของภาษาอังกฤษ เทียบกับภาษาญี่ปุ่น

Video อธิบาย UX ของ Sharp เป็นภาษาญี่ปุ่น

ผมยังไม่สามารถอธิบายได้ว่าเพราะอะไร แต่ Video ที่เป็นภาษาญี่ปุ่น ดูมีชีวิตมากกว่า ดูใช้ความคิดในการนำเสนอ ช่วยให้เราบริโภคได้ง่ายขึ้น ไม่ใช่แค่การเรียกร้องความสนใจ แต่เป็นการอธิบายที่ทำให้ผมอยากใช้ sharp ขึ้นมาทันที แม้ว่าจะฟังภาษาญี่ปุ่นไม่ออกก็ตาม

ถ้าใครพอนึกออกว่าประเด็นความต่างอยู่ตรงไหน ลองแลกเปลี่ยนกันดูนะครับ

เมื่อแนวทางออกแบบของ Apple ถูกท้าทาย

Apple ยึดแนวทางออกแบบ Application ให้เหมือนของจริงมาตั้งแต่ไหนแต่ไร แต่จะมาชัดมากๆ ก็ตอนที่ทำ iPhone iPad โดย Apple บอกในเอกสาร Human Interface Guideline ว่า

When virtual objects and actions in an application are metaphors for objects and actions in the real world, users quickly grasp how to use the app. The classic example of a software metaphor is the folder: People put things in folders in the real world, so they immediately understand the idea of putting files into folders on a computer.

ดังนั้น App ต่างๆ ที่ Apple พัฒนาออกมาจึงมักจะทำให้เหมือนกับเอาของสิ่งนั้นนั้นมาใส่ไว้ใน iPhone, iPad เพื่อให้ผู้ใช้สามารถเดาได้ว่า App นั้นๆ ทำมาเพื่ออะไร และอาจจะได้ยาวไปถึงว่ามันทำงานอย่างไรด้วยเลย

โปรแกรม Calculator เลียนแบบทั้งสีและตำแหน่ง

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

ตัวอย่างเว็บที่ทำเหมือนของจริง

และมีอีกกลุ่มที่คิดว่าแนวทาง Skeuomorphism อาจจะถูก แต่แนวทางของ Apple มันสุดโต่งเกินไป หรือไม่ก็คิดว่าแนวทาง Skeuomorphism นั้นผิด กลุ่มนี้จะถูกเรียกว่า Anti-skeuomorphism ซึ่งมีมากขึ้นเรื่อยๆ โดยเฉพาะเมื่อ Microsoft กล้าฉีกตัวเองออกไปจากแนวทางนี้

ปุ่มใน Windows 7 และ Window 8

หลังจาก Windows 8 ออกมา Microsoft ก็ถือว่าเป็นผู้นำคนสำคัญของกลุ่ม Anti-skeuomorphism แม้ว่าตอนแรกจะบอกว่าตนเองเลียนแบบป้าย Metro มาก็ตาม แต่สุดท้ายก็ถือว่าเป็นการฉีกแนวทาง Skeuomorphism แบบ Apple ไปได้

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

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

หน้าจอโปรแกรม Note ของทั้ง 3 platform

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

ถ้าสนใจเรื่องนี้อ่านเพิ่มเติมได้ที่

• medialoot.com
• fastcodesign.com
• webdesign.tutsplus.com
• usabilitycounts.com

4 อย่างที่ห้ามพลาด เมื่อย้ายจาก iOS ไปออกแบบ App บน Android

แต่ละ Platform ต่างก็มี Guideline เป็นของตนเองครับ สำหรับ Android ดูเหมือนจะพึ่งเริ่มนิ่ง ตอนนี้เลยเป็นเวลาที่เหมาะมากที่จะมาวิเคราะห์กันครับ

สำหรับคนที่ออกแบบ App บน iOS มาก่อน ผมมองว่าวินาทีนี้ Concept สำคัญที่ต่างกันมากๆ ระหว่าง iOS กับ Android ก็ตรงที่ Android เน้นให้ออกแบบทีเดียว ทำงานได้กับ Device ทุกแบบ ส่วนของ iOS จะเน้นให้ออกแบบ App ให้เหมาะกับแต่ละ Device (ซึ่งมีแค่ iPad กับ iPhone) เลยทำให้การออกแบบบน Android จะมีเงื่อนไขเรื่องการปรับเปลี่ยนหน้าจอแบบอัตโนมัติเข้ามาด้วย

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

ทีนี้เท่าที่ผมลองไล่ดู มี 4 อย่างที่คนทำ iOS มาก่อนควรทำความเข้าใจ และระลึกอยู่เสมอเวลาที่ออกแบบ App บน Android ครับ

1. Tab ของ Android อยู่ด้านบน

การลากนิ้วเพื่อเปลี่ยน Tab

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

2.  Android มีปุ่ม Back และ ปุ่ม Up โดยปุ่ม Back จะของเป็นของ System อยู่ด้านล่าง ส่วนปุ่มที่อยู่ในตำแหน่ง Back ของ iOS เราจะเรียกว่าปุ่ม Up

แสดงการทำงาน และตำแหน่งของปุ่ม Back และ Up

ในรูปแสดงการทำงานของโปรแกรม Mail โดยเริ่มที่หน้าแสดงรายการจดหมาด เมื่อมีการกดที่จดหมายฉบับใด โปรแกรม Mail จะแสดงหน้าเนื้อหาของจดหมายนั้น และผู้ใช้สามารถกด next เพื่อดูจดหมายถัดไปได้ หากกดปุ่ม Back ที่อยู่ด้านล่าง โปรแกรม Mail จะแสดงจดหมายหน้าที่ผ่านมา แต่ถ้ากดปุ่ม Up ที่อยู่ด้านบน โปรแกรมจะกลับไปหน้า แสดงรายการจดหมาย ต่างจากโปรแกรม iOS ที่ปุ่มด้านบนทำหน้าที่เป็นปุ่ม Bak

3. การจัดวางตำแหน่งบน Toolbar

ตำแหน่งต่างๆ บน toolbar

 บน iOS ตัว Toolbar ด้าย ซ้ายมักจะเป็นการกลับไปหน้าก่อนหน้า หรือหน้าด้านซ้ายมือ ส่วนด้านขวาจะเป็น Action สำหรับ page นั้นๆ เช่น Add, Filter, Edit เป็นต้น ส่วนตรงกลางจะแสดงชื่อของหน้านั้นๆ

แต่ของ Android จะเรียงไม่เหมือนกันครับ (1) ด้านซ้ายมือของ Android จะแสดง icon ของ App เพื่อบอกผู้ใช้ว่ากำลังใช้ App อะไรอยู่ (2) ถัดจาก icon จะยังชิดซ้ายเหมือนกัน คือ ช่องที่ใช้เลือกและแสดงว่าตอนนี้ข้อมูลที่แสดงอยู่ด้านล่างเป็นข้อมูลอะไร (3) ชิดขวาจะเป็น Action ของเนื้อหาด้านล่าง (4) เป็น Menu เพิ่มตามถ้าพื้นที่แสดง Action ไม่พอ

การแสดง Toolbar บนหน้าจอต่างๆ

ในกรณีที่พื้นที่แสดง Action ไม่พอเราจะดันให้มาอยู่ด้านล่าง ดังรูปครับ

4. ถ้าคิดจะทำ UI Element เอง ให้คิดให้หนักๆ ไม่ใช่ว่าของ iOS จะคิดน้อย เพราะต้องคำนึงถึง Accessibility และ พฤติกรรมของตัว Element นั้นๆ แต่ของ Android นั้นอาจจะถึงขั้นไม่สามารถคิดได้ เพราะนักพัฒนาจะต้องทำให้ Element ที่ตัวเองสร้างขึ้นมาสามารถทำงานบนอุปกรณ์ที่แตกต่างกันให้ได้ และอาจจะต้องรองรับอุปกรณ์ที่ยังไม่มีในปัจจุบัน

ตัวอย่างตำแหน่งของ Menu บนอุปกรณ์ที่ต่างกัน

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

ทั้งนี้ใครต้องการจะรู้รายละเอียดเพื่อออกแบบ App บน Android ให้เข้ากับ Ecosystem ของมัน แนะนำให้อ่าน android pattern ครับ ส่วนใครที่ยังไม่เคยออกแบบบน iOS ผมแนะนำว่าก่อนจะอ่าน Android ควรลองอ่าน HIG ของ iOS ก่อนครับ ในนั้นมีทฤษฏีที่มีประโยชน์อยู่มากมายทีเดียว