ใส่ใจกับความเท่าเทียมกัน

OS ที่ใส่ใจเรื่องความเท่าเทียมกัน จะมาพร้อมกับความสามารถด้าน Accessibility ทั้งงานด้านเทคนิค และงานออกแบบ ตัว Control ที่ออกมาจะต้องได้รับการทดสอบว่ายังสามารถทำงานได้ดีใน Accessibility Mode ด้วย เราลองมาดูตัวอย่างของ iOS กันก่อน

ตัวอย่างการกลับภาพ ขาวเป็นดำ ของ iOS

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

ตัวอย่าง Control ของ iOS จะยังคงความหมายเดิมอยู่ เช่น ปุ่ม ON/OFF ที่เป็น ON จะแสดงสีสว่างให้รู้ว่าเปิดอยู่ ส่วนที่เป็น OFF จะแสดงสีกลืนไปเดียวกับพื้นหลังให้รู้ว่ามันไม่ได้ทำงาน นอกจากนั้นตัวหนังสือก็สามารถอ่านได้อย่างชัดเจนด้วย

เช่นเดียวกัน scroll bar ผู้ใช้จะรู้ได้ทันทีว่าด้านที่เป็น value อยู่ด้านซ้ายหรือขวา โดยดูจากสีเข้ม/สว่าง ทั้งแบบที่ธรรมดาและแบบกลับขาวเป็นดำ

ตัวอย่างการกลับขาวเป็นดำของ Android

สำหรับ Android ตัว UI ก็ได้รับการออกแบบให้รองรับแล้วเช่นกัน เราจะเห็นว่าสีที่เป็น ON จะแตกต่างจากสีอื่นๆ แม้ว่าตัวหนังสือ ON/OFF จะอ่านไม่ค่อยชัด แต่ก็ถือว่าอ่านออกครับ

แต่สำหรับใครก็ตามที่คิดจะวาด controller ขึ้นมาเอง อยากให้แน่ใจว่าได้ทดสอบเรื่อง Accessibility แล้วนะครับ

 

ตัวอย่าง control ที่สร้างเอง

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

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

สุดท้ายที่อยากฝากไว้คือการทำ Accessibilty ที่ดีไม่ใช่การทำตาม Guideline เพราะ Accesibility ไม่ใช่เรื่องของ Guideline แต่มันเป็นเรื่องของคน ถ้าเราใส่ใจในความเท่าเทียมกันของคน เราจะได้ Accessibility ที่ดีมากเองครับ

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

แนะนำโปรแกรมที่ iOS Designer ควรพกติดตัว

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

วันนี้เลยมีโปรแกรมมาแนะนำหนึ่งตัวครับ ชื่อว่า LiveView

LiveView Desktop

LiveView on iTunes

เราต้องติดตั้งโปรแกรม LiveView บนเครื่องของเรา จากนั้นก็ Download โปรแกรม LiveView ลงบนอุปกรณ์ iPhone, iPad ครับ หลังจากนั้นก็ทำตามขั้นตอนเพื่อเชื่อม LiveView Desktop เข้ากับ LiveView Devise หลังจากนั้นโปรแกรม LiveView Desktop จะส่งภาพหน้าจอของเราไปยัง iPhone, iPad ให้

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

ที่สำคัญโปรแกรมนี้ฟรี :-)

แต่สำหรับใครที่อยากได้โปรแกรมที่ดูครบกว่านี้ อยากให้ทดลอง xScope Mirror ครับ ราคา 29.99$

คิดให้หนักถ้าจะบังคับผู้ใช้ให้ 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 หน้าจอแรกของ DoctorMe

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

DoctorMe เป็นโปรแกรมเพื่อการรักษาสุขภาพด้วยตัวเองบน iOS และ Android พอดีได้มีส่วนร่วมในการออกแบบ interaction และ UX ทั้งหมดของโปรแกรม

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

• อาการเฉพาะส่วนต่างๆ ของร่างกาย
• อาการที่เกิดขึ้นที่ใดก็ได้

 ร่างแรกที่ทีมทำกันออกมาทีมนึกถึงกันว่าเนื่องจากเป็นเรื่องสุขภาพเลยทำเป็นแบบนี้

DoctorMe สำหรับ iOS ร่างแรก

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

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

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

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

และรุ่นสุดท้ายที่เปิดให้ดาวน์โหลดก็เป็นรูปร่างแบบนี้

จริงๆ แล้วยังมี UX อีกหลายส่วนที่ยังไม่สมบูรณ์และกำลังคิดต่อกันอีกคือ ทำอย่างไรถึงจะแสดงเนื้อหาที่เพิ่มเข้ามาใหม่ให้เห็นได้ง่ายๆ, ในเมนู "เพิ่มเติม" มีข้อมูลโรงพยาบาลใกล้ตัว แต่เข้าถึงยาก ควรจะจัดหมวดหมู่ของการเรียงเมนูหน้าแรกใหม่ ฯ ซึ่งต้องแก้กันต่อไปจ้ะ

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

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

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