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

כדי לשפר את חוויית המשתמש הכוללת, כדאי לעיין בהנחיות האלה לעיצוב תוספים ל-Google Meet.

שיטות מומלצות להרשאת גישה

מומלץ להשתמש בשיטות העבודה המומלצות הבאות לכל תוסף ל-Google Meet שדורש אימות או הרשאה.

כניסה באמצעות חשבון Google

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

פתיחת דף הכניסה של צד שלישי בחלון חדש

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

בקשה נכונה של היקפי הרשאות ל-Google APIs

אם התוסף שלכם ל-Meet קורא ל-Google APIs, אתם צריכים לספק רשימה מלאה של היקפי OAuth שנדרשים לתוסף. ההגדרה מתבצעת בדף 'הגדרת אפליקציה' ב-Google Workspace Marketplace. אחרי שמוסיפים את היקפי ההרשאות האלה, המשתמשים רואים הנחיה כשהם מתקינים את התוסף שלכם ל-Meet, שבה מוסבר להם לאילו סוגי נתונים הם מאשרים לאפליקציה שלכם לגשת.

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

הדרך הקלה ביותר להתחיל לכתוב קוד לקריאה לממשקי Google Workspace API היא לפעול לפי המדריך לתחילת העבודה עם JavaScript. הגישה הזו תואמת לשיטות המומלצות לשימוש בכניסה לחשבון Google ובחלונות דו-שיח. שימו לב: כדי לאתחל את לקוח הטוקן ב-JavaScript, צריך לבקש בנפרד את ההיקפים שבהם האפליקציה משתמשת בפועל בזמן הריצה. כדי ליהנות מחוויית המשתמש הטובה ביותר, ההיקפים המבוקשים האלה צריכים להיות זהים לאלה שבדף 'הגדרת אפליקציה' ב-Google Workspace Marketplace. היתירות הזו מספקת פתרון חלופי למקרה שבו משתמש ביטל הרשאות גישה (scopes).

שיטות מומלצות לניהול הקמפיין

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

שימוש בגרסה האחרונה של Google Meet Add-ons SDK

ערכת ה-SDK של תוספים ל-Meet מתעדכנת באופן קבוע. ערכת ה-SDK תואמת לגרסאות סמנטיות. כדי למצוא את הגרסה העדכנית:

  • כשמשתמשים ב-gstatic: גרסת ה-SDK העדכנית נמצאת בכתובת ה-URL של gstatic שמופיעה בהוראות לשימוש ב-SDK.
  • כשמשתמשים ב-npm: מריצים את הפקודה npm update @googleworkspace/meet-add-ons מתוך הספרייה שמכילה את package.json של האתר שמארח את התוסף ל-Meet.

יצירת פרויקט Google Cloud לצורך הכנה לבדיקה

אחרי שמפרסמים את התוסף ל-Google Meet ב-Google Workspace Marketplace, כל פריסה חדשה של התוסף זמינה באופן מיידי למשתמשי Meet. המשתמשים יראו את העדכונים האלה ברגע שהם ינקו את המטמון או כשתוקף המטמון יפוג. לכן, מומלץ לא להעביר שינויים לאתר הפעיל עד שהשינויים ייבדקו באופן יסודי.

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

כדי ליצור את הסביבות החלופיות האלה לתוסף, קודם צריך לארח סביבות חלופיות של אפליקציית האינטרנט שמכילה את התוסף בדומיין שבבעלותכם. לאחר מכן, תוכלו ליצור סביבות חלופיות לתוסף Meet על ידי הוספת פריסות נוספות לפרויקט הביניים שלכם ב-Google Cloud. לפריסות החדשות האלה צריכים להיות קובצי מניפסט שמפנים לסביבות החלופיות של אפליקציית האינטרנט. לאחר מכן, מומלץ להתקין כל סביבת תוסף באופן הבא:

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

כתיבת בדיקות

לפני שפורסים את התוסף ל-Meet בסביבת פיתוח, מומלץ לכתוב בדיקות יחידה. הבדיקות של יחידות הקוד צריכות לכלול:

  • ליצור מוקאפ של Meet Add-ons SDK, ואז לוודא שהתוסף ל-Meet קורא לפונקציות של ה-SDK כמצופה.
  • בדיקת יחידות של כל הפונקציונליות של התוסף שלא קשורה ל-SDK באמצעות מסגרת בדיקת האינטרנט המועדפת.

שיטות מומלצות לשיפור חוויית המשתמש

השיטות המומלצות הבאות יעזרו לכם ליצור תוסף ל-Meet שהוא אינטואיטיבי ומשוכלל יותר.

ניהול כל המצבים ההתחלתיים בחלונית הצדדית

מומלץ מאוד להגדיר את התוסף על סמך פעולות משתמשים שבוצעו בחלונית הצדדית. כדי לעשות את זה, מגדירים את מצב ההתחלה של הפעילות ב-JavaScript. כל הנתונים שמוזנים ל-ActivityStartingState צריכים להיות מוגדרים על ידי יוזם התוסף (בדרך כלל מארח הפגישה) בחלונית הצדדית. אפשר לחשוב על התצוגה הראשונה של חלונית הצד בתור טופס ששולט בהגדרת התוסף.

סוגרים את החלונית הצדדית כשלא משתמשים בה

אחרי שמתחילים את הפעילות באמצעות הקריאה לשיטה startActivity(), צריך להשאיר את חלונית הצד פתוחה רק אם היא חלק מהותי מחוויית המשתמש בתוסף של Google Meet. אפשר לסגור את החלונית הצדדית אחרי שהבמה הראשית נפתחת על ידי קריאה לשיטה unloadSidePanel().

קידום התוסף ל-Meet באמצעות שיתוף מסך

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

הנחיות לעיצוב לוגו

כדי שהלוגו שלכם ב-Meet ייראה הכי טוב שאפשר גם עכשיו וגם בעתיד, חשוב לפעול לפי ההנחיות הבאות כשמעצבים אותו:

מומלץ להשתמש בפורמט קובץ PNG בגודל ‎256px x 256px.

כן, חשוב להשתמש בשקיפות.

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

חשוב לוודא שהלוגו (ונכסים גרפיים אחרים) נראים טוב במצב ניגודיות גבוהה. לשם כך, אפשר להשתמש בכלי לבדיקת ניגודיות כמו Contrast Checker של Web Accessibility In Mind (WebAIM).

פועלים בהתאם לדרישות הגרפיות לשילובים ספציפיים של אפליקציות.

אל תכללו מרווחים פנימיים בתמונה. במקום זאת, מרחיבים את התמונה לגבולות הקובץ.