@atlaskit/ads-mcp 1.0.0 → 1.1.0

package/dist/cjs/tools/get-atlaskit-utilities/get-atlaskit-utilities-tool.js

@@ -0,0 +1,40 @@
+"use strict";
+
+var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault");
+Object.defineProperty(exports, "__esModule", {
+  value: true
+});
+exports.getAtlaskitUtilitiesTool = void 0;
+var _regenerator = _interopRequireDefault(require("@babel/runtime/regenerator"));
+var _asyncToGenerator2 = _interopRequireDefault(require("@babel/runtime/helpers/asyncToGenerator"));
+var _atlaskitUtilities = require("./atlaskit-utilities.codegen");
+/* eslint-disable-next-line import/extensions -- MCP SDK requires .js extensions for ESM imports */
+
+var getAtlaskitUtilitiesTool = exports.getAtlaskitUtilitiesTool = /*#__PURE__*/function () {
+  var _ref = (0, _asyncToGenerator2.default)( /*#__PURE__*/_regenerator.default.mark(function _callee() {
+    var utilities;
+    return _regenerator.default.wrap(function (_context) {
+      while (1) switch (_context.prev = _context.next) {
+        case 0:
+          utilities = _atlaskitUtilities.atlaskitUtilities.map(function (utility) {
+            return {
+              name: utility.name,
+              package: utility.package
+            };
+          });
+          return _context.abrupt("return", {
+            content: [{
+              type: 'text',
+              text: JSON.stringify(utilities, null, 2)
+            }]
+          });
+        case 1:
+        case "end":
+          return _context.stop();
+      }
+    }, _callee);
+  }));
+  return function getAtlaskitUtilitiesTool() {
+    return _ref.apply(this, arguments);
+  };
+}();

package/dist/cjs/tools/get-atlaskit-utilities/list-get-atlaskit-utilities-tool.js

@@ -0,0 +1,22 @@
+"use strict";
+
+Object.defineProperty(exports, "__esModule", {
+  value: true
+});
+exports.listGetAtlaskitUtilitiesTool = void 0;
+var _zod = require("zod");
+var _helpers = require("../../helpers");
+/* eslint-disable-next-line import/extensions -- MCP SDK requires .js extensions for ESM imports */
+
+var listGetAtlaskitUtilitiesTool = exports.listGetAtlaskitUtilitiesTool = {
+  name: 'atlaskit_get_utilities',
+  description: "Returns the names and packages of all atlaskit utilities (functions, constants, types) excluding utilities covered by the Atlassian Design System.\n\nWHEN TO USE:\nUse this when you want to see what utilities are available without the full metadata payload.\n\nNo parameters.",
+  annotations: {
+    title: 'Get all Atlaskit utilities',
+    readOnlyHint: true,
+    destructiveHint: false,
+    idempotentHint: true,
+    openWorldHint: true
+  },
+  inputSchema: (0, _helpers.zodToJsonSchema)(_zod.z.object({}))
+};

package/dist/cjs/tools/get-atlaskit-utilities/types.js

@@ -0,0 +1,5 @@
+"use strict";
+
+Object.defineProperty(exports, "__esModule", {
+  value: true
+});

package/dist/cjs/tools/get-guidelines/guidelines-structured-content.codegen.js

@@ -9,7 +9,7 @@ exports.guidelinesStructuredContent = void 0;
  *
  * Structured content for content guidelines from design-system-docs foundations content.
  *
- * @codegen <<SignedSource::172be2830ddae4adfd4b9c4a11d5b54a>>
+ * @codegen <<SignedSource::613be582db295e634b62c0f119c15494>>
  * @codegenCommand yarn build structured-docs
  */
 
@@ -38,7 +38,7 @@ var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
   content: '<SectionMessage title="">\n\tDate and time formatting is tied to a person’s locale and account settings. Because of this, what\n\ta customer sees could be different from the guidelines on this page.\n</SectionMessage>\n\n## Date and time for internationalization\n\nEach programming language has an i18n (internationalization) library that automatically localizes\ntime and date strings based on a user’s locale settings/preferences. Time and date strings should\nnever be localized manually by a designer, engineer, or translator.\n\nThe Product Internationalization team is responsible for creating app UI content in non-English\nlanguages by localizing externalized code strings provided by our Product Engineers.\n\nEngineers must:\n\n- Ensure date and time references/strings are not hardcoded \n- Reference the programming i18n library API, which will automatically format time and date strings\n  as per a customer’s detected or selected locale.\n\n## Date formats\n\nAtlassian uses US date formatting (for example: January 12, 2028).\n\nWhen you’re handing designs over to engineers, you need to specify which date format length is\nneeded. The i18n library API will use this information to format the date accordingly. Date and time\nformats should not be hardcoded.\n\nThere are 4\n[date format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats):\nfull, long, medium, and short.\n\n### Full date\n\nThe full date format is weekday, month, day, year.\n\n<DoDontGrid>\n\t<DoDont type="do">Sunday, August 14, 2028</DoDont>\n</DoDontGrid>\n\n### Long date\n\nA long date format is month, day, year\n\n<DoDontGrid>\n\t<DoDont type="do">November 8, 2008</DoDont>\n</DoDontGrid>\n\n### Medium date\n\nThe medium date format is abbreviated month, day, year. Only use this format when space is limited.\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 26, 1952</DoDont>\n</DoDontGrid>\n\n#### Abbreviating months and days\n\nIf you need to abbreviate months or days, use the first 3 letters of the month or day.\n\n| Month abbreviation | Month in full |     | Day abbreviation | Day in full |\n| ------------------ | ------------- | --- | ---------------- | ----------- |\n| Jan                | January       |     | Mon              | Monday      |\n| Feb                | February      |     | Tue              | Tuesday     |\n| Mar                | March         |     | Wed              | Wednesday   |\n| Apr                | April         |     | Thu              | Thursday    |\n| May                | May           |     | Fri              | Friday      |\n| Jun                | June          |     | Sat              | Saturday    |\n| Jul                | July          |     | Sun              | Sunday      |\n| Aug                | August        |     |                  |             |\n| Sep                | September     |     |                  |             |\n| Oct                | October       |     |                  |             |\n| Nov                | November      |     |                  |             |\n| Dec                | December      |     |                  |             |\n\n### Short date\n\nShort format dates are written in digits.\n\nIn most cases, avoid short format dates as different countries use the date in a different order,\nwhich can cause confusion and effect readability and usability. In the US, 10-8-2026 is October 8,\n2026, but in Australia and the UK, it’s August 10, 2026.\n\nHowever, short format dates might be suitable for situations like data storage, sorting or\nfiltering, or data export/import. If using, use the ISO 8601 international standard for numerical\ndate format, which is YYYY-MM-DD.\n\n## Ordinal numbers\n\nDon’t use ordinal numbers (1st, 2nd, 3rd, and so on) in dates.\n\n## Date ranges\n\nIf you have a date range, use ‘to’ and not hyphens. For example: ‘2020 to 2024’. Hyphens are read\nout by screen readers as ‘hyphen’, which can lead to confusion.\n\nAn exception is financial years, which use a hyphen without spaces on either side. For example:\nFY2008-09\n\nUse ‘and’ if a range is preceded by ‘between’. For example: He was in Paris between 2025 and 2026.\n\n<DoDontGrid>\n\t<DoDont type="do">2014 to 2015</DoDont>\n\t<DoDont type="dont">2014-15</DoDont>\n</DoDontGrid>\n\n## Time formats\n\nShow time in digits for precision and to give a clearer expression of time.\n\nSpecify to engineers which time format length is needed. The i18n library API will then format the\ntime according to a customer’s account settings. Make sure time is not hardcoded.\n\nUse a colon (:) to separate the hours and minutes (though this might change depending on a user’s\nlocale and account settings).\n\nLike dates, there are 4\n[time format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats):\nfull, long, medium, and short.\n\n### Full time\n\nThe full time format is hour, minutes, seconds, and time zone spelt out.\n\n<DoDontGrid>\n\t<DoDont type="do">3:30:10 p.m. Pacific Standard Time</DoDont>\n</DoDontGrid>\n\n### Long time\n\nThe long time format is hour, minutes, seconds, and the time zone initials.\n\n<DoDontGrid>\n\t<DoDont type="do">11:18:30 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium time\n\nThe medium time format is hour, minutes, and seconds.\n\n<DoDontGrid>\n\t<DoDont type="do">8:50:28 a.m.</DoDont>\n</DoDontGrid>\n\n### Short time\n\nThe short time format is hour and minutes.\n\n<DoDontGrid>\n\t<DoDont type="do">2:40 p.m.</DoDont>\n</DoDontGrid>\n\n### 24-hour time\n\nThe 24-hour format is useful for more serious communications, for example in the case of outages and\nsecurity comms. The use of the 24-hour format is mostly system-driven by the i18n library API.\n\nThis format numbers hours from 00:00 hours (midnight) to 23:59 and uses 4 digits: the first 2 digits\nare the hours and the next 2 digits are the minutes. Use a colon (:) to separate the hours and\nminutes, though this might change depending on someone\'s account settings.\n\n## Writing time\n\n### Duration and timestamps\n\nWhen writing timestamps, labels on graphs, or durations, avoid using zeros before the hour. For\nexample: 5:29. not 05:29. Use a colon between the hours and minutes with no spaces on either side.\n\n### Using a.m. and p.m.\n\nFormat time using ‘a.m.’ and ‘p.m.’ when creating content like blogs, manuals, and instructions.\n\n- Lowercase ‘a.m.’ and ‘p.m.’\n- Use periods between the letters\n- Add a space between the time and the ‘a.m.’ or ‘p.m.’. For example: 6:30 a.m. (not 6:30a.m.)\n\n### Time range\n\n- If you have a time range that’s entirely in the morning or evening, use \'a.m.\' or \'p.m.\' only\n  once. For example: 6:30 to 10 p.m.\n- If the time range goes from the morning into the evening (or vice versa), use both. For example:\n  10 a.m. to 2 p.m.\n\n### Noon, midday, and midnight\n\nWhere suitable, use ‘noon’, ‘midday’ or ‘midnight’ instead of ‘12 am’ or ‘12 pm’ as it makes it\neasier for people to differentiate between these times.\n\n### Avoid using ‘fortnightly ‘or ‘bi’ for months and years\n\nAvoid using ‘fortnightly’ and the prefix ‘bi’ to mean either 2 or twice, as these terms can be\nconfusing.\n\nInstead of:\n\n- **Fortnightly**: write ‘every 2 weeks’\n- **Bimonthly**: write ‘twice a month’ or ‘every 2 months’\n- **Biannual**: write ‘twice a year’ or ‘every 2 years’.\n\n<DoDontGrid>\n\t<DoDont type="do">Your sprint will repeat every 2 weeks.</DoDont>\n\t<DoDont type="dont">Your sprint will repeat fortnightly.</DoDont>\n</DoDontGrid>\n\n## Date and time formats\n\nThere are also full, long, medium, and short format lengths when combining date and time.\n\n### Full date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Wednesday, June 12, 2024 at 6:25:59 p.m. Eastern Standard Time</DoDont>\n</DoDontGrid>\n\n### Long date and time\n\n<DoDontGrid>\n\t<DoDont type="do">April 25, 2027 at 9:05:32 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 5, 1999, 1:25:59 a.m.</DoDont>\n</DoDontGrid>\n\n### Short date and time\n\n<DoDontGrid>\n\t<DoDont type="do">2028-10-22, 6:25 p.m. </DoDont>\n</DoDontGrid>\n\n## Relative date and time\n\nIn some cases, like when the exact date is less important, the easiest way to describe something\nthat happened very recently is using the ‘ago’ format.\n\nFor future and past events, use approximate time by rounding down to the largest or most recent date\nor time.\n\nYou should always provide a way for people to see the actual timestamp, usually via a tooltip.\n\n### Past\n\n| Description                 | Display                      | Display when limited space     |\n| --------------------------- | ---------------------------- | ------------------------------ |\n| Within the last few seconds | just now                     | now                            |\n| Within the last minute      | a minute ago                 | 1 m                            |\n| Within 59 minutes           | x minutes ago                | X m                            |\n| 60 minutes ago              | 1 hour ago                   | 1 h                            |\n| x hours ago                 | x hours ago                  | X h                            |\n| 1 day ago                   | yesterday                    | 1 d                            |\n| 1 day ago (with time)       | yesterday at 5:05 pm         | n/a                            |\n| 2 days ago < 7 days         | x days ago                   | Use the truncated date (Aug 8) |\n| 7 days ago                  | 1 week ago                   | Use the truncated date (Aug 8) |\n| > 7 days ago                | Date stamp: "August 8, 2018" | Use the truncated date (Aug 8) |\n\n### Future\n\n| Description                   | Display                      | Display when limited space     |\n| ----------------------------- | ---------------------------- | ------------------------------ |\n| Within the next few seconds   | shortly                      | now                            |\n| In the next minute            | In 1 minute                  | in 1 m                         |\n| In the next 60 minutes        | In x minutes                 | in X m                         |\n| In 60 minutes                 | In 1 hour                    | in 1 hr                        |\n| In x hours                    | In x hours                   | in X hr                        |\n| In 1 day (by date, not hours) | tomorrow                     | Use the truncated date (Aug 8) |\n| In 2 to 7 days                | In x days                    |                                |\n| In 7 days                     | In 1 week                    |                                |\n| In > 7 days                   | Date stamp: "August 8, 2018" |                                |\n| > 7 days ago                  | Date stamp: "August 8, 2018" |                                |\n\n## Style and punctuation\n\nStyle and punctuation for dates and time can change depending on locale and is determined by the\ni18n library API.\n\n### Capitalization\n\n- Months and days in English are proper nouns and start with a capital letter.\n- Specific days or periods in history are all proper nouns, so should be capitalized. For example:\n  New Year’s Day, Renaissance, Cold War.\n- Use capital letters for all institutional holidays, religious days, and public events. For\n  example: Ramadan, Yom Kippur, Good Friday, Martin Luther King Jr. Day.\n\n### Apostrophes\n\n- Avoid using apostrophes in UI copy and in developer and support documentation.\n- In more casual writing, you can use an apostrophe to stand in for the missing numerals in the\n  year, such as \'the \'70s’.\n\n## Resources\n\n- [Int.DateTimeFormat constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#try_it) -\n  a JavaScript library that devs can use and where designers can check formatting of date and time.\n- [Date formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats)\n- [Time formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats)',
   keywords: ['date', 'time', 'formatting', 'localization', 'datetime', 'content']
 }, {
-  content: 'People care about how apps talk to them. YouTube, GitHub, and Slack all have a distinct voice, tone,\nand personality.\n\nApps engage us, manage to make us feel at home, capture our attention, and earn our loyalty.\n\nPoor messaging contributes to a poor user experience, which leads to dissatisfaction. On the other\nhand, good copy reflects our apps\' voice (personality) and enables us to build a better relationship\nwith our audience.\n\nIn short, good messaging may not be the reason people stay with our apps, but bad messaging could be\nthe reason they decide to leave.\n\n## Choose a message type\n\nUse different types of messages to guide people through their tasks. Each message type has a\nconsistent visual and writing style to help people know what to expect.\n\nUse these guidelines to choose and write the types of messages:\n\n- [Information message](https://atlassian.design/foundations/content/designing-messages/info-messages)\n  — provides additional information to motivate people.\n- [Error message](https://atlassian.design/foundations/content/designing-messages/error-messages) —\n  alerts people of a problem that has occurred and informs them what to do next.\n- [Success message](https://atlassian.design/foundations/content/designing-messages/success-messages)\n  — celebrates success along with the people using our apps.\n- [Warning message](https://atlassian.design/foundations/content/designing-messages/warning-messages)\n  — gives advanced notice of a potential change that may result in loss of data or an error state.\n- [Feature discovery](https://atlassian.design/foundations/content/designing-messages/feature-discovery)\n  — lets people know about a new feature.\n\n## Select the right component\n\nUse the table to identify the right component for your content.\n\nFor example:\n\n- If you want to highlight a new feature to a user, consider a spotlight card, benefits modal, or\n  empty state.\n- If you want to tell someone they\'ve accomplished a task, consider a flag.\n\n| Component                                     | Information message | Success message | Warning message | Error message | Feature discovery |\n| --------------------------------------------- | ------------------- | --------------- | --------------- | ------------- | ----------------- |\n| **Empty state**                               | Yes                 | Yes             |                 |               | Yes               |\n| **Banner**                                    | Yes                 |                 | Yes             | Yes           |                   |\n| **Flag**                                      | Yes                 | Yes             | Yes             | Yes           |                   |\n| **Section message**                           | Yes                 |                 | Yes             | Yes           |                   |\n| **Inline message**                            | Yes                 | Yes             | Yes             | Yes           |                   |\n| **Modal dialog**                              | Yes                 |                 | Yes             |               |                   |\n| **Benefits modal**                            |                     |                 |                 |               | Yes               |\n| **Onboarding (spotlight) and spotlight card** |                     |                 |                 |               | Yes               |\n\n### Empty state\n\nUse empty states to show when there is nothing to display in a view, for example, when a board has\nno tasks, someone clears their inbox, or a search returns no results.\n\nRead guidance on writing effective\n[empty state messages](https://atlassian.design/foundations/content/designing-messages/empty-state).\n\n<img\n\tsrc={messagesEmptyState}\n\talt="Empty state encouraging an admin to add people to a Jira project space."\n/>\n\nAn empty state can appear as a full-screen message or within panels, tables, and other containers.\n\n[Usage guidance for empty state component](https://atlassian.design/components/empty-state/usage).\n\n### Banner\n\nUse banners only for critical system-level messaging for example, warnings about loss of data or\nfunctionality.\n\n<img src={messagesBanner} alt="Banner message example with a red error message." />\n\nBanners appear at the top of the screen and shift the content below them.\n\n[Usage guidance for banner component](https://atlassian.design/components/banner/usage).\n\n### Flag\n\nUse flags for confirmations, alerts, and acknowledgments that require minimal user interaction.\n\n<img\n\tsrc={messagesFlag}\n\talt="Example of a flag message with a green tick icon, the heading \'You are now connected\', and the text describing a group the user is added to."\n/>\n\nFlags are event-driven messages that appear by overlaying content at the bottom left of the screen,\nemerging from the navigation sidebar.\n\n[Usage guidance for flag component](https://atlassian.design/components/flag/usage).\n\n### Section message\n\nUse section messages to alert the user of something that has happened in a specific section of the\nscreen.\n\n<img\n\tsrc={messagesSectionMessages}\n\talt="Example of a section message showing green tick icon, the heading Merged pull request, details of the pull request, and links to the hash and user name, and the time it happened."\n/>\n\nSection messages appear above the affected area (for example, work items in Jira).\n\n[Usage guidance for section message component](https://atlassian.design/components/section-message/usage).\n\n### Inline message\n\nUse inline messages to alert people to a required action or important information.\n\n<img\n\tsrc={messagesInlineDialog}\n\talt="Example of a cursor on a yellow caution icon triggering an inline dialog message."\n/>\n\nInline messages consist of an icon, message, and sometimes secondary text. People can interact with\nthe icon, title, or secondary text to reveal the full inline message.\n\n[Usage guidance for inline message component](https://atlassian.design/components/inline-message/usage).\n\n### Modal dialog\n\nUse modal dialogs to present a short-term task the user needs to perform.\n\n<img\n\tsrc={messagesModal}\n\talt="A modal that presents a task and a dropdown menu, with a clear action."\n/>\n\nModal dialogs display content in a layer above the page.\n\n[Usage guidance for modal dialog component](https://atlassian.design/components/modal-dialog/usage).\n\n### Benefits modal\n\nBenefits modals explain the value of a significant new feature or experience change.\n\nRead guidance on writing effective\n[feature discovery messages](https://atlassian.design/foundations/content/designing-messages/feature-discovery).\n\n<img\n\tsrc={messagesBenefitsModal}\n\talt="A modal for a Jira update that includes the key elements of a benefits modal."\n/>\n\nA benefits modal focuses a person\'s attention on a large or impactful update.\n\n[Usage guidance for benefits modal component](https://atlassian.design/components/onboarding/benefits-modal/usage).\n\n### Onboarding (spotlight) and spotlight card\n\nAn onboarding spotlight introduces new features to users through focused messages or multi-step\ntours. A spotlight card is for onboarding messages that need a more flexible layout, or don\'t\nrequire a dialog.\n\nRead guidance on writing effective\n[feature discovery messages](https://atlassian.design/foundations/content/designing-messages/feature-discovery).\n\n<img\n\tsrc={messagesOnboarding}\n\talt="An example of a spotlight pulse expanded into a spotlight component that encourages people to try the new feature."\n/>\n\n[Usage guidance for onboarding (spotlight) component](https://atlassian.design/components/onboarding/usage)\nand [spotlight card component](https://atlassian.design/components/onboarding/spotlight-card/usage).\n\n## Set the appearance (color and icon)\n\nMessages use colors and icons to help indicate content and urgency.\n\nMake sure you use the right\n[color role for your situation](https://atlassian.design/foundations/color#color-roles). For\nexample, yellow typically implies a warning, while green can imply success.\n\n<img\n\tsrc={colorRolesAndIcons}\n\talt="Icons showing different icons and colors we use in messages. Informative messages use a blue circle icon with an i inside, success is a green check icon, warning is a yelowish triangle icon with an exclamation mark, danger is a red diamond icon with an exclamation mark, and discovery or new is a purple circle with a question mark inside."\n/>\n\nReview [guidelines on using icons](https://atlassian.design/foundations/iconography) and\n[usage guidance for the icon component](https://atlassian.design/components/icon/usage).',
+  content: 'People care about how apps talk to them. YouTube, GitHub, and Slack all have a distinct voice, tone,\nand personality.\n\nApps engage us, manage to make us feel at home, capture our attention, and earn our loyalty.\n\nPoor messaging contributes to a poor user experience, which leads to dissatisfaction. On the other\nhand, good copy reflects our apps\' voice (personality) and enables us to build a better relationship\nwith our audience.\n\nIn short, good messaging may not be the reason people stay with our apps, but bad messaging could be\nthe reason they decide to leave.\n\n## Choose a message type\n\nUse different types of messages to guide people through their tasks. Each message type has a\nconsistent visual and writing style to help people know what to expect.\n\nUse these guidelines to choose and write the types of messages:\n\n- [Information message](https://atlassian.design/foundations/content/designing-messages/info-messages)\n  — provides additional information to motivate people.\n- [Error message](https://atlassian.design/foundations/content/designing-messages/error-messages) —\n  alerts people of a problem that has occurred and informs them what to do next.\n- [Success message](https://atlassian.design/foundations/content/designing-messages/success-messages)\n  — celebrates success along with the people using our apps.\n- [Warning message](https://atlassian.design/foundations/content/designing-messages/warning-messages)\n  — gives advanced notice of a potential change that may result in loss of data or an error state.\n- [Feature discovery](https://atlassian.design/foundations/content/designing-messages/feature-discovery)\n  — lets people know about a new feature.\n\n## Select the right component\n\nUse the table to identify the right component for your content.\n\nFor example:\n\n- If you want to highlight a new feature to a user, consider using spotlight or empty state.\n- If you want to tell someone they\'ve accomplished a task, consider a flag.\n\n| Component           | Information message | Success message | Warning message | Error message | Feature discovery |\n| ------------------- | ------------------- | --------------- | --------------- | ------------- | ----------------- |\n| **Empty state**     | Yes                 | Yes             |                 |               | Yes               |\n| **Banner**          | Yes                 |                 | Yes             | Yes           |                   |\n| **Flag**            | Yes                 | Yes             | Yes             | Yes           |                   |\n| **Section message** | Yes                 |                 | Yes             | Yes           |                   |\n| **Inline message**  | Yes                 | Yes             | Yes             | Yes           |                   |\n| **Modal dialog**    | Yes                 |                 | Yes             |               |                   |\n| **Spotlight**       |                     |                 |                 |               | Yes               |\n\n### Empty state\n\nUse empty states to show when there is nothing to display in a view, for example, when a board has\nno tasks, someone clears their inbox, or a search returns no results.\n\nRead guidance on writing effective\n[empty state messages](https://atlassian.design/foundations/content/designing-messages/empty-state).\n\n<img\n\tsrc={messagesEmptyState}\n\talt="Empty state encouraging an admin to add people to a Jira project space."\n/>\n\nAn empty state can appear as a full-screen message or within panels, tables, and other containers.\n\n[Usage guidance for empty state component](https://atlassian.design/components/empty-state/usage).\n\n### Banner\n\nUse banners only for critical system-level messaging for example, warnings about loss of data or\nfunctionality.\n\n<img src={messagesBanner} alt="Banner message example with a red error message." />\n\nBanners appear at the top of the screen and shift the content below them.\n\n[Usage guidance for banner component](https://atlassian.design/components/banner/usage).\n\n### Flag\n\nUse flags for confirmations, alerts, and acknowledgments that require minimal user interaction.\n\n<img\n\tsrc={messagesFlag}\n\talt="Example of a flag message with a green tick icon, the heading \'You are now connected\', and the text describing a group the user is added to."\n/>\n\nFlags are event-driven messages that appear by overlaying content at the bottom left of the screen,\nemerging from the navigation sidebar.\n\n[Usage guidance for flag component](https://atlassian.design/components/flag/usage).\n\n### Section message\n\nUse section messages to alert the user of something that has happened in a specific section of the\nscreen.\n\n<img\n\tsrc={messagesSectionMessages}\n\talt="Example of a section message showing green tick icon, the heading Merged pull request, details of the pull request, and links to the hash and user name, and the time it happened."\n/>\n\nSection messages appear above the affected area (for example, work items in Jira).\n\n[Usage guidance for section message component](https://atlassian.design/components/section-message/usage).\n\n### Inline message\n\nUse inline messages to alert people to a required action or important information.\n\n<img\n\tsrc={messagesInlineDialog}\n\talt="Example of a cursor on a yellow caution icon triggering an inline dialog message."\n/>\n\nInline messages consist of an icon, message, and sometimes secondary text. People can interact with\nthe icon, title, or secondary text to reveal the full inline message.\n\n[Usage guidance for inline message component](https://atlassian.design/components/inline-message/usage).\n\n### Modal dialog\n\nUse modal dialogs to present a short-term task the user needs to perform.\n\n<img\n\tsrc={messagesModal}\n\talt="A modal that presents a task and a dropdown menu, with a clear action."\n/>\n\nModal dialogs display content in a layer above the page.\n\n[Usage guidance for modal dialog component](https://atlassian.design/components/modal-dialog/usage).\n\n### Spotlight\n\nUse a spotlight to bring attention to a specific part of the UI, such as a button or icon, to\neducate users about key features or workflows.\n\nRead guidance on writing effective\n[feature discovery messages](https://atlassian.design/foundations/content/designing-messages/feature-discovery).\n\n<img\n\tsrc={spotlightSingleStep}\n\talt="Example of a single-step spotlight with content about Jira tasks pointing at a task on a Jira board."\n/>\n\n[Usage guidance for spotlight component](https://atlassian.design/components/spotlight/usage).\n\n## Set the appearance (color and icon)\n\nMessages use colors and icons to help indicate content and urgency.\n\nMake sure you use the right\n[color role for your situation](https://atlassian.design/foundations/color#color-roles). For\nexample, yellow typically implies a warning, while green can imply success.\n\n<img\n\tsrc={colorRolesAndIcons}\n\talt="Icons showing different icons and colors we use in messages. Informative messages use a blue circle icon with an i inside, success is a green check icon, warning is a yelowish triangle icon with an exclamation mark, danger is a red diamond icon with an exclamation mark, and discovery or new is a purple circle with a question mark inside."\n/>\n\nReview [guidelines on using icons](https://atlassian.design/foundations/iconography) and\n[usage guidance for the icon component](https://atlassian.design/components/icon/usage).',
   keywords: ['designing messages', 'messages', 'banner', 'flag', 'section message', 'inline message', 'modal', 'empty state', 'content']
 }, {
   content: "An empty state message appears after someone has completed a task or workflow, or has cleared all\ndata associated with certain functionality. For example, clearing their inbox. These messages are a\nway to celebrate, add energy, and motivate people to get on with their next task.\n\nEmpty states can appear within a particular functionality or as a full-screen message. When crafting\nan empty state message, remember that most people scan text instead of reading everything. Make\nevery word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Titles\n\n- Include an informative, scannable title. Try and limit the number of words as much as possible.\n- Titles are a good place to add wink if it’s appropriate.\n- Write in sentence case and don’t use punctuation unless it's a question.\n- Use the heading to describe the empty state or as an opportunity to tell people what they can do.\n\n### Body copy\n\n- Include the reason for the empty state and where they can go next. If there is nothing for them to\n  do, celebrate finishing a task.\n- Avoid repeating content from the title.\n- Keep messages one to two sentences long. Be considerate of people's time and patience. Be short,\n  to the point, and avoid using jargon.\n- Avoid having people look in another location for more information, but if it can't be avoided, use\n  a link to support content.\n\n### Call to action (CTA)\n\n- When offering an action to perform after an empty state, use imperative verbs such as “Try”,\n  “Remove”, or “Create”, in the CTA to describe what action people will be making instead of vague\n  terms such as “OK”.\n- An option to dismiss or cancel lets people feel reassured that they can opt-out.\n- Limit your CTA to one or two words.\n- Your CTA button should always complement the title of the empty state.\n- Empty states are an opportunity to encourage people to interact further with our apps. While\n  optional they’re a good way to educate people about where they can go next or motivate them to\n  explore.\n\nBe careful of how many call to action buttons are on one page. You don’t want to overwhelm people\nwith too many options.\n\n## Voice and tone\n\nYou want to leave people feeling motivated, supported, and delighted. Convey accurate emotions and\nmake sure people know how to respond. Follow some of the following\n[Atlassian voice and tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n### Motivate by showing possibilities\n\nCompleting a task makes people feel ambitious, inspired, curious. Provide people with the incentive\nand excitement for continued growth in our apps.\n\nShow the possibilities of what can be accomplished by presenting them with next steps, or offer\nopportunities for advanced knowledge. This is always better than leaving people at a dead end.\n\n### Delight with unexpectedly pleasing experiences\n\nWe’re celebrating the success or progress of completing a task. Write to convey excitement. You are\ngiving a pat on the back for a job well done.\n\nBut remember not to overdo it. Timing and repetition are critical. Messages that appear more\nfrequently should be more concise and less delightful, for example clearing notifications. If\nmessages are appearing repeatedly, consider multiple versions. These are low commitment experiences,\nwe want to give flowers not puppies.\n\nMessages that appear after a bigger, optimistic action can be more playful, for example, a modal\ndialog. Remember that depending on the component you use, illustrations can also help to add a wink\nto your message.\n\n## Patterns and UX strategies\n\nIf an empty state has more than one potential cause or solution, try one of the following writing\nstrategies.\n\n### An empty state vs. a blank slate message\n\nAn empty state lets people know when they’ve completed or have cleared a task(s). By contrast, a\nblank slate is a type of message in which people have never come across or tried a new feature\nbefore. Blank slates promote and encourage people to try something new.\n\nUse text, design elements, and visual clues to differentiate where people are in their journeys.",
@@ -65,7 +65,7 @@ var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
   content: '<SectionMessage title="Atlassian vocabulary">\n\tFor specific vocabulary and to view our internal word list and glossary, head to{\' \'}\n\t<Link href="https://go.atlassian.com/vocab">go/vocab (Atlassians only)</Link>.\n</SectionMessage>\n\n## Style and formatting\n\n### Abbreviations\n\n- Use the full name of features and apps in customer-facing copy.\n- Don’t use \'e.g.\', ‘i.e.’, ‘etc.’, or \'&\' as they\'re not localization friendly and can be confusing\n  for users of assistive technologies.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask the experts at Jira Service Desk.</DoDont>\n\t<DoDont type="dont"> Ask the experts at JSD.</DoDont>\n\t<DoDont type="do">Use an input component. For example, a button or a select.</DoDont>\n\t<DoDont type="dont"> Use an input component, e.g. a button or a select etc.</DoDont>\n</DoDontGrid>\n\n#### Plural abbreviations\n\nDon’t use an apostrophe for plural abbreviations.\n\n<DoDontGrid>\n\t<DoDont type="do">1990s, DVDs</DoDont>\n\t<DoDont type="dont"> 1990’s, DVD’s</DoDont>\n</DoDontGrid>\n\n### Articles (a, an, the)\n\nAvoid articles in buttons, labels, and action-based headings in the UI.\n\n<DoDontGrid>\n\t<DoDont type="do">Create password</DoDont>\n\t<DoDont type="dont"> Create a password</DoDont>\n</DoDontGrid>\n\n### Bold\n\nUse bold text to draw the reader’s eye to key phrases and statements in your content, though don\'t\nover do it.\n\n- For in-app copy or help articles, use bold when referring to static UI elements like menu items,\n  buttons, or headings.\n- If bold is needed but the UI doesn’t support it — for example in a UI message or a flag where the\n  title is already bold — you can use [italics](#italics).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>General configuration</b> then <b>User macros</b>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tGo to the <b>settings page and select Configuration</b>.\n\t</DoDont>\n</DoDontGrid>\n\n### Capitalization\n\n- Use sentence case in all titles, headings, menu items, labels, and buttons.\n- Capitalize proper nouns in headings, such as names of people, companies, or apps.\n\n<DoDontGrid>\n\t<DoDont type="do">Create work item</DoDont>\n\t<DoDont type="dont">Create Work Item</DoDont>\n\t<DoDont type="do">Add permissions for Arni Karan</DoDont>\n\t<DoDont type="dont">Add permissions for arni karan</DoDont>\n</DoDontGrid>\n\n### Contractions (shortened words)\n\n- Use contractions, where possible, as they convey a conversational, friendly tone.\n- Use curly apostrophes in UI copy\n  - On a Mac: **option** + **shift** + **]**\n  - On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDontGrid>\n\t<DoDont type="do">We can’t load this page.</DoDont>\n\t<DoDont type="dont">We cannot load this page.</DoDont>\n</DoDontGrid>\n\n### Date and time\n\nView [date and time guidelines](https://atlassian.design/foundations/content/date-time).\n\n### Gender (he, she, they)\n\n- If known, use the pronouns a customer provides. If you don’t know, avoid gendered pronouns\n  wherever possible.\n- If it’s not possible, use ’they’ or ’their’ rather than ‘his/her’ or ’he/she’.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask your admin to add you.</DoDont>\n\t<DoDont type="dont">Ask your admin if she can add you.</DoDont>\n\t<DoDont type="do">Add permissions to their account.</DoDont>\n\t<DoDont type="dont">Add permissions to her account.</DoDont>\n</DoDontGrid>\n\n### Headings and titles\n\n- Use sentence case. Only capitalize the first word of a sentence, proper nouns, and trademarked\n  names (for example: apps, countries, people\'s names).\n- Don’t use bold or italics.\n- Don\'t use periods.\n- Reconsider using question marks. Preferably rephrase the heading so it’s a statement.\n- Phrase UI and documentation headings with an action verb.\n- Avoid gerunds (the ‘ing’ form of verbs) in UI copy.\n\n<DoDontGrid>\n\t<DoDont type="do">Organize your to-do list with Trello</DoDont>\n\t<DoDont type="dont">\n\t\tWant to Organize <em>Your</em> To-Do List With Trello?\n\t</DoDont>\n\t<DoDont type="do">Add a page to your project</DoDont>\n\t<DoDont type="dont">Adding a page to your project</DoDont>\n</DoDontGrid>\n\n#### Articles in headings\n\n- Articles (a, an, the) aren’t always needed in UI headings.\n- They\'re better suited to more conversational sections, like product marketing copy and empty\n  states, as they make these sections more approachable and improve understanding.\n\n<DoDontGrid>\n\t<DoDont type="do">Create work item</DoDont>\n\t<DoDont type="dont">Create a work item</DoDont>\n</DoDontGrid>\n\n### Italics\n\nIn apps, use italics sparingly as it can be difficult to read. Don’t use italics in hyperlinks.\n\nItalics can be used for:\n\n- UI elements that might change, like a field name or user input.\n- For emphasis if the UI doesn’t support bold. For example, in a flag or UI message.\n\n### Lists\n\nUse lists to draw the reader’s eye and make items easier to scan and follow. Try to limit lists to 6\nitems or less. If there are more items, make multiple lists.\n\n#### Bulleted list\n\n- Use to list options or when the order of the items doesn’t matter.\n- Phrase each item in a parallel way.\n- Don’t use commas or periods at the end of each item.\n\n##### Fragmented sentences\n\nIf your list has fragmented sentences, use a lowercase letter for each item and don’t use a period\nat the end of the list. Use a lead-in sentence with a colon before the items.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tDue to security concerns, all employees are required to:\n\t\t<ul>\n\t\t\t<li>wear an identification tag</li>\n\t\t\t<li>use their security pass to enter or leave an office before 7 a.m. and after 6 p.m.</li>\n\t\t\t<li>alert security if a suspicious package is found</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tDue to security concerns, all employees are required to;\n\t\t<ul>\n\t\t\t<li>Wear an identification tag in the building,</li>\n\t\t\t<li>\n\t\t\t\tYou must use your identification tag to enter an office before 7 a.m. and exit after 6 p.m.,\n\t\t\t\tand\n\t\t\t</li>\n\t\t\t<li>If a suspicious package is found, alert security.</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n##### Complete sentences\n\nFor lists with complete sentences, start an item with a capital letter and end it with a period.\nDon’t use a lead-in sentence with a colon.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tAtlassian has updated security requirements for employees.\n\t\t<p></p>\n\t\t<ul>\n\t\t\t<li>Always wear your identification tag when working in an office.</li>\n\t\t\t<li>\n\t\t\t\tUse your identification tag to enter an office before 7 am and when you leave after 6 pm.\n\t\t\t</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tAtlassian has updated security requirements for employees:\n\t\t<ul>\n\t\t\t<li>always wear your identification tag when working in an office</li>\n\t\t\t<li>\n\t\t\t\tuse your identification tag to enter an office before 7 am and when you leave after 6 pm.\n\t\t\t</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n#### Numbered lists\n\nUse numbered lists for tasks or lists where the order of the items matters. Capitalize the first\nword of each item and end the item with a period.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tTo add a new user macro:\n\t\t<ol>\n\t\t\t<li>\n\t\t\t\tGo to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b>.\n\t\t\t</li>\n\t\t\t<li>\n\t\t\t\tChoose <b>Create a user macro</b>.\n\t\t\t</li>\n\t\t\t<li>Enter the macro details.</li>\n\t\t</ol>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tTo add a new user macro -\n\t\t<ol>\n\t\t\t<li>\n\t\t\t\tgo to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b>\n\t\t\t</li>\n\t\t\t<li>\n\t\t\t\tchoose <b>Create a user macro</b>\n\t\t\t</li>\n\t\t\t<li>enter the macro details.</li>\n\t\t</ol>\n\t</DoDont>\n</DoDontGrid>\n\n### Monospaced text\n\nUse `monospaced font` for names of a file or directory. It’s mostly used in attributes, strings, and\nadministrator and developer docs.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tThe location of the Home directory is stored in a configuration file called\n\t\t<code>confluence-init.properties</code>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tThe location of the Home directory is stored in a configuration file called{\' \'}\n\t\t<b>confluence-init.properties</b>.\n\t</DoDont>\n</DoDontGrid>\n\n### Numbers\n\nUse digits rather than words in most cases.\n\n**Exceptions**:\n\n- If a number starts a sentence, write it out.\n- In common expressions, write the number out. For example: _It’s one thing after another_.\n- When writing long-form or formal content, write out numbers one to nine.\n- Write out the numbers ‘zero’ and ‘one’ if it could be confused for the letters L, I, or O.\n\n<DoDontGrid>\n\t<DoDont type="do">Your password should be a minimum of 8 characters. </DoDont>\n\t<DoDont type="dont">Your password should be a minimum of eight characters.</DoDont>\n\t<DoDont type="do">Loom is one of the best apps for sharing information in a personal way.</DoDont>\n\t<DoDont type="dont">Loom is 1 of the best apps for sharing information in a personal way.</DoDont>\n</DoDontGrid>\n\n#### Number ranges\n\nUse ’to’ and not hyphens in number ranges, except if space is limited, like in a table or mobile\napp.\n\n<DoDontGrid>\n\t<DoDont type="do">View rows 1 to 4 in the table.</DoDont>\n\t<DoDont type="dont">View rows 1-4 in the table.</DoDont>\n</DoDontGrid>\n\n#### Numbers \'out of\'\n\nUse ‘of’ rather than a forward slash ( / ) to show a number out of another number.\n\n<DoDontGrid>\n\t<DoDont type="do">Step 1 of 2</DoDont>\n\t<DoDont type="dont">Step 1/2</DoDont>\n</DoDontGrid>\n\n#### Numbers from 1,000\n\nUse a comma to indicate the thousand in a number.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>4,500</li>\n\t\t\t<li>10,000</li>\n\t\t\t<li>1,250,000</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>4500</li>\n\t\t\t<li>10000</li>\n\t\t\t<li>1250000</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Spelling words\n\nUse US English in UI copy and code. Check spellings in\n[Merriam-Webster online dictionary](https://www.merriam-webster.com/).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>color</li>\n\t\t\t<li>organization</li>\n\t\t\t<li>labeled</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>colour</li>\n\t\t\t<li>organisation</li>\n\t\t\t<li>labelled</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Truncation\n\nEllipses (…) are used to show that text has been cut off — or truncated — when a message doesn’t fit\nin a given space.\n\n- Avoid truncation whenever possible: shorten UI messages or wrap the text.\n- Test your designs using multiple screen widths and magnification levels to ensure it doesn’t\n  truncate.\n- If truncation can’t be avoided, for example in user-generated content or icon buttons, use a\n  [tooltip](https://atlassian.design/components/tooltip/examples) to display the full text for\n  accessibility and usability.\n- In ADS components that truncate, the ellipsis appears without any space next to the last visible\n  character (for example: Work in pro…).\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: truncationDo, alt: \'\' }}>\n\t\tShorten or wrap messages.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: truncationDont, alt: \'\' }}>\n\t\tDon’t truncate unless it can’t be avoided.\n\t</DoDont>\n</DoDontGrid>\n\n### UI elements\n\n- Use sentence case, even if the UI element doesn’t use it.\n- Use bold to emphasize the UI element in a step.\n- If the UI element has an icon, bold both the name and the icon.\n- Avoid using a > symbol where possible, as it is read out as “greater than” by assistive\n  technologies, leading to confusion. Use ‘then’ instead.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>More</b>, then <b>Link work item</b>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tGo to <b>More</b> > <b>Link Work Item</b>.\n\t</DoDont>\n</DoDontGrid>\n\n## Grammar\n\n### Active voice\n\nUse active voice whenever possible as it improves readability and reflects Atlassian’s\n[voice and tone](https://atlassian.design/foundations/content/voice-tone).\n\nActive voice:\n\n- puts the emphasis on the person or thing doing an action.\n- makes content shorter, clearer, friendlier, and more conversational.\n\n<DoDontGrid>\n\t<DoDont type="do">Administrators control access to Atlassian Cloud applications.</DoDont>\n\t<DoDont type="dont">\n\t\tAccess to Atlassian Cloud applications is controlled by administrators.\n\t</DoDont>\n</DoDontGrid>\n\n### Pronouns (you, your, we)\n\n- Minimize the use of pronouns.\n- Most of the time they can be avoided. However, when advising a user, indicating that something in\n  the UI is theirs, or in error messages, you can use ‘you’ or ’your’ or ’we’ for a friendlier tone.\n\n<DoDontGrid>\n\t<DoDont type="do">Get access to your work items here.</DoDont>\n\t<DoDont type="dont">Get access to the work items here.</DoDont>\n\t<DoDont type="do">Your projects</DoDont>\n\t<DoDont type="dont">My projects</DoDont>\n\t<DoDont type="do">We couldn\'t load your page</DoDont>\n\t<DoDont type="dont">The page couldn\'t be loaded </DoDont>\n</DoDontGrid>\n\n### Tense\n\n**Present tense** helps make instructions and messages in the UI clear and engaging.\n\n<DoDontGrid>\n\t<DoDont type="do">We can’t load work item DSP-32113.</DoDont>\n\t<DoDont type="dont">We couldn’t load work item DSP-32113.</DoDont>\n\t<DoDont type="do">Validation is required.</DoDont>\n\t<DoDont type="dont">Validation will be required.</DoDont>\n</DoDontGrid>\n\n**Past tense** can be used to communicate a completed action, like in error message headings and\nsuccess flags, or where there could be confusion.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>Upload failed</li>\n\t\t\t<li>File created</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>Upload fail</li>\n\t\t\t<li>File create</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n## Punctuation\n\n### Apostrophes (\')\n\n- Use an apostrophe to show possession. The apostrophe is placed before the ‘s’ for singular terms\n  and after the ‘s’ for plurals.\n- If a word ends in an ‘s’ and is singular, add an ‘s after the ‘s’.\n- Use a curly apostrophe for better readability and to differentiate from code.\n  - On a Mac: **option** + **shift ** + **]**\n  - On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>A week’s time</li>\n\t\t\t<li>Three weeks’ time</li>\n\t\t\t<li>James’s work items</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>A weeks time</li>\n\t\t\t<li>Three week\'s time</li>\n\t\t\t<li>James\' work items</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Colons (:)\n\n- Use colons to introduce a bulleted list or series of steps.\n- Don’t use colons at the end of headings.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tA password should have:\n\t\t<ul>\n\t\t\t<li>12 characters or more </li>\n\t\t\t<li>at least one symbol and one number</li>\n\t\t\t<li>a mix of capital and lowercase letters</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<p>\n\t\t\t<b>Turn on two-factor authentication:</b>\n\t\t</p>\n\t\t<p>Keep your account safe with an extra layer of security.</p>\n\t</DoDont>\n</DoDontGrid>\n\n### Commas (,)\n\nUse an Oxford (or ‘serial’) comma to offset the final item in a list.\n\n<DoDontGrid>\n\t<DoDont type="do">Jira, Confluence, Loom, and Bitbucket are all Atlassian apps.</DoDont>\n\t<DoDont type="dont">Jira, Confluence, Loom and Bitbucket are all Atlassian apps. </DoDont>\n</DoDontGrid>\n\n### Dashes (—) and hyphens (-)\n\n#### Dashes\n\n- Use dashes in UI content sparingly. If using, use a spaced em dash.\n- In long-form content, use them sparingly to show an abrupt change in a sentence — like this. If\n  the break happens in the middle of a sentence —  ike this — use spaced em dashes on either side of\n  the phrase.\n- If possible, rewrite the sentence or make 2 sentences to avoid a dash. Clear, concise sentences\n  are better for readability and accessibility.\n- Don\'t use a dash or hyphen for ranges of numbers. Use \'to\' instead.\n- When adding the space, use non-breaking spaces (**option** + **shift** + **space**) to avoid the\n  dash shifting to a new line.\n- To make an em dash:\n  - On a Mac: **option** + **shift** + **hyphen**\n  - On Windows: **Control** + **Alt** + **-** (or **Alt** + **0151**)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tJira Service Management belongs to Jira\'s family of apps. They’re all built on the same platform\n\t\tand share the same site URL.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tJira Service Management belongs to Jira\'s family of apps — they’re all built on the same\n\t\tplatform and share the same site URL.\n\t</DoDont>\n\t<DoDont type="do">50 to 100</DoDont>\n\t<DoDont type="dont">50—100</DoDont>\n</DoDontGrid>\n\n#### Hyphens\n\n- If a noun is described by 2 or more words, use a hyphen to join those words together so they act\n  as a compound adjective (or compound modifier).\n- **Exceptions**: don’t add a hyphen after the word ‘very’ or adverbs ending in -ly.\n- For specific hyphenated word guidance, check\n  [Vocabulary (Atlassians only)](https://hello.atlassian.net/wiki/spaces/AV/pages/1686830783/Atlassian+global+vocabulary+list).\n- Use a hyphen when not doing so could cause confusion or ambiguity. Consult the\n  [Merriam-Webster dictionary](https://www.merriam-webster.com/) if you’re not sure.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>system-wide update</li>\n\t\t\t<li>character-counter logic</li>\n\t\t\t<li>widely communicated update</li>\n\t\t\t<li>very cold drink</li>\n\t\t\t<li>autocorrect</li>\n\t\t\t<li>coworker</li>\n\t\t\t<li>preexisting</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>system wide update</li>\n\t\t\t<li>character counter logic</li>\n\t\t\t<li>widely-communicated update</li>\n\t\t\t<li>very-cold drink</li>\n\t\t\t<li>auto-correct</li>\n\t\t\t<li>co-worker</li>\n\t\t\t<li>pre-existing</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>re-sign the document</li>\n\t\t\t<li>re-create the page</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>resign the document</li>\n\t\t\t<li>recreate the page</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Ellipses ( … )\n\n- Don’t put spaces in between the periods in an ellipsis.\n- Use the symbol for the ellipsis rather than a string of periods:\n  - On a Mac: **Option** + **;**\n  - On Windows: **Ctrl** + **Alt** + **.** (or **Alt** + **0133**)\n\n#### Truncation\n\nEllipses can be used to show that text has been cut off — or truncated — when a message doesn’t fit\nin a given space. View [truncation guidance](#truncation).\n\n#### Quotes\n\n- When using an ellipsis to omit part of a long quote, include spaces on either side of the ellipsis\n  ( … ).\n- For example: “From medicine and space travel to disaster response … our products help teams all\n  over the planet advance humanity through the power of software.” Atlassian: Discover our story.\n\n### Exclamation marks (!)\n\n- Avoid exclamation marks in UI copy and minimize their use in product marketing copy.\n- They can be considered for exciting or new things, but ask yourself if it’s really that exciting\n  or if one is needed. Don’t use more than one exclamation mark per page.\n\n<DoDontGrid>\n\t<DoDont type="do">Project is complete.</DoDont>\n\t<DoDont type="dont">Project is complete!</DoDont>\n</DoDontGrid>\n\n### Periods (.)\n\n- Use a period (full stop) at the end of complete sentences, including in helper text, messages, and\n  notifications.\n- Don’t use periods in headers, titles, tooltips, field descriptions, and menu names, even if they\n  are full sentences. While long content is discouraged, an exception is if these elements contain\n  more than 1 sentence.\n- Only use periods in a bulleted list if the item is a complete sentence. Don’t add a period at the\n  end of a list of fragments.\n- Add only one space after a period (full stop).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<p>\n\t\t\t<b>Accessibility principles</b>\n\t\t</p>\n\t\t<p>Our principles cover the main requirements to design and build accessible experiences.</p>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<p>\n\t\t\t<b>Accessibility principles.</b>\n\t\t</p>\n\t\t<p>Our principles cover the main requirements to design and build accessible experiences.</p>\n\t</DoDont>\n</DoDontGrid>\n\nIf a link ends a sentence, include a period but don’t hyperlink it.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tAtlassian’s work is guided by{\' \'}\n\t\t<a href="https://www.atlassian.com/company/values">5 core values</a>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tAtlassian’s work is guided by{\' \'}\n\t\t<a href="https://www.atlassian.com/company/values">5 core values.</a>\n\t</DoDont>\n</DoDontGrid>\n\n### Quotation marks (‘’ | “”)\n\nIn the UI, use:\n\n- single curly quotes, unless you\'re writing in code or there’s a semantic reason to use straight\n  quotes.\n\nIn body copy and long-form content, such as documentation and marketing, use:\n\n- double quotes (”“) for speech and direct quotes. Don’t use italics.\n- single quotes (‘’) to draw attention to a word you’re defining.\n\n<DoDontGrid>\n\t<DoDont type="do">“We have big things planned for the coming year,” said Mike.</DoDont>\n\t<DoDont type="dont">‘We have big things planned for the coming year,’ said Mike.</DoDont>\n\t<DoDont type="do">They tried to avoid talking about the ‘big’ secret.</DoDont>\n\t<DoDont type="dont">They tried to avoid talking about the “big“ secret.</DoDont>\n</DoDontGrid>\n\n#### Emphasis\n\nDon’t use quotation marks to emphasize UI elements, page titles, and other objects. Instead use\n[bold](#bold).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>Settings</b>.\n\t</DoDont>\n\t<DoDont type="dont">Go to ‘Settings’.</DoDont>\n</DoDontGrid>\n\n#### Shortcuts\n\n##### Mac\n\n- Double quotes:\n  - opening marks: **option** + **[**\n  - closing marks: **option** + **shift** + **[**\n- Single quotes:\n  - opening marks: **option** + **]**\n  - closing marks: **option** + **shift** + **]**\n\n##### Windows\n\n- Double quotes:\n  - opening marks: **Alt** + **0147**\n  - closing marks: **Alt** + **0148**\n- Single quotes:\n  - opening marks: **Alt** + **0145**\n  - closing marks: **Alt** + **0146**',
   keywords: ['language', 'grammar', 'capitalization', 'truncation', 'content']
 }, {
-  content: 'We use the Atlassian voice and tone in all of our properties and content, from user interfaces to\nemail, social media, and other channels.\n\nAny Atlassian who works with customer-facing communications should follow the voice and tone\nguidelines: content designers, engineers, product designers, blog contributors, product managers,\nmarketers... pretty much everyone.\n\nTo help teams do the best work of their lives, we:\n\n- offer solutions that help people at the moment they need it\n- simplify complex problems into easy-to-understand pieces\n- inspire people to try new things\n\nWith a familiar tone, clear language, and a solid knowledge of our audience, we craft messages that\nget teams moving in the right direction, then we get out of their way.\n\nThe Atlassian voice is based on the Atlassian brand personality traits of:\n\n- bold\n- optimistic\n- practical, with a wink\n\nTo provide consistent, friendly, and helpful content for people, use this guidance with our other\nguidelines:\n\n- [Language and grammar](https://atlassian.design/foundations/content/language-and-grammar)\n- [Inclusive language](https://atlassian.design/foundations/content/inclusive-writing)\n- [Vocabulary (Atlassians only)](https://go.atlassian.com/vocab)\n\n## Atlassian’s personality traits\n\nWhen writing with Atlassian\'s voice, we\'re part of the team. We\'re that friend or colleague who is\nalways up on new trends and wants to be helpful and share new wisdom with everyone in a relatable\nway.\n\nWe know when it\'s time to be serious and direct, and when it\'s time to be more casual.\n\nPersonality comes across best in the details. The emphasis of each trait should be contextual to the\naudience and situation.\n\nHere are some questions you can ask yourself during your process to assess whether or not you’re\nleveraging our personality traits well.\n\n- What is the emotional state of the person when encountering your solution during their journey?\n- How might our personality traits help enhance a moment of celebration?\n- How might our personality traits help diffuse a moment of frustration or pain?\n\n### Bold\n\nMotivate teams to do their best work. Offer best practices to get people going in the right\ndirection.\n\nBe bold and offer just enough help to get the work started, and then get out of the way.\n\nGive accurate information so people can make educated decisions. Understand the person\'s struggles\nand desired outcomes and give enough information to let them get where they need to go.\n\n### Optimistic\n\nGo on the journey with people and highlight the key points that will help them the most, right now.\n\nBe in the moment by focusing attention on the important bits first. This gives people confidence in\nour apps.\n\nWeave a consistent story across our fabric and be diligent about vocabulary across all messaging by\nbeing brand-conscious across apps.\n\nCreate a seamless flow across all the things. Let people know that they can jump in and start\nworking, and can expect a familiar experience across all of the things. Keep teams in the loop about\nwhat is happening by informing them of relevant features, apps, and opportunities for success.\n\n### Practical, with a wink\n\nGet to the point and be direct. Be concise.\n\nBe on the lookout for opportunities and be quick to offer a helping hand. Give the user just enough\nto know that something awesome is around the corner and then get out of the way.\n\nWrite clear, accurate, and concise text that makes interfaces more usable and consistent — and\nbuilds trust.\n\nWrite text that is understandable by anyone, anywhere, regardless of their culture or language so\nthat everyone feels they are part of the team.\n\n## Voice and tone principles\n\nA consistent voice creates better relationships with our customers.\n\nBut, there is one caveat.\n\nThere are times when you need to speak to different subsets of people, for instance among different\napps, and your tone might not be quite the same. That\'s okay! We\'ve provided enough guidance to help\nadjust our tone to accommodate for:\n\n- where people are at in their journey\n- their emotional state\n- the app or property you are writing for\n\nThe voice and tone principles:\n\n- [Inform to build trust](https://atlassian.design/foundations/content/voice-tone#inform-to-build-trust)\n- [Empower to inspire action](https://atlassian.design/foundations/content/voice-tone#empower-to-inspire-action)\n- [Encourage people along the path](https://atlassian.design/foundations/content/voice-tone#encourage-people-along-the-path)\n- [Motivate by showing possibilities](https://atlassian.design/foundations/content/voice-tone#motivate-by-showing-possibilities)\n- [Satisfy by meeting expectations](https://atlassian.design/foundations/content/voice-tone#satisfy-by-meeting-expectations)\n- [Delight with unexpectedly pleasing experiences](https://atlassian.design/foundations/content/voice-tone#delight-with-unexpectedly-pleasing-experiences)\n\n### Inform to build trust\n\n**Inform** by being **open** and **clear** on what people are experiencing in our apps.\n\nTell people what they need to know at that moment and nothing more. Be aware of when a user may be\nnew or confused, and tone down the boldness by being more prescriptive. Let people know where they\nare in their journey and what they are looking at in the app.\n\nWrite as a knowledgable member of the team. Show up at the right time and be open, humble, and warm\n— offer direction for the most appropriate next steps and get out of the way.\n\n#### When we need to be less bold\n\nPerson is feeling: apprehension, confusion, annoyance, fear, loathing, anger.\n\nExamples: new users, evaluators, and when introducing a new concept, feature, or app\n\n<img\n\tsrc={lessBoldLight}\n\tsrcDark={lessBoldDark}\n\talt="Slider between less bold and more bold, with the dot much closer to less bold end."\n/>\n\n#### Places we use this principle\n\n- In-app: [flags](https://atlassian.design/components/flag/usage),\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages),\n  and [onboarding (spotlight)](https://atlassian.design/components/onboarding/usage)\n- Being informative and to build trust\n\n### Empower to inspire action\n\n**Educate** where we people need it most. Offer **opportunities** to learn at pivotal times to\n**empower** people to move in the right direction. Offer best practices and recommendations for next\nsteps while suggesting ways to improve and make decisions.\n\nLet people know Atlassian and fellow community members are available to help people make decisions.\n\nWrite as if you are educating. You are a teacher with empathy and an understanding of what it’s like\nto be in the weeds. You expect your audience to have a basic understanding.\n\n#### When we want to be more bold\n\nPerson is feeling: confident, interested, trust, anticipation.\n\nExamples: power users, admins, everyday users\n\n<img\n\tsrc={moreBoldLight}\n\tsrcDark={moreBoldDark}\n\talt="Slider between less bold and more bold, with the dot much closer to more bold end."\n/>\n\n#### Places we use this principle\n\n- In-app: [onboarding (spotlight)](https://atlassian.design/components/onboarding/usage),\n  [benefits modal](https://atlassian.design/components/onboarding/benefits-modal/usage), and\n  [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Something requires an action from the person\n- Educational opportunities\n- Social opportunities — let them know best practices\n\n### Encourage people along the path\n\n**Inspire** initial **optimism** by providing **support** in the right place. Be **consistent** and\n**dependable**.\n\nOffer waypoints, help, and support if people are feeling confused or frustrated at a point in their\njourney. This principle is about being human, giving guidance, support, and encouragement along the\nway.\n\nGuide people by revealing information gracefully. Let them know they are on the right path, they\naren’t alone, and that delivering projects and building teams can be challenging.\n\nWrite in an upbeat, friendly way. Acknowledge the opportunities in the here-and-now and walk through\nit with them.\n\n#### When we need to be less optimistic\n\nPerson is feeling: anticipation, unsupported, confused, uncertain\n\nExamples: new to Atlassian, evaluators, or when introducing a new concept, feature, or app\n\n<img\n\tsrc={lessOptimisticLight}\n\tsrcDark={lessOptimisticDark}\n\talt="Slider between less optimistic and more optimistic, with the dot much closer to the less optimistic end."\n/>\n\n#### Places we use this principle\n\n- In-app:\n  [information messages](https://atlassian.design/foundations/content/designing-messages/info-messages),\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages),\n  and [section messages](https://atlassian.design/components/section-message/usage)\n- Something requires an action from the person\n\n### Motivate by showing possibilities\n\nProvide **incentive** and **excitement** for continued growth.\n\nConsider why someone would want to do this.\n\nShow the possibilities of what can be accomplished by giving examples of how other people accomplish\nthe same task, or by presenting the ideal state. Describe the end result, giving expert testimony,\nor offer opportunities for advanced knowledge.\n\nWrite like an expert. Focus more on the solution than on the problem. Show people the possible\nbenefits.\n\n#### When we want to be more optimistic\n\nPerson is feeling: ambitious, inspired, curious, admiration.\n\nExamples: power users, admins, everyday users\n\n<img\n\tsrc={moreOptimisticLight}\n\tsrcDark={moreOptimisticDark}\n\talt="Slider between less optimistic and more optimistic, with the dot much closer to the more optimistic end."\n/>\n\n#### Places we use this principle\n\n- In-app: [onboarding (spotlight)](https://atlassian.design/components/onboarding/usage) and\n  [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Educational opportunities — it\'s a chance to tell them how other industry leaders do it, give best\n  practices, and tips and tricks\n\n### Satisfy by meeting expectations\n\nGive people what they need.\n\nProvide **quick and thorough** answers, guidance, actions, and instructions. We aren’t trying to\nlead, inspire, motivate, delight, or encourage. Simply tell people what they need to know and get\nout of the way.\n\nAll of our content should be practical at a minimum. Write as if you are explaining to your friend\nhow to travel somewhere you’ve visited regularly.\n\n#### When we need to be practical\n\nPerson is feeling: overwhelmed and stressed.\n\nExamples: people under pressure with deadlines — everyone feels this way sometimes\n\n<img\n\tsrc={lessWinkyLight}\n\tsrcDark={lessWinkyDark}\n\talt="Slider between practical and winky, with the dot much closer to the practical end."\n/>\n\n#### Places we use this principle\n\n- Whenever we can\n- In-app:\n  [warning messages](https://atlassian.design/foundations/content/designing-messages/warning-messages),\n  [information messages](https://atlassian.design/foundations/content/designing-messages/info-messages),\n  and\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages)\n\n### Delight with unexpectedly pleasing experiences\n\n“Wink” where appropriate. We deliver appropriate **delight** — celebrate **success** or **progress**\nonce we’ve built **trust**.\n\nBut don’t overdo it. These are little flourishes: we give flowers, not puppies.\n\nPay particular attention to people’s state of mind. Think about the timing, and how frequently they\nwill see this.\n\n#### When we can share a little delight\n\nPerson is feeling: successful, joy, pride, relief.\n\nExamples: evaluators, power users, during social interactions\n\n<img\n\tsrc={moreWinkyLight}\n\tsrcDark={moreWinkyDark}\n\talt="Slider between practical and winky, with the dot much closer to the winky end."\n/>\n\n#### Places we use this principle\n\n- In-app:\n  [success messages](https://atlassian.design/foundations/content/designing-messages/success-messages)\n  and [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Social interactions and while introducing new experiences',
+  content: "<SectionMessage title=\"\">\n\tThe guidance on this page relates to voice and tone for user interfaces and app experiences. For\n\tbroader guidance, including marketing, view{' '}\n\t<Link href=\"https://go.atlassian.com/voice-tone\">Brand Voice and Tone (Atlassians only)</Link>\n</SectionMessage>\n\nOur voice is essentially Atlassian's personality and is made up of the following traits:\n\n- Bold\n- Optimistic\n- Practical, with a wink\n\nTone is how we express Atlassian’s voice, and it should change depending on the situation the user\nis in (for example, receiving an error versus successfully completing a project).\n\nWhether it’s writing content for our apps, user interface, websites, or communications, you should\nfollow our voice and tone guidelines to ensure people recognize they’re interacting with Atlassian\nwherever they are.\n\n## How to apply Atlassian’s personality traits\n\nHow each trait is applied should depend on the audience and situation. Use these questions to help\nyou work out the right balance:\n\n- What is the emotional state of the user when they encounter your content or solution, and where\n  are they on their journey?\n- How might our personality traits enhance a moment of celebration?\n- How might our personality traits diffuse a moment of frustration or pain?\n\n<br></br>\n\n### Bold\n\nWhen we say bold, it’s about motivating teams with the right amount of support at the right time to\ndo their best work.\n\n- Offer best practices or just enough help to get the work started.\n- Give accurate information so people can make educated decisions.\n- Understand a person's struggles and desired outcomes, and give just enough information so someone\n  can get where they need to go.\n\n#### When to be more bold\n\n- Person is feeling: confident, interested, trust, anticipation.\n- Examples: power users, admins, daily users.\n\n#### When to be less bold\n\n- Person is feeling: apprehension, confusion, annoyance, fear, anger.\n- Examples: new users, trial users, when introducing a new concept, feature, or app.\n\n<br></br>\n\n### Optimistic\n\nWriting with optimism is understanding where in the journey someone is and highlighting the key\npoints that will help them along the way.\n\n- Focus on the most important bits the person needs in the moment. This gives people confidence in\n  our apps.\n- Weave a consistent story across apps and use the same vocabulary across all messaging.\n- Create a seamless flow across experiences. This lets people know that no matter where they’re\n  working, they can expect a familiar, consistent experience.\n- Keep people in the loop by informing them of relevant features, apps, and opportunities for\n  success.\n\n#### When to be more optimistic\n\n- Person is feeling: ambitious, inspired, curious, admiration.\n- Examples: power users, admins, daily users.\n\n#### When to be less optimistic\n\n- Person is feeling: anticipation, unsupported, confused, uncertain.\n- Examples: someone is new to Atlassian, trial users, when introducing a new concept, feature, or\n  app.\n\n<br></br>\n\n### Practical, with a wink\n\nOur practical side means getting to the point and being direct and concise.\n\n- Be on the lookout for opportunities where we can offer a helping hand.\n- Write clear, accurate, and concise content that makes interfaces more usable and consistent — and\n  builds trust.\n- Write content that is understandable for anyone, anywhere, regardless of their culture or language\n  so that everyone feels part of the team.\n\nThe ‘with a wink’ part of this trait needs more discernment when applying it to UI and app content\n(as opposed to marketing content) and remember that it isn’t always appropriate to use. Be mindful\nof where someone is at and what they might be experiencing before going beyond the practical.\n\n#### When to be more practical\n\n- Person is feeling: overwhelmed, unsure, hesitant, stressed.\n- Examples: people with deadlines or being blocked by errors, supporting new or occasional users,\n  introducing new features.\n\n#### When you can add the ‘wink’\n\n- Person is feeling: successful, joy, proud, relief.\n- Examples: power users, during social interactions, success messages.\n\n<br></br>\n\n## Voice and tone principles\n\nAtlassian's personality traits help keep our voice consistent across a range of different customer\nand app experiences. We can better support the full spectrum of experience for people by applying\nthe following principles.\n\nOur voice and tone principles:\n\n- [Inform to build trust](https://atlassian.design/foundations/content/voice-tone#inform-to-build-trust)\n- [Empower to inspire action](https://atlassian.design/foundations/content/voice-tone#empower-to-inspire-action)\n- [Encourage people along the path](https://atlassian.design/foundations/content/voice-tone#encourage-people-along-the-path)\n- [Motivate by showing possibilities](https://atlassian.design/foundations/content/voice-tone#motivate-by-showing-possibilities)\n- [Satisfy by meeting expectations](https://atlassian.design/foundations/content/voice-tone#satisfy-by-meeting-expectations)\n- [Delight with unexpectedly pleasing experiences](https://atlassian.design/foundations/content/voice-tone#delight-with-unexpectedly-pleasing-experiences)\n\n<br></br>\n\n### Inform to build trust\n\nBe open and clear about the experience.\n\n- Tell people only what they need to know in the moment and nothing more.\n- Be aware of when a user may be new or confused, and tone down the boldness by being more\n  prescriptive.\n- Let people know where they are in their journey and what this part of the app will do.\n\nWrite as a knowledgable member of the team. Show up at the right time and be open, humble, and warm.\nOffer direction for the most appropriate next steps.\n\n#### Places to use 'Inform to build trust'\n\n- In-app: [flags](https://atlassian.design/components/flag/usage),\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages),\n  and [spotlights](https://atlassian.design/components/spotlight/usage)\n- New features or apps\n- In confusing, warning, or error states\n\n<br></br>\n\n### Empower to inspire action\n\nEducate where people need it most.\n\n- Offer opportunities to learn at pivotal times to empower people to move in the right direction.\n- Give best practices and recommendations for next steps.\n- Suggest ways to improve or make decisions.\n- Let people know that Atlassian and fellow community members are available to help them make\n  decisions.\n\nWrite as if you are educating. You are a teacher with empathy and an understanding of what it’s like\nto be in the weeds. You expect your audience to have a basic understanding.\n\n#### Places to use 'Empower to inspire action'\n\n- In-app: [spotlights](https://atlassian.design/components/spotlight/usage) and\n  [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- When something requires an action\n- When guidance is needed\n\n<br></br>\n\n### Encourage people along the path\n\nInspire by providing support in the right place. Be consistent and dependable.\n\n- Offer waypoints, help, and support if people are feeling confused or frustrated at points along\n  their journey.\n- Be human: give guidance, support, and encouragement along the way.\n- Guide people by revealing information gracefully. Let them know they’re on the right path, they\n  aren’t alone, and that delivering projects and building teams can be challenging.\n\nWrite in an upbeat, friendly way. Acknowledge the opportunities in the here-and-now and walk through\nit with them.\n\n#### Places to use 'Encourage people along the path'\n\n- In-app:\n  [information messages](https://atlassian.design/foundations/content/designing-messages/info-messages),\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages),\n  and [section messages](https://atlassian.design/components/section-message/usage)\n- When something requires an action\n\n<br></br>\n\n### Motivate by showing possibilities\n\nProvide incentive and enthusiasm for continued growth.\n\n- Consider why someone would want to do this.\n- Show the possibilities of what can be accomplished by giving examples of how other people\n  accomplish the same task or by presenting the ideal state.\n- Describe the end result by giving expert testimony or offer opportunities for advanced knowledge.\n\nWrite like an expert. Focus more on the solution than on the problem. Show people the possible\nbenefits.\n\n#### Places to use 'Motivate by showing possibilities'\n\n- In-app: [spotlights](https://atlassian.design/components/spotlight/usage) and\n  [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Educational opportunities — it's a chance to give best practices, and tips and tricks\n\n<br></br>\n\n### Satisfy by meeting expectations\n\nGive people what they need.\n\n- All of our content should be practical at a minimum.\n- Provide quick and thorough answers, guidance, actions, and instructions (rather than trying to\n  lead, inspire, motivate, delight, or encourage).\n- Simply tell people what they need to know and get out of the way.\n\nWrite as if you are explaining to your friend how to travel somewhere you’ve visited regularly.\n\n#### Places to use 'Satisfy by meeting expectations'\n\n- In-app:\n  [warning messages](https://atlassian.design/foundations/content/designing-messages/warning-messages),\n  [information messages](https://atlassian.design/foundations/content/designing-messages/info-messages),\n  and\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages)\n- Across all UI and app content\n\n<br></br>\n\n### Delight with unexpectedly pleasing experiences\n\nYou can deliver appropriate delight (a ‘wink’) by celebrating success or progress, but only once\nyou’ve built trust. Don’t overdo it. \n\n- Delight means little flourishes, not humor or being cheeky.\n- Always ask yourself what someone might be feeling at that moment and if delight is appropriate.\n  Also question whether it will be understood or appreciated by our global audience.\n- Think about the timing and how frequently a user will see this. Once may amuse, but a dozen times\n  may annoy.\n\n#### Places to use ‘Delight with unexpectedly pleasing experiences’\n\n- In-app:\n  [success messages](https://atlassian.design/foundations/content/designing-messages/success-messages)\n  and [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Social interactions, while introducing new experiences",
   keywords: ['voice', 'tone', 'writing', 'content', 'brand']
 }, {
   content: 'import {\n\tTokenElevationBackgroundChangeExample,\n\tTokenElevationChangeExample,\n} from \'../../../components/interactive-elevations\';\n\n\n\n\n\nElevations are the layered surfaces that form the foundation of the UI. They create a blank canvas\nwhere other UI will be placed, such as text, icons, backgrounds, and borders.\n\n![](./_assets/elevation-layers.png)\n\nMost elevations consist of surfaces and shadows. Together, surfaces and shadows give the impression\nof lift or depth. Elevations can guide focus through layering, or indicate that the UI can be\nscrolled, slid, or dragged.\n\n## Applying elevations\n\nThe elevations use [design tokens](https://atlassian.design/tokens/design-tokens) to apply different\nsurface levels. The highest two elevation surfaces, raised and overlay, are paired with shadows to\ncreate more depth.\n\n![](./_assets/applying-elevations-light.png)\n\n### Elevations in dark theme\n\nShadows can be harder to see in dark mode, so dark mode elevations also rely on different surface\ncolors. Imagine that the surfaces are distantly lit from the front — the higher the elevation, the\nlighter the surface looks.\n\n![](./_assets/applying-elevations-dark-1.png)\n\nRaised and overlay surfaces are still paired with shadows for added depth and consistency in dark\nmode.\n\n![](./_assets/applying-elevations-dark-2.png)\n\n## Types of elevations\n\nThere are four basic elevation levels:\n\n1. [Sunken](#sunken)\n2. [Default](#default)\n3. [Raised](#raised)\n4. [Overlay](#overlay)\n\nThere is also one "[overflow](#overflow)" elevation for special cases.\n\n### Sunken\n\nSunken is the lowest elevation available. The sunken surface creates a backdrop (or well) where\nother content sits. Columns on a Kanban board are a good example of the sunken elevation.\n\nOnly use sunken surfaces on the default surface level. Don’t apply sunken elevations on raised or\noverlay elevations. To differentiate areas of the UI in other ways, use whitespace or borders\ninstead.\n\n![](./_assets/elevation-sunken-1.png)\n\n#### Using `elevation.surface.sunken` vs `color.background.neutral`\n\nAlthough `elevation.surface.sunken` and `color.background.neutral` tokens may appear similar in\nlight mode, they behave differently in dark mode. Here are the main differences between the two:\n\n`elevation.surface.sunken` is an opaque (solid) token that darkens in both light and dark modes. Use\nthis token as a backdrop to group content or elements together (such as a kanban board) on the\ndefault surface.\n\n![](./_assets/elevation-sunken-2.png)\n\n`color.background.neutral` is a token that uses a transparent color. It darkens in light mode and\nlightens in dark mode. Use this token when you need the background to adapt to different elevations,\nwhich is relevant in dark mode since surfaces change depending on what elevation you’re on.\n\n![](./_assets/elevation-sunken-3.png)\n\n### Default\n\nThe default elevation is the baseline with respect to all other layers. It represents a flat UI\nsurface with no visual lift, such as a Confluence page.\n\nUse `elevation.surface` as the starting point for body content when building a UI. To create flat\ncards, pair with a border.\n\n![](./_assets/elevation-surface-1.png)\n\n### Raised\n\nRaised elevations sit slightly higher than default elevations. They are reserved for cards that can\nbe moved, such as Jira and Trello cards. In special circumstances, they can be used for cards as a\nway to provide additional heirarchy or emphasis.\n\nAlways pair `elevation.surface.raised` with `elevation.shadow.raised`. This is particularly\nimportant in dark mode, where raised surfaces are lighter to help differentiate elevations.\n\n![](./_assets/elevation-raised-1.png)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tUse raised elevations intentionally. If using for emphasis, limit to one section or focal point\n\t\tof the screen.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tRaised elevations can create visual noise, so don’t use to group content when a border or white\n\t\tspace would suffice.\n\t</DoDont>\n</DoDontGrid>\n\n### Overlay\n\nOverlay is the highest elevation available. It is reserved for a UI that sits over another UI, such\nas modals, dialogs, dropdown menus, floating toolbars, and floating single-action buttons.\n\nAlways pair `elevation.surface.overlay` with `elevation.shadow.overlay`. This is important in dark\nmode, where overlay surfaces are lighter to help differentiate elevations.\n\nOverlays can stack on top of other overlays.\n\n![](./_assets/elevation-overlay-1.png)\n\n### Overflow\n\nOverflow is a shadow indicating content has [scrolled](#scrolled) outside a view. It can be used for\nvertical or horizontal scroll. An example of overflow shadows is the horizontal scroll in tables on\na Confluence page.\n\n![](./_assets/elevation-overflow-1.png)\n\nIf box shadows are not technically feasible, use the combination of\n`elevation.shadow.overflow.spread` and `elevation.shadow.overflow.perimeter` to replicate the\noverflow shadow.\n\n## Interaction states\n\n### Hovered and pressed\n\nElevations use surface color changes to communicate hovered and pressed states. Use the hovered and\npressed elevation tokens to create these visual changes.\n\n![](./_assets/elevation-hovered.png)\n\nTransitions between elevations can be used as an alternative to hovered and pressed tokens, but only\nfor default and raised elevations (not overlays):\n\n- Transition to overlay elevation on hover\n- Transition to raised elevation on press\n\nThis approach should be used sparingly to avoid excessive animation. It should not be used for very\nsmall UI, as elevation changes are harder to see than surface color changes at this size.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tUse the recommended hovered and pressed tokens for interaction states on elevations.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tDon’t combine elevation transitions and hovered and pressed tokens for interactive states. Use\n\t\tone or the other.\n\t</DoDont>\n</DoDontGrid>\n\n#### Background change example\n\n<TokenElevationBackgroundChangeExample />\n\n#### Elevation change example\n\n<TokenElevationChangeExample />\n\n### Dragged\n\nUse the overlay elevation for any UI that is being dragged. Once moved, it returns to its original\nelevation.\n\n![](./_assets/elevation-dragged-1.png)\n\n### Scrolled\n\nWhen scrollable content exceeds the available area, a border or [overflow](#overflow) shadow can be\napplied at the point the content is cut off to indicate there is hidden content that can be scrolled\nback into view.\n\nA border is the default approach for scrolled content and can be seen in modal sticky headers and\nfooters, and top and side navigation.\n\n![](./_assets/elevation-scrolled.png)\n\n[Overflow](#overflow) shadows are reserved for experiences where a border might be easily missed,\nsuch as in very small UI or tables that use borders to separate cells.\n\nBoth approaches should apply the appropriate surface token where the content is being hidden.\n\n## All elevation tokens and values\n\nFor the full list of elevation design tokens and their values, see our\n[design token reference list](https://atlassian.design/components/tokens/all-tokens). Every token\ncomes with a description to help you ensure you’re using the correct one.\n\n## Best practices\n\n### Follow the recommended surface and shadow pairings\n\nRaised and overlay elevations have dedicated surface and shadow pairings.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: pairingDo, alt: \'\' }}>\n\t\tWhen creating elevations, always pair matching surface and shadow tokens.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: pairingDont, alt: \'\' }}>\n\t\tDon\'t mix different shadow and surface elevation tokens.\n\t</DoDont>\n</DoDontGrid>\n\n### Replace elevation surfaces with background colors only when required\n\nElevation surfaces use our\n[neutral palettes](https://atlassian.design/foundations/color#neutral-colors). If a different color\nis needed, surface tokens can be swapped for any solid background token. When using background\ntokens, align to the behavior of\n[interaction states for color tokens](https://atlassian.design/foundations/color#interaction-states).\n\n![](./_assets/background-colors.png)\n\n### Avoid excessive use of raised and overlay elevations\n\nThe shadows and surfaces of raised and overlay elevations can create busy UI if not applied\nintentionally. Follow the recommended guidance when considering these elevations.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: groupingDo, alt: \'\' }}>\n\t\tLimit the use of overlay elevations by grouping related buttons together in a floating toolbar\n\t\tif they are required to sit over another UI.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: groupingDont, alt: \'\' }}>\n\t\tDon’t have more than one floating button next to each other.\n\t</DoDont>\n</DoDontGrid>\n\n### Check contrast ratios\n\nAlways make sure your elevation and background choices are accessible.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tCheck the contrast ratio for UI on overlay surfaces in dark mode to ensure it meets\n\t\taccessibility requirements.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tDon\'t assume that because UI is accessible in light mode, it will be in dark mode. Some UI may\n\t\tneed tweaking.\n\t</DoDont>\n</DoDontGrid>\n\n## Z-index\n\nThe z-index determines the stacking order of elements. Elements with a higher z-index always sit in\nfront of elements with a lower z-index.\n\nDifferent UI can have the same elevation style, but each UI should apply a different z-index to\nindicate the layer(s) order in a stack (or where the elements touch).\n\n| Z-index | Example usage                                                                     | Elevation level |\n| ------- | --------------------------------------------------------------------------------- | --------------- |\n| 100     | None                                                                              | None            |\n| 200     | [Atlassian navigation](https://atlassian.design/components/atlassian-navigation/) | Default         |\n| 300     | [Inline dialog](https://atlassian.design/components/inline-dialog/)               | Overlay         |\n| 400     | [Popup](https://atlassian.design/components/popup/)                               | Overlay         |\n| 500     | [Blanket](https://atlassian.design/components/blanket/)                           | None            |\n| 510     | [Modal](https://atlassian.design/components/modal-dialog/)                        | Overlay         |\n| 600     | [Flag](https://atlassian.design/components/flag/)                                 | Overlay         |\n| 700     | [Spotlight](https://atlassian.design/components/onboarding/)                      | Overlay         |\n| 800     | [Tooltip](https://atlassian.design/components/tooltip/)                           | None            |\n\n## Related\n\n- Learn about the basics of [design tokens](https://atlassian.design/tokens/design-tokens).\n- See the list of [all design tokens](https://atlassian.design/components/tokens/all-tokens) for\n  full descriptions and values for all tokens.',
@@ -80,7 +80,7 @@ var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
   content: 'Icons are symbols designed to represent concepts or specific features. A company\'s iconography style\ncan express a lot about a brand and its values.\n\nAtlassian\'s iconography has rounded corners and curves to align with our typography and other\nrounded UI elements, whilst square end terminals add boldness to create a harmonious app expression\nof Atlassian\'s broader design language.\n\n## Iconography principles\n\nFollow these principles to design and use Atlassian icons in a cohesive, useful, and legible way.\n\n**Design for universal understanding**\n\nDesign icons that use widely recognized symbols and established visual metaphors. Ensure icons are\neasily understood by a diverse audience by avoiding specific cultural or language aspects.\n\n**Balance simplicity and detail to create legibility**\n\nCraft icons that are simple enough for quick recognition, yet detailed enough to convey meaning\neffectively, even at small sizes.\n\n**Maintain visual harmony**\n\nEnsure icons work together as a cohesive system by adhering to consistent size, shape, and style\nguidelines across the entire set.\n\n**Use icons intentionally**\n\nIcons are powerful signifiers that can aid comprehension and help with navigation. They can also add\nclutter or confuse people when used poorly. Use text labels to support icons wherever possible, and\navoid using icons where they aren’t necessary.\n\n## Using Atlassian icons\n\nAtlassian icons are available as a component (React), Figma library, and in our documentation:\n\n- [View Atlassian icons](https://atlassian.design/components/icon)\n- [Icon component usage](https://atlassian.design/components/icon/usage)\n- [Icon tile component](https://atlassian.design/components/icon/icon-tile)\n- [Figma library of Atlassian icons (Atlassian employees only)](https://go.atlassian.com/ads-icons-figma)\n\n## Visual style\n\nAtlassian’s icon style has a 1.5px stroke width with shapes that pair rounded corners with sharp\ninterior corners and square line caps.\n\n### Simplicity and metaphor\n\nWherever possible, use [existing icons](https://atlassian.design/components/icon) to maintain\nconsistency and reinforce visual concepts across Atlassian apps so they become familiar to\ncustomers.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: consistencyDo, alt: \'\' }}>\n\t\tUse an existing icon or visual metaphor for consistency and clarity wherever possible.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: consistencyDont, alt: \'\' }}>\n\t\tCreate a new icon if a suitable one already exists to represent the same metaphor.\n\t</DoDont>\n</DoDontGrid>\n\nUse simplified shapes with the minimum detail required to express a metaphor. The goal of an icon is\nto aid clear, quick comprehension — excess detail can distract and do the opposite. The small size\nof icons makes it harder to see fine details, so optimise for simplicity and legibility.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: simplifiedShapesDo, alt: \'\' }}>\n\t\tUse simple shapes with the minimum detail required to express a metaphor with clarity and\n\t\tlegibility.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: simplifiedShapesDont, alt: \'\' }}>\n\t\tDon’t add excess detail. This may distract and be challenging to understand at a small sizes.\n\t</DoDont>\n</DoDontGrid>\n\nWhen creating a new icon, use symbols that clearly represent a concept. Try to use metaphors with\nclear and established associations wherever possible.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: metaphorsDo, alt: \'\' }}>\n\t\tUse familiar symbols with clear and established associations that clearly represent a concept.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: metaphorsDont, alt: \'\' }}>\n\t\tUse caution when creating an icon that isn’t a widely recognized symbol. It may be confused with\n\t\tanother concept or misunderstood.\n\t</DoDont>\n</DoDontGrid>\n\n### Perspective and angles\n\nShapes should appear straight on or from a full 90 degree profile. Don’t use diagonal perspectives\nto create 3D shapes because these can be hard to discern at a glance, especially for people with\nsome cognitive disabilities.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: perspectiveDo, alt: \'\' }}>\n\t\tUse shapes that appear straight on without dimensionality.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: perspectiveDont, alt: \'\' }}>\n\t\tDon’t use diagonal perspectives to create 3D shapes as they can be hard to discern at a glance.\n\t</DoDont>\n</DoDontGrid>\n\n### Size and spacing\n\nSystem icons are drawn within a 16 × 16px bounding box and are available in two sizes:\n\n#### Medium (16px) — use in most cases\n\nMedium icons are 16 × 16px in size and are the **default** size in our system. This size balances\nharmoniously with body text and the density of Atlassian’s apps.\n\n#### Small (12px) — Use sparingly\n\nSmall icons are 12 × 12px in size and are downscaled from their 16px counterpart. This size should\nbe used sparingly as they aren\'t as legible as 16px icons. Limit usage of 12px icons to the\nfollowing uses:\n\n- **Chevrons** — always use 12px chevrons, particularly within buttons, icon buttons, and dropdowns\n  to maintain cohesion with Atlassian\'s visual language.\n\n- **Field validation messaging** — use 12px status icons for information, warnings, and errors.\n\n- **Within small contained elements** — 12px icons balance with small text within tags, badges,\n  statuses, and other similar compact elements.\n\n- **App affiliation** — use 12px icons for "Powered by Atlassian Intelligence" or other Atlassian\n  app affiliations.\n\n- **Secondary actions** — use 12px icons to communicate hierarchy between primary way-finding icons\n  and secondary actions so they don’t compete for attention.\n\n- **Supporting role** — use 12px icons for supporting actions that shouldn\'t draw attention away\n  from important content.\n\n![](./_assets/icon_sizing_options.png)\n\nTo apply spacing around an icon, we recommend placing it within a Box primitive with a padding value\napplied from our spacing system.\n\nWhen larger icons sizes are needed for decorative purposes, consider using an\n[icon tile](https://atlassian.design/components/icon/icon-tile) which places the icon on a colored\nbackground tile. Icon tiles are available in multiple sizes and provides accessible icon and\nbackground color pairings.\n\n### Shapes\n\nIcons use consistent shapes to ensure a consistent look and feel across the set. We’ve designed each\nshape for optical scale and balance, so that taller, thinner shapes don’t feel like a different\nscale from shorter or wider shapes.\n\n![](./_assets/Keyline_shapes.png)\n\nWhen designing new icons, you can use our icon template with built-in keyline shapes to guide your\ndesigns.\n\nReusing existing shapes from other icons can also help with consistency across the set. Make sure to\nuse shapes that best represent the object metaphor you are expressing.\n\n### Corners and curves\n\nCurved edges lend to a friendlier feel, but keep internal edges sharp to maintain clarity.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: cornersDo, alt: \'\' }}>\n\t\tWhere possible, keep internal angles sharp.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: cornersDont, alt: \'\' }}>\n\t\tDon’t apply curves on internal anchor points.\n\t</DoDont>\n</DoDontGrid>\n\n### End caps\n\nEnd points should be squared off, not rounded.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: endPointsDo, alt: \'\' }}>\n\t\tSet end point style to "none" to ensure the path aligns with a pixel edge to prevent blurry\n\t\tresults.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: endPointsDont, alt: \'\' }}>\n\t\tDon’t use "round" or "square" stroke end point styles.\n\t</DoDont>\n</DoDontGrid>\n\n### Color\n\nLike most elements in our system, icons use design tokens for colors. Icons can use icon-specific\ncolor tokens or text color tokens for when you\'re matching an icon and text color. You can set the\ncolor of the icon using the\n[icon component](https://atlassian.design/components/icon/code#UNSAFE_IconNew-color).\n\nBoth icon and text color tokens are designed to have enough color contrast against backgrounds and\nsurfaces in Atlassian apps.\n\n## Contribution and adding new icons\n\nCurrently Atlassian teams can contribute icons to our system for new designs and features.\n\n- Before contributing an icon, look at our existing icon library and consider the following\n  questions:\n- Is the icon I’m contributing very similar to another system icon?\n- Can I use an existing multi-purpose icon?\n- Could my icon be confused with another concept that exists in apps?\n- Does this design really require an icon at all? Would a text label, button, or other approach\n  provide a clearer affordance for customer understanding?\n\nTo contribute a new icon, follow the\n[contribution guide (Atlassian employees only)](https://go.atlassian.com/ads-icon-contribution).\n\n## Related\n\n- Browse all icons and learn how to use them in apps with the\n  [icon component](https://atlassian.design/components/icon).',
   keywords: ['iconography', 'icons', 'visual design', 'symbols', 'brand', 'component design']
 }, {
-  content: 'import {\n\tTypographyPrinciples,\n\tTypographyHeadingTable,\n\tTypographyBodyTable,\n\tTypographyMetricTable,\n\tTypographyCodeTable,\n} from \'@af/design-system-docs-ui\';\n\n\n\nimport {\n\tAtlassianLogoCard,\n\tAttributionCards,\n\tPropertyCards,\n\tAppCards,\n} from \'./_logo-asset-cards.partial\';\n\n\n\n\n\n\n\n\n\n<SectionMessage title="Download logos" appearance="information">\n\t<Text>\n\t\tThe full set of app (product) logos are available in{\' \'}\n\t\t<Link href="https://orangedam.atlassian.com/">Atlassian Mosaic</Link>\n\t</Text>\n</SectionMessage>\n\nThis page includes downloadable logo files for use in marketing contexts as well as specific usage\nguidance for app or marketing contexts.\n\nIf you want to add logos to app (product) experiences, use the\n[logo component](https://atlassian.design/components/logo/examples).\n\n## Download the logos\n\nEach downloadable file includes variations of color and layout in approved formats and the below\nelements combined together:\n\n- logomarks – the icon portion of a logo\n- wordmarks – the name of the app (product) or property\n- straplines or other secondary text.\n\nAssets for isolated logomarks are also included.\n\n![Annotated graphic of the Atlassian logo, showing the logomark, strapline and wordmark.](./_assets/logo-anatomy.png)\n\n### Our iconic Atlassian logo\n\nOur iconic company logo.\n\nInclude `Atlassian` as the alt-text for the logo in digital experiences.\n\n<AtlassianLogoCard />\n\n#### Atlassian app strapline\n\nThe Atlassian logomark and wordmark can be coupled with a list of app (product) names under it.\nFollow the below guidance when using logos that contain straplines:\n\n- Always centre the app names under the logo and don’t scale the logo below 280px wide.\n- Write Atlassian and the app name in the alt-text in digital experiences.\n\n![Logo strapline with Jira, Confluence, Trello and Bitbucket wordmarks center-aligned beneath the Atlassian logo.](./_assets/logo-centered.png)\n\n### Attribution logos\n\nThe attribution logos are a type of lockup that combine app (product) or property logomarks with the\nAtlassian strapline.\n\nThey create consistency in our portfolio, and help customers connect them with our overall Atlassian\nbrand. Follow the below guidance when using attribution logos:\n\n- Only use attribution logos when the Atlassian context is not clear. For example, in\n  advertisements, videos, and white papers. You don’t need to use them on Atlassian properties like\n  [www.atlassian.com](https://www.atlassian.com) or in app (product) user interfaces.\n- Never compose your own attribution logos or deconstruct the official assets.\n- Write the name of the app (product)/property and Atlassian in the alt-text for in digital\n  experiences.\n\n<AttributionCards />\n\n### Property logos\n\nThe Atlassian program and property logos are a lockup of the Atlassian logomark and wordmark and the\nname in Charlie Sans. Follow the below guidance when using property logos:\n\n- On a white background, the program name is rendered in neutral with the logo in primary blue. On\n  darker backgrounds, both program and logo are white.\n- Write `Atlassian` and the name of the property as the alt-text in digital experiences.\n\n<PropertyCards />\n\n### App (product) logos\n\nWith the Atlassian System of Work and collections framework our primary products, secondary products\nand plaftform features are now referred to as apps.\n\nWe’ve updated our logos to reflect this change, using marks that symbolize functionality, contained\nin a tile. An app’s glyph is chosen based on the apps functionality; its tile color refers to its\ncollection.\n\nThe logomarks are contained by a tile shape, colored with their associated collection. Follow the\nbelow guidance when using App (product) logos:\n\n- Use when the Atlassian context is clear.\n- If you need to connect the app to Atlassian, use an attribution logo instead. For example, in a\n  video or advertisement.\n- Write the name of the apps in the alt-text in digital experiences.\n\nAssets include both isolated logomarks and lockups with wordmarks.\n\n<AppCards />\n\n#### Logomarks\n\nA logomark is a symbol or icon shown without the app (product)/property name or brand workmark. For\nan app (product), this refers to the tile. Follow the below guidance when using logomarks:\n\n- If you’re including the logomark in product experiences, use the\n  [icon](https://atlassian.design/components/logo/examples#icon) variant of the logo component.\n- Only use logomarks on their own when the context is very clear and where possible pair with\n  descriptive text.\n- Write `Atlassian` or the app/property name in the alt-text in digital experiences.\n\n![](./_assets/lockups-nav.png)\n\nLogomarks are paired with native text in top navigations.\n\n![](./_assets/logos-contained-logomarks.png)\n\nLogomarks are suitable when rendering the app name natively in its environment is more legible and\nuser-friendly.\n\n![](./_assets/logos-jira-app-store.png)\n\nLogomarks can be used when environmental restrictions do not allow for proper clearance guidelines\nto be followed for full logos.\n\n#### Logomark shape and size\n\nThe [logo](https://atlassian.design/components/logo) component comes in specific sizes and the\nlogomark has a pre-defined radius. These should not be altered.\n\nThe exception to this is when appearing on external sources such as Apple mobile apps and Google\nMarketplace where specific container shapes need to be used.\n\nLogomarks should never be nested inside additional containers.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: tileRadiusDo, alt: \'\' }}>\n\t\tUse the default radius values that are applied to the backgrounds of app logo icons.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: tileRadiusDont, alt: \'\' }}>\n\t\tDon’t adjust the radius values of the backgrounds of product logo icons.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: containersDo, alt: \'\' }}>\n\t\tAllow breathing room around product logo icons.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: containersDont, alt: \'\' }}>\n\t\tDon’t add unnecessary containers around app logo icons.\n\t</DoDont>\n</DoDontGrid>\n\n### Aligning logos\n\n#### Align logomarks with other elements\n\n- Middle align with the logo mark when the copy is less than the height of the container.\n- Top-align or stack below with center-alignment if it’s taller than the container.\n\n![](./_assets/logos-alignment-ratio.png)\n\n#### Aligning app (product) logos\n\nWhere app (product) logos are arranged in a vertical or horizontal list, use the height or weight of\nthe logomark portion to align.\n\n![](./_assets/tile-align-horizontal.png) ![](./_assets/tile-align-vertical.png)\n\n## Logo clearance\n\nWhen displaying logos outside of an app UI, surround them with clear space free of type, graphics,\nand other elements that might cause visual clutter.\n\n#### Ideal clearance — Atlassian logo\n\n![](./_assets/clearance-horizontal.png) ![](./_assets/clearance-vertical.png)\n\n#### Minimum clearance — Atlassian logo\n\nUse the capital "A" of the Atlassian wordmark to define the minimum clearance around the logo.\n\n![](./_assets/top-bottom-clearance-atlassian.png)\n\n#### Ideal clearance — app (product) logo\n\n![](./_assets/logos-ideal-clearance-app.png)\n\n#### Minimum clearance — app (product) logo\n\nUse the height and width of the logo wordmark to find the minimum clearance around the logo.\n\n![](./_assets/top-bottom-clearance-app.png)\n\n## Color options\n\nLogos are available in three color options to suit different colored environments – Brand, inverse\nand neutral.\n\n![](./_assets/logo-stack-colors.png)\n\nDon’t edit or place logos in ways that reduce the clarity and legibility of the image.\n\n<DoDontGrid>\n\t<DoDont type="dont" image={{ url: colorDont, alt: \'\' }}>\n\t\tDon’t use unapproved color combinations.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: shadowDont, alt: \'\' }}>\n\t\tDon’t use a drop shadow.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: legibilityDont, alt: \'\' }}>\n\t\tDon’t use the logo on top of complex backgrounds.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: outlineDont, alt: \'\' }}>\n\t\tDon’t outline the logo.\n\t</DoDont>\n</DoDontGrid>',
+  content: 'import {\n\tTypographyPrinciples,\n\tTypographyHeadingTable,\n\tTypographyBodyTable,\n\tTypographyMetricTable,\n\tTypographyCodeTable,\n} from \'@af/design-system-docs-ui\';\n\n\n\nimport {\n\tAtlassianLogoCard,\n\tAttributionCards,\n\tPropertyCards,\n\tAppCards,\n} from \'./_logo-asset-cards.partial\';\n\n\n\n\n\n\n\n\n\n<SectionMessage title="Download logos" appearance="information">\n\t<Stack space="space.100">\n\t\t<Text>\n\t\t\tThe full set of app (product) logos are available in{\' \'}\n\t\t\t<Link href="https://orangedam.atlassian.com/">Atlassian Mosaic</Link>.\n\t\t</Text>\n\t\t<Text>\n\t\t\tLogos used to represent third-party integrations are available in{\' \'}\n\t\t\t<Link href="https://atlaskit.stg.atlassian.com/packages/platform-labs/logo-third-party">\n\t\t\t\tAtlaskit staging (Atlassians only)\n\t\t\t</Link>\n\t\t\t.\n\t\t</Text>\n\t</Stack>\n</SectionMessage>\n\nThis page includes downloadable logo files for use in marketing contexts as well as specific usage\nguidance for app or marketing contexts.\n\nIf you want to add logos to app (product) experiences, use the\n[logo component](https://atlassian.design/components/logo/examples).\n\n## Download the logos\n\nEach downloadable file includes variations of color and layout in approved formats and the below\nelements combined together:\n\n- logomarks – the icon portion of a logo\n- wordmarks – the name of the app (product) or property\n- straplines or other secondary text.\n\nAssets for isolated logomarks are also included.\n\n![Annotated graphic of the Atlassian logo, showing the logomark, strapline and wordmark.](./_assets/logo-anatomy.png)\n\n### Our iconic Atlassian logo\n\nOur iconic company logo.\n\nInclude `Atlassian` as the alt-text for the logo in digital experiences.\n\n<AtlassianLogoCard />\n\n#### Atlassian app strapline\n\nThe Atlassian logomark and wordmark can be coupled with a list of app (product) names under it.\nFollow the below guidance when using logos that contain straplines:\n\n- Always centre the app names under the logo and don’t scale the logo below 280px wide.\n- Write Atlassian and the app name in the alt-text in digital experiences.\n\n![Logo strapline with Jira, Confluence, Trello and Bitbucket wordmarks center-aligned beneath the Atlassian logo.](./_assets/logo-centered.png)\n\n### Attribution logos\n\nThe attribution logos are a type of lockup that combine app (product) or property logomarks with the\nAtlassian strapline.\n\nThey create consistency in our portfolio, and help customers connect them with our overall Atlassian\nbrand. Follow the below guidance when using attribution logos:\n\n- Only use attribution logos when the Atlassian context is not clear. For example, in\n  advertisements, videos, and white papers. You don’t need to use them on Atlassian properties like\n  [www.atlassian.com](https://www.atlassian.com) or in app (product) user interfaces.\n- Never compose your own attribution logos or deconstruct the official assets.\n- Write the name of the app (product)/property and Atlassian in the alt-text for in digital\n  experiences.\n\n<AttributionCards />\n\n### Property logos\n\nThe Atlassian program and property logos are a lockup of the Atlassian logomark and wordmark and the\nname in Charlie Sans. Follow the below guidance when using property logos:\n\n- On a white background, the program name is rendered in neutral with the logo in primary blue. On\n  darker backgrounds, both program and logo are white.\n- Write `Atlassian` and the name of the property as the alt-text in digital experiences.\n\n<PropertyCards />\n\n### App (product) logos\n\nWith the Atlassian System of Work and collections framework our primary products, secondary products\nand plaftform features are now referred to as apps.\n\nWe’ve updated our logos to reflect this change, using marks that symbolize functionality, contained\nin a tile. An app’s glyph is chosen based on the apps functionality; its tile color refers to its\ncollection.\n\nThe logomarks are contained by a tile shape, colored with their associated collection. Follow the\nbelow guidance when using App (product) logos:\n\n- Use when the Atlassian context is clear.\n- If you need to connect the app to Atlassian, use an attribution logo instead. For example, in a\n  video or advertisement.\n- Write the name of the apps in the alt-text in digital experiences.\n\nAssets include both isolated logomarks and lockups with wordmarks.\n\n<AppCards />\n\n#### Logomarks\n\nA logomark is a symbol or icon shown without the app (product)/property name or brand workmark. For\nan app (product), this refers to the tile. Follow the below guidance when using logomarks:\n\n- If you’re including the logomark in product experiences, use the\n  [icon](https://atlassian.design/components/logo/examples#icon) variant of the logo component.\n- Only use logomarks on their own when the context is very clear and where possible pair with\n  descriptive text.\n- Write `Atlassian` or the app/property name in the alt-text in digital experiences.\n\n![](./_assets/lockups-nav.png)\n\nLogomarks are paired with native text in top navigations.\n\n![](./_assets/logos-contained-logomarks.png)\n\nLogomarks are suitable when rendering the app name natively in its environment is more legible and\nuser-friendly.\n\n![](./_assets/logos-jira-app-store.png)\n\nLogomarks can be used when environmental restrictions do not allow for proper clearance guidelines\nto be followed for full logos.\n\n#### Logomark shape and size\n\nThe [logo](https://atlassian.design/components/logo) component comes in specific sizes and the\nlogomark has a pre-defined radius. These should not be altered.\n\nThe exception to this is when appearing on external sources such as Apple mobile apps and Google\nMarketplace where specific container shapes need to be used.\n\nLogomarks should never be nested inside additional containers.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: tileRadiusDo, alt: \'\' }}>\n\t\tUse the default radius values that are applied to the backgrounds of app logo icons.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: tileRadiusDont, alt: \'\' }}>\n\t\tDon’t adjust the radius values of the backgrounds of product logo icons.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: containersDo, alt: \'\' }}>\n\t\tAllow breathing room around product logo icons.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: containersDont, alt: \'\' }}>\n\t\tDon’t add unnecessary containers around app logo icons.\n\t</DoDont>\n</DoDontGrid>\n\n### Aligning logos\n\n#### Align logomarks with other elements\n\n- Middle align with the logo mark when the copy is less than the height of the container.\n- Top-align or stack below with center-alignment if it’s taller than the container.\n\n![](./_assets/logos-alignment-ratio.png)\n\n#### Aligning app (product) logos\n\nWhere app (product) logos are arranged in a vertical or horizontal list, use the height or weight of\nthe logomark portion to align.\n\n![](./_assets/tile-align-horizontal.png) ![](./_assets/tile-align-vertical.png)\n\n## Logo clearance\n\nWhen displaying logos outside of an app UI, surround them with clear space free of type, graphics,\nand other elements that might cause visual clutter.\n\n#### Ideal clearance — Atlassian logo\n\n![](./_assets/clearance-horizontal.png) ![](./_assets/clearance-vertical.png)\n\n#### Minimum clearance — Atlassian logo\n\nUse the capital "A" of the Atlassian wordmark to define the minimum clearance around the logo.\n\n![](./_assets/top-bottom-clearance-atlassian.png)\n\n#### Ideal clearance — app (product) logo\n\n![](./_assets/logos-ideal-clearance-app.png)\n\n#### Minimum clearance — app (product) logo\n\nUse the height and width of the logo wordmark to find the minimum clearance around the logo.\n\n![](./_assets/top-bottom-clearance-app.png)\n\n## Color options\n\nLogos are available in three color options to suit different colored environments – Brand, inverse\nand neutral.\n\n![](./_assets/logo-stack-colors.png)\n\nDon’t edit or place logos in ways that reduce the clarity and legibility of the image.\n\n<DoDontGrid>\n\t<DoDont type="dont" image={{ url: colorDont, alt: \'\' }}>\n\t\tDon’t use unapproved color combinations.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: shadowDont, alt: \'\' }}>\n\t\tDon’t use a drop shadow.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: legibilityDont, alt: \'\' }}>\n\t\tDon’t use the logo on top of complex backgrounds.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: outlineDont, alt: \'\' }}>\n\t\tDon’t outline the logo.\n\t</DoDont>\n</DoDontGrid>',
   keywords: ['logos', 'brand', 'identity', 'logo usage', 'brand guidelines']
 }, {
   content: '## About radius tokens\n\nRadius tokens standardize corner roundness, ensuring consistency and cohesion throughout all of our\napps. Pair radius tokens with radius focus tokens to bring focus to the selected element. This helps\nusers identify which element is active.\n\n## Radius tokens and usage guidelines\n\nUse radius tokens to apply roundness across different states and use cases.\n\n<Stack space="space.200">\n\t<RadiusTable />\n\t<Text>* Token values are subject to change and should be used as an indication only.</Text>\n</Stack>\n\n## Radius examples and usage\n\n### Extra small\n\nUse the `radius.xsmall` token for extra small detail elements like badges, checkboxes, avatar\nlabels, and keyboard shortcuts.\n\n![Two examples, one of checkboxes and one of keyboard shortcuts in a tooltip, both of which use the "radius.xsmall" token.](./_assets/radius-xsmall.png)\n\n### Small\n\nUse the `radius.small` token for small elements like labels, lozenges, timestamps, tags, dates,\ntooltip containers, imagery inside tables, and compact buttons.\n\n![Examples of lozenges, tooltips, dates and photos in a section that all use the "radius.small" token.](./_assets/radius-small.png)\n\n### Medium\n\nUse the `radius.medium` token for interactive elements like buttons, inputs, text areas, selects,\nnavigation items, and smart links.\n\n![Examples of buttons, smart links, text fields, dropdowns, and navigation menu items all using the "radius.medium" token.](./_assets/radius-medium.png)\n\n### Large\n\nUse the `radius.large` token for elements like cards, in-page containers, floating UIs, and dropdown\nmenus.\n\n![Two examples, one of a progress summary card and one of a Jira work item on a board, both of which use the "radius.large" token.](./_assets/radius-large.png)\n\n### Extra large\n\nUse the `radius.xlarge` token for full-page containers, large containers, modal dialogs, Kanban\ncolumns, and tables.\n\n![Two examples, one of a confirmation dialog and one of a table, both of which use the "radius.xlarge" token.](./_assets/radius-xlarge.png)\n\n### Extra extra large\n\nUse the `radius.xxlarge` token for video players.\n\n![An example of the Loom video player using the "radius.xxlarge" token.](./_assets/radius-xxlarge.png)\n\n### Full\n\nUse the `radius.full` token for avatars, names, user-related UI, and emoji reactions. This token can\nalso be used for dividers and other pill-shaped elements since it results in a fully round radius.\n\n![A mix of circular and pill-shaped examples of avatars, user mentions, and name cursors all using the "radius.full" token.](./_assets/radius-full.png)\n\n### Tile\n\nUse the `radius.tile` token exclusively for tile components, such as icon tile or object tile. This\ntoken should not be used outside of tiles.\n\n![An example of tile objects all using the "radius.tile" token.](./_assets/radius-tile.png)\n\n## Radius token for focus state\n\nA component\'s focus state is critical for accessibility. The corner radius of the focus ring must\nalign visually with the component it surrounds.\n\n### Focus state design specifications\n\n![Diagram showing an interactive element with a blue focus ring offset by 2px. A note explains “Focus ring radius = element radius + 2px,” illustrating how the focus ring\'s corner radius is calculated relative to the component.](./_assets/focus-ring-1.png)\n\nThe focus ring is implemented in two key ways:\n\n1. **Offset**: The focus ring is positioned 2px away from the component\'s bounding box.\n2. **Radius value**: The corner radius of the focus ring is always +2px greater than the component’s\n   base corner radius value.\n\n### How to implement the focus ring for code and design\n\nThe focus ring is managed differently between code and design:\n\n- **In code**: When you’re using interactive design system components, focus rings are automatically\n  applied. When you’re building custom components, use the\n  [focusable component](https://atlassian.design/components/primitives/focusable/examples). The 2px\n  visual offset and the radius calculation (component radius +2px) are automatically handled by the\n  focusable component\'s logic. This means developers never need to apply a separate radius token for\n  the focus state.\n- **In design**: Automatic calculations aren’t possible in design tools, so designers must use a\n  dedicated set of tokens to enforce the correct radius relationship. These tokens mirror the\n  component radius names but carry the calculated +2px value to ensure visual accuracy in design\n  files.\n\n![Diagram of a button showing the base radius of "radius.medium" and its corresponding focus‑state radius token "radius.focus.medium" relationship.](./_assets/focus-ring-2.png)\n\n<Stack space="space.200">\n\t<RadiusFocusTable />\n\t<Text>* Token values are subject to change and should be used as an indication only.</Text>\n</Stack>',