BlackBerry จัดเรื่อง UX มาอย่างดี แต่สำหรับใคร

หลังจากได้เห็น UI ของ BlackBerry PlayBook ก็พบว่าเค้าคิดมาอย่างดีเลย เก็บทุกอย่างได้เรียบร้อย ต่อยอดจากทั้งของ iPhone และ Android มาได้อีกขั้น โดยแก้ปัญหาทั้งในเรื่อง multitask และแก้ปัญหาเรื่องหน้าจอ Widget vs Icon ไปในตัว แต่ใครล่ะที่จะชอบ

ความลื่นไหลของ UI บน BlackBerry PlayBook

iPad และ iPhone มีปัญหาในเรื่องการใช้งานแบบ Multitask ไม่ใช่ว่าระบบ Multitask ของ iOS มีปัญหา แต่ปัญหาคือผู้ใช้ไม่รู้ว่ามันสลับไปมาระหว่าง App ที่เปิดเอาไว้ได้ การใช้ double tab  บนปุ่ม Home ก็เป็นเรื่องที่เหมือนซ่อนเอาไว้ ส่วนการใช้ห้านิ้วลากบนหน้าจอเพื่อสลับ App ก็มีปัญหาว่า ผู้ใช้จำไม่ได้ว่า App อะไรอยู่ทางซ้ายหรือทางขวา ทำให้ต้องลากไปเรื่อยๆ

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

PlayBook นำส่วน Multitask และ Icon มาไว้ด้วยกัน

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

หลายคนอาจจะรู้สึกว่าไม่เห็นมีอะไร ทุกอย่างก็อยู่บนหน้าจอไม่มีซ่อนเอาไว้ น่าจะง่ายขึ้นด้วยซ้ำ นั่นแสดงว่าคุณอยู่ในกลุ่มเป้าหมายของ PlayBook ครับ 

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

Firefox OS

การใช้ HTML เป็นฐานในการพัฒนาโปรแกรมบน Mobile Platform เป็นความหวังมาตั้งแต่สมัย iPhone ออกมาใหม่ๆ จน Android ออกมาก็ยังไม่ประสบความสำเร็จ โดยติดในหลายๆ เรื่อง เช่นเรื่องของการตอบสนองที่สู้ Native ไม่ได้ หรือในเรื่องของการควบคุมความสามารถต่างๆ ของ Hardward ที่ต้องตาม Native อยู่เสมอ

แต่เมื่อ WebOS ออกมาโดยใช้ HTML+JS เป็นหลัก สามารถทำงานได้อย่างรวดเร็วน่าประทับใจ และยังมี Usability ที่ดีและสวยมาก มันจึงเป็นตัวที่บอกว่าความหวังนั้นยังไม่หายไป ถึงแม้ว่าตอนหลัง WebOS จะไม่สำเร็จในอ้อมอก Palm และ HP แต่ก็มี Firefox OS เข้ามาเป็นความหวังใหม่ครับ

ถ้า WebOS เป็น Apple เจ้า Firefox OS ก็เป็น Android ในโลกของ HTML+JS ครับ

หน้าตา Firefox OS (May 9, 2012)

ข้อเสียของความเป็นเว็บคือต้องเสียเวลา Render HTML ซึ่งใช้พลังมากกว่า Native ทำให้มีโอกาสที่จะทำงานช้าสูงมาก แต่ก็แลกมาด้วยข้อดีว่ามันความยืดหยุ่นในการปรับแต่งสู. และมีความซับซ้อนน้อยกว่าสำหรับนักพัฒนา ผมอยากให้ดู video อีกอันเพื่อเปรียบเทียบว่า เพียงไม่กี่เดือนหน้าตาของ Firefox OS นั้นเปลี่ยนไปขนาดไหน

หน้าตา Firefox OS (Oct 18, 2012)

ถ้า Firefox OS ประสบความสำเร็จในด้านความเร็ว ความเสถียร และความนิยม มันจะทำให้โลกของ Usability ใน Mobile สนุกมากทีเดียว เพราะทุกคนจะได้ลองปรับแต่ง Mobile OS ไปตามใจชอบได้อย่างง่ายดายจนน่ากลัว

สิ่งที่น่าเป็นห่วงคือถ้าปรับแต่งได้ง่าย คนก็จะปรับแต่งจนผู้ใช้ต้องเรียนรู้ใหม่ทุกครั้งที่ซื้อโทรศัพท์ หรือถ้า App ไม่มีแนวที่ชัดเจนก็จะทำให้ผู้ใช้ต้องเรียนรู้ใหม่ทุกครั้งที่ติดตั้ง App ดังนั้นทีม Firefox OS ควรจะเริ่มสร้าง Interface Guideline ที่ชัดเจนมากๆ หรืออีกทางคือสร้าง App พื้นฐานให้ไปในแนวทางเดียวกัน จนนักพัฒนาสามารถจับหลักได้ แล้วพัฒนาไปในแนวทางเดียวกันครับ 

การจัดการกับภาพที่ถูกจำกัดรูปทรง

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

ตัวอย่างงานออกแบบส่วนหัวของเว็บ

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

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

ตัวอย่างงานออกแบบหัวเว็บที่ปรับแล้ว

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

อีกตัวอย่างหนึ่งคือ Banner ของ Coca-Cola

ตัวอย่าง banner ของ Coca-cola และ ข้อความที่ส่งออกไป

ในตัวอย่างจะเห็นว่าข้อความสำคัญคือทรงของขวด หยดน้ำ และคำว่า Coca-Cola ยังคงเอาไว้ครบใน Banner โดยไม่จำเป็นต้องตัดภาพทั้งขวดมาลง

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

สำหรับใครที่ต้องการรายละเอียด สามารถดูได้จาก video นี้ครับ

Video ของ Before & After เรื่อง Extreme photo cropping

เรื่องของ Graphic Design ก็ถือว่าเป็นเรื่องสำคัญมากๆ ในการทำ UX เพราะใครๆ ก็ชอบของสวยงาม ดังนั้นถ้าอยากให้ผู้ใช้รู้สึกดีก็ควรส่งมอบแต่สิ่งสวยงามให้ผู้ใช้ครับ

UX และ UI ก็เหมือนไก่กับไข่ มันเกิดพร้อมกัน

วีดีโอขำๆ เกี่ยวกับความสัมพันธ์ของ UX และ UI ครับ

ผู้ช่วยสำหรับงานออกแบบ UI ของมือถือ

ช่วงนี้ชีวิตวุ่นวาย ทำให้บทความที่เตรียมเอาไว้หมดลงอย่างรวดเร็ว ทำให้ต้องเร่งหาความรู้ใหม่ๆ มาเขียนลง ux.in.th ไม่งั้นจะหมดแรงเอาได้ :-D 

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

ตัวอย่าง Template ที่มีเตรียมไว้

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

ตัวอย่า Template สำหรับ WP7

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

ดังนั้นใครที่กำลังหมกมุ่นอยู่กับการออกแบบโปรแกรมบนมือถือ ให้รีบ Download โดยด่วนครับ

Original: Download the package

My Dropbox: pixle_outline_tapsize.zip

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

ที่มา: androiduipatterns.com, smashingmagazine.com

Traditional web หรือ Rich Internet web

ก่อนหน้านี้เว็บส่วนมากจะไม่มีลูกเล่นพิเศษ การกด Link หรือกดปุ่มใดๆ จะมีการ Refresh ทั้งหน้าจอเสมอ ซึ่งผมมองว่านั่นเป็นสิ่งที่ทำให้เว็บง่าย ทั้งการทำความเข้าใจได้เร็วและโอกาสที่จะเดาการทำงานผิดก็น้อยด้วย ผมจะเรียกเว็บแบบนี้ว่า Traditional web 

ส่วนเว็บในปัจจุบันที่สามารถทำหลายอย่างได้ในหน้าเดียว ตัวเว็บสามารถ refresh ได้เป็นจุดๆ สามารถ double click, drag & drop, right click ได้ เหมือนกับการยก Desktop Application มาไว้บนเว็บ บางทีเราเลยเรียกว่า Web Desktop Class Application หรือในที่นี้เราจะเรียกมันว่า Rich Internet Application 

ภาพเปรียบเทียบ Traditional web เทียบกับ Rich Internet App

RIA หรือ Rich Internet Application เติบโตมาจากเทคโนโลย Java Applet, Flash, SVG จนปัจจุบันเทคโนโลยี และมาตรฐานของ HTML/HTML5 พัฒนาขึ้นมาจนเราไม่ต้องใช้ plugin ทั้งสามตัวที่กล่าวมาก็สามารถทำ RIA ได้ ทำให้ผู้ใช้สะดวกสะบายขึ้นมาก เพราะไม่ต้องลงโปรแกรมเสริม

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

ตัวอย่าง RIA จาก framework cappuccino

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

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

ก่อนพัฒนาขอให้แน่ใจว่าเราเลือกรูปแบบการพัฒนา ให้เข้ากับผู้ใช้ของเราแล้ว และคุณลักษณะของโปรแกรมของเราแล้ว จึงค่อยเริ่มงานพัฒนานะครับ

กรณีศึกษาโปรแกรม calculator ของ Apple

วันก่อนเราพูดถึงแนวทาง Skeuomorphism ของ Apple แล้วก็มีตัวอย่างของ Calculator ที่เทียบระหว่างของจริง กับของที่อยู่บน iPhone ทำให้เกิดความอยากรู้ว่า โปรแกรม calculator หน้าตาแบบนี้มันเริ่มมาตั้งแต่เหมื่อไหร

Apple II, Apple II Quark, Apple II GS

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

ก็คนเรามักจะมาผิดเอาตอนจบนี่ละ เลยทำเป็นปุ่มใหญ่ๆ ซะเลย :-D (ผมเดาน่ะนะ)

แต่ไหนๆ ค้นมาแล้ว เลยเอามาใส่ให้หมดเลย

Mac OS System 1.1, 3.0 และ 4.0

Mac OS System 7, 7.5, 8.0 และ 9.0

Mac OS X Developer Preview 1, 2

Mac OS X Developer Preview 3, 4

ผมประทับใจการเปลี่ยนจาก 3 ไปเป็น 4 มากๆ ครับ ตัว version 3 จะใช้ของเท่าที่มีซึ่งไม่เหมาะ และไม่สวย แต่พอมา version 4 เราจะเห็นว่าปุ่มที่เรียงติดกัน ไม่ควรจะเด่นเหมือกับปุ่ม OK, Cancel

Mac OS X 10.1

Mac OS X Jaguar และ Panther

Mac OS X Mountain Lion และ iOS

ได้เห็นความเปลี่ยนแปลแบบนี้ก็สนุกดีครับ โดยเฉพาะตอนที่พยายามเดาว่าแต่ละความเปลี่ยนแปลงเค้าคิดอะไร และต้องผ่านอะไรบ้างกว่าจะมาเป็นตัวปัจจุบัน

ที่มามีหลายที่มากๆ แต่หลักๆ เอามาจาก guidebookgallery.org

เมื่อ Microsoft พูดถึงโลกใหม่ของ PC

คนที่พูดคือ Craig Mundie ซึ่งทำงานอยู่ที่ Microsoft's Chief Research and Strategy Officer เค้าได้พูดถึงการที่เทคโนโลยีในปัจจุบันเปิดโอกาศให้เราทำงานกับเทคโนโลยีได้อย่างเป็นธรรมชาติ และช่วยให้เราเชื่อมโยงกันมากขึ้น

วีดีโอ A New Age of Personal Computing

ดูไปก็สนุกๆ ดีครับ

ความแตกต่างของหน้า Edit ระหว่าง iOS และ Android

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

สำหรับบน iPhone คนออกแบบ User Interface อาจจะพอคิดแบบนั้นได้ เพราะมันมีรูปแบบที่เป็นที่นิยมของหน้า Edit อยู่

Apple Guideline

ในรูปด้านบนเป็นโครงสร้างหน้าจอ Edit ที่นิยมบน iPhone เราจะเห็น Title ที่อยู่ตรงกลางเพื่อบอกว่าหน้านี้คืออะไร และมีปุ่ม Cancel Done อยู่ด้านซ้ายและขวา ส่วนปุ่ม Delete จะอยู่ล่างสุด หากหน้าจอ Edit ยาวกว่าหนึ่งหน้าจอ ปุ่ม Edit จะถูกดันจนมองไม่เห็นในหน้าแรก

สำหรับ App บน iPhone เรายังพอจะบอกให้ Programmer ทำตามที่เค้านิยมกันได้ครับ แต่สำหรับบน Android เราต้องบอกให้ชัดเจนมากขึ้น เพราะยังไม่มีรูปแบบที่มาตรฐานหรือเป็นที่นิยมจริงๆ

Android Ice Scream Sandwich (Edit contact)

บน Android Ice Scream Sandwich รูปแบบข้างต้นน่าจะเป็นรูปแบบที่เป็นมาตรฐานต่อไปในอนาคต โดยปุ่ม Done อยู่ทางมุมบนขวา ส่วน Delete และ Discard จะขึ้นมาเมื่อกดปุ่ม Menu (ปุ่มที่เรียงเป็นแนวตั้งสามปุ่ม) หรือถ้าผู้ใช้กด System Back ก็จะได้ผลเหมือน Done

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

Android Gingerbread (Edit contact)

อีกรูปแบบนึงจะมีปุ่ม Cancel และ Save ติดอยู่ด้านล่าง อันนี้เป็นหน้าจอ Edit สมัย Android Gingerbread ซึ่งผู้ใช้ที่ยังเป็นรุ่นนี้อยู่จะเคยชินกับปุ่มแบบนี้ ถ้าให้ดีเราควรตรวจสอบว่าผู้ใช้ นั้นใช้ระบบอะไรอยู่และแสดงหน้าจอ Edit ในแบบที่เค้าคุ้นเคยครับ อาจจะเป็นงานหนักแต่ถ้าใครใส่ใจต่อ User Experience ของคนที่ใช้ระบบเก่า ก็ควรทำครับ

Android Tasks (Edit task)

แบบสุดท้ายเป็นตัวอย่างของโปรแกรม Tasks บน Android โปรแกรมนี้สร้างรูปแบบของหน้า Edit ขึ้นมาเอง แม้ว่าจะทำตาม Guideline ของ Android แต่ก็ไม่เหมือนหน้า Edit ของโปรแกรมที่ Google ทำขึ้นมา

ในหน้าจอนี้ผู้ใช้สามารถบอกให้โปรแกรม Save ได้สามที่ จุดที่แรกคือกดเครื่องหมาย < มุมบนซ้าย ข้างๆ โลโก้  จุดที่สองคือเครื่องหมายถูกที่มุมบนขวา จุดที่สามคือกดที่ปุ่ม system back

ถ้าผู้ใช้ต้องการลบ ให้กดที่รูปถังขยะข้างๆ เครื่องหมายกากบาท และถ้าต้องการยกเลิกการแก้ไขให้กดที่เครื่องหมายกากบาทครับ

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

สำหรับใครก็ตามที่กำลังออกแบบ User Interface อย่าลืมวาดหน้า Edit ให้ Programmer ด้วยนะครับ

อ่านเพิ่มเติมได้ที่ androiduipatterns.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 ก่อนครับ ในนั้นมีทฤษฏีที่มีประโยชน์อยู่มากมายทีเดียว

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/

ออกแบบ Mobile UI ตามแนว Print Media

บริษัท TAT (The Astonishing Tribe) ได้ทดลองออกแบบ Mobile UI โดยเลียนแบบลักษณะของงานสิ่งพิมพ์ ได้ผลมาตาม video ครับ

ผมว่าแนวทางนี้น่าสนใจมากทีเดียวครับ ก่อนหน้านี้ตอนที่เราเริ่มทำเว็บกันใหม่ๆ เราก็พยายามเอาหน้าสิ่งพิมพ์มาไว้บนเว็บเช่นเดียวกัน จนสุดท้ายเว็บก็มีแนวทางของมันเอง 

แต่สำหรับโลก Mobile จะไม่เหมือนกัน ด้วยลักษณะการถือการอ่าน จะคล้ายกับสิ่งพิมพ์พวกหนังสือ หรือนิตยสารมากกว่า ดังนั้นมันอาจจะประสบความสำเร็จก็ได้

ผมเข้าใจว่าโลกของสิ่งพิมพ์มันวิวัฒนาการมานานมาก มี best practist อยู่มากมายที่เอามาใช้ได้ทันที ถ้าเราเปิดใจเราจะสามารถรับเอาสิ่งดีๆ เหล่านี้มาไว้ใน Application ของเราได้ครับ

Microsoft แสดงหน้าจอ Metro สำหรับงาน Enterprise

หลายคนพอเห็น Theme Metro มักจะนึกว่า รูปแบบโล่งๆ แบบนี้เวลาเอาไปทำงาน Enterprise ที่มันซับซ้อนมากๆ จะออกแบบให้มันเข้ากับ Metro ได้อย่างไร

ช่วงต้นปี Microsoft เปิด video keynote บนเว็บ msconvergence.com แสดงให้เราดูว่าเจ้า Metro ก็สามารถเป็น Enterprise Application ได้เหมือนกันนะ

หน้าจอ Dashboard

หน้าจอบริหารงาน Finance แบบภาพรวม

หน้าจอรายละเอียดทาง Finance แบบสองส่วนในหน้าเดียว

หน้าจอรายละเอียดทาง Finance แบบตาราง

หน้าจอ Approve Project

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

ผมยังนึกหน้าจอตอนที่กรอก Invoice ด้วย Metro ไม่ออก แต่เท่าที่เห็นในภาพก็มีแนวโน้มจะทำได้ดีครับ

ที่มา - get-spblog.com

Outlook New look พื้นที่ทำงาน

โปรแกรม mail กลายเป็นโปรแกรมสำคัญเพื่อให้ ecosystem ของทั้่ง google, microsoft และ apple สมบูรณ์ ดังนั้นเราจึงสามารถวิเคราะห์ยุทธศาสตร์ที่แต่ค่ายวางแผนไว้ได้โดยผ่านโปรแกรม Mail ที่ทั้งสามค่าส่งออกมา

ล่าสุดทาง Microsoft ปรับปรุง Outlook เพื่อให้เข้ากับแผน "Metro" ที่ได้วางเอาไว้

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

ยิ่งหน้าจอแบบ Metro บังคับให้ Microsoft ตัดความฟุ่มเฟือยทิ้งไปทั้งหมด ไม่ว่าจะเป็น Logo Microsoft, Banner ด้านบน, Menu ที่เชื่อมไปยังบริการอื่นๆ, การ custom photo themes, ช่องค้นหาของ bing ทั้งหมดถูกตัดออกจน Outlook เรียบร้อยมากขึ้น ดูสมกับเป็น Metro และที่สำคัญคือมันช่วยลดระยะเวลาในการเรียนรู้ของผู้ใช้ลงไปได้มาก

แต่ถ้าเทียบกับคู่แข่งทั้ง Google และ Mac ผมมองว่าจุดยืนของ Microsoft เป็นจุดที่ต้องทำการบ้านหนักกว่าคู่แข่งทั้งสองมากๆ 

เมื่อลองเทียบกับ Google จะเห็นว่า Google ยังคงความเป็น web เอาไว้ และ แยกหน้าจอ Subject ออกจากหน้าจอเนื้อหา mail ทำให้สามารถแสดงข้อมูลของ Mail เยอะในแบบที่คนที่ใช้ Mail แบบ Hardcore ต้องการ

สำหรับ Apple  จะมีหน้าตาเป็น Application ชัดเจน โดยเน้นเอา Element ต่างๆ ของ Application ในไว้บนเว็บ ตัดตัวหนังสือ และคำสั่งออกไปเป็นจำนวนมาก คงเหลือไว้แต่คำสั่งที่ใช้กันบ่อยๆ อันไหนที่ไม่ค่อยได้ใช้ก็จะซ่อนเอาไว้ และจะใช้ได้ก็ต่อเมื่อเป็นผู้ใช้เริ่มเรียนรู้มากขึ้น เช่น เราสามารถเลือก mail ทีละหลายๆ อันได้ แต่ต้องกด shift หรือ control ค้างไว้ เป็นต้น Apple จึงเหมาะกับผู้ใช้ตามบ้าน ไม่ใช้คนที่ใช้ Mail จริงๆ จังๆ

จากการออกแบบที่ดูยากก็ไม่ยาก ง่ายก็ไม่ง่ายนักเราเลยเดาว่า Outlook ต้องการให้ทั้งผู้ใช้ตามบ้าน และผู้ใช้แบบ Hardcore สามารถใช้ได้ทั้งคู่ คือทั้งสองคนต้องมีความสุขกับ ​Outlook ไม่ว่าคุณจะส่ง Mail วันละแค่สองสามฉบับ หรืองานของคุณคือการส่ง mail ทั้งวัน Outlook จึงดูกึ่งๆ ไม่เป็นทั้ง Pro และ Home

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

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

Apple ให้ความสำคัญกับพื่นที่เนื้อหา Mail เป็น  50% ของจอ และแทบจะเป็นสี่เหลี่ยมจัตตุรัส แสดงว่าเน้นข้อมูลที่เป็นรูปภาพ หรือ Multimedia มากกว่า Text ทำให้คิดว่า iCloud เหมาะกับผู้ใช้บ้านๆ ที่เน้นส่งรูปหากันมากกว่า

Microsoft มีขนาดของพื้นที่น้อยที่สุด แต่ก็มีขนาดเป็นสี่เหลี่ยมเช่นเดียวกัน ก็พอจะเดาได้ว่าเน้น Multimedia เหมือนกัน แสดงว่าตั้งจะจับกลุ่มบ้านๆ ด้วย แต่ก็ไม่ได้ทิ้งกลุ่ม Pro เพราะถ้าสังเกตุในช่องแสดงเนื้อหา Mail จะมีส่วนที่เป็นข้อมูลประกอบ Mail สูงเป็น 1 ใน 5 ของเนื้อที่เลยทีเดียวครับ

ผมไม่แน่ใจว่า Default ของการแสดงผลบน Outlook เป็นแบบในภาพ หรือเป็นแบบสลับ list กับ detail แต่อย่างไรก็ตามเมื่อ Microsoft คิดจะจับทั้งสองตลาดจึงต้องทำการบ้านมากกว่าอีกสองค่าย และต้องคิดให้หนักเพื่อที่จะซ่อน feature จากกลุ่มผู้ใช้ตามบ้าน และแสดง feature เหล่านั้นกับกลุ่ม Pro 

ส่วนตัวผมมีความสุขกับการใช้ gmail เพราะมี function ครบและ function ต่างๆ มันกระจายอยู่ตาม content ที่มันจะ action ด้วย จึงทำให้หาง่าย ติดที่มันให้พื้นที่ใช้งานน้อยมากทำให้ขัดใจอยู่เสมอโดยเฉพาะตอนดูรูป ส่วนของ mac ผมสามารถใช้ Application ได้สะดวกกว่า จึงไม่ค่อยเปิด iCloud ขึ้นมาใช้ครับ