รูปแบบการนำทางบน iOS สมัยใหม่

 (frankrausch.com)
6 คะแนน โดย GN⁺ 2023-12-13 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • การนำทางในแอป iOS ต้องแยกแยะลำดับชั้น โอเวอร์เลย์ และโฟลว์ภายในวิวให้ชัดเจน เพื่อให้ผู้ใช้เข้าใจ ตำแหน่งปัจจุบัน และเส้นทางย้อนกลับ
  • รูปแบบเชิงโครงสร้างแบ่งเป็น Drill-Down, Flat, Pyramid และ Hub-and-Spoke โดยความหมายของการเปลี่ยนหน้าจอแตกต่างกัน เช่น การสำรวจแบบต้นไม้ การแบ่งด้วยแท็บ การย้ายระหว่างหน้าจอพี่น้อง และการกลับสู่ฮับ
  • โอเวอร์เลย์เป็นกลไกสำหรับดึงความสนใจ แต่ระดับการบล็อกหน้าจอด้านหลังและการกระทำที่ผู้ใช้ต้องทำจะแตกต่างกันตาม ความเป็นโมดัลและระดับแรงเสียดทาน
  • การนำทางแบบฝังควรอยู่ภายในวิวหรือโมดัลเฉพาะ และต้องออกแบบไม่ให้ การเปลี่ยนสถานะ หรือโฟลว์แบบ Step-by-Step ดูเหมือนการย้ายลำดับชั้น
  • แท็บต้องคาดเดาได้ ปุ่ม Cancel ไม่ควรทิ้งข้อมูลทันที และในแอป iOS การรักษา ขอบเขตของลำดับชั้น สถานะ และโมดัล ให้ชัดเจนเหมาะสมกว่าการย้ายไปมาอย่างไร้แบบแผน

สามแกนของการนำทางบน iOS

  • โดยทั่วไป แอป iOS มักประกอบด้วย ต้นไม้ลำดับชั้นแบบคงที่ หลายระดับ
  • การนำทางเชิงโครงสร้างมีหน้าที่ช่วยให้ผู้ใช้เข้าใจว่ามาจากไหน อยู่ตรงไหนในลำดับชั้น และจะกลับไปยังตำแหน่งเดิมได้อย่างไร
  • โอเวอร์เลย์สามารถปรากฏเหนือบริบทใดก็ได้ และอาจซ้อนทับบนโอเวอร์เลย์อื่นได้ด้วย
    • โอเวอร์เลย์แบบโมดัล จะไม่หายไปจนกว่าผู้ใช้จะทำบางอย่าง และจะบล็อกอินเทอร์เฟซด้านหลัง
    • โอเวอร์เลย์แบบไม่ใช่โมดัล จะไม่บล็อกแอป
  • การนำทางแบบฝังเหมาะกับการรวมไว้ภายในวิวหรือโอเวอร์เลย์แบบโมดัลเฉพาะ ให้สอดคล้องกับโมเดลเชิงโครงสร้างและเชิงพื้นที่ของ iOS

รูปแบบการนำทางเชิงโครงสร้าง

  • Drill-Down

    • Drill-Down คือรูปแบบการสำรวจ โครงสร้างแบบต้นไม้ ของข้อมูลผ่านรายการทีละระดับ
    • แอนิเมชันการเปลี่ยนหน้าจอสื่อถึง การเคลื่อนที่ในแนวนอน ระหว่างคอลัมน์
      • การเคลื่อนไปทางขวาหมายถึงการเข้าไปยังระดับที่ลึกขึ้นของลำดับชั้นต้นไม้
      • การเคลื่อนไปทางซ้ายหมายถึงการกลับไปยังลำดับชั้นที่สูงกว่า
    • การนำทางแบบ Drill-Down เป็นโครงสร้าง modeless ดังนั้นคำถามอย่างการบันทึกหรือไม่บันทึกจะไม่ขัดจังหวะการสำรวจลำดับชั้น
    • Navigation Bar แสดงชื่อหน้าจอปัจจุบัน และ Disclosure indicator ในแถวรายการแสดงว่าสามารถเข้าไปยังลำดับชั้นที่ลึกขึ้นได้
    • ปุ่ม Back เป็นเส้นทางที่ชัดเจนในการกลับไปยังลำดับชั้นด้านบน และหากมีพื้นที่เพียงพอ ควรใช้ชื่อหน้าจอแม่เป็นป้ายกำกับแทน “Back” ทั่วไป
    • การปัดจากขอบซ้ายของหน้าจอไปทางขวาทำหน้าที่เดียวกับปุ่ม Back
    • การใช้งานแบบกำหนดเองควรให้การเปลี่ยนหน้าจอที่โต้ตอบได้และยกเลิกได้ ซึ่งควบคุมด้วย screen-edge pan gesture เหมือนมาตรฐาน iOS
    • สำหรับภาษาที่อ่านจากขวาไปซ้าย ทิศทางการนำทางและตำแหน่งคอนโทรลจะถูก มิเรอร์ให้สอดคล้องกับทิศทางการอ่าน
    • โครงสร้างต้นไม้สามารถสร้างแบบไดนามิกเพื่อการกรองฐานข้อมูลได้
      • ในแอปเพลง สามารถ Drill-Down ไปยังอัลบั้มเดียวกันจากจุดเริ่มต้นที่ต่างกัน เช่น Artist, Album, Genre และใช้ร่วมกับอินเทอร์เฟซค้นหาได้
    • Drill-Down คือรูปแบบแปรผันแบบ หนึ่งคอลัมน์ต่อหน้าจอ ของ Miller columns สไตล์ macOS Finder

  • Flat

    • รูปแบบ Flat แบ่งลำดับชั้นที่ระดับรากและแสดงด้วย tab bar
      • บน iPad สามารถแสดงเป็น sidebar ได้
    • รายการใน tab bar ถูกคัดเลือกโดยยึดฟีเจอร์หลักของแอปเป็นศูนย์กลาง และสร้างความคาดหวังของผู้ใช้กับ mental model ต่อแอป
    • รายการหนึ่งใน tab bar จะถูกเลือกอยู่เสมอ และการเลือกที่ใช้งานอยู่จะกำหนดสิ่งที่แสดงในพื้นที่เนื้อหาหลักของแอป
    • รายการ tab bar ที่เลือกอยู่ในปัจจุบันไม่ควรถูกเปลี่ยนแบบโปรแกรมโดยไม่มีการโต้ตอบจากผู้ใช้ หรือเปลี่ยนทางอ้อม เช่น จากการแตะปุ่มอื่นในอินเทอร์เฟซ
    • tab bar จะยังคงมองเห็นได้ทั่วทั้งหน้าจอของแอป ยกเว้นกรณีถูกบังชั่วคราวด้วย modal sheet
    • แท็บอาจใช้เป็นตัวกรอง หรือเป็นจุดเข้าใช้งานที่แตกต่างกันสำหรับคอลเลกชันเนื้อหาขนาดใหญ่ เช่น คลังเพลง วิดีโอ หรือรูปภาพ
    • แต่ละเซกชันรักษา สถานะการนำทาง ของลำดับชั้นย่อยของตนเอง
    • รายการ tab bar ต้องทำงานอย่างคาดเดาได้ และไม่ควรเปิด sheet หรือเรียกใช้การกระทำ
    • เมนู Hamburger คือวิธีนำทางแบบซ่อนที่ตรงข้ามกับ tab bar

  • Pyramid

    • รูปแบบ Pyramid ช่วยให้ย้ายอย่างรวดเร็วระหว่างวิวพี่น้องในระดับลำดับชั้นเดียวกัน โดยไม่ต้องกลับไปยังหน้าจอแม่
    • ในแอปสื่อ เจสเจอร์ปัดแนวนอนมักถูกใช้เพื่อย้ายระหว่างวิวพี่น้อง
    • สามารถใช้ปุ่มได้เช่นกัน เช่น ปุ่มลูกศรเชฟรอน Next Message และ Previous Message ในแอป iOS Mail
    • แอป iOS Photos เป็นตัวอย่างของรูปแบบ Pyramid
      • แตะรูปภาพเพื่อเปิดเต็มหน้าจอ แล้วปัดซ้ายขวาเพื่อเลื่อนดูภาพที่อยู่ติดกัน
    • สำหรับคอลเลกชันขนาดเล็ก ใช้ page control เพื่อแสดงจำนวนรายการทั้งหมดและตำแหน่งของรายการปัจจุบันในบรรดารายการพี่น้อง
    • iOS App Switcher ใช้รูปแบบ Pyramid สำหรับย้ายอย่างรวดเร็วระหว่างแอป และให้การนำทางที่เร็วกว่าการผ่านหน้าจอ Home

  • Hub-and-Spoke

    • รูปแบบ Hub-and-Spoke เหมาะเมื่อมีคอลเลกชันขนาดใหญ่ที่ไม่เกี่ยวข้องกันอยู่ที่ระดับบนสุดของลำดับชั้น
    • หากต้องสลับระหว่างวิวลูกแบบเต็มหน้าจอ ต้องกลับไปยังฮับก่อนเสมอ
    • หน้าจอ Home ของ iOS คือคอลเลกชันของแอปพลิเคชันทั้งหมดที่ติดตั้งไว้ และทำหน้าที่เป็น สถานะเป็นกลาง ที่เชื่อถือได้ของระบบปฏิบัติการ
    • Home indicator ที่ด้านล่างของหน้าจอเป็น ทางออก ที่เรียนรู้ง่ายและใช้งานได้เสมอ ซึ่งพาผู้ใช้กลับไปยังอินเทอร์เฟซหน้าจอ Home ที่คุ้นเคย
    • รูปแบบนี้แทบไม่ถูกใช้ภายในแอป
      • ภายในแอปแทบไม่มีกรณีที่ต้องการการแยกส่วนอย่างแข็งแรงเท่ากับการแยกระหว่างแอปพลิเคชันในระดับระบบปฏิบัติการ

การนำทางแบบโอเวอร์เลย์

  • High-Friction Modal

    • โอเวอร์เลย์ High-Friction Modal จะบล็อกหน้าจอด้านหลังจนกว่าผู้ใช้จะตัดสินใจ เช่น sheet หรือกล่องโต้ตอบแจ้งเตือนที่มีหลายการกระทำ
    • ในการเขียนอีเมลหรือสร้างอีเวนต์ปฏิทิน จำเป็นต้องเลือกว่าจะดำเนินต่อด้วย Done หรือ Send หรือเปลี่ยนใจด้วย Cancel
    • ปุ่ม Cancel ไม่ควรทิ้งสถานะหรือข้อมูลใด ๆ โดยตรง
      • เมื่อแตะ Cancel ใน modal sheet ควรแสดงกล่องโต้ตอบยืนยันเพิ่มเติมเป็นมาตรการป้องกันเสมอ
      • ในกล่องโต้ตอบแจ้งเตือน Cancel ต้องไม่เป็นการกระทำแบบทำลายข้อมูลโดยเด็ดขาด
    • โมดัลมุ่งเน้นการทำงานเฉพาะและเป็นอิสระให้เสร็จสิ้น เช่น การเขียนอีเมลหรือเพิ่มอีเวนต์ปฏิทิน

  • Low-Friction Modal

    • Low-Friction Modal บล็อกส่วนที่เหลือของแอป เช่น sheet, menu, popover แต่ไม่บังคับให้ตัดสินใจแบบ “เลือกอย่างใดอย่างหนึ่ง”
    • ควรปิดได้ง่าย เช่น กดปุ่มปิดหรือปัด sheet ลงแล้วหายไป
    • เมื่อแตะนอก context menu หรือ popover ก็จะหายไป
    • กล่องโต้ตอบแจ้งเตือนที่มีเพียงปุ่ม OK ปิดได้ง่าย แต่ แรงเสียดทานต่ำ ไม่ได้เท่ากับ ไม่มีแรงเสียดทาน
    • ควรหลีกเลี่ยงการแจ้งเตือนที่มีการกระทำเดียวให้มากที่สุด
      • เพราะขัดจังหวะโฟลว์ของผู้ใช้ และมักแทนที่ได้ด้วยข้อความแบบ inline หรือการแจ้งเตือนแบบไม่ใช่โมดัล

  • Non-Modal

    • โอเวอร์เลย์ Non-Modal ปิดทับบางส่วนของหน้าจอ แต่ไม่บล็อกอินเทอร์เฟซด้านหลัง
    • เนื่องจากเป็นแบบไม่บล็อก จึงมีแรงเสียดทานน้อยมากหรือไม่มีเลย
    • อาจปรากฏขึ้นเพื่อตอบสนองต่อทริกเกอร์จากภายนอกแอป เช่น การแจ้งเตือนของระบบปฏิบัติการ
    • หากหายไปโดยอัตโนมัติ ควรให้ข้อมูลรอบข้างที่เหลือบเห็นได้ในทันทีโดยรบกวนน้อยที่สุด
    • โอเวอร์เลย์แบบไม่ใช่โมดัลชั่วคราวอาจมีการโต้ตอบแบบเลือกได้
      • เช่น แตะการแจ้งเตือน หรือปัดตัวแสดงระดับเสียงก่อนที่มันจะหายไปเพื่อปรับระดับเสียง
    • โอเวอร์เลย์ที่ไม่บล็อกส่วนที่เหลือของแอป และไม่ปรากฏหรือหายไปโดยอัตโนมัติ อาจเรียกว่า palette

การนำทางแบบฝัง

  • State Change

    • วิวหนึ่งอาจมีได้หลาย สถานะ
    • วิวรายการสามารถมีสถานะ empty, loading, populated ได้ โดยไม่ดูเหมือนตำแหน่งในลำดับชั้นการนำทางเปลี่ยนไป
    • ต้องตรวจสอบให้แน่ใจว่าการเปลี่ยนสถานะไม่ได้เป็นลำดับชั้นจริง ๆ และไม่ใช่โมดัล
    • การเปลี่ยนสถานะในตำแหน่งเดิมควรหลีกเลี่ยงการเปลี่ยนหน้าจอแบบเต็มจอ
    • ตัวอย่างรวมถึงโหมดแก้ไขของรายการ อินเทอร์เฟซเว็บเบราว์เซอร์ แผนที่ถนนที่แพนได้ และภาพที่ซูมได้
    • ตัวเลือกของวิวเปลี่ยนเพียงวิธีแสดงเนื้อหาโดยไม่เปลี่ยนตำแหน่งของผู้ใช้
      • การสลับระหว่าง list view และ thumbnail view คือการสลับการแสดงภาพของข้อมูลเดียวกันในบริบทเดียวกันด้วยรูปแบบที่ต่างกัน

  • Step-by-Step

    • รูปแบบ Step-by-Step เชื่อมหน้าจอชุดหนึ่งเป็นโฟลว์เชิงเส้น เช่น guided tour, โฟลว์การตั้งค่า, tutorial สำหรับ onboarding
    • กระบวนการที่ต้องป้อนข้อมูลจำนวนมาก เช่น การชำระเงินในร้านค้าออนไลน์ ก็ต้องใช้หลายขั้นตอนเช่นกัน
    • การย้ายไปข้างหน้าและย้อนกลับภายในลำดับไม่ได้เปลี่ยนระดับลำดับชั้น ซึ่งเป็นจุดที่ต่างจากรูปแบบ Drill-Down
    • ควรแสดงลำดับ Step-by-Step ภายในโอเวอร์เลย์แบบโมดัล
      • ปุ่ม Back ในบริบทนี้มีวัตถุประสงค์ต่างจากปุ่ม Back ของ Drill-Down เชิงลำดับชั้น
    • โดยปกติกระบวนการจะจบด้วยปุ่ม Done หรือ Close ซึ่งจะปิดโมดัลที่บรรจุอยู่ด้วย
    • จำนวนขั้นตอนและเส้นทางอาจเปลี่ยนไปตามตัวเลือกที่เลือก
    • Wizard และ assistant เป็นชื่ออื่นของรูปแบบนี้
    • กระบวนการ Step-by-Step อาจรู้สึกน่าเบื่อ
      • หากคาดว่าผู้ใช้จะทำบ่อย อาจพิจารณารวมหลายขั้นตอนเป็นสถานะต่าง ๆ ภายในวิวเดียว เพื่อเพิ่มความละเอียดของข้อมูลและลดการสลับบริบท

  • Content-Driven

    • การนำทางแบบ Content-Driven คือวิธีที่ไฮเปอร์ลิงก์หรือปุ่มพาผู้ใช้ข้ามไปยังหน้าหรือวิวอื่นในทันที
    • การนำทางเว็บในเบราว์เซอร์ทำงานด้วยวิธีนี้
    • ในแอป iOS ควรหลีกเลี่ยงรูปแบบนี้ ยกเว้นแอปที่แสดงไฮเปอร์เท็กซ์ เกมแบบ immersive หรือเนื้อหาไม่เชิงเส้นที่คล้ายกัน
    • หากต้องแสดงเนื้อหาไฮเปอร์เท็กซ์ในแอป อาจพิจารณารวมไว้ในอินเทอร์เฟซเบราว์เซอร์ที่มีคอนโทรลย้อนกลับและไปข้างหน้า
    • การเปลี่ยนสถานะของอินเทอร์เฟซเบราว์เซอร์ที่แยกต่างหากเข้าใจง่ายกว่าการเปลี่ยนตำแหน่งในลำดับชั้นของแอปอย่างไม่คาดคิด
    • สามารถใช้ลิงก์เพื่อย้ายระหว่างแอปได้
    • Deep Links ใช้ URL scheme หรือ Universal Links ที่เชื่อมกับโดเมน เพื่อนำผู้ใช้จากแอปหรือเว็บไซต์หนึ่งไปยังลำดับชั้นลึกของอีกแอปหนึ่ง

เอกสารอ้างอิง

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
GN⁺ 2023-12-13
ความคิดเห็นบน Hacker News

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

    • นี่คือความต่างระหว่างแอปที่ปรับให้เป็นแอปที่ดี กับแอปที่ปรับเพื่อ การมีส่วนร่วมและยอดขาย
      คล้ายกับซูเปอร์มาร์เก็ตที่เปลี่ยนตำแหน่งชั้นวางของเป็นระยะ ๆ ถ้าการนำทาง เจสเจอร์ และพฤติกรรมสม่ำเสมอ ผู้ใช้จะได้สิ่งที่ต้องการอย่างมีประสิทธิภาพเกินไปแล้วออกไปได้เร็วเกินไป
    • ผมไม่เคยเห็นแอปไหนชวนสับสนเท่า แอป Reddit ทางการ และผมก็ถือว่าสติปัญญาตัวเองอยู่ระดับปกติ
      ผมดูแลซับเรดดิตที่มีสมาชิก 30,000 คน เลยจำเป็นต้องใช้ Reddit บนมือถือให้ได้ แต่มันแทบเป็นไปไม่ได้ ทุกอย่างต้องทำหลายขั้นตอนเกินไป และไม่รู้เลยว่าตอนนี้อยู่ตรงไหน รู้สึกเหมือนขยะจริง ๆ
    • เป็นเรื่องน่าอับอายจริง ๆ ที่ Steve Huffman ทำลาย Reddit ด้วยวิธีกำจัด Apollo
      ผมเลิกใช้ Reddit ไปตั้งแต่หลายปีก่อนแล้ว แต่เรื่องนี้คือฟางเส้นสุดท้าย
    • แอป Reddit ทางการเป็นหนึ่งในไม่กี่แอปที่ผม หลงทาง อยู่เป็นประจำ
      การกลับไปหน้าหลักใช้พลังใจมากเกินไป จนผมแค่บังคับปิดแอปแล้วเปิดใหม่
    • ใน Apollo เองก็สามารถเปิดเลเยอร์อย่างซับเรดดิต โปรไฟล์ผู้ใช้ หรือโพสต์ ซ้อนกันไปได้ไม่รู้จบ จนทำให้สับสนได้เหมือนกัน
      ผ่านไปแค่ไม่กี่ชั้น ถ้าจะกลับไปหน้าจอแรกก็ต้องปัดหรือกดย้อนกลับไปเรื่อย ๆ จนกว่าจะถึง ซึ่งค่อนข้างยุ่งยาก อาจจะมีเจสเจอร์ลับอะไรสักอย่างที่ผมไม่รู้ก็ได้

  • พอเห็นคำว่า “แพตเทิร์นการนำทางของ iOS” แล้วสะดุ้งเลย มันไม่มีแพตเทิร์น และเป็นหนึ่งในสิ่งที่แย่ที่สุดของ iOS เมื่อเทียบกับ Android
    บน Android การย้อนกลับทำได้ง่ายและอาจมีได้หลายความหมาย ผมใช้ iOS มานานกว่าหนึ่งปีแล้ว แต่ยังต้องหลับหูหลับตาลองหนึ่งในสอง “แพตเทิร์น” ของการย้อนกลับ แล้วค่อยไปมองหาปุ่มในตำแหน่งที่มือเอื้อมไม่ถึง และบางครั้งก็ยังใช้ไม่ได้
    ไม่ควรปล่อยให้แพตเทิร์นเป็นหน้าที่ของนักพัฒนา แต่ควรแก้ที่ ระดับระบบปฏิบัติการ นักพัฒนาไม่อยากให้ผู้ใช้ออกจากบางส่วนของแอปอยู่แล้ว ลองกดย้อนกลับใน Instagram Reels ดูก็ได้

    • สำหรับผม จุดที่ว่า “บน Android การย้อนกลับทำได้ง่ายและอาจมีได้หลายความหมาย” นี่แหละคือหนึ่งในสิ่งที่แย่ที่สุดของ Android
      ปุ่มย้อนกลับ ไม่มีความสม่ำเสมอเลยว่ามันจะทำอะไร แม้แต่ผมที่เป็นนักพัฒนายังต้องคิดว่าในสถานการณ์หนึ่ง ๆ การย้อนกลับควรทำอะไร ควรกลับไปหน้าก่อนหน้า หรือควรขึ้นไปหนึ่งระดับในการนำทางแบบเจาะลึกก็ไม่ชัดเจน บางครั้งสองอย่างนี้เหมือนกัน แต่ก็ไม่ใช่เสมอไป
      บางทีมันขึ้นไปหนึ่งระดับในโครงสร้างการนำทาง บางทีกลับไปหน้าก่อนหน้า บางทีปิดกล่องโต้ตอบ และบางครั้งถึงกับปิดแอปไปเลย ขึ้นอยู่กับบริบทแล้วเป็นไปได้ทุกพฤติกรรม และถ้ามีหลายอย่างที่ใช้ได้ ก็ไม่ชัดเจนว่าเป็นอันไหน วิธีเดียวที่จะรู้คือกดดูแล้วดูว่าเกิดอะไรขึ้น
      ผมเกลียด องค์ประกอบ UI ที่กำกวม เวลาคลิกอะไรสักอย่าง ผมอยากรู้ว่าจะเกิดการทำงานอะไรขึ้น
    • ประสบการณ์ของ activity stack บน Android เป็นส่วนที่ผมชอบที่สุดในการออกแบบระบบ
      มันสร้างความสม่ำเสมอในระดับลึก ทำให้การนำทางไม่ลำบาก คงจะดีมากถ้า iOS มีสิ่งเดียวกันฝังมาในลักษณะเดียวกัน
      activity stack ทำงานข้ามแอป ดังนั้นแม้หลายแอปจะร่วมกันจัดการงานหนึ่ง เจสเจอร์ย้อนกลับก็จะพากลับไปยังหน้าจอก่อนหน้าทันทีเสมอ
    • ผมไม่เข้าใจว่าทำไมปุ่มย้อนกลับของ iOS ถึงกระจัดกระจายไปทั่วแบบนั้น
      บางครั้งอยู่ซ้ายบน บางครั้งซ้ายล่าง บางครั้งขวาล่าง และก็คงมีแอปที่วางไว้ที่อื่นอีก
      Android มี ปุ่มย้อนกลับระดับระบบปฏิบัติการ ที่เอื้อมถึงได้เสมอแม้ใช้มือเดียว วิธีนี้เหนือกว่ามาก
    • ประเด็นที่ว่า “ไม่ควรปล่อยให้แพตเทิร์นเป็นหน้าที่ของนักพัฒนา แต่ควรแก้ที่ระดับระบบปฏิบัติการ” ผมว่า Apple ไม่ทำเพราะในทางปฏิบัติแทบเป็นไปไม่ได้
      ตัวอย่างเช่น ถ้าสามารถเปลี่ยนเนื้อหาของ view ได้ ก็สามารถล้างเนื้อหาทั้งหมดแล้วแทนที่ด้วยเนื้อหาใหม่ทั้งหมดได้เช่นกัน ถ้าสิ่งนี้เกิดขึ้นจากการกระทำบางอย่างของผู้ใช้ โดยสาระแล้วก็เหมือนกับ “ย้ายไปหน้าจอใหม่” แต่ถ้านักพัฒนาไม่ได้ใช้การเรียก API ของระบบปฏิบัติการตามที่เสนออย่าง createNewView แล้วแค่เปลี่ยนเนื้อหาใน view ปัจจุบัน เจสเจอร์ระดับระบบปฏิบัติการก็จะไม่ทำงาน
      อย่างไรก็ตาม Apple อาจบังคับให้ต้องใช้ API ของระบบปฏิบัติการนี้เพื่อให้ผ่านการตรวจแอปได้ ถึงอย่างนั้น ผมก็ยังคิดว่าสิ่งใดคือ “view ใหม่ที่ย้อนกลับได้” และสิ่งใดคือ “view เดิมที่แค่เปลี่ยนเนื้อหา” ก็ยังมีความเป็นอัตวิสัยอยู่พอสมควร
    • เมนูแชร์ แย่มาก ผมไม่รู้ว่าคนเราควรจะเข้าใจมันได้อย่างไร
      มันแสดงรายชื่อติดต่อ แอปพลิเคชัน รายการแนวตั้ง รายการแนวนอน และรายการอื่น ๆ ด้านล่าง แถมยังต้องรู้ก่อนว่าต้องลากขึ้นถึงจะเห็น ตำแหน่งในแต่ละแอปก็ไม่เหมือนกัน และไอคอนก็ไม่มีอะไรเกี่ยวข้องกับ “แชร์” หรือ “คัดลอก/วาง” เลย
      คนที่โตมากับสมาร์ตโฟนก็ปรับตัวได้เหมือนเคย ถ้าตอนที่มันเริ่มใช้กัน คุณยังอายุไม่เกิน 40–50 ปี โดยทั่วไปก็น่าจะปรับตัวได้ ของสมัยใหม่ส่วนใหญ่ถูกออกแบบมาแย่มากและมักไม่เสถียร AppleTV ก็เป็นแบบนั้น และก็เหมือนเวลาพูดถึงการเปลี่ยนรหัสผ่าน Wi‑Fi ที่ต้องทำเพื่อเลี่ยงบั๊ก แต่ไม่รู้ว่าทำไมกดปุ่มเปิด/ปิดแล้วถึงไม่รีบูต

  • ไม่แน่ใจว่าเกี่ยวข้องมากพอไหม แต่บน Mac และตอนนี้บน iPadOS(https://useyourloaf.com/blog/ipad-customizable-toolbars/) คอนโทรลแถบเครื่องมือ ในตัวรองรับการปรับแต่งโดยผู้ใช้ในระดับสูง
    ลองใช้งานได้ในแอปเนทีฟหลายตัว รวมถึง Finder
    วิดเจ็ตในตัวที่ทรงพลังเป็นสิ่งที่ถูกประเมินค่าต่ำไปบนเดสก์ท็อป Mac และก็เป็นจุดที่น่ากังวลเมื่อ SwiftUI เข้ามาครองพื้นที่มากขึ้น มันเป็นข้อดีใหญ่ของ iOS ด้วย แต่แอปมักพยายามใส่ดีไซน์ของตัวเองมากเกินไป จึงทำให้ไม่ค่อยเด่นชัดนัก
    แต่ไม่รู้ว่าผมจำผิดหรือเปล่า แอป iOS สมัยก่อนเคยรองรับการปรับแต่งแถบแท็บเป็นค่าเริ่มต้นไม่ใช่หรือ แน่นอนว่ามันต่างจากแถบเครื่องมือ แต่การให้แก้ลำดับแท็บและเลือกได้ว่าจะแสดงแท็บไหนจริง ๆ ให้ความรู้สึกเหมือนเป็นสิ่งเทียบเท่าทางแนวคิดกับการปรับแต่งแถบเครื่องมือในตัว แต่หลายปีแล้วที่ไม่ได้เห็น
    ตามเอกสารแล้วยังมีอยู่ อยากรู้ว่ามีใครรู้จักแอปที่ยังใช้แพตเทิร์นนี้อยู่ไหม: https://developer.apple.com/documentation/uikit/uitabbarcont...
    ยังไงก็ตาม แถบแท็บก็เจ๋ง แอป Apple TV ส่วนใหญ่ที่ผมเคยใช้ใช้วิธีนี้ และประสบการณ์ที่สอดคล้องกันนั้นยอดเยี่ยมมาก

    • ในยุคแรก ๆ การสลับแท็บและใส่หรือเอาออกเฉพาะสิ่งที่ต้องการเป็นเรื่องค่อนข้างพบได้บ่อย
      จำได้ว่าในสมัยที่ Facebook ยังพอใช้ได้ อาจจะราว ๆ iOS 7 สามารถเปลี่ยนรายการอย่างแชต ฟีด การแจ้งเตือน กลุ่ม ด้วยวิธีนี้ได้
    • แอป Apple หลายตัว เช่น Apple Store และ Music ใช้ แถบแท็บ ด้านล่าง แต่ปรับแต่งไม่ได้
      แอปนอก Apple ที่นึกออก ล้วนย้ายไปใช้เมนูแฮมเบอร์เกอร์ที่ค้นหาได้ยากไปนานแล้ว
    • บน Mac อยากให้มีแอปมากขึ้นใช้ แถบเครื่องมือมาตรฐาน
      ความสามารถในการปรับแต่งดีมาก แต่แทบไม่พบในงานที่ทำเอง
    • UITabBar นั้นถูกจำกัดเรื่องการปรับแต่งอย่างน่าเจ็บปวดมาโดยตลอด แม้ในมุมโปรแกรมเมอร์ และแทบไม่มีโปรเจกต์ไหนสนใจด้านที่ให้ผู้ใช้ปรับเอง
      ผมคิดว่า Apple ล็อกหน้าตาไว้แน่นเกินไป จนสุดท้ายทำให้ทุกคนหันไปแทนที่ด้วยอย่างอื่น
    • ยังคิดถึงฟีเจอร์ที่เคย จัดเรียงแถบเครื่องมือใหม่ ได้ในแอป iOS อย่างแอป Music
      ในแท็บของ Apple Music มี 2 แท็บที่ผมไม่ใช้เลยจริง ๆ อยากให้ทำให้ไปที่เพลย์ลิสต์กับอัลบั้มได้ทันที

  • ข้อความในข้อแรกที่ว่า “การนำทางแบบเจาะลึกไม่มีสถานะ” ดูเหมือนจะกลับกัน
    หน้าจอ N ขึ้นอยู่กับสิ่งที่ทำมาก่อน และยังสามารถย้อนกลับไปตรงนั้นได้ จึงเป็นโครงสร้างที่มี สถานะเยอะมาก หากจะให้มีประโยชน์ ก็ต้องติดตามสถานะภายในจริง ๆ เช่น เนื้อหารายการขึ้นอยู่กับสถานะ N-1 ไม่อย่างนั้นคงแย่มาก
    UI ที่ไม่มีสถานะน่าจะเป็นอะไรอย่างโมดัลชั้นเดียว คือมีหรือไม่มี อย่างใดอย่างหนึ่ง โดยเฉพาะถ้าเป็นแบบชั่วคราวและไม่มีวิธี “กลับมาทำต่อ” ก็ยิ่งถือว่าไม่มีสถานะได้ชัดเจนขึ้น
    หลายปีมานี้เห็นการถกเถียงมากมายที่ใช้คำว่า “มีสถานะ” ในความหมายที่ต่างกันโดยสิ้นเชิง และช่วงหลังยิ่งเห็นเพิ่มขึ้นอย่างระเบิด ดังนั้นผมเริ่มสรุปได้ว่าแทบไม่มีใครตกลงกันได้ว่าหมายถึงอะไร และมีคนไม่มากที่ตระหนักถึงข้อนั้น
    อยากรู้ว่า UI ที่มีสถานะ สำหรับพวกคุณคืออะไร ความต่างนี้น่าสนใจ

    • เห็นด้วยว่านิพจน์ “UI ที่มีสถานะ” โดยทั่วไปคลุมเครือ แต่ในบริบทของการนำทาง มักได้ยินว่ามีการเรียกโครงสร้างแบบลำดับชั้นว่าไม่มีสถานะ และเรียก activity stack ว่ามีสถานะ
      ในโครงสร้างแบบลำดับชั้นอย่าง iOS ลูกทุกตัวต้องมีพ่อแม่เพียงตัวเดียว ดังนั้นแค่รู้หน้าปัจจุบันก็รู้ได้ว่าปุ่ม “ย้อนกลับ” จะทำอะไร ไม่ว่าคุณจะมาถึงหน้านั้นอย่างไร มันจะขึ้นไปยังหน้าพ่อแม่หนึ่งระดับในลำดับชั้น
      ใน activity stack อย่าง Android แค่หน้าปัจจุบันยังไม่พอ ต้องรู้ด้วยว่ามาถึงหน้านั้นได้อย่างไร เพราะปุ่ม “ย้อนกลับ” หมายถึงการย้อนกลับไปในประวัติ
      เว็บไซต์จำนวนมากรองรับทั้งสองแบบ ปุ่มย้อนกลับของเบราว์เซอร์มีสถานะและนำทางในประวัติส่วนตัว แต่การนำทางภายในหน้าอย่าง breadcrumb มักไม่มีสถานะ เพราะไม่ขึ้นอยู่กับเส้นทางเฉพาะที่ใช้มาถึงหน้านั้น แน่นอนว่ามีข้อยกเว้น อินเทอร์เฟซค้นหาจำนวนมาก เมื่อเข้าไปดูรายการแล้วกลับด้วยการนำทางในหน้า จะกลับไปยังคำค้นก่อนหน้า ไม่ใช่หน้าพ่อแม่ จึงถือได้ว่ามีสถานะ
    • สำหรับผม UI ที่มีสถานะ หมายถึงการที่ฟรอนต์เอนด์ใช้ตัวแปรเพื่อจัดการพฤติกรรมของตัวเอง

  • ตรงนี้เห็นถ้อยคำที่ไม่ถูกต้องอยู่จุดหนึ่ง คือส่วนที่ว่า “ปัดจากขอบซ้ายของหน้าจอไปทางขวา เท่ากับการกดปุ่มย้อนกลับ”
    ถ้าจะทำเอง นี่ไม่ควรเป็น swipe gesture แต่ควรเป็น edge pan gesture ต้องเป็นการลากแบบโต้ตอบที่ตามนิ้วและยกเลิกได้ ไม่อย่างนั้นความรู้สึกจะผิดไป

    • แอป iOS ของ X/Twitter กับแอป Reddit ดูเหมือนจะมีปัญหานี้
      บ่อยมากที่กำลังพิมพ์อะไรอย่างตั้งใจ แล้วแค่แตะโดนขอบโทรศัพท์นิดเดียว ความคิดเห็นทั้งอันก็หายไป
    • การปัดจากซ้ายไปขวาเพื่อย้อนกลับเป็นวิธีทำ “ปุ่มย้อนกลับ” ที่แย่มาก และไม่ควรทำเด็ดขาด ควรมีปุ่มย้อนกลับจริงเสมอ
      เหตุผลคือมี คนถนัดซ้าย อยู่ การเคลื่อนไหวนี้ไม่เป็นธรรมชาติและไม่สะดวกสำหรับนิ้วโป้งซ้าย จะกลับทิศทางเพื่อคนถนัดซ้ายก็ไม่ได้ เพราะถ้าอ่านจากซ้ายไปขวา การปัดไปทางขวาดูเหมือนเป็นการไปข้างหน้า ไม่ใช่ย้อนกลับ
      โดยรวมแล้วไม่ชอบการนำทางด้วยการปัด บน iOS นั้นแย่เป็นพิเศษ ปัดจากล่างขึ้นบนแล้วมีเมนูบางอย่างโผล่ขึ้นมา ซึ่งมีของสำคัญอยู่จริง แต่เวลาต้องการกลับหาไม่เจอ และตอนเลื่อนเว็บเพจก็เรียกผิดอยู่เรื่อย
      โดยทั่วไปกว่านั้น iOS เสื่อมถอยกลายเป็นระบบปฏิบัติการที่ซับซ้อนอย่างเลวร้ายและนำทางยากราวฝันร้าย และรู้สึกว่า Apple ต้องกลับมาใส่ใจ UI/UX อย่างจริงจังอีกครั้ง ปัญหาหลักดูเหมือนเป็นความคาดหวังว่ามือถือจะต้องจัดการงานจำนวนมากที่ตั้งแต่แรกมันไม่เหมาะจะทำ
    • Sailfish OS จัดการเรื่องนี้ได้ถูกต้องและสอดคล้องกันในทุกแอป
      https://sailfishos.org/
      โดยรวมรู้สึกว่ามันเรียบง่ายกว่าและดีกว่า iOS กับ Android

  • เป็นแหล่งข้อมูลที่ดีมากสำหรับคนที่มีปัญหากับซอฟต์แวร์เชิงภาพ
    ไดอะแกรม และคำอธิบายที่ชัดเจนนั้นยอดเยี่ยมมาก

  • Frank Rausch คือผู้สร้าง “V for Wiki” ซึ่งเป็นแอป Wikipedia ที่ดีที่สุด
    ดังนั้นเมื่อเขาพูดถึงดีไซน์และประสบการณ์ผู้ใช้บน iOS ก็น่าฟังทีเดียว
    https://web.archive.org/web/20211223231349/https://v-for-wik...

    • แยกอีกเรื่องหนึ่ง ผมไม่รู้ว่าเกิดอะไรขึ้นกับ V For Wiki กันแน่
      ใช้อยู่ทุกวัน แล้ววันหนึ่งจู่ ๆ ก็หยุดทำงาน พอลองหาใน App Store ก็หายไปแล้ว เสียใจมากจริง ๆ

  • อยากให้ปิดการทำงานที่ว่า “ปัดจากขอบซ้ายของหน้าจอไปทางขวาเท่ากับกดปุ่มย้อนกลับ” ได้
    เวลา เลื่อนแนวนอน บนเว็บเพจที่ไม่พอดีกับหน้าจอ มันสั่งย้อนกลับโดยไม่ตั้งใจบ่อยเกินไป

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

    • เป็นแบบนั้นมาตั้งแต่แรกแล้ว
      น่าประหลาดใจที่ทนมาได้ถึง 12 ปี ก่อนจะตัดสินใจว่าไม่ไหวอีกต่อไป

  • ตอนที่เริ่มพัฒนา iPhone ครั้งแรก ๆ คือช่วงที่ SDK อย่างเป็นทางการเพิ่งออกมา Apple เข้มงวดกับ Human Interface Guidelines มาก และเอกสารเกี่ยวกับองค์ประกอบของ UI ที่ดีและแพตเทิร์นมาตรฐานที่ควรทำตามก็ยอดเยี่ยมมาก
    แต่พอย้ายไปสู่ดีไซน์แบบ “แฟลต” สิ่งนั้นดูเหมือนจะหายไปหมดแล้ว ผมคิดว่าเหตุผลหลักคือเอกสารเหล่านั้นไม่สมเหตุสมผลอีกต่อไป
    เมื่อก่อนมันชัดเจนมาก เช่น “ทำให้การโต้ตอบของผู้ใช้มองเห็นได้ชัดเจน” แต่ตอนนี้กลายเป็น “นี่อาจคลิกได้ หรืออาจเป็นแค่ข้อความ หรืออาจต้องกดค้าง”
 
genkino 2023-12-13

สวัสดีครับ! ผมเองก็เพิ่งทราบตอนแชร์บทความนี้ให้เพื่อนร่วมงานเหมือนกันว่า ตามมาตรฐานการสะกดคำภาษาเกาหลี คำที่ถูกต้องคือ 내비게이션 ไม่ใช่ 네비게이션 ครับ ฮ่าๆ ถึงจะเป็นคำที่ถอดเสียงมาจากภาษาอังกฤษ เลยอาจจะกำกวมอยู่ว่าแบบไหนถึงจะเรียกว่าถูกต้องแน่ แต่เพราะเป็นพื้นที่ที่มีหลายคนเข้ามาอ่าน ผมเลยลองแอบคอมเมนต์ไว้เผื่อว่าจะได้ใช้ตามรูปแบบมาตรฐานกันครับ
 
xguru 2023-12-14

บทความนี้เป็นเนื้อหาที่ GPT-4 สรุปไว้ครับ ดูเหมือนว่า GPT จะใช้คำว่า "navigation" ได้ถูกต้องเป็นส่วนใหญ่ แต่บางครั้งก็ปะปนใช้ "nebigeisyeon" ด้วย ผมเลยแก้ไขไว้แล้วครับ 555