เว็บเป็นแพลตฟอร์มที่น่าทึ่ง ซึ่งเข้าถึงผู้ใช้ทั่วโลก บนอุปกรณ์ต่างๆ เป็นหลัก ใช้งานง่ายและแชร์ได้ไม่ยาก โดยไม่ต้องติดตั้งอะไรเลย แต่ที่สำคัญที่สุด มันเป็นระบบนิเวศแบบเปิดที่ทุกคนจะใช้หรือสร้างได้
แอปบางแอปไม่สามารถสร้างและแสดงบนเว็บแบบเปิดได้ในปัจจุบัน เราเรียกสิ่งนี้ว่าช่องโหว่ของแอป ความแตกต่างระหว่างสิ่งที่เป็นไปได้บนเว็บ กับความเป็นไปได้ในโฆษณาเนทีฟ เราต้องการอุดช่องว่างนั้น เราเชื่อว่าเว็บแอปควรทำได้ทุกอย่างที่แอปที่มาพร้อมเครื่อง
เราจะออกแบบและปรับใช้ความสามารถใหม่เหล่านี้อย่างไร
เราพัฒนากระบวนการนี้เพื่อให้ออกแบบและพัฒนาความสามารถของแพลตฟอร์มเว็บใหม่ๆ ที่ตรงกับความต้องการของนักพัฒนาซอฟต์แวร์ได้อย่างรวดเร็ว โดยไม่ต้องเสียค่าใช้จ่าย และที่สำคัญที่สุดคือต้องทำงานภายในกระบวนการมาตรฐานที่มีอยู่ การที่เราพัฒนาฟีเจอร์ของแพลตฟอร์มเว็บอื่นๆ ทั้งหมดนั้นไม่ต่างอะไร แต่การให้ความสำคัญกับความคิดเห็นของนักพัฒนาซอฟต์แวร์
ความคิดเห็นของนักพัฒนาซอฟต์แวร์เป็นสิ่งสำคัญที่ช่วยให้มั่นใจได้ว่าเรากำลังจัดส่งฟีเจอร์ที่เหมาะสม แต่เมื่อกระบวนการทำงานล่าช้า การเปลี่ยนแปลงก็ทำได้ยาก ด้วยเหตุนี้เราจึงเริ่มขอความคิดเห็นได้เร็วขึ้น เมื่อได้รับความคิดเห็นทางเทคนิคและกรณีการใช้งานที่นำไปใช้ได้จริงตั้งแต่เนิ่นๆ การให้คำแนะนำที่ถูกต้องหรือแม้กระทั่งหยุดการพัฒนานั้นก็ง่ายขึ้น โดยไม่จำเป็นต้องส่งฟีเจอร์ที่แย่หรือนำไปใช้อย่างไม่เหมาะสม ฟีเจอร์ที่กำลังพัฒนาที่ WICG ไม่ได้มีความสำคัญมากนัก และข้อมูลที่คุณให้มีส่วนช่วยพัฒนารูปแบบที่ยิ่งใหญ่
เป็นที่น่าสังเกตว่าแนวคิดหลายๆ อย่างไม่เคยผ่านขั้นตอนอธิบายหรือช่วงทดลองใช้จากต้นทางเลย เป้าหมายของกระบวนการคือการจัดหาฟีเจอร์ที่เหมาะสม ซึ่งหมายความว่าเราต้องเรียนรู้และทำซ้ำอย่างรวดเร็ว การไม่จัดส่งคุณลักษณะเพราะไม่สามารถตอบสนอง ความต้องการของนักพัฒนาซอฟต์แวร์ได้ก็ไม่เป็นไร เพื่อการเรียนรู้นี้ เราจึงนำกระบวนการต่อไปนี้มาใช้ (แม้ว่าบ่อยครั้งจะมีการจัดลำดับขั้นตอนในภายหลังบ่อยครั้งเนื่องจากเราได้รับความคิดเห็นเข้ามา)
ระบุความต้องการของนักพัฒนาแอป
ขั้นตอนแรกคือการระบุและทำความเข้าใจความต้องการของนักพัฒนาแอป นักพัฒนาซอฟต์แวร์ ต้องการบรรลุเป้าหมายใด ใครจะเป็นผู้ใช้ เป็นอย่างไรบ้าง และปัญหาหรือความหงุดหงิดที่ได้รับการแก้ไขโดยความสามารถใหม่นี้ ซึ่งโดยปกติแล้ว รายการเหล่านี้มักเป็นคำขอฟีเจอร์จากนักพัฒนาซอฟต์แวร์ ซึ่งมักจะส่งผ่านข้อบกพร่องที่ยื่นใน Bug.chromium.org
สร้างคำอธิบาย
หลังจากระบุความจำเป็นของความสามารถใหม่แล้ว ให้สร้างเครื่องมืออธิบาย ซึ่งก็คือเอกสารการออกแบบที่มีไว้เพื่ออธิบายปัญหา พร้อมด้วยตัวอย่างโค้ดที่แสดงวิธีการทำงานของ API คำอธิบายคือเอกสารการออกแบบที่มีชีวิตซึ่งจะต้องผ่านการปรับปรุงครั้งใหญ่เมื่อความสามารถใหม่ๆ พัฒนาขึ้น
รับข้อเสนอแนะและนำมาใช้ซ้ำในข้อความอธิบาย
เมื่อผู้อธิบายมีความชัดเจนในระดับที่เหมาะสมแล้ว ก็ถึงเวลาเผยแพร่คำอธิบาย ขอความคิดเห็น และทำซ้ำการออกแบบ นี่เป็นโอกาสในการตรวจสอบว่าความสามารถใหม่นี้ตรงตามความต้องการของนักพัฒนาซอฟต์แวร์และทำงานในแบบที่คาดหวังไว้ นี่เป็นโอกาสอันดีในการรวบรวมการสนับสนุนจากสาธารณะ และเป็นการยืนยันว่า มีความจำเป็นจริงๆ สำหรับความสามารถนี้
ย้ายการออกแบบไปยังข้อกำหนดเฉพาะและทำซ้ำ
เมื่อตัวอธิบายอยู่ในสถานะที่ดี งานออกแบบจะเปลี่ยนไปเป็นข้อกำหนดอย่างเป็นทางการ โดยร่วมมือกับนักพัฒนาซอฟต์แวร์และผู้ให้บริการเบราว์เซอร์รายอื่นๆ เพื่อทำซ้ำและปรับปรุงการออกแบบ
จากนั้นเมื่อการออกแบบเริ่มเสถียรแล้ว เรามักจะใช้ช่วงทดลองใช้จากต้นทางเพื่อทดสอบการติดตั้งใช้งาน ช่วงทดลองใช้จากต้นทางช่วยให้คุณได้ลองใช้ฟีเจอร์ใหม่ๆ กับผู้ใช้จริงและแสดงความคิดเห็นเกี่ยวกับการใช้งาน ผลตอบรับจากการใช้งานจริงนี้จะช่วยกำหนดรูปแบบและตรวจสอบความถูกต้องของการออกแบบ ทำให้มั่นใจได้ว่าเราทำอย่างถูกต้องก่อนที่จะกลายเป็นมาตรฐาน
จัดส่ง
สุดท้าย เมื่อช่วงทดลองใช้จากต้นทางเสร็จสมบูรณ์ ข้อกำหนดได้รับการสรุปผลและขั้นตอนการเปิดตัวอื่นๆ ทั้งหมดเสร็จสมบูรณ์แล้ว ก็ถึงเวลาจัดส่งผลิตภัณฑ์ให้เสถียร
ออกแบบให้มีความปลอดภัย ความเป็นส่วนตัว และความไว้วางใจของผู้ใช้
บางฟีเจอร์อาจดูน่ากลัวในตอนแรก โดยเฉพาะอย่างยิ่งเมื่อพูดถึงวิธีการติดตั้งในเครื่อง แต่โดยปกติเว็บจะปลอดภัยกว่าแบบปกติทั่วไป การเปิดหน้าเว็บก็ไม่ควรน่ากลัว
ไม่ควรมีการให้สิทธิ์เข้าถึงโดยค่าเริ่มต้น แต่ใช้โมเดลสิทธิ์ที่อนุญาตให้ผู้ใช้ควบคุมสิทธิ์โดยสมบูรณ์และสามารถเพิกถอนได้ง่าย คุณจึงต้องมีความชัดเจนว่ามีการใช้ API เหล่านี้เมื่อใดและอย่างไร เราได้ระบุกระบวนการคิดส่วนหนึ่งไว้ในการควบคุมการเข้าถึงฟีเจอร์แพลตฟอร์มเว็บที่มีประสิทธิภาพ