แนวทางปฏิบัติแนะนำ

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

แนวทางปฏิบัติแนะนำโดยทั่วไป

เราขอแนะนำให้คุณทำตามแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้สำหรับส่วนเสริมทั้งหมดที่เพิ่งพัฒนา

กำหนดการเป็นเจ้าของส่วนเสริมก่อนเริ่ม

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

ขยายการใช้งาน Google Workspace ไม่ต้องทำซ้ำ

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

จำกัดขอบเขตให้แคบ

เมื่อกำหนดขอบเขตอย่างชัดแจ้ง ให้เลือกชุดขอบเขตที่ให้สิทธิ์น้อยที่สุดเสมอ ตัวอย่างเช่น อย่าให้ส่วนเสริมเข้าถึงปฏิทินของผู้ใช้อย่างเต็มรูปแบบโดยใช้ขอบเขต https://www.googleapis.com/auth/calendar หากส่วนเสริมต้องการสิทธิ์เข้าถึงแบบอ่านเพียงอย่างเดียว สำหรับสิทธิ์การเข้าถึงระดับอ่านอย่างเดียว ให้ใช้ขอบเขต https://www.googleapis.com/auth/calendar.readonly

หลีกเลี่ยงการพึ่งพาไลบรารีมากเกินไป

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

เวลาในการตอบสนองที่อธิบายไว้ข้างต้นจะมีผลกับโปรเจ็กต์ Apps Script ที่ใช้เป็นไลบรารีฝั่งเซิร์ฟเวอร์เท่านั้น คุณสามารถใช้ไลบรารี JavaScript ฝั่งไคลเอ็นต์อย่าง jQuery ได้อย่างอิสระและไม่มีปัญหาเวลาในการตอบสนองนี้

แนวทางปฏิบัติแนะนำสำหรับส่วนเสริมของ Google Workspace

แนวทางปฏิบัติแนะนำต่อไปนี้ใช้กับส่วนเสริม Google Workspace และการใช้บริการบัตรเท่านั้น

ใช้การ์ดเพียงไม่กี่ใบ

หากส่วนเสริมใช้การ์ดมากเกินไป การกำหนดค่าการนำทางจะซับซ้อนและจัดการได้ยาก

หลีกเลี่ยงการสร้างการ์ดมากเกินความจำเป็น

ใช้ฟังก์ชันการสร้างวิดเจ็ต

เมื่อเขียนโค้ดที่สร้าง Card หรือออบเจ็กต์ UI อื่นๆ ที่ซับซ้อน ให้พิจารณาวางโค้ดนั้นในฟังก์ชันของตัวเอง ฟังก์ชันการสร้างนี้ควรสร้างแค่ออบเจ็กต์แล้วแสดงผล ซึ่งช่วยให้คุณสร้างออบเจ็กต์ดังกล่าวใหม่ได้อย่างรวดเร็วเมื่อใดก็ตามที่ต้องรีเฟรช UI อย่าลืมเรียกใช้ build() หลังจากใช้คลาสเครื่องมือสร้างในบริการบัตร

ทำให้การ์ดเรียบง่าย

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

ใช้การ์ดแสดงข้อผิดพลาด

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

เขียนการทดสอบและทดสอบข้อความ

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

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

    Logger.log(response.printJson());

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

ใช้ข้อมูลการทดสอบที่เหมาะกับแอปพลิเคชันโฮสต์แต่ละรายการที่มีส่วนเสริมนั้นขยายอยู่ ตัวอย่างเช่น หากส่วนเสริมขยายการใช้งานใน Gmail คุณอาจต้องส่งอีเมลทดสอบ 2-3 ฉบับและรหัสข้อความ เพื่อให้มั่นใจว่าส่วนเสริมจะทำงานได้ตามที่คาดไว้เมื่อให้เนื้อหาข้อความที่แตกต่างกัน คุณดูรหัสข้อความของข้อความที่ระบุได้โดยการแสดงข้อความโดยใช้เมธอด Gmail API Users.messages.list หรือโดยใช้บริการ Gmail ของ Apps Script

แนวทางปฏิบัติแนะนำเกี่ยวกับการประชุมในปฏิทิน

หากส่วนเสริมของคุณผสานรวมตัวเลือกการประชุมในปฏิทินของบุคคลที่สามลงใน Google ปฏิทิน ให้ทำตามแนวทางปฏิบัติแนะนำเพิ่มเติมต่อไปนี้

เก็บไฟ onCreateFunction ไว้

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

ใช้ช่อง ConferenceData ที่เหมาะสมสำหรับข้อมูลการประชุม

เมื่อสร้างออบเจ็กต์ ConferenceData คุณจะป้อนข้อมูลรายละเอียดการประชุมได้ (รหัสการเข้าถึง, หมายเลขโทรศัพท์, PIN, URI ฯลฯ) โปรดใช้ช่อง EntryPoint ที่เกี่ยวข้องสำหรับข้อมูลนี้ อย่าวางรายละเอียดเหล่านี้ไว้ในช่องหมายเหตุ ConferenceData

ไม่ต้องเพิ่มรายละเอียดการประชุมลงในกิจกรรมใน Google ปฏิทิน

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