שיטות מומלצות

שיפור של המשתמשים כדי ליהנות מהחוויה הכוללת, אפשר להיעזר במדריכים האלה לעיצוב.

שיטות מומלצות כלליות

אנחנו ממליצים לך לפעול לפי השיטות המומלצות הבאות לגבי כל התוספים עד עכשיו.

לפני שמתחילים: איך מגדירים את הבעלות על התוסף

תוספים מוגדרים על ידי פרויקטים של 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 או אובייקטים מורכבים אחרים של ממשק המשתמש, כדאי להכניס את הקוד הזה בפונקציה משלו. פונקציית היצירה הזו צריכה פשוט ליצור את האובייקט ולהחזיר אותו. כך אפשר אתם יוצרים מחדש את האובייקט הזה בכל פעם שצריך לרענן את ממשק המשתמש. כדאי לזכור לשלוח קריאה אל build() אחרי השימוש בכיתות של ה-builder שירות כרטיסים.

כרטיסים פשוטים יותר

אם בכרטיס מסוים יש יותר מדי ווידג'טים, הוא עלול למלא חלק גדול מדי מהמסך הופכות להיות פחות שימושיות. חלקים גדולים מהכרטיסים מוצגים כרכיבים מכווצים בממשק המשתמש, מסתירה מידע מהמשתמש. המטרה היא לייעל את התוסף ולספק בדיוק מה שהמשתמש צריך, ולא יותר.

שימוש בכרטיסי שגיאה

יוצרים כרטיסים עבור תנאי שגיאה. אם התוסף מייצר שגיאה, הוא אמור להציג כרטיס עם מידע על השגיאה והוראות לתיקון השגיאה. אם אפשר. לדוגמה, אם התוסף לא מצליח להתחבר מכיוון שההרשאה נכשלה, יש להציג כרטיס שכולל את המידע הזה ולבקש המשתמש כדי לאמת את פרטי החשבון שבהם נעשה שימוש.

כתיבת בדיקות והודעות בדיקה

מומלץ לבדוק היטב את כל התוספים שאתם יוצרים. לבנות פונקציות בדיקה ליצור כרטיסים ווידג'טים באמצעות נתוני בדיקה, ואז לוודא שהאובייקטים נוצרה כמצופה.

כשמשתמשים בפונקציות קריאה לפעולה (callback), בדרך כלל צריך ליצור אובייקט תגובה. אפשר להשתמש בהצהרות כמו את השלבים הבאים כדי לוודא שהתשובות בנויות בצורה נכונה:

    Logger.log(response.printJson());

הרצת פונקציות בדיקה שיצרתם ישירות מ-Apps Script בעזרת התפריט הפעלה. כאשר יש לכם תוסף שימושי שפועל, יש להתקין את הגרסה שלא פורסמה כדי שתוכלו לבדוק אותו.

להשתמש בנתוני הבדיקה המתאימים לכל אפליקציה מארחת שהתוסף מרחיב. עבור לדוגמה, אם התוסף מרחיב את Gmail, סביר להניח שתזדקקו לכמה הודעות אימייל לבדיקה ואת מזהי ההודעות שלהם, כדי שתוכלו לוודא שהתוסף יפעל שהייתה צפויה להתקבל כאשר תוכן הודעה שונה. אפשר לקבל את מזהה ההודעה של הודעה נתונה על ידי רישום הודעות באמצעות Users.messages.list ב-Gmail API או על ידי שימוש ב-Apps Script שירות Gmail.

שיטות מומלצות לשיחות ועידה ביומן

אם התוסף משלב צד שלישי שיחת ועידה ביומן ביומן Google, כדאי לפעול לפי השיטות המומלצות הנוספות הבאות:

שמירה על תאורה בonCreateFunction

כל onCreateFunction כפי שמגדירים במניפסט נקרא באופן סינכרוני כאשר משתמש מנסה כדי ליצור פתרון לשיחות ועידה מהסוג הזה. ודאו שהפונקציות האלה מבצעות רק העבודה המינימלית הדרושה כדי ליצור את שיחת הוועידה. יותר מדי מאמץ יכולות לגרום להאטת חוויית המשתמש בתוסף.

צריך להשתמש בשדות ConferenceData המתאימים לנתונים של שיחת הוועידה

כשבונים ב- ConferenceData אובייקטים, אפשר לאכלס אותם בפרטים על שיחת הוועידה (גישה קודים, מספרי טלפון, קודי אימות, מזהי URI וכו'). חשוב להשתמש שדה EntryPoint למידע הזה. אין למקם את הפרטים האלה ב-ConferenceData שדה הערות.

לא לצרף פרטים של שיחת ועידה לאירוע ביומן Google

התוסף לא צריך להוסיף מידע על צד שלישי שנוצר של שיחות ועידה בתיאור האירוע ביומן Google. יומן Google זאת באופן אוטומטי במקרה הצורך.