คู่มือสไตล์ UI สําหรับส่วนเสริม Google Workspace
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
ส่วนเสริมของ Google Workspace ควรสอดคล้องกับรูปแบบและเลย์เอาต์ของแอปพลิเคชันโฮสต์ที่ขยาย โดยควรขยาย UI อย่างเป็นธรรมชาติโดยใช้การควบคุมและลักษณะการทำงานที่คุ้นเคย หลักเกณฑ์ที่แสดงที่นี่อธิบายวิธีจัดการข้อความ รูปภาพ การควบคุม และการสร้างแบรนด์ที่ส่งเสริมประสบการณ์ของผู้ใช้ที่มีคุณภาพสูง
หากส่วนเสริมเปิดหน้าเว็บแยกต่างหากซึ่งเป็นส่วนหนึ่งของการทํางานของส่วนเสริม (เช่น หน้าการตั้งค่าสําหรับส่วนเสริม) โปรดตรวจสอบว่าหน้าเว็บเหล่านั้นเป็นไปตามหลักเกณฑ์ด้านสไตล์เหล่านี้ด้วย
ข้อความและรูปภาพ
ส่วนนี้จะอธิบายวิธีใช้ข้อความและรูปภาพในส่วนเสริมอย่างถูกต้อง
ชื่อส่วนเสริม
คุณต้องตั้งชื่อส่วนเสริมในไฟล์ Manifest ของโปรเจ็กต์และเมื่อคุณกำหนดค่าส่วนเสริมเพื่อเผยแพร่
ชื่อจะปรากฏในหลายๆ ที่ เช่น ข้อมูลใน Google Workspace Marketplace และภายในเมนู สิ่งที่ควรทราบเมื่อเลือกชื่อ
- ใช้ตัวพิมพ์ใหญ่สำหรับชื่อ
- หลีกเลี่ยงเครื่องหมายวรรคตอน โดยเฉพาะวงเล็บ เว้นแต่ว่าจะเป็นองค์ประกอบของแบรนด์
- โปรดใช้ข้อความสั้นๆ โดยควรมีความยาวไม่เกิน 15 อักขระ ระบบอาจตัดชื่อที่ยาวในข้อมูล Google Workspace Marketplace และที่อื่นๆ โดยอัตโนมัติ
- อย่าใส่คำว่า "Google", "Gmail" หรือชื่อผลิตภัณฑ์อื่นๆ ของ Google ในชื่อส่วนเสริม
- อย่าใส่คำว่า "ส่วนเสริม" ในชื่อส่วนเสริม
- ละเว้นข้อมูลเวอร์ชัน
รูปแบบการเขียน
คุณไม่จำเป็นต้องเขียนมาก การดำเนินการส่วนใหญ่ควรแสดงอย่างชัดเจนผ่านไอคอน เลย์เอาต์ และป้ายกำกับสั้นๆ หากพบว่าส่วนหนึ่งของส่วนเสริมต้องมีคำอธิบายที่ละเอียดกว่าที่ป้ายกำกับสั้นๆ จะระบุได้ แนวทางปฏิบัติแนะนำคือให้สร้างหน้าเว็บแยกต่างหากที่อธิบายส่วนเสริมและลิงก์ไปยังหน้านั้น
เมื่อเขียนข้อความ UI
- ใช้ตัวพิมพ์ตามแบบประโยค (โดยเฉพาะสำหรับปุ่ม ป้ายกำกับ และการดําเนินการของการ์ด)
- โปรดใช้ข้อความสั้นๆ ง่ายๆ ที่ไม่มีศัพท์เฉพาะหรือคำย่อ
การดำเนินการแบบทั่วไปและการดําเนินการกับการ์ด
หากคุณใช้การดำเนินการแบบสากลหรือการดำเนินการกับการ์ดในส่วนเสริม การดำเนินการดังกล่าวจะปรากฏเป็นรายการเมนูในการ์ดที่คุณกำหนด คุณเลือกข้อความที่จะใช้ในเมนูเหล่านี้สําหรับการดําเนินการเหล่านี้ได้ เมื่อเลือกข้อความที่จะใช้
- หลีกเลี่ยงข้อความเมนูที่ซ้ำกันเพียงชื่อของส่วนเสริม
- เริ่มรายการเมนูแต่ละรายการด้วยคำที่เป็นคำสั่ง เช่น "เรียกใช้" "กำหนดค่า" หรือ "สร้าง"
- อธิบายงาน ไม่ใช่คอมโพเนนต์ UI ที่การดำเนินการแสดง
- หากการดําเนินการเริ่มต้นเวิร์กโฟลว์และไม่มีคำกริยาที่อธิบายสิ่งที่ทํา ให้ตั้งชื่อเป็น "เริ่ม"
- กำหนดจำนวนรายการในเมนูให้น้อยเพื่อไม่ให้ผู้ใช้ต้องเลื่อนดูรายการจำนวนมาก หากต้องการใช้การดําเนินการเพิ่มเติม ให้พิจารณาใช้การ์ดหลายใบที่มีการดําเนินการที่แตกต่างกันในแต่ละใบ
ข้อความแสดงข้อผิดพลาด
เมื่อเกิดข้อผิดพลาดขึ้น คุณควรใช้ภาษาที่เข้าใจง่าย อธิบายปัญหาจากมุมมองของผู้ใช้และแนะนำวิธีแก้ไข
- ไม่อนุญาตให้ผู้ใช้เห็นข้อยกเว้นที่โค้ดของคุณแสดง แต่ให้ใช้คำสั่ง
try...catch
เพื่อขัดจังหวะข้อยกเว้น แล้วแสดงข้อความแสดงข้อผิดพลาดที่ผู้ใช้เข้าใจง่าย
- ก่อนเผยแพร่ ให้ตรวจสอบว่าส่วนเสริมไม่ได้แสดงข้อมูลการแก้ไขข้อบกพร่องใน UI
เนื้อหา Help
คุณอาจต้องออกแบบการ์ดที่แสดงข้อมูลความช่วยเหลือหรืออธิบายวิธีการทำงานของส่วนเสริมให้ผู้ใช้ทราบ หากคุณสร้างเนื้อหาช่วยเหลือสำหรับส่วนเสริม โปรดอย่าลืมทำสิ่งต่อไปนี้
- แสดงวิธีการเป็นรายการสัญลักษณ์หัวข้อย่อยหรือรายการที่เรียงลำดับเลข หากเป็นไปได้ แนะนำผู้ใช้ให้เห็นภาพขั้นตอนต่างๆ จนกว่าจะได้ผลลัพธ์ที่ต้องการ โดยอ้างอิงถึงองค์ประกอบ UI ที่มีชื่ออย่างชัดเจน
- ตรวจสอบว่าวิธีการอธิบายข้อกำหนดต่างๆ อย่างชัดเจน เช่น การตั้งค่าสเปรดชีตในลักษณะหนึ่งๆ
- คุณลิงก์ไปยังเนื้อหาความช่วยเหลือภายนอกได้ เช่น หน้าเว็บที่รองรับ
รูปภาพ
รูปภาพที่ใช้ในส่วนเสริมต้องเป็นไอคอนประเภทต่างๆ ที่มีให้อยู่แล้วหรือรูปภาพที่โฮสต์แบบสาธารณะซึ่งระบุด้วย URL เมื่อใช้รูปภาพที่โฮสต์ ให้ตรวจสอบว่าทุกคนที่อาจใช้ส่วนเสริมของคุณเข้าถึงรูปภาพเหล่านั้นได้
การควบคุม
ส่วนนี้จะแสดงหลักเกณฑ์ด้านประสบการณ์ของผู้ใช้สำหรับวิดเจ็ตแบบอินเทอร์แอกทีฟ
ใช้ปุ่มเพื่อควบคุมการดําเนินการหลักของอินเทอร์เฟซผู้ใช้แทนวิดเจ็ตอื่นๆ
- ป้ายกํากับปุ่มข้อความส่วนใหญ่ควรขึ้นต้นด้วยคํากริยา
- ในกรณีส่วนใหญ่ แถวปุ่มควรมีปุ่มไม่เกิน 3 ปุ่ม
DecoratedText
วิดเจ็ต DecoratedText ช่วยให้คุณนำเสนอเนื้อหาข้อความด้วยไอคอน ปุ่ม หรือสวิตช์ได้
- ขึ้นต้นประโยคด้วยตัวพิมพ์ใหญ่ หรือใช้ตัวพิมพ์ใหญ่กับอักษรตัวแรกของคำและวิสามานยนาม (สำหรับภาษาอังกฤษ) สำหรับเนื้อหาข้อความ
- ระบบจะตัดข้อความของวิดเจ็ต DecoratedText หากข้อความไม่พอดีกับพื้นที่ที่มีอยู่ ดังนั้น โปรดพยายามเขียนเนื้อหาข้อความให้สั้นที่สุดเสมอ
คุณสามารถใช้วิดเจ็ตอินพุตแบบเลือกได้หลายประเภทในส่วนเสริม เช่น ช่องการเลือกแบบเลื่อนลง ช่องทำเครื่องหมาย และปุ่มตัวเลือก
- ใช้ช่องทําเครื่องหมายเมื่อผู้ใช้เลือกตัวเลือกได้หลายรายการ หรือไม่มีตัวเลือกใดเลย
ใช้ปุ่มตัวเลือก (หรือเมนูตัวเลือก) เมื่อต้องเลือกตัวเลือกเพียงรายการเดียว
ใช้เมนูแบบเลื่อนลงเมื่อระบุรายการทางเลือกสั้นๆ ขณะพยายามประหยัดพื้นที่ใน UI
- ใช้การขึ้นต้นประโยคด้วยตัวพิมพ์ใหญ่สำหรับข้อความที่กำหนดให้กับแต่ละตัวเลือก
- หลีกเลี่ยงการใช้การเปลี่ยนแปลงการเลือกเพื่อทริกเกอร์การดำเนินการที่สำคัญซึ่งแก้ไขได้ยาก เนื่องจากผู้ใช้มักทำผิดพลาดเมื่อทำการเลือก แต่ให้ลองเพิ่มปุ่มที่อ่านค่าการเลือกปัจจุบัน แล้วทริกเกอร์การดำเนินการแทน
- สำหรับเมนูแบบเลื่อนลง ให้จัดเรียงตัวเลือกตามลําดับตัวอักษรหรือตามรูปแบบที่ผู้ใช้ทุกคนเข้าใจได้ (เช่น แสดงวันของสัปดาห์ตามลําดับโดยเริ่มจากวันอาทิตย์หรือวันจันทร์)
- จํากัดจํานวนตัวเลือกในวิดเจ็ตอินพุตการเลือกหนึ่งๆ เป็นจํานวนที่เหมาะสม หากมีตัวเลือกมากเกินไป ผู้ใช้อาจใช้วิดเจ็ตได้ยาก ในกรณีดังกล่าว ให้พิจารณาแบ่งตัวเลือกออกเป็นหมวดหมู่ต่างๆ และวิดเจ็ตหลายรายการ
การป้อนข้อความ
อินพุตข้อความเป็นพื้นที่สำหรับให้ผู้ใช้ป้อนข้อมูลสตริง
- อย่าใช้การป้อนข้อความเพื่อบังคับให้ผู้ใช้พิมพ์รายการที่เป็นไปได้จากชุดที่เจาะจง ใช้เมนูแบบเลื่อนลงแทน
- ใช้คำแนะนำและคำใบ้เพื่อช่วยผู้ใช้ป้อนข้อความที่มีรูปแบบและเนื้อหาที่ถูกต้อง
- ใช้การป้อนข้อความหลายบรรทัดหากข้อความที่จะป้อนมีความยาวมากกว่า 2-3 คำ
การสร้างแบรนด์
ส่วนนี้จะแสดงหลักเกณฑ์ด้านประสบการณ์ของผู้ใช้สำหรับการเพิ่มองค์ประกอบการสร้างแบรนด์ลงในอินเทอร์เฟซของส่วนเสริม
ในส่วนเสริม
หากต้องการใส่การแสดงแบรนด์ใน UI ของส่วนเสริม ให้ใช้ข้อความสั้นๆ และเบาสบาย
วิธีนี้ช่วยให้ผู้ใช้มุ่งเน้นที่ฟังก์ชันการทำงานของส่วนเสริม
- ส่วนต่างๆ ทั้งหมดของส่วนเสริมต้องเป็นไปตามหลักเกณฑ์การใช้แบรนด์
- อย่าใส่คำว่า "Google", "Gmail" หรือชื่อผลิตภัณฑ์อื่นๆ ของ Google
- อย่าใส่ไอคอนผลิตภัณฑ์ของ Google แม้ว่าจะมีการดัดแปลงไอคอนก็ตาม
- อย่าใส่คำว่า "ส่วนเสริม" ในข้อความการสร้างแบรนด์
- ข้อความการสร้างแบรนด์ควรมีความยาวไม่เกิน 2-3 คำ
ใน Google Workspace Marketplace
เมื่อกำหนดค่าส่วนเสริมเพื่อเผยแพร่ คุณจะต้องระบุชิ้นงานกราฟิกและข้อความจำนวนหนึ่งเพื่อสร้างข้อมูลผลิตภัณฑ์ใน Google Workspace Marketplace
ทุกแง่มุมของข้อมูลผลิตภัณฑ์ใน Store และชิ้นงานเหล่านี้ต้องเป็นไปตามหลักเกณฑ์การใช้แบรนด์
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2024-12-22 UTC
[null,null,["อัปเดตล่าสุด 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)."]]