Mark Zuckerberg เคยกล่าวไว้ว่า “ความผิดพลาดที่ใหญ่ที่สุดที่เราทำในฐานะบริษัทคือการเดิมพัน HTML5 มากเกินไปเมื่อเทียบกับ Native… เพราะมันไม่ได้อยู่ที่นั่น และไม่ใช่ว่า HTML5 ไม่ดี ฉันตื่นเต้นกับมันในระยะยาวจริงๆ” และใครจะไม่ตื่นเต้นกับโอกาสของ ฐานรหัสเดียวที่ทำงานข้ามแพลตฟอร์มต่างๆ ได้

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

• คู่มือสำหรับผู้เริ่มต้นใช้งานเว็บแอปแบบก้าวหน้า
• การสร้างบล็อกของเว็บแอปโปรเกรสซีฟ
• การสร้างเว็บแอปที่สมบูรณ์ในพื้นฐานสำหรับแอป

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

สำหรับลูกค้าของเรา Beyond the Rack ซึ่งเป็นผู้ค้าปลีกอีคอมเมิร์ซออนไลน์เท่านั้น เป้าหมายหลักของเราคือการสร้างแอปที่มีประสบการณ์ผู้ใช้ที่ยอดเยี่ยม เช่นเดียวกับ Zuckerberg เราต้องการใช้เส้นทาง HTML5 — วิธีการ "เขียนครั้งเดียว เรียกใช้ได้ทุกที่" สำหรับแอปที่เขียนด้วยอินเทอร์เฟซเว็บ HTML5 นั้นมีความน่าสนใจอย่างยิ่ง แต่ในโลกปัจจุบันที่แอปกลายเป็นวิธีหลักที่ผู้ใช้โต้ตอบกับผลิตภัณฑ์ของคุณ ประสิทธิภาพไม่ได้เป็นเพียงสิ่งที่ดีที่จะมีเท่านั้น แต่ยังเป็นข้อได้เปรียบทางการแข่งขันอีกด้วย

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

กล่าวโดยย่อ อย่าเลือกระหว่างอินเทอร์เฟซดั้งเดิมและเว็บ ใช้ทั้งสองอย่าง

ในงานชิ้นนี้ ฉันจะแนะนำคุณผ่านประสบการณ์ของเราในการสร้างแอปสำหรับ Beyond the Rack ซึ่งเราผสมผสานเนื้อหาแบบเนทีฟและเนื้อหาเว็บเพื่อสร้างแอปที่ "ให้ความรู้สึก" แบบเนทีฟ

กรณีศึกษา: การสร้างแอปเพื่อสิ่งที่เหนือกว่าแร็ค

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

เราตระหนักดีว่าในการสร้างแอปที่ยอดเยี่ยม เราต้องทำงานที่ยอดเยี่ยมด้วยสามสิ่งต่อไปนี้:

• อินเทอร์เฟซการช้อปปิ้ง
  Beyond the Rack เป็นผู้ค้าปลีกออนไลน์เท่านั้น ดังนั้นการมีอินเทอร์เฟซที่ยอดเยี่ยมสำหรับการเรียกดูการขายและการซื้อจึงเป็นสิ่งสำคัญ เนื่องจากเรากำลังสร้างแอปที่มาพร้อมเครื่อง เราจึงมีโอกาสที่จะก้าวไปไกลกว่าที่ประสบการณ์บนเว็บจะมอบให้ได้
• ความสามารถในการแบ่งปัน
  เนื่องจากตัวขับเคลื่อนรายได้จำนวนมากสำหรับ Beyond the Rack คือลูกค้าที่แบ่งปันรายการขายต่างๆ กับเพื่อน เราจึงต้องตรวจสอบให้แน่ใจว่าการแบ่งปันระหว่าง iOS, Android และเบราว์เซอร์จะราบรื่นที่สุด
• การค้นพบได้
  Beyond the Rack มอบการขายแบบจำกัดเวลาให้กับผู้ใช้ ดังนั้น การติดต่อผู้ใช้อย่างรวดเร็วจึงเป็นสิ่งสำคัญมาก การส่งข้อความแบบพุชเป็นวิธีที่ดีที่สุดในการดึงดูดลูกค้าประจำเหล่านั้น และท้ายที่สุดก็เป็นแรงผลักดันที่สำคัญที่สุดในการตัดสินใจสร้างแอป

มาเจาะลึกว่าเราสร้างคุณลักษณะที่สำคัญที่สุดบางอย่างของแอป Beyond the Rack สำหรับ iOS และ Android กันอย่างไร: คุณลักษณะใดของแอปที่สร้างขึ้นโดยใช้เทคโนโลยีเว็บ คุณลักษณะใดบ้างที่มาพร้อมเครื่องโดยสมบูรณ์ และวิธีทำงานร่วมกันทั้งหมด

อินเทอร์เฟซการช็อปปิ้ง

The Native Bits

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

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

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

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

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

แอปอื่นๆ จำนวนหนึ่งใช้ประโยชน์จากองค์ประกอบการนำทางดั้งเดิมเพื่อให้สอดคล้องกับรูปแบบการออกแบบระบบปฏิบัติการ ลองดูรูปภาพของแอพ Android ของ Basecamp ซึ่งใช้ประโยชน์จากแถบการนำทางดั้งเดิม:

เปรียบเทียบแอพของ Amazon กับเว็บไซต์บนมือถือ:

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

นี่อาจเป็นเรื่องแปลกใจสำหรับหลาย ๆ คน แต่นักพัฒนาแอพ Facebook ยังค้นหาจุดที่น่าสนใจอย่างต่อเนื่อง ใช้ประโยชน์จากเนทีฟหรือเว็บเมื่อเหมาะสมกับแต่ละฟีเจอร์ ตามบทความที่เขียนโดยวิศวกรของ Facebook: “สำหรับพื้นที่ภายในแอพที่เราคาดว่าจะทำการเปลี่ยนแปลงบ่อยขึ้น เราจะยังคงใช้โค้ด HTML5 ต่อไป เนื่องจากเราสามารถผลักดันการอัปเดตฝั่งเซิร์ฟเวอร์โดยไม่ต้องให้คนดาวน์โหลดแอปเวอร์ชันใหม่ ” ดูเหมือนว่า Facebook จะใช้แนวทางเดียวกันกับที่นี่: เลือกเทคโนโลยีสำหรับแต่ละคุณสมบัติตามประสิทธิภาพ ความพยายามในการพัฒนาที่จำเป็น และความรวดเร็วในการนำออกจากระบบ

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

เว็บบิต

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

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

เว็บไซต์จะต้องสามารถตรวจจับบริบทของแอปได้ในสามที่: CSS, JavaScript และเซิร์ฟเวอร์ เราสร้างคลาส app เพื่อเขียน CSS แบบมีเงื่อนไขและเมธอด isRunningInApp เพื่อเขียน JavaScript แบบมีเงื่อนไข และเราผนวก App เข้ากับเอเจนต์ผู้ใช้สำหรับลอจิกฝั่งเซิร์ฟเวอร์แบบมีเงื่อนไข

ตัวอย่างที่เราใช้การปรับปรุงแบบก้าวหน้าภายในแอพนั้นอยู่บนหน้าแสดงผลิตภัณฑ์ของเรา เราปรับให้เหมาะสมโดยการเพิ่มปุ่ม "หยิบใส่ตะกร้า" ในตำแหน่งคงที่สำหรับแอปเท่านั้น:

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

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

ความสามารถในการแบ่งปัน

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

การทำให้เนื้อหาสามารถแชร์ระหว่างเว็บและแอปอาจเป็นเรื่องยาก เพื่อให้สำเร็จ คุณจะต้องจับคู่ลิงก์แอปและลิงก์ของเว็บ นี่เป็นเรื่องน่าปวดหัวในช่วงที่มีการตอบสนองล่วงหน้า เมื่อเปิด URL เดสก์ท็อปจะนำคุณไปยังหน้าแรกของ URL อุปกรณ์เคลื่อนที่ เนื่องจากมีการเปลี่ยนเส้นทางและอื่นๆ ทุกวันนี้เราเห็นปัญหาเดียวกันนี้กับแอพ — แบนเนอร์ใน Safari และ Chrome ขอให้คุณเปิดลิงก์ในแอพ เฉพาะแอพที่ไม่แสดงสิ่งที่คุณกำลังมองหา ปล่อยให้คุณค้นหามันใหม่ทั้งหมดอีกครั้ง โชคดีที่การจัดการลิงก์ของเว็บในแอป Beyond the Rack นั้นง่ายมาก เพราะสิ่งที่เราต้องทำคือโหลด URL นั้นในมุมมองเว็บ เราแค่ต้องตรวจสอบให้แน่ใจว่าลิงก์ของเว็บนำผู้ใช้ไปยังแอปแทนเบราว์เซอร์

บน Android การเปิด URL ในแอปทำได้ง่าย คุณเพียงแค่ต้องตั้งค่าตัวกรองเจตนาเพื่อโหลดแอปทุกครั้งที่ผู้ใช้พยายามโหลด URL ที่ระบุ (ในกรณีของเรา www.beyondtherack.com ) เมื่อติดตั้งแอปแล้ว ผู้ใช้จะมีตัวเลือกในการเปิด URL ในแอปหรือในเบราว์เซอร์:

iOS มีเส้นทางที่ค่อนข้างยากในการเปิดใช้ URL ของเว็บให้เปิดในแอปได้โดยตรง ก่อนหน้านี้ iOS อนุญาตให้คุณลงทะเบียนสคีมาของแอปสำหรับแต่ละแอปเท่านั้น (เช่น beyondtherack:// ) เนื่องจากไม่สามารถทราบได้ว่าแอปใดติดตั้งไว้ ทางเลือกเดียวคือเปิดลิงก์ที่กำหนดใน Safari จากนั้นให้พยายามเปิดลิงก์นั้นในแอป สิ่งนี้มาพร้อมกับความรำคาญเล็กน้อย: หากไม่ได้ติดตั้งแอปไว้ ผู้ใช้จะได้รับข้อความแสดงข้อผิดพลาดที่น่ารำคาญว่า “Safari ไม่สามารถเปิดเพจได้เนื่องจากที่อยู่ไม่ถูกต้อง” โชคดีที่การแฮ็กทำให้คุณสามารถระงับข้อผิดพลาดนั้นได้โดยใช้ iframes หากคุณต้องการสนับสนุนการเชื่อมโยงในรายละเอียดบน iOS 8 นี่เป็นตัวเลือกที่ดีที่สุด

โชคดีที่ iOS 9 ได้เปิดตัวการเชื่อมโยงแบบสากล ซึ่งช่วยให้แอปสามารถสกัดกั้นลิงก์ของเว็บได้ก่อนที่ลิงก์จะผ่าน Safari ## ความสามารถในการค้นพบได้ทันเวลาเป็นสิ่งสำคัญอย่างยิ่งสำหรับบริษัทอย่าง Beyond the Rack ตามเนื้อผ้า วิธีการหลักของบริษัทในการแจ้งลูกค้าเกี่ยวกับการขายคือผ่านแคมเปญอีเมล แต่ด้วยแอป มันสามารถ **สื่อสารโดยตรงกับลูกค้าเกี่ยวกับการขาย** ซึ่งมีประสิทธิภาพมาก (แน่นอนว่าการแจ้งเตือนแบบพุชกำลังเข้ามาในเบราว์เซอร์อย่างช้าๆ โดยมี [Chrome เป็นผู้นำค่าใช้จ่าย](https://gauntface.com/blog/2014/12/15/push-notifications-service-worker) แต่สำหรับอุปกรณ์ Android รุ่นเก่า และสำหรับ iOS เราเลือกได้ว่าจะใช้เนทีฟหรือเทคโนโลยีเว็บ) เช่นเดียวกับการแบ่งปัน การตัดสินใจของเราที่จะใช้ประโยชน์จากเนื้อหาเว็บโดยตรงในแอปทำให้การตั้งค่า **การแจ้งเตือนแบบพุช** ทำได้ง่าย เนื่องจากทุกผลิตภัณฑ์และการขายสามารถระบุได้ด้วย URL เดียวกันทั้งบนเว็บไซต์และในแอป การให้ความรู้แก่นักการตลาดเกี่ยวกับวิธีพุชการแจ้งเตือนไปยังลูกค้าจึงเป็นเรื่องง่าย - สิ่งที่พวกเขาต้องทำคือแชร์ URL เดียวกันกับที่ใช้ในการแชร์ ในแคมเปญอีเมล ข้อแตกต่างที่น่าสนใจอย่างหนึ่งระหว่าง iOS และ Android คือ **ระบบอนุญาต** สำหรับการแจ้งเตือนแบบพุช บน iOS การอนุญาตสำหรับการแจ้งเตือนจะถูกควบคุมโดยระบบปฏิบัติการ ในขณะที่ Android ไม่ต้องการการอนุญาต ถึงกระนั้น เรารู้สึกว่าการขออนุญาตเป็นสิ่งที่ถูกต้องจากมุมมองด้านการบริการลูกค้า ดังนั้น เมื่อผู้ใช้เข้าสู่ระบบแอพเป็นครั้งแรก เราถามว่าพวกเขาต้องการการแจ้งเตือนหรือไม่:

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

ผล

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

• ธุรกรรมต่อผู้เข้าชมที่ไม่ซ้ำนั้นได้รับประสบการณ์การใช้งานแอพมากกว่าเว็บ 76%
• ผู้ใช้รายวันที่ไม่ซ้ำของแอปมี แนวโน้มที่จะทำ Conversion มากขึ้น 20%
• ผู้ใช้แอปใช้ เวลาในการท่องเว็บมากกว่าผู้ใช้เว็บถึง 63%

ชนะประสิทธิภาพอย่างรวดเร็ว

การสร้างแอปที่โหลดเนื้อหาเว็บและให้ความรู้สึกเหมือนเป็นต้นฉบับนั้นไม่ได้มาจากในกล่องบน iOS หรือ Android ต่อไปนี้คือความท้าทายด้านประสิทธิภาพสองสามข้อที่เราเผชิญซึ่งควรค่าแก่การแบ่งปัน:

• บน iOS โมเมนตัมการเลื่อนในมุมมองเว็บจะไม่ตรงกับโมเมนตัมการเลื่อนที่ตรงกันในมุมมองการเลื่อนแบบเนทีฟ สิ่งนี้ถูกเปิดเผยในการทดสอบผู้ใช้ นี่คือหนึ่งซับในการแก้ปัญหานั้น: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• โปรดใช้ความระมัดระวังเมื่อปรับขนาดการดูเว็บ เราพบปัญหาที่การปรับขนาดทำให้เกิดการทาสีใหม่ทั้งหมด ซึ่งทำให้ประสิทธิภาพการเลื่อนในอุปกรณ์รุ่นเก่าลดลง
• การจัดการกับการใช้งานมุมมองเว็บที่แตกต่างกันหลายร้อยรายการบน Android อาจเป็นเรื่องที่เจ็บปวด ปัญหาที่เจ็บปวดที่สุดที่เราพบคือบั๊กการดูเว็บที่ทราบใน Android 4.4.2 ซึ่งส่งข้อยกเว้นที่ร้ายแรงใน Chromium ซึ่งทำให้แอปหยุดทำงาน การลบการ transform: translate3d ในเวอร์ชัน Android นั้นดูเหมือนจะทำเคล็ดลับได้ หรือคุณสามารถใช้ทางม้าลายเพื่อจัดส่งรันไทม์เว็บที่คอมไพล์แล้วด้วยแอปของคุณ (เราไม่ได้ทำสิ่งนี้ แต่เราวางแผนสำหรับโครงการในอนาคต)
• ใช้ FastClick ไม่เพียงเพราะลบการดีเลย์การคลิก 300 มิลลิวินาทีเท่านั้น แต่ยังเป็นเพราะแก้ไขข้อผิดพลาดในการคลิกมุมมองเว็บที่เปิดตัวใน iOS 8.4.1 ด้วย สำหรับเรา บั๊กแสดงออกมาเองโดยไม่อนุญาตให้เปลี่ยนหน้าหากการคลิกช้าเกินไป
• ทำทุกอย่างที่ทำได้เพื่อให้การเลื่อนดูน่าทึ่ง คุณสามารถยกเลิกกิจกรรมการเลื่อน หลีกเลี่ยงการทาสีใหม่โดยไม่จำเป็น และอื่นๆ หากการเลื่อนไม่ทำงานที่ 60 เฟรมต่อวินาที ผู้ใช้จะสังเกตเห็นในแอปมากกว่าบนเว็บ
• ทำทุกอย่างเพื่อให้โหลดหน้าเว็บได้ภายในเวลาไม่ถึง 1,000 มิลลิวินาที

เครื่องมือในการสร้างแอปที่ใช้ประโยชน์จากเว็บไซต์ของคุณ

คุณมีตัวเลือกมากมายในการสร้างแอปที่ใช้ประโยชน์จากเว็บไซต์ที่มีอยู่ของคุณ แนวทางที่เราใช้คือการสร้างแอปเฉพาะสำหรับแต่ละแพลตฟอร์ม (โดยใช้ Xcode และ Android Studio) ใช้ประโยชน์จากมุมมองเว็บหรือมุมมองดั้งเดิมเมื่อจำเป็น

เมื่อโหลดมุมมองเว็บสำหรับคุณลักษณะเฉพาะ เราแนะนำให้รวมมุมมองเว็บของ Cordova แทนการใช้ไลบรารีมุมมองเว็บที่จัดเตรียมโดย iOS และ Android โดยตรง วิธีนี้จะทำให้การดูเว็บของคุณมีคุณลักษณะหลายอย่างที่คุณต้องสร้างขึ้นเอง เช่น บริดจ์เว็บสู่เนทีฟเพื่อสื่อสารจาก JavaScript ไปยังโค้ดเนทีฟ และในทางกลับกัน ความสามารถในการเข้าถึงเหตุการณ์วงจรชีวิต ตลอดจนการเข้าถึง ไปจนถึงปลั๊กอิน Cordova มากมาย อีกทางหนึ่งคือ สะพานเชื่อมระหว่างเว็บกับเจ้าของภาษาอื่นๆ สองสามแห่งมีให้สำหรับแพลตฟอร์มต่างๆ หากคุณต้องการหลีกเลี่ยงขึ้นอยู่กับคอร์โดวา

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

บทสรุป

ด้วย Beyond the Rack เรามุ่งมั่นที่จะสร้างแอพที่เราสามารถส่งมอบคุณค่าให้กับผู้ใช้ได้อย่างง่ายดายโดยไม่ต้องเสียสละประสบการณ์ โดยการปฏิบัติตาม แนวทางที่ทำให้เทคโนโลยีอยู่ที่เบาะหลัง ทำให้เราใช้เทคโนโลยีที่เหมาะสมกับงานได้ เราเชื่อว่าเราทำสำเร็จแล้ว เมื่อมีการเปลี่ยนแปลงหรือแนะนำคุณลักษณะ เราจะถามตัวเองเสมอว่า “เราต้องการออกแบบประสบการณ์ใดที่จะแก้ปัญหาของผู้ใช้ได้ดีที่สุด ประสบการณ์นั้นต้องการการใช้ประสิทธิภาพขั้นสูงหรือแอนิเมชั่นหรือไม่”

คำตอบสำหรับคำถามนั้นจะเป็นตัวกำหนดว่าเราสร้างคุณสมบัติด้วยเทคโนโลยีเว็บและนำกลับมาใช้ใหม่ในเบราว์เซอร์และบน Android และ iOS หรือสร้างแบบกำหนดเองสำหรับแต่ละแพลตฟอร์ม

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