ปรับปรุงข้อมูลผู้ใช้ ประสบการณ์โดยรวมได้โดยทำตามคำแนะนำส่วนเสริมต่อไปนี้ การออกแบบอีกด้วย
แนวทางปฏิบัติแนะนำโดยทั่วไป
เราขอแนะนําให้คุณทําตามแนวทางปฏิบัติแนะนําต่อไปนี้สําหรับส่วนเสริมทั้งหมดที่คุณ พัฒนา
กำหนดการเป็นเจ้าของส่วนเสริมก่อนเริ่ม
ส่วนเสริมจะกำหนดโดยโครงการ 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 ไม่ได้ บริการไม่ได้เนื่องจากการอนุมัติล้มเหลว แสดงการ์ดที่ระบุข้อมูลนี้และถาม ให้ผู้ใช้ยืนยันข้อมูลบัญชีที่ใช้
เขียนการทดสอบและข้อความทดสอบ
คุณควรทดสอบส่วนเสริมทั้งหมดที่สร้างขึ้นอย่างละเอียดถี่ถ้วน สร้างฟังก์ชันทดสอบที่ สร้างการ์ดและวิดเจ็ตโดยใช้ข้อมูลทดสอบ จากนั้นตรวจสอบว่าออบเจ็กต์เหล่านั้น ตามที่คาดไว้
เมื่อใช้ฟังก์ชัน Callback การดำเนินการ คุณต้องสร้างออบเจ็กต์การตอบกลับ คุณสามารถใช้คำสั่ง เช่น ต่อไปนี้เพื่อยืนยันว่าสร้างการตอบกลับได้ถูกต้อง
Logger.log(response.printJson());
เรียกใช้ฟังก์ชันทดสอบที่คุณสร้างจาก Apps Script โดยตรง ของตัวแก้ไขโดยใช้เมนูเรียกใช้ เมื่อคุณมีส่วนเสริมที่ใช้งานได้ อย่าลืมติดตั้งเวอร์ชันที่ไม่ได้เผยแพร่ เพื่อให้คุณทดสอบได้
ใช้ข้อมูลการทดสอบที่เหมาะกับแอปพลิเคชันโฮสต์แต่ละรายการที่ส่วนเสริมขยายให้ สำหรับ เช่น หากส่วนเสริมใช้กับ Gmail ได้ คุณก็อาจต้องการอีเมลทดสอบ 2-3 ฉบับ และรหัสข้อความด้วย เพื่อให้มั่นใจได้ว่าส่วนเสริมจะทำงาน ควรคาดหวังเมื่อมีเนื้อหาข้อความที่แตกต่างกัน คุณสามารถรับรหัสข้อความสำหรับ ที่ระบุโดยแสดงรายการข้อความโดยใช้ User.messages.list ของ Gmail API หรือใช้ บริการ Gmail
แนวทางปฏิบัติแนะนำสำหรับการประชุมทางวิดีโอในปฏิทิน
หากส่วนเสริมของคุณทำงานร่วมกับบุคคลที่สาม การประชุมในปฏิทิน ใน Google ปฏิทิน โปรดทำตามแนวทางปฏิบัติแนะนำเพิ่มเติมต่อไปนี้
รักษาไฟ onCreateFunction
ไว้
onCreateFunction
แต่ละรายการ
ที่คุณกำหนดในไฟล์ Manifest จะถูกเรียกแบบซิงโครนัสเมื่อผู้ใช้พยายาม
สร้างโซลูชันการประชุมประเภทนั้น โปรดตรวจสอบว่าฟังก์ชันเหล่านี้ทำหน้าที่
การทำงานขั้นต่ำที่จำเป็นเพื่อสร้างการประชุม ทำสิ่งเหล่านี้มากเกินไป
อาจทำให้ส่วนเสริมของคุณได้รับประสบการณ์การใช้งานที่ช้า
ใช้ช่อง ConferenceData
ที่เหมาะสมสําหรับข้อมูลการประชุม
เมื่อคุณสร้าง
ConferenceData
แล้วคุณจะเห็นรายละเอียดเกี่ยวกับการประชุม (การเข้าถึง
รหัส, หมายเลขโทรศัพท์, PIN, URI เป็นต้น) อย่าลืมใช้คอลัมน์ที่สอดคล้องกัน
ช่อง EntryPoint
สำหรับข้อมูลนี้ อย่าวางรายละเอียดเหล่านี้ไว้ใน ConferenceData
หมายเหตุ
ไม่เพิ่มรายละเอียดการประชุมลงในกิจกรรมใน Google ปฏิทิน
ส่วนเสริมของคุณไม่จำเป็นต้องเพิ่มข้อมูลเกี่ยวกับบุคคลที่สามที่สร้างขึ้น กับคำอธิบายกิจกรรมของ Google ปฏิทิน Google ปฏิทินจะทำสิ่งต่อไปนี้ โดยอัตโนมัติเมื่อจำเป็น