מדריך סגנון לממשק המשתמש של תוספים ל-Google Workspace
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
תוספים ל-Google Workspace צריכים להיות עקביים עם הסגנון והפריסה של אפליקציית המארח שהם מרחיבים. הם צריכים להרחיב את ממשק המשתמש באופן טבעי באמצעות אמצעי בקרה והתנהגויות מוכרים. ההנחיות שמפורטות כאן מתארות דרכים לטיפול בטקסט, בתמונות, באמצעי הבקרה ובמיתוג, שמקדמות חוויית משתמש באיכות גבוהה.
אם התוסף פותח דפי אינטרנט נפרדים שהם חלק בלתי נפרד מהפעלת התוסף (כמו דף הגדרות של התוסף), חשוב לוודא שגם דפי האינטרנט האלה עומדים בהנחיות הסגנון האלה.
טקסט ותמונות
בקטע הזה מוסבר איך להשתמש בצורה נכונה בטקסט ובתמונות בתוסף.
הימנעו משימוש בסימני פיסוק, במיוחד בסוגריים, אלא אם הם חלק מהמותג.
כדאי שהשם יהיה קצר – 15 תווים או פחות. יכול להיות ששמות ארוכים יקוצרו באופן אוטומטי בדף המוצר ב-Google Workspace Marketplace ובמקומות אחרים.
אסור לכלול בשם התוסף את המילים 'Google', 'Gmail' או שמות של מוצרים אחרים של Google.
אין לכלול את המילה 'תוסף' בשם התוסף.
לא לכלול את פרטי הגרסה.
סגנון כתיבה
לא צריך לכתוב הרבה. רוב הפעולות צריכות להיות ברורות באמצעות סמלים, פריסה ותוויות קצרות. אם חלק מהתוסף שלכם צריך הסבר מפורט יותר ממה שתוויות קצרות יכולות לספק, מומלץ ליצור דף אינטרנט נפרד שמתאר את התוסף ולקשר אליו.
כשכותבים טקסט בממשק המשתמש:
להשתמש באותיות רישיות (במיוחד בלחצנים, בתווית ובפעולות בכרטיסים).
מומלץ להשתמש בטקסט קצר ופשוט ללא מונחים מקצועיים או ראשי תיבות.
פעולות כלליות ופעולות בכרטיס
אם משתמשים בפעולות אוניברסליות או בפעולות בכרטיס בתוסף, הן מופיעות כפריטי תפריט בכרטיסים שתגדירו. אתם יכולים לבחור את הטקסט שיופיע בתפריטים האלה עבור הפעולות האלה. כשבוחרים את הטקסט לשימוש:
מומלץ להימנע מטקסט בתפריט שפשוט חוזר על שם התוסף.
כדאי להתחיל כל פריט בתפריט במילה שמציינת פעולה, כמו 'הפעלה', 'הגדרה' או 'יצירה'.
מתארים את המשימה, ולא את רכיב ממשק המשתמש שבו מוצגת הפעולה.
אם הפעולה מתחילה תהליך עבודה ואין פועל יחיד שמתאר את הפעולה, אפשר לקרוא לה 'התחלה'.
מומלץ להשתמש במספר קטן של פריטים בתפריט כדי למנוע מהמשתמשים לגלול ברשימת פריטים גדולה. אם אתם רוצים להטמיע פעולות נוספות, כדאי להשתמש בכמה כרטיסים עם פעולות שונות בכל אחד מהם.
הודעות שגיאה
כשמשהו משתבש, חשוב להשתמש בשפה פשוטה. צריך להסביר את הבעיה מנקודת המבט של המשתמש ולהציע איך לפתור אותה.
אל תאפשרו למשתמש לראות חריגות שהקוד שלכם גורם להן. במקום זאת, השתמשו בהצהרות try...catch כדי ליירט חריגות, ואז להציג הודעת שגיאה ידידותית למשתמש.
לפני הפרסום, חשוב לוודא שהתוסף לא מציג מידע על ניפוי באגים בממשק המשתמש.
תוכן העזרה
כדאי לעצב כרטיסים שמוצגים בהם מידע עזר או הסבר למשתמשים על הפעולה של התוסף. אם אתם יוצרים תוכן עזרה לתוסף, חשוב לזכור:
כשאפשר, כדאי להציג את ההוראות ברשימת תבליטים או ברשימת מספרים. להנחות את המשתמשים עד לתוצאה הסופית, עם הפניות ברורות לרכיבי ממשק המשתמש שצוינו בשמות.
חשוב להסביר בבירור את כל הדרישות בהוראות, למשל הגדרת גיליון אלקטרוני באופן מסוים.
אפשר לקשר לתוכן עזרה חיצוני, כמו דפי אינטרנט תומכים.
תמונות
התמונות שבתוסף יכולות להיות מסוגי הסמלים המובנים או תמונה שמתארחת באופן ציבורי ומסומנת באמצעות כתובת URL. כשמשתמשים בתמונות מתארחות, חשוב לוודא שכל מי שעשוי להשתמש בתוסף יוכל לגשת אליהן.
חשוב להשתמש באות גדולה בתחילת המשפט (באנגלית) בתוכן הטקסט.
הטקסט של ווידג'ט DecoratedText יקוצר אם הוא לא יתאים למרחב הזמין. לכן, תמיד כדאי לנסות לשמור על תוכן הטקסט קצר ככל האפשר.
קלטות בחירה
תוכלו להשתמש במגוון של ווידג'טים של קלט בחירה בתוסף: תיבות בחירה נפתחות, תיבות סימון ולחצני בחירה.
כדאי להשתמש בתיבות סימון כשאנשים יכולים לבחור כמה אפשרויות, או לא לבחור אף אפשרות.
משתמשים בלחצני בחירה (או בתפריט בחירה) כשצריך לבחור רק אפשרות אחת.
כדאי להשתמש ברשימה נפתחת כשמציגים רשימה קצרה של חלופות ומנסים לחסוך מקום בממשק המשתמש.
חשוב להשתמש באות גדולה בתחילת המשפט (באנגלית) בטקסט שמוקצה לכל אפשרות.
מומלץ להימנע משימוש בשינויים בבחירות כדי להפעיל פעולות משמעותיות שקשה לבטל, כי אנשים נוטים לעשות שגיאות כשהם בוחרים. במקום זאת, מומלץ להוסיף לחצן שקורא את ערכי הבחירה הנוכחיים ואז מפעיל את הפעולה.
בתפריטים נפתחים, כדאי למיין את האפשרויות לפי סדר אלפביתי או לפי סכימה לוגית שכל המשתמשים יכולים להבין (למשל, הצגת ימי השבוע בסדר, החל מיום ראשון או מיום שני).
כדאי להגביל את מספר האפשרויות בווידג'ט מסוים של קלט לבחירה למספר סביר. אם יש יותר מדי אפשרויות, יכול להיות שיהיה למשתמשים קשה להשתמש בווידג'ט. במקרים כאלה, מומלץ לפצל את האפשרות לקטגוריות שונות ולכמה ווידג'טים.
קלט טקסט
קלט טקסט מספק למשתמשים מקום להזין נתוני מחרוזת.
אל תשתמשו בקלט טקסט כדי לגרום למשתמש להקליד אחת מקבוצה ספציפית של רשומות אפשריות. במקום זאת, משתמשים בתפריט נפתח.
כדאי להשתמש בטיפים והצעות כדי לעזור למשתמש להזין טקסט בפורמט ובתוכן הנכונים.
אם הטקסט שרוצים להזין מכיל יותר ממספר מילים, כדאי להשתמש בקלט טקסט בכמה שורות.
מיתוג
בקטע הזה מפורטות הנחיות לגבי חוויית המשתמש להוספת רכיבי מיתוג לממשק התוסף.
בתוסף
אם אתם רוצים לכלול מיתוג בממשק המשתמש של התוסף, חשוב לשמור על העיצוב קצר ופשוט.
כך אנשים יוכלו להתמקד בפונקציונליות של התוסף.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2024-12-22 (שעון UTC)."],[[["\u003cp\u003eGoogle Workspace add-ons should seamlessly integrate with the host application's style and layout using familiar controls and behaviors.\u003c/p\u003e\n"],["\u003cp\u003eAdd-on names should be concise, using title case, avoiding punctuation and Google product names, and kept to 15 characters or less.\u003c/p\u003e\n"],["\u003cp\u003eUI text should be minimal, using sentence case, simple language, and clear action verbs in menus and buttons.\u003c/p\u003e\n"],["\u003cp\u003eBranding should be subtle within the add-on, adhering to Google's branding guidelines, and avoiding Google product names or icons.\u003c/p\u003e\n"],["\u003cp\u003eError messages should be user-friendly, providing clear explanations and solutions instead of technical jargon or exceptions.\u003c/p\u003e\n"]]],["Add-ons must match the host application's style and extend the UI naturally. Key actions include: using title case for the add-on's name (15 characters or less), and avoiding punctuation, Google product names, \"add-on\", and version info. UI text should be in sentence case, short, and jargon-free, with menu items starting with action words. Error messages should use plain language. Images should be accessible, buttons should primarily use verbs, and text inputs should employ hints. Branding must be brief, adhering to specific guidelines.\n"],null,["# UI style guide for Google Workspace add-ons\n\nGoogle Workspace add-ons should be consistent with the\nstyle and layout of the\n[host application](/workspace/add-ons/guides/glossary#host_or_host_application)\nthey extend. They should extend the UI\nnaturally by using familiar controls and behaviors. The guidelines presented\nhere describe ways of handling text, images, controls, and branding that promote\na high-quality user experience.\n\nIf your add-on opens separate web pages that are an integral part of the add-on's\noperation (such as a settings page for the add-on), make sure those web pages\nalso follow these style guidelines.\n\nText and images\n---------------\n\nThis section tells you how to properly use text and images in your add-on.\n\n### Add-on name\n\nYou must set your add-on's name in its project\n[manifest](/workspace/add-ons/concepts/workspace-manifests) and when you\n[configure your add-on for publication](/workspace/marketplace/sdk#text_assets).\nThe name appears in many places, such as the [Google Workspace Marketplace](https://workspace.google.com/marketplace/)\nlisting and within menus. When choosing a name:\n\n- Use title case.\n- Avoid punctuation, especially parentheses, unless part of your brand.\n- Keep it short---15 or fewer characters is best. Long names may be automatically truncated in the Google Workspace Marketplace listing and elsewhere.\n- Don't include the words \"Google\", \"Gmail\", or other Google product names in your add-on name.\n- Don't include the word \"add-on\" in your add-on name.\n- Leave out version information.\n\n### Writing style\n\nYou shouldn't need to write much. Most actions should be made clear through\niconography, layout, and short labels. If you find a portion of your add-on\nneeds more extensive explanation than short labels can provide, it's a best\npractice to create a separate web page describing your add-on and link to it.\n\nWhen writing UI text:\n\n- Use sentence case (especially for buttons, labels, and card actions).\n- Prefer short, simple text without jargon or acronyms.\n\n### Universal and card actions\n\nIf you use [universal actions](/workspace/add-ons/how-tos/universal-actions)\nor [card actions](/apps-script/reference/card-service/card-action) in your\nadd-on, they appear as menu items in the [cards](/workspace/add-ons/concepts/cards)\nyou define. You can choose the text that is used in these menus for these\nactions. When choosing the text to use:\n\n- Avoid menu text that simply repeats your add-on's name.\n- Start each menu item with an action word such as \"Run\", \"Configure\", or \"Create\".\n- Describe the task, not the UI component that the action displays.\n- If your action begins a workflow and there's no single verb that describes what it does, call it \"Start\".\n- Keep the number of menu items small to avoid forcing the user to scroll through a large list. If you have more actions to implement, consider using multiple cards with different actions on each.\n\n### Error messages\n\nWhen something goes wrong, it's important to use plain language. Explain the\nproblem from the user's standpoint, and suggest how to fix it.\n\n- Don't allow the user to see any exceptions your code throws. Instead, use `try...catch` statements to intercept exceptions, then display a user-friendly error message.\n- Before you publish, check that your add-on doesn't display debug information in the UI.\n\n### Help content\n\nYou may wish to design cards that display help information or explain the\noperation of the add-on to the user. If you do build help content for your\nadd-on, remember to:\n\n- When possible, show instructions in a bulleted or numbered list. Walk users through to the end result, with clear references to named UI elements.\n- Make sure your instructions clearly explain any requirements, like setting up a spreadsheet in a certain way.\n- Feel free to link to external help content, such as supporting web pages.\n\n### Images\n\nImages used in your add-on are either one of the\n[built-in icon types](/apps-script/reference/card-service/icon)\nor a publicly hosted image specified by a URL. When using hosted images,\nbe sure that they are accessible by everyone who may use your add-on.\n\nControls\n--------\n\nThis section provide user experience guidelines for\n[interactive widgets](/workspace/add-ons/concepts/widgets#user_interaction_widgets).\n\n### Buttons\n\nUse buttons to control your user interface's main actions rather than\nother widgets.\n\n- Most text button labels should start with a verb.\n- Button rows should be limited to three or fewer buttons in most cases.\n\n### DecoratedText\n\n[DecoratedText widgets](/workspace/add-ons/concepts/widgets#informational_widgets)\nlet you present text content with icons, buttons or switches.\n\n- Use sentence case for the text content.\n- The text of a DecoratedText widget is truncated if it cannot fit into the available space. For this reason, always try to keep the text content as short as you can.\n\n### Selection inputs\n\nYou can use a variety of\n[selection input widgets](/workspace/add-ons/concepts/widgets#user_interaction_widgets)\nin your add-on: drop-down selection boxes, checkboxes, and radio buttons.\n\n- Use checkboxes when people can select multiple options, or no option at all. Use radio buttons (or a select menu) when exactly one option must be selected. Use dropdowns when providing a short list of alternatives while trying to save space in the UI.\n- Use sentence case for the text that is assigned to each option.\n- Avoid using selection changes to trigger major, hard-to-reverse actions, because people often make mistakes when making selections. Instead, consider adding a button that reads the current selection values and then triggers the action.\n- For dropdowns, sort the options alphabetically or by a logical scheme that all users can understand (such as presenting the days of the week in order, starting from Sunday or Monday).\n- Restrict the number of options in a given selection input widget to a reasonable number. If there are too many options, users may find it hard to use the widget. In those cases, consider breaking the option into different categories and multiple widgets.\n\n### Text inputs\n\nText inputs provide a place for users to enter string data.\n\n- Don't use a text input to make the user type one of a specific set of possible entries. Use a dropdown select instead.\n- Use hints and suggestions to help the user enter text with the correct format and content.\n- Use multiline text inputs if the text to be entered is more than a few words.\n\nBranding\n--------\n\nThis section provide user experience guidelines for adding branding elements\nto your add-on interface.\n\n### In your add-on\n\nIf you'd like to include branding in your add-on UI, keep it brief and light.\nThis helps people focus on your add-on functionality.\n\n- All aspects of your add-on must follow the [branding guidelines](https://developer.chrome.com/webstore/branding).\n- Don't include the word \"Google\", \"Gmail\", or other Google product names.\n- Don't include Google product icons, even if they are altered.\n- Don't include the word \"add-on\" in your branding text.\n- Branding text should be no more than a few words.\n\n### In the Google Workspace Marketplace\n\nWhen you configure your add-on for publication,\nyou provide a number of graphical and text assets to build the\nGoogle Workspace Marketplace listing.\n\nAll aspects of your store listing and these assets must follow the\n[branding guidelines](https://developer.chrome.com/webstore/branding)."]]
