Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Tingkatkan pengalaman pengguna secara keseluruhan dengan mengikuti panduan ini untuk
desain add-on.
Praktik terbaik umum
Sebaiknya gunakan praktik terbaik berikut untuk semua
add-on yang Anda kembangkan.
Menentukan kepemilikan add-on sebelum memulai
Add-on ditentukan oleh project Apps Script, yang harus dimiliki oleh akun tertentu atau ditempatkan di drive bersama. Sebelum membuat kode add-on, tentukan akun yang harus memiliki project, dan akun yang bertindak sebagai penayangnya. Tentukan juga akun yang akan bertindak sebagai kolaborator, dan pastikan akun tersebut memiliki akses ke project skrip dan project Google Cloud terkait.
Memperluas Google Workspace, bukan mereplikasinya
Add-on dimaksudkan untuk memberikan kemampuan baru ke
aplikasi Google Workspace yang diperluas, atau mengotomatiskan tugas yang kompleks.
Add-on yang hanya mereplikasi fungsi yang sudah ada dalam
aplikasi atau yang tidak melakukan peningkatan signifikan pada alur kerja
kemungkinan tidak akan lulus peninjauan add-on untuk publikasi.
Membatasi cakupan
Saat menentukan cakupan secara eksplisit, selalu pilih kumpulan cakupan yang paling tidak permisif. Misalnya, jangan izinkan
add-on Anda meminta akses penuh ke Kalender
pengguna dengan cakupan
https://www.googleapis.com/auth/calendar jika hanya memerlukan akses baca. Untuk akses hanya baca, gunakan cakupan https://www.googleapis.com/auth/calendar.readonly.
Menghindari terlalu mengandalkan library
Menggunakan library Apps Script dapat
menyebabkan add-on Anda berjalan lebih
lambat
daripada jika semua kode Apps Script berada dalam
satu project skrip. Meskipun library Apps Script berfungsi di
add-on, Anda mungkin mengalami penurunan performa jika menggunakannya. Hindari menyertakan library yang tidak diperlukan dalam project Anda, dan pertimbangkan cara
untuk mengurangi ketergantungan add-on Anda pada library tersebut.
Latensi yang dijelaskan di atas hanya berlaku untuk project Apps Script
yang digunakan sebagai library sisi server. Anda dapat menggunakan library JavaScript sisi klien seperti jQuery secara bebas tanpa mengalami latensi ini.
Praktik terbaik add-on editor
Praktik terbaik berikut hanya berlaku untuk
add-on Editor.
Menempatkan HTML antarmuka dan JavaScript sisi klien dalam file skripnya sendiri
Anda dapat membuat beberapa file skrip dalam project Apps Script.
Lebih mudah untuk mengelola add-on yang kompleks jika Anda menempatkan
HTML dan JavaScript yang menentukan sidebar dan dialog add-on
dalam file skrip yang didedikasikan untuknya.
Menguji secara menyeluruh dalam berbagai mode otorisasi
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-04-09 UTC."],[[["\u003cp\u003eEnhance user experience by adhering to add-on design guidelines that focus on ownership, functionality, and security.\u003c/p\u003e\n"],["\u003cp\u003eDesign add-ons to extend Google Workspace capabilities, rather than duplicating existing features, to ensure successful publication.\u003c/p\u003e\n"],["\u003cp\u003ePrioritize security by minimizing the scope of access your add-on requires, requesting only necessary permissions.\u003c/p\u003e\n"],["\u003cp\u003eOptimize performance by limiting reliance on external libraries and, if applicable to Editor add-ons, strategically organizing code within dedicated script files.\u003c/p\u003e\n"],["\u003cp\u003eFor Editor add-ons, thorough testing across various authorization modes is crucial to ensure functionality and user experience.\u003c/p\u003e\n"]]],["Before coding, determine the add-on's ownership, publisher, and collaborators, ensuring all have access to the project. Prioritize extending, not replicating, Google Workspace functionality and use the narrowest scopes possible when defining permissions. Avoid over-reliance on Apps Script libraries due to potential performance issues. Organize complex add-ons by placing HTML and JavaScript in dedicated script files. Thoroughly test the add-on in various authorization modes and file configurations.\n"],null,["# Best practices\n\nImprove your users' overall experience by following these guides for\nadd-on design.\n\nGeneral best practices\n----------------------\n\nYou are encouraged to use the following best practices for all\nadd-ons you develop.\n\n### Determine add-on ownership before starting\n\nAdd-ons are defined by Apps Script projects, which\nmust be owned by a specific account or else placed in a [shared\ndrive](/workspace/drive/v3/web/about-shareddrives). Before coding an\nadd-on, determine what account should own the project,\nand what account acts as its publisher. Also determine what accounts are to act\nas collaborators, and make sure those accounts have access to the script project\nand its associated\n[Google Cloud project](/apps-script/guides/cloud-platform-projects).\n| **Note:** It's important to plan add-on ownership. If the add-on owner leaves your organization, you must make sure ownership is transferred or else you could lose the ability to update and manage your add-on. For this reason, it may be best to create an organization account specifically to own and publish your organization's add-ons. You can also use a shared drive to act as the script project owner, but a specific account must act as the add-on publisher.\n\n### Extend Google Workspace, don't replicate it\n\nAdd-ons are meant to provide new capabilities to the\nGoogle Workspace applications they extend, or else automate complex tasks.\nAdd-ons that merely replicate functionality already within the\napplication or ones that don't make significant improvements to a workflow\naren't likely to pass [add-on review](/workspace/marketplace/about-app-review) for publication.\n\n### Keep the scopes narrow\n\nWhen [defining your scopes\nexplicitly](/apps-script/concepts/scopes#set-explicit), always choose the\nleast-permissive set of scopes possible. For example, don't have your\nadd-on request full access to the user's\nCalendar with the `https://www.googleapis.com/auth/calendar`\nscope if it only needs read access. For read-only access, use the\n`https://www.googleapis.com/auth/calendar.readonly` scope.\n\n### Avoid relying too much on libraries\n\nUsing Apps Script [libraries](/apps-script/guides/libraries) can\ncause your add-on to [run more\nslowly](/apps-script/guides/support/best-practices#avoid_libraries_in_ui-heavy_scripts)\nthan it would if all the Apps Script code were contained within a\nsingle script project. Although Apps Script libraries work in\nadd-ons, you might run into performance reductions if you use\nthem. Avoid including unnecessary libraries in your project, and consider ways\nto reduce your add-on's reliance on them.\n\nThe latency described above only applies to Apps Script projects\nbeing used as server-side libraries. You can use client-side JavaScript\nlibraries like jQuery freely without encountering this latency.\n\nEditor add-on best practices\n----------------------------\n\nThe following best practices only apply to\nEditor add-on.\n\n### Place interface HTML and client-side JavaScript in their own script files\n\nYou can create multiple script files in an Apps Script project.\nIt's easier to manage a complex add-on if you place the\nHTML and JavaScript that defines the add-on sidebars\nand dialogs in script files dedicated to them.\n\n### Test thoroughly in different authorization modes\n\nWhen [testing your add-on](/workspace/add-ons/how-tos/testing-editor-addons), be\nsure to try configurations that have different files and different\n[authorization\nstates](/workspace/add-ons/concepts/editor-auth-lifecycle#states)."]]
