@rio-cloud/uikit-mcp 1.0.0

package/data/pages/Getting-started/start/guidelines/supported-browsers.json

@@ -0,0 +1,22 @@
+{
+  "metadata": {
+    "captured_at": "2025-11-21T12:07:01.187Z",
+    "source": "https://uikit.developers.rio.cloud/#start/guidelines/supported-browsers",
+    "category": "Getting started",
+    "section": "Guidelines",
+    "slug": "start/guidelines/supported-browsers",
+    "version": "v1.13.2",
+    "hash_algorithm": "sha256",
+    "hash": "5e776bd5886687d2245a03647024b5898ff93de463e022b0d8c74d5913babf4b"
+  },
+  "title": "Supported Browsers",
+  "lead": "We currently support the following browsers:",
+  "content": [
+    {
+      "heading": "Supported Browsers",
+      "body": "",
+      "examples": []
+    }
+  ],
+  "see_also": []
+}

package/data/pages/Getting-started/start/guidelines/writing.json

@@ -0,0 +1,242 @@
+{
+  "metadata": {
+    "captured_at": "2025-11-21T12:07:01.906Z",
+    "source": "https://uikit.developers.rio.cloud/#start/guidelines/writing",
+    "category": "Getting started",
+    "section": "Guidelines",
+    "slug": "start/guidelines/writing",
+    "version": "v1.13.2",
+    "hash_algorithm": "sha256",
+    "hash": "b344403ee146c061529388badaccec33fd0a3f60509ef93948b66679cd632d9d"
+  },
+  "title": "Writing style guide",
+  "lead": "UX writing doesn't receive as much attention as it should. In the past, digital experiences featured words written by different individuals - ranging from designers to engineers — at various times and in diverse styles, all without a centralized guide.",
+  "content": [
+    {
+      "heading": "Writing style guide",
+      "body": "Consequently, the language sometimes proves to be confusing, lacking consistency from one screen to another, and occasionally feels robotic or overly enthusiastic when a more conversational tone is needed.\n\nA good understanding of UX writing plays a pivotal role in creating better digital experiences. If the language within your product is intricate, uninspiring, or unfriendly, it’s likely that users will perceive your product in the same way — complex, uninspiring, and unfriendly.\n\n- Microsoft Writing Style Guide\n- Intuit content design\n- Google’s content design\n- Adobe Spectrum",
+      "examples": []
+    },
+    {
+      "heading": "Here's what you will find in the RIO’s writing style guide",
+      "body": "- Voice and tone\n- Write like you speak Project friendliness with contractions Get to the point fast Be brief Addressing the user clearly Active and passive voice Focus your message\n- Capitalization\n- Title case vs. sentence case Sentence case rules When in doubt, don’t capitalize Use ALL CAPS only when you should\n- Punctuation\n- Skip periods and unnecessary punctuation Skip colons in headings Use exclamation points sparingly Remember the last comma\n- UI elements\n- Buttons Links Forms Input placeholder Form labels and placeholders Dialogs Error states Notifications\n- Error messages\n- Errors in general Avoid showing a message whenever possible Have the system automatically resolve errors Use plain language, and avoid jargon\n- Commonly misspelled or misformatted words\n\n- Write like you speak\n- Project friendliness with contractions\n- Get to the point fast\n- Be brief\n- Addressing the user clearly\n- Active and passive voice\n- Focus your message\n\n- Title case vs. sentence case\n- Sentence case rules\n- When in doubt, don’t capitalize\n- Use ALL CAPS only when you should\n\n- Skip periods and unnecessary punctuation\n- Skip colons in headings\n- Use exclamation points sparingly\n- Remember the last comma\n\n- Buttons\n- Links\n- Forms\n- Input placeholder\n- Form labels and placeholders\n- Dialogs\n- Error states\n- Notifications\n\n- Errors in general\n- Avoid showing a message whenever possible\n- Have the system automatically resolve errors\n- Use plain language, and avoid jargon",
+      "examples": []
+    },
+    {
+      "heading": "Voice and tone",
+      "body": "- Clear and understandable\n- Friendly, honest, and responsible\n- Concise and simple",
+      "examples": []
+    },
+    {
+      "heading": "Write like you speak",
+      "body": "Read your text aloud. Does it sound like something a real person would say? Be friendly and conversational. No. Robot. Words.",
+      "examples": []
+    },
+    {
+      "heading": "Project friendliness with contractions",
+      "body": "Use contractions: it’s, you’ll, you’re, we’re, let’s To sound more conversational and natural. Use commonly understood contractions to keep sentences from feeling out-of-touch, robotic, or overly formal.\n\nHowever, sometimes \"do not\" can give more emphasis than \"don't” when caution is needed.\n\n- Avoid contracting nouns with is, does, has, or was. This might make it look like the noun is possessive.\n- Be mindful of how many contractions you use in a sentence. Too many contractions can make things difficult to read.\n- Avoid using contractions when dealing with legal concerns, payment processing, and account security. Casual isn’t always the best style when handling sensitive information.\n\n- To help you avoid traffic, remember anniversaries, and in general do more, RIO needs to know what you’re interested in, what’s on your calendar, and who you’re doing things with.\n- The business is closed\n\n- To help you avoid traffic, remember anniversaries, and in general do more, RIO needs to know what you are interested in, what is on your calendar, and who you are doing things with.\n- The business's closed",
+      "examples": []
+    },
+    {
+      "heading": "Get to the point fast",
+      "body": "Lead with what’s most important. Front-load keywords for scanning. Make customer choices and next steps obvious.",
+      "examples": []
+    },
+    {
+      "heading": "Be brief",
+      "body": "Give customers just enough information to make decisions confidently. Prune every excess word.",
+      "examples": []
+    },
+    {
+      "heading": "Addressing users clearly",
+      "body": "When addressing the user directly, it's important to use the second person pronouns 'you' or 'your'' rather than 'my' or 'I.' This choice of words, utilizing 'you,' creates trust and mutual understanding, whereas 'my' can potentially cause confusion among our users. I is also helping the user to feel like the UI is talking to them and referring to their actions.\n\nDon’t combine first and second person. Avoid mixing 'me' or 'my' with 'you' or 'your.'\n\nAn exception to this rule are found in agreements or acknowledgments. For example, “I agree to the terms of service.”\n\nProfile and settings\n\nLorem ipsum dolor sit amet consectetur adipisicing elit. Aliquam velit commodi sunt nostrum nisi? Voluptas eos dolorum error amet esse. Fugit consequatur obcaecati deleniti! Corrupti praesentium molestiae voluptate a rem.\n\nMy profile & settings\n\nLorem ipsum dolor sit amet consectetur adipisicing elit. Aliquam velit commodi sunt nostrum nisi? Voluptas eos dolorum error amet esse. Fugit consequatur obcaecati deleniti! Corrupti praesentium molestiae voluptate a rem.",
+      "examples": []
+    },
+    {
+      "heading": "Active and passive voice",
+      "body": "Use active voice in most cases and use passive voice sparingly.\n\n- With active voice, sentences are simpler, shorter, clearer, and more conversational.\n- With passive voice, you can soften and provide distance in select situations (e.g., notification of a disabled account).\n\nActive voice means the subject of the sentence performs the action. With passive voice, the subject receives the action. For avoiding passive voice it often helps to rephrase a message and center it around the object or the actions that someone could undertake.\n\nUsing present tense and an active voice shortens and simplifies our sentences. Past and future tenses, along with passive voice, make our users read more words to convey the same message. Additionally, the active voice ensures we take responsibility for our actions.\n\nOne exception is when you want to specifically emphasize the action over the subject. In some cases, this is fine: Your account was flagged by our Abuse team.\n\nJohn Doe resolved your comment\n\nYour payment has been declined\n\nSomething went wrong\n\nYour comment was resolved by John Doe\n\nWe declined your payment\n\nAn error happened\n\nQuickly categorize your transactions\n\nThe team conducted usability tests with customers\n\nWe couldn’t save your changes. Try again in a moment.\n\nChanges saved\n\n34 invoices sent\n\nYour transactions can quickly be categorized\n\nUsability tests were conducted with customers\n\nYour changes weren’t saved\n\nThe system saved your changes\n\nYou sent 34 invoices",
+      "examples": []
+    },
+    {
+      "heading": "Focus your message",
+      "body": "Create a hierarchy of information. Lead with the main point or the most important content, in sentences, paragraphs, sections, and pages.",
+      "examples": []
+    },
+    {
+      "heading": "Capitalization",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Title case vs. sentence case",
+      "body": "In most products and websites today, there are two ways to capitalize words:\n\n- Title case: Capitalize every word. This Is Title Case.\n- Sentence case: Capitalize the first word. This is sentence case.\n\nEven though title case looks more formal, serious and provides symmetry especially on buttons or short headlines, it is also harder to implement. Many rules and exceptions behind it are sometimes not easy to understand or to grasp.\n\nSentence case on the other hand is much easier to read especially when the text gets long. It is also easier to define and easier to explain to designers and engineers. No rules for what to capitalize and what no. Sentence case also looks more friendly and casual. It feels more natural and approachable.",
+      "examples": []
+    },
+    {
+      "heading": "Sentence case rules",
+      "body": "Use sentence case, even in headings and titles, labels and buttons.\n\nSentence case is friendly. It helps support the approachable RIO style and brand personality. It also makes translation a bit easier.\n\nSentence case tends to be easier to read and comprehend, especially when CTA labels are more than three words. Also, breadcrumb labels in sentence case are easier to scan.\n\nSentence case improves consistency. In an environment of many independent teams, it’s a lot easier to implement the sentence case.\n\nProper nouns, Products, and branded terms may also be capitalized.",
+      "examples": []
+    },
+    {
+      "heading": "When in doubt, don’t capitalize",
+      "body": "Default to sentence-style capitalization. Capitalize only the first word of a heading or phrase and any proper nouns or names. Never Use Title Capitalization (Like This).\n\n- Find a RIO partner\n- New RIO customer\n- Limited-time offer\n- Join us online\n\n- Find a RIO Partner\n- New RIO Customer\n- Limited-Time Offer\n- Join Us Online\n\nA proper noun is a specific name used for an individual person, place, organization, or sometimes thing, which is always capitalized in English. Proper nouns differ from common nouns, which are general names for a class of objects or concepts.\n\nExamples of proper nouns include:\n\n- People: \"John Smith,\" \"Marie Curie\"\n- Places: \"New York,\" \"Mount Everest,\" \"The Nile River\"\n- Organizations: \"Microsoft,\" \"United Nations\"\n- Titles: \"The Great Gatsby,\" \"Time Magazine\"\n\nIn contrast, examples of common nouns include:\n\n- People: \"man,\" \"woman\"\n- Places: \"city,\" \"mountain,\" \"river\"\n- Organizations: \"company,\" \"club\"\n- Titles: \"book,\" \"magazine\"",
+      "examples": []
+    },
+    {
+      "heading": "Use ALL CAPS only when you should",
+      "body": "Avoid using ALL CAPITAL LETTERS. It’s like screaming, and it may present additional difficulty for reading longer texts. We occasionally display all capital letters in headings on marketing pages, badges (such as NEW, PLUS, or FREE), or navigation labels but of these uses are exceptions.\n\nThere are capitalization exceptions on some marketing pages. To attract new customers and encourage action, marketers might capitalize the word free or some catch phrases. Research proves that the capitals are effective for conversion, but the promotional tone of the capital letters is out of place in the in-product conversation.",
+      "examples": []
+    },
+    {
+      "heading": "Punctuation",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Skip periods and unnecessary punctuation (\" : ! ?\")",
+      "body": "Skip end punctuation on titles, headings, subheads, UI titles, and items in a list that are three or fewer words. Save the periods for paragraphs and body text. This helps readers scan text more easily.\n\n- Labels\n- Single sentence tooltip text\n- Bulleted lists\n- Dialog headlines and single sentence dialog body\n\n- Multiple sentences\n- Long or complex sentences, if it suits the context\n- Any sentence followed by a link. Links themselves should not be full sentences.",
+      "examples": []
+    },
+    {
+      "heading": "Skip colons in headings",
+      "body": "For headings on lists of items, do not use colons. For lists within body text, use a colon.",
+      "examples": []
+    },
+    {
+      "heading": "Use exclamation points sparingly",
+      "body": "Exclamation points can come across as shouting or overly friendly.",
+      "examples": []
+    },
+    {
+      "heading": "Remember the last comma",
+      "body": "In a list of three or more items, include a comma before the conjunction. Don't use it followed by an ampersand. The comma that comes before the conjunction is known as the Oxford or serial comma.",
+      "examples": []
+    },
+    {
+      "heading": "UI elements",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Buttons",
+      "body": "Button texts should always include verbs. Keep things clear and concise, and use sentence case. It’s OK to use an ampersand in button text.\n\nPair action verbs with nouns. Is the user saving details, downloading an invoice, or editing an order? Pairing tells the user exactly what will happen.\n\nIn general, follow these guidelines\n\n- Use chevron icons (left and right) to indicate directions\n- Use the plus and delete icons for creation and deletion respectively\n- Explain what’s going to happen next\n- Be concise\n\nExplain what’s going to happen next\n\nAmbiguous button labels, such as yes/no, submit/cancel, or abort/continue provide minimal information to the user. This requires the user to read the dialog text in order to complete the task, making them prone to misinterpretation and adding extra effort for users.\n\nAre you sure you want to edit this existing order?\n\nAre you sure you want to edit this existing order?\n\nConsider this: If you remove all the text around your buttons, could the user still accomplish the task? If not, change your button labels. Use words that motivate immediate action.\n\nDon’t cancel the cancellation\n\nWhen you have buttons for actions that could cause problems, like deleting something or stopping a service, it's important to make sure people understand what the buttons do.\n\nFor example, if one button says confirm and another says cancel, it might not be clear which one actually cancels the action. This can lead to people making mistakes.\n\nTo help users, always use clear words on buttons that tell them exactly what will happen when they click them.\n\nIf you use the same words on the buttons as you do in the title or header, it makes everything easier to understand and encourages users to take the right action. This way, you avoid confusing labels like confirm/cancel. Also, if you use a word like 'keep' on the second button, it makes it really easy for users to not accidentally cancel something.\n\nDon’t truncate button text\n\nAvoid truncating button text, as it can confuse users about the buttons intention.\n\nStrive for concise button text, and consider using labels if needed.\n\nIf your buttons have longer text that doesn't fit due to limited space, stack them to ensure clarity, especially in narrow containers with multiple buttons.",
+      "examples": []
+    },
+    {
+      "heading": "Forms",
+      "body": "General form guidelines\n\nPlease follow these rules when implementing and designing form in your service\n\n- Mark optional or required fields. Add the \"* Fields are required\" legend.\n- Group the label and the respective form element and separate them visually from other form elements\n- Use placeholders to provide users a hint to avoid input mistakes\n- In case explain what you want the data for\n\nWhen to validate\n\n- Validate on submit and re-validate on change\n- Validate on blur\n- Don’t validate on first input click and avoid showing errors immediately when the user starts typing\n- If realtime validation is needed, use a debounce mechanism to delay validation until the user pauses typing for a short period (e.g., 300-500 milliseconds). This reduces the number of validations and prevents overwhelming the user.\n- For input length validation, display a character counter instead of an error message\n- Use default values or limit options, no validation is needed\n- Disable the submit button, if possible, to avoid errors when using multiple required fields\n- Never rely on a red input border alone in case of an error\n\nBy using techniques like debouncing, on-blur validation, and friendly error messages, you can provide a balanced and user-friendly validation experience.\n\nIn case there is only one or just a few optional fields, rather mark the optional fields than marking all other fields required.\n\nWhen using the * character to mark required fields, please add the explanation for the user even though it is common to use.",
+      "examples": []
+    },
+    {
+      "heading": "Input placeholder",
+      "body": "Placeholder text for form inputs generally should not contain a trailing \"...\" (ellipsis). The purpose of a placeholder is to provide a short hint to the user about what to enter in the field, and adding an ellipsis can create unnecessary visual clutter and may be confusing.\n\nBest practices for placeholder text\n\n- Clear and concise Keep placeholder text short and to the point. Long placeholder text gets cropped making it inaccessible. Use longer text as help text instead.\n- Descriptive Ensure the placeholder text clearly describes the expected input\n- Avoid ellipses Do not use trailing ellipses for placeholders in inputs, for inputs with autocomplete, selects, or dropdowns. Ellipsis are typically used to indicate truncation or continuation, which is not the purpose of placeholder text. It can create ambiguity and doesn't provide clear guidance on what to enter.\n\nExamples of good placeholder text\n\n- \"Search by name\"\n- \"Search for products\"\n- \"Search in table\"\n- \"Find a vehicle by name\"\n- \"Add comment\"\n- \"New message\"\n- \"Enter keywords (e.g., documentation, examples)\"",
+      "examples": []
+    },
+    {
+      "heading": "Form labels and placeholders",
+      "body": "When designing forms, it is crucial to use labels and placeholders effectively to ensure a clear and user-friendly experience.\n\nDifferentiating labels and placeholders\n\n- Avoid redundancy Using both a label and a placeholder with the same value is redundant and unhelpful. Each element serves a distinct purpose.\n- Label usage Labels should clearly describe the input field's purpose. They are persistent and help users understand what information is required, even after they begin typing.\n- Placeholder usage Placeholders should provide an example of the expected input format, not a call-to-action (CTA). For example, use \"example@mail.com\" for an email input field.\n- Special cases for placeholders In most cases, search fields can use a placeholder with CTA text instead of a label. This approach simplifies the form and enhances usability. It can also be applied to other input fields where a label would be unnecessary and would complicate the design, such as message inputs, comment sections, and chat windows.\n- Appropriate styling Form labels should not be styled as headlines. Headline styles are generally too prominent and can distract from the form's usability. Labels should be clear and readable, ensuring they complement the form design without overwhelming it. Headlines should be used for an entire form or a form section to provide clear grouping and structure. For more detailed grouping within a form, you may use the <fieldset> element with a <legend> to create a clearly defined section, which helps users understand the organization and purpose of different parts of the form. This approach enhances readability and navigability, making the form more user-friendly.",
+      "examples": []
+    },
+    {
+      "heading": "Dialogs",
+      "body": "Avoid presenting users with unclear choices. “Cancel” doesn't make sense here because no clear action is proposed.",
+      "examples": []
+    },
+    {
+      "heading": "Error states",
+      "body": "Always use the header and the description of a state when using components like ErrorState, NotFoundState, EmptyState, or any other state.\n\nLeaving out the message and using the headline for the user action feels like shouting to the user.",
+      "examples": []
+    },
+    {
+      "heading": "Notifications",
+      "body": "This guide outlines the best practices for crafting notification messages. The aim is to ensure consistency, clarity, and brevity across all notification messages.\n\nGeneral notification guideline\n\nNaming the subject first in notifications is a common and effective best practice. Here’s why this approach is beneficial:\n\n1. Clarity It immediately informs the user about what the notification is regarding. This is particularly useful when multiple notifications are displayed at once or when users are multitasking.\n2. Consistency Maintaining a consistent structure helps users quickly understand the nature of the notification. If the subject is always mentioned first, users will become accustomed to scanning for that information first.\n3. Prioritization In notifications where users might need to take action or understand the context quickly, presenting the subject first allows them to prioritize their attention effectively.\n4. Readability It can improve readability and user experience by clearly separating the notification's subject from its outcome or details.\n\nConsiderations\n\n- Keep the message consistent in structure across different contexts\n- Use a period at the end of the message only if part of a full sentence in a larger context but omit it in standalone notifications.\n- Keep the message short and to the point\n- The tone should be professional and neutral\n- Use simple and straightforward language. Don’t use technical terms that may not be familiar to all users.\n- Don’t use exclamation marks (e.g., \"Address copied to clipboard!\")\n\n- Name copied to clipboard\n- Tour published successfully\n- Appointment created successfully\n- Failed to create the appointment\n- The file could not be uploaded\n- Your changes could not be saved",
+      "examples": []
+    },
+    {
+      "heading": "Data load error",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Invalid input",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Appointment not scheduled",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "New feature: Order tracking",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Account review completed",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Completed successfully",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Error",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Invalid",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Error",
+      "body": "Usage guide for notifications\n\nA comprehensive guide to using default, info, success, warning, and error notifications effectively.\n\nNeutral or low-priority updates that don’t fit into other categories.\n\n- Best for: General feedback or updates, non-urgent information, or messages without special emphasis.\n- Examples: \"Your report is being generated\" \"This feature is in beta\"\n\n- \"Your report is being generated\"\n- \"This feature is in beta\"\n\nProvide actionable or helpful information to the user.\n\n- Best for: Announcements, tips, or non-urgent details users should know.\n- Examples: \"A new version of the app is available\" \"This vehicle has no position data\" \"Pro tip: Use filters to narrow your search results.\"\n\n- \"A new version of the app is available\"\n- \"This vehicle has no position data\"\n- \"Pro tip: Use filters to narrow your search results.\"\n\nCelebrate or confirm that an action was successfully completed.\n\n- Best for: Positive feedback for completed tasks or goals.\n- Examples: \"Your profile has been updated successfully\" \"Your message has been sent\" \"Payment processed successfully\"\n\n- \"Your profile has been updated successfully\"\n- \"Your message has been sent\"\n- \"Payment processed successfully\"\n\nAlert users about potential risks or actions they should take to avoid issues.\n\n- Best for: Situations requiring user action to prevent problems or risks.\n- Examples: \"Your password will expire soon. Update it now.\" \"Your account is approaching its storage limit\" \"Some items in your cart are no longer available\"\n\n- \"Your password will expire soon. Update it now.\"\n- \"Your account is approaching its storage limit\"\n- \"Some items in your cart are no longer available\"\n\nNotify users of problems or issues that require immediate attention.\n\n- Best for: Failed actions, critical issues, or situations blocking progress.\n- Examples: \"Failed to save changes. Please try again.\" \"Unable to process your payment\" \"Something went wrong. Contact support for assistance.\"\n\n- \"Failed to save changes. Please try again.\"\n- \"Unable to process your payment\"\n- \"Something went wrong. Contact support for assistance.\"\n\n\"Copy to clipboard\" notification guidelines\n\nAll success notifications for clipboard actions should follow this structure: \"<Item> copied to clipboard\"\n\n- <Item>: The specific content that has been copied (e.g., Address, Coordinates, Link, Name)\n- copied to clipboard: A fixed phrase that confirms the action and its result\n- Omit the close button as this message should be shown with the default timeout and disappear automatically\n\n- Address copied to clipboard\n- Coordinates copied to clipboard\n- Name copied to clipboard\n- Text copied to clipboard",
+      "examples": []
+    },
+    {
+      "heading": "48.11293, 11.53486",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Error messages",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Errors in general",
+      "body": "Errors can cause frustration, confusion, a loss of data, or more work for the user. These moments make it harder for them to finish their task.\n\nNo matter the design component or the length of the message, the most thorough error messages consist of three clear communication elements\n\n- What happened\n- The underlying cause (if possible)\n- How to fix it",
+      "examples": []
+    },
+    {
+      "heading": "Avoid showing a message whenever possible",
+      "body": "The best error message is no error happening at all.\n\nFind ways to avoid the error altogether, like by using in-line validation, visual cues, and disabled states to guide users.",
+      "examples": []
+    },
+    {
+      "heading": "Have the system automatically resolve errors",
+      "body": "Avoid using error messages as the first solution. Instead, design things so that the user interface doesn't need to show errors or ask users to fix problems whenever you can.\n\nFor instance, if a user types \"101\" into a field that should only allow numbers up to 100, like percentages, the system should automatically change the value to 100.",
+      "examples": []
+    },
+    {
+      "heading": "Use plain language, and avoid jargon",
+      "body": "Your Users may not understand \"server architecture\" or \"client-side queries\". Know your audience, and write your error messages in plain, usable language so that your user will understand what went wrong and how it’s being resolved.\n\nTechnical terms are different than jargon. If you’re confident that your audience would be readily familiar with technical terms, and if such terms are relevant to the message, you can include them.",
+      "examples": []
+    },
+    {
+      "heading": "Commonly misspelled or misformatted words",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "List of commonly misspelled words",
+      "body": "There are quite a few words that are commonly written incorrectly or inconsistently in software and UI texts. Here are some frequent ones\n\n- Login vs. log in ✅ Correct: Log in (verb) / Login (noun, adjective) ❌ Incorrect: Login to your account (should be Log in to your account)\n- Sign up vs. signup ✅ Correct: Sign up (verb) / Signup (noun, adjective) ❌ Incorrect: Create a sign up (should be Create a signup)\n- Log out vs. logout ✅ Correct: Log out (verb) / Logout (noun, adjective) ❌ Incorrect: Please logout (should be Please log out)\n- Cancel vs. abort ✅ Preferred: Cancel (stop an action before it completes, more user friendly) ✅ Correct but technical: Abort (To forcefully stop a process. Used in more technical contexts, like system failures - e.g., \"Process aborted due to an error\") ❌ Incorrect in general UI: Abort (too harsh for standard user actions)\n- Email vs. e-mail ✅ Correct: Email (correct and widely used in software, more modern, should be capitalized at the start of a sentence) ✅ Correct within copy: email (standard when it's in the middle of a sentence, as it's a common noun, e.g., \"Please enter your email address.\") ❌ Incorrect: E-mail (technically correct but outdated)\n- Email vs. e-mail in German context 🇩🇪 ✅ Correct in German UI: E-Mail (official and correct) ❌ Incorrect: Email (while gaining popularity, \"Email\" is still considered incorrect in formal German writing) ❌ Incorrect: email without capitalization in German ✅ Correct: E-Mail-Adresse (official and correct) ❌ Incorrect: Email-Adresse without capitalization in German\n- Username vs. user name ✅ Correct: Username ❌ Incorrect: User name (though some older UIs still use this)\n- Last name vs. surname 🟢 Preferred: Last name (even in en-GB UI) ✅ Formal: Surname (less common in UI, more in official documents) ❌ Incorrect: Lastname (should be two words: Last name)\n- Last name vs. surname in German context 🇩🇪 🟢 German UI: Nachname ✅ Official forms: Familienname (but avoid in casual UI)\n- Ok vs. okay ✅ Correct: OK (most common in UI) ❌ Incorrect: Okay (too informal for UI)\n- Home page vs. homepage ✅ Correct: Home page (two words) ❌ Incorrect: Homepage (often used but technically incorrect)\n- 2FA vs. two-factor authentication ✅ Correct: Two-factor authentication (2FA) ❌ Incorrect: 2FA authentication (redundant)\n- Wi-fi vs. wifi vs. WiFi ✅ Correct: Wi-Fi ❌ Incorrect: WiFi (often seen but not the official spelling)\n\n- ✅ Correct: Log in (verb) / Login (noun, adjective)\n- ❌ Incorrect: Login to your account (should be Log in to your account)\n\n- ✅ Correct: Sign up (verb) / Signup (noun, adjective)\n- ❌ Incorrect: Create a sign up (should be Create a signup)\n\n- ✅ Correct: Log out (verb) / Logout (noun, adjective)\n- ❌ Incorrect: Please logout (should be Please log out)\n\n- ✅ Preferred: Cancel (stop an action before it completes, more user friendly)\n- ✅ Correct but technical: Abort (To forcefully stop a process. Used in more technical contexts, like system failures - e.g., \"Process aborted due to an error\")\n- ❌ Incorrect in general UI: Abort (too harsh for standard user actions)\n\n- ✅ Correct: Email (correct and widely used in software, more modern, should be capitalized at the start of a sentence)\n- ✅ Correct within copy: email (standard when it's in the middle of a sentence, as it's a common noun, e.g., \"Please enter your email address.\")\n- ❌ Incorrect: E-mail (technically correct but outdated)\n\n- ✅ Correct in German UI: E-Mail (official and correct)\n- ❌ Incorrect: Email (while gaining popularity, \"Email\" is still considered incorrect in formal German writing)\n- ❌ Incorrect: email without capitalization in German\n\n- ✅ Correct: E-Mail-Adresse (official and correct)\n- ❌ Incorrect: Email-Adresse without capitalization in German\n\n- ✅ Correct: Username\n- ❌ Incorrect: User name (though some older UIs still use this)\n\n- 🟢 Preferred: Last name (even in en-GB UI)\n- ✅ Formal: Surname (less common in UI, more in official documents)\n- ❌ Incorrect: Lastname (should be two words: Last name)\n\n- 🟢 German UI: Nachname\n- ✅ Official forms: Familienname (but avoid in casual UI)\n\n- ✅ Correct: OK (most common in UI)\n- ❌ Incorrect: Okay (too informal for UI)\n\n- ✅ Correct: Home page (two words)\n- ❌ Incorrect: Homepage (often used but technically incorrect)\n\n- ✅ Correct: Two-factor authentication (2FA)\n- ❌ Incorrect: 2FA authentication (redundant)\n\n- ✅ Correct: Wi-Fi\n- ❌ Incorrect: WiFi (often seen but not the official spelling)",
+      "examples": []
+    }
+  ],
+  "see_also": []
+}

package/data/pages/Getting-started/start/howto.json

@@ -0,0 +1,72 @@
+{
+  "metadata": {
+    "captured_at": "2025-11-21T12:06:59.532Z",
+    "source": "https://uikit.developers.rio.cloud/#start/howto",
+    "category": "Getting started",
+    "section": "Welcome",
+    "slug": "start/howto",
+    "version": "v1.13.2",
+    "hash_algorithm": "sha256",
+    "hash": "49593e94f3b75ad9e500803602528cde77240f91e08dc9749745fbe73c6c7691"
+  },
+  "title": "How to use the UIKIT",
+  "lead": "Install the latest version of the UIKIT (that includes latest beta versions as well) via",
+  "content": [
+    {
+      "heading": "How to use the UIKIT",
+      "body": "- Install the npm package\n- Typescript\n- Document <head /> key meta tags\n- UIKIT CSS\n- Brand themes Print styles Additional styling information Dark mode\n- UIKIT Javascript packages via CDN\n- Dependencies\n\n- Typescript\n\n- Brand themes\n- Print styles\n- Additional styling information\n- Dark mode",
+      "examples": []
+    },
+    {
+      "heading": "Install the npm package",
+      "body": "```javascript\nnpm install @rio-cloud/rio-uikit\n```\n\nOr install a dedicated version via\n\n```javascript\nnpm install @rio-cloud/rio-uikit@1.13.2\n```\n\nThe UIKIT provides CommonJS modules (using require()) as well as ES Modules (using import statements) and is also tree-shakable, means only those components that you import as a direct import from the UIKIT will be added to your bundle. The CommonJS modules are inside the /lib/es folder due to backward compatibility. For the new EcmaScript modules you can omit the path entirely. Import components as follows:\n\n```javascript\n// CommonJS imports\nimport ClearableInput from '@rio-cloud/rio-uikit/lib/es/ClearableInput';\nimport Spinner from '@rio-cloud/rio-uikit/lib/es/Spinner';\n\n// EcmaScript module imports\nimport ClearableInput from '@rio-cloud/rio-uikit/ClearableInput';\nimport Spinner from '@rio-cloud/rio-uikit/Spinner'\n```\n\n> Note: When using EcmaScript Modules, make sure to update your configuration as Webpack and Jest don't work with ESM imports out of the box. When using Vite, you can also migrate to Vitest.\n\nEven though it is possible to import components without the direct import as shown below but this is not recommended as it results in larger bundles as the entire UIKIT will be added to your bundle.\n\n```javascript\n// Don't use this\nimport { ClearableInput, Spinner } from \"@rio-cloud/rio-uikit\";\n```\n\n> Tip: For better loading performance we recommend splitting your UIKIT imports into a dedicated bundle and not mixing it with other vendor imports. Checkout https://webpack.js.org/guides/code-splitting/ for more details.",
+      "examples": []
+    },
+    {
+      "heading": "TypeScript",
+      "body": "The UIKIT is built with TypeScript and defines the types inside the components.\n\n> Note: Do not import types from the ./types.ts file directly as this is an internal file and subject to change. Import enums, constants and types from the declaration file together with the component.\n\n```javascript\nimport AutoSuggest, { type AutoSuggestSuggestion } from \"@rio-cloud/rio-uikit/AutoSuggest\";\nimport Select, { type SelectOption } from \"@rio-cloud/rio-uikit/Select\";\nimport TableViewToggles, { type TableViewTogglesViewType } from \"@rio-cloud/rio-uikit/TableViewToggles\";\n```",
+      "examples": []
+    },
+    {
+      "heading": "Document <head /> key meta tags",
+      "body": "Mandatory\n\nThe utf-8 meta tag is essential for ensuring that your webpage correctly displays text in a wide range of languages and symbols. By setting the character encoding to UTF-8, this tag enables support for almost all characters, including those used in non-Latin scripts, special symbols, and emojis.\n\nThis not only guarantees proper rendering of your content but also prevents common issues such as garbled or corrupted text and icons, known as mojibake. Modern web browsers and standards expect UTF-8 encoding by default, making this tag a critical component of any HTML document. Including this tag ensures your webpage is globally accessible and aligns with current best practices in web development.\n\n```html\n<meta charset=\"utf-8\" />\n```\n\nBest practices\n\nThe viewport meta tag is a cornerstone of responsive web design. It configures the viewport settings to match the device’s screen width, ensuring that your webpage adapts seamlessly to different screen sizes. Without this tag, mobile devices often display pages as a scaled-down version of their desktop layout, requiring users to zoom or scroll horizontally.\n\nBy specifying the initial scale and width, this tag guarantees that your content is displayed optimally on all devices, from smartphones to tablets to desktops. Additionally, it improves user experience, enhances accessibility, and supports SEO by meeting mobile-friendly standards, making it a crucial inclusion in any modern HTML document.\n\n```html\n<meta name=\"viewport\" content=\"initial-scale=1.0, width=device-width\" />\n```",
+      "examples": []
+    },
+    {
+      "heading": "UIKIT CSS",
+      "body": "> Recommended: RECOMMENDED\n\nWhen utilizing the ApplicationLayout component, the UIKIT automatically ensures the inclusion of the necessary CSS style tag within your index.html, providing seamless integration and enhanced functionality.\n\nYou no longer need to manually add the CSS style tag to your index.html. Feel free to remove it if you prefer to manage it yourself.\n\n> Note: Please note that every application and every widget must be wrapped with the <ApplicationLayout />, as it executes our init function.\n\n> Not Recommended: NOT RECOMMENDED\n\nUse the CSS Stylesheet as follows (specify your required version number in the URL) if you need more control on what style you want to use.\n\n```html\n<link rel=\"stylesheet\" type=\"text/css\" href=\"https://uikit.developers.rio.cloud/1.13.2/rio-uikit.css\">\n```\n\n> Note: Please make sure to use the same UIKIT style version as the npm package, otherwise this will lead to inconsistency and UI bugs.",
+      "examples": []
+    },
+    {
+      "heading": "Brand themes",
+      "body": "In addition to the RIO theme, the UIKIT offers other brand-specific themes.\n\nThese other themes may only be used for applications or services who don't run on the RIO platform. All platform services have to use the RIO theme to achieve a distinct look and feel for the user when switching between services and applications.\n\nIn order to use such a brand theme, modify the URL in the <link> tag that loads the CSS\n\n```html\n<link rel=\"stylesheet\" type=\"text/css\" href=\"https://uikit.developers.rio.cloud/1.13.2/vw-uikit.css\">\n```\n\n```html\n<link rel=\"stylesheet\" type=\"text/css\" href=\"https://uikit.developers.rio.cloud/1.13.2/man-uikit.css\">\n```\n\n```html\n<link rel=\"stylesheet\" type=\"text/css\" href=\"https://uikit.developers.rio.cloud/1.13.2/scania-uikit.css\">\n```\n\n> Recommended: RECOMMENDED\n\nYou can simply omit the <link> tag in your index.html altogether. The UIKIT will automatically load the correct CSS file for you.\n\n```html\n<html data-brand=\"vw\">\n```\n\n```html\n<html data-brand=\"man\">\n```\n\n```html\n<html data-brand=\"scania\">\n```",
+      "examples": []
+    },
+    {
+      "heading": "Print styles",
+      "body": "The UIKIT supports simple print stylings in order to have printable content. See Print CSS\n\n```html\n<link rel=\"stylesheet\" type=\"text/css\" href=\"https://uikit.developers.rio.cloud/1.13.2/rio-uikit-print-utilities.css\">\n```",
+      "examples": []
+    },
+    {
+      "heading": "Additional styling information",
+      "body": "In some cases like using D3 you may need the color variables as .json from the UIKIT provided via CDN. You can fetch the provided file from CDN via the following URL\n\n```html\nhttps://uikit.developers.rio.cloud/1.13.2/rio-uikit-colors.json\n```\n\nor import it from the UIKIT JavaScript bundle as follows\n\n```javascript\nimport { colors } from \"rio-uikit\";\n```",
+      "examples": []
+    },
+    {
+      "heading": "Dark mode",
+      "body": "The UIKIT is fully dark mode ready.\n\n> Note: Please note that every application and every widget must be wrapped with the <ApplicationLayout /> as it executes our init function.\n\n```jsx\n<ApplicationLayout>\n    <ApplicationLayout.Header>\n        <ApplicationHeader label='RIO Service' navItems={navItems} />\n    </ApplicationLayout.Header>\n    <ApplicationLayout.Body>\n        <div>My application</div>\n    </ApplicationLayout.Body>\n</ApplicationLayout>\n```\n\n```jsx\n<ApplicationLayout>\n    <div>My widget</div>\n</ApplicationLayout>\n```\n\nIn cases where the React ApplicationLayout component cannot be used, you can import the new darkmode.js from the UIKIT CDN and add it to your index.html. This script will take care of listening to the theme switch for you.\n\n```html\n<script src=\"https://uikit.developers.rio.cloud/1.13.2/rio-darkmode.js\"></script>\n```\n\nIf you want to react on the dark mode for instance to exchange some images or apply some specific utility classes, you can use the custom hook useDarkMode to do so.\n\nTo manually enable dark mode when testing your application locally, adddata-theme=\"dark\" to the <html> tag.",
+      "examples": []
+    },
+    {
+      "heading": "UIKIT Javascript packages via CDN",
+      "body": "> not recommended for production: NOT RECOMMENDED FOR PRODUCTION\n\nThe UIKIT can be integrated via URL from the UIKIT CDN. This is helpful, when building HTML mockups or on code sample platforms like codesandbox.io\n\nUse the UIKIT JavaScript bundle as shown below. The UIKIT will be accessible via window.RioUikit.\n\n```html\n<script src=\"https://uikit.developers.rio.cloud/1.13.2/rio-uikit.js\"></script>\n```",
+      "examples": []
+    },
+    {
+      "heading": "Dependencies",
+      "body": "As of version 1.7.0 the RIO UIKIT has the following dependencies:\n\npeerDependencies\n\n```javascript\n\"react\": \">=18.0.0\"\n\"react-dom\": \">=18.0.0\"\n```",
+      "examples": []
+    }
+  ],
+  "see_also": []
+}

package/data/pages/Getting-started/start/intro.json

@@ -0,0 +1,37 @@
+{
+  "metadata": {
+    "captured_at": "2025-11-21T12:06:59.360Z",
+    "source": "https://uikit.developers.rio.cloud/#start/intro",
+    "category": "Getting started",
+    "section": "Welcome",
+    "slug": "start/intro",
+    "version": "v1.13.2",
+    "hash_algorithm": "sha256",
+    "hash": "212f81e12f448c7a07c48b0dbbe420532ebddbc1331548b681e7bc1d5b804839"
+  },
+  "title": "Getting started with our UI Library",
+  "lead": "Welcome! This UI library is designed to help you build beautiful, consistent, and maintainable user interfaces with minimal effort. Here’s how you can make the most of it:",
+  "content": [
+    {
+      "heading": "Getting started with our UI Library",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Use atomic CSS classes for styling",
+      "body": "- Consistency By using our predefined classes, your UI will have a common look and feel across all components\n- Maintainability When design updates occur, changes to the utility classes automatically propagate across the entire project, making updates easy and seamless\n- No custom styles needed Avoid the overhead of writing custom CSS. Use the tools we’ve already created to keep your codebase lean and manageable.\n\nFor example, instead of writing custom CSS for a flex container:\n\n```css\n.my-container {\n  display: flex;\n  justify-content: center;\n}\n```\n\nSimply apply the atomic classes:\n\n```html\n<div class=\"display-flex justify-content-center\">...</div>\n```",
+      "examples": []
+    },
+    {
+      "heading": "Use React components for structure",
+      "body": "- Quickly build UIs using pre-built components like the buttons, selects, and dialogs\n- Combine React components with CSS classes to create complex layouts with minimal custom code\n- Extend your layouts by composing React components while using utility classes to tweak the design where necessary",
+      "examples": []
+    },
+    {
+      "heading": "Why stick to our CSS classes and components?",
+      "body": "- Efficiency Our library is optimized to reduce the need for custom styling and component creation. You’ll spend less time on UI design and more time on functionality.\n- Design flexibility When design changes occur, updating the UIKIT, a single CSS class or React component ensures that your entire project is updated without manual intervention\n- Better collaboration By sticking to the predefined patterns, your team will maintain consistency across projects, making it easier for multiple developers to collaborate without the risk of style mismatches",
+      "examples": []
+    }
+  ],
+  "see_also": []
+}

package/data/pages/Getting-started/start/responsiveness.json

@@ -0,0 +1,52 @@
+{
+  "metadata": {
+    "captured_at": "2025-11-21T12:06:59.542Z",
+    "source": "https://uikit.developers.rio.cloud/#start/responsiveness",
+    "category": "Getting started",
+    "section": "Guidelines",
+    "slug": "start/responsiveness",
+    "version": "v1.13.2",
+    "hash_algorithm": "sha256",
+    "hash": "8f145d78e8f3d22c41561cf66482f13195ee50d98a914389b4fb481a1b32ad54"
+  },
+  "title": "Responsiveness - for all platforms",
+  "lead": "The UIKIT considers all platforms — both desktop and mobile. We recognize that people work across many different products and often need to support multiple platforms and the UIKIT is a foundation for that with its many responsive building blocks and responsive components.",
+  "content": [
+    {
+      "heading": "Responsiveness - for all platforms",
+      "body": "",
+      "examples": []
+    },
+    {
+      "heading": "Principal",
+      "body": "To build for all platforms, there are a lot of options and tools that can be used.",
+      "examples": []
+    },
+    {
+      "heading": "Layout",
+      "body": "Fluid container\n\nResponsive grid systems\n\nA responsive grid system allows a layout to change dynamically based on the size of the screen or the surrounding element. This also guarantees consistent layouts across all products.",
+      "examples": []
+    },
+    {
+      "heading": "Spacings & sizing",
+      "body": "The UIKIT offers also responsive padding and margin classes that allow reducing or increasing the spacing around elements depending on a certain breakpoint. This for example enables to set a smaller margin on mobile devices than on desktops.\n\nWith our flexible and responsive width and height classes, you have the freedom to define different sizes for different breakpoints or use our min- and max classes.",
+      "examples": []
+    },
+    {
+      "heading": "Container queries",
+      "body": "While the traditional responsive utilities mentioned above (e.g., --sm--, --md--, --lg--) adapt components based on the viewport width, container queries take a different approach by allowing components to respond to the size of their parent container instead. This enables a more context-aware and flexible design system—especially useful when components live in dynamic or nested layouts (like sidebars, cards, or split views).\n\nWhy use container queries?\n\nSometimes, the screen size alone is not enough to decide how a component should behave. For example:\n\n- A card inside a wide layout may want to show content side-by-side.\n- The same card inside a sidebar should stack the content vertically.\n\nContainer queries let components adapt to these situations without relying on global breakpoints.\n\nUsage\n\nThe RIO UIKIT introduces container query utility classes using the following format:\n\n```html\ncq-[cq-breakpoint]:[utility-class]\n```\n\nWhere cq-breakpoint is the container width in pixels that triggers the style, such as:\n\n- cq-300:padding-10\n- cq-500:flex-column\n- cq-600:grid-cols-2\n\nThe utility is applied only when the container width is greater than or equal to the breakpoint.\n\nAvailable utility classes\n\nContainer queries support not all, but many of the same utility categories as responsive viewport classes:\n\n- Spacing: margin, padding, etc.\n- Layout: display-flex, flex-row, flex-column, gap, display-grid, grid-cols, col-span, etc.\n- Text sizes: text-size, line-height\n- Custom responsive behaviors based on your layout context\n\nSee the full list of container query utilities in the Container queries section.\n\nExample\n\n```html\n<div className=\"cq-container\">\n    <div className=\"cq-300:flex-column cq-600:flex-row cq-300:padding-10\">\n        <!-- content -->\n    </div>\n</div>\n```\n\nIn this example:\n\n- The inner element uses a column layout when its container is at least 300px wide.\n- It switches to a row layout when the container is at least 600px wide.\n- Padding is also conditionally applied based on container size.\n\n> Note: Make sure the container element has cq-container applied, as it sets up the container context required for the styles to react correctly.",
+      "examples": []
+    },
+    {
+      "heading": "Device utils",
+      "body": "We also offer a set of device utility functions such as hasTouch, isMobile, and isDesktop. This allows to hide or show elements for mobile or to switch settings for some components how to behave. For instance, you might want to show the table card view when a page is rendered on mobile. Or you might want to expand or collapse information depending on your device.\n\nFurthermore, we offer some hooks like the useWindowResize hook that helps to react to the user changing his window size and to react accordingly. The useOnlineStatus lets you show a message to the user when his device is offline or online again or to react to that event.",
+      "examples": []
+    },
+    {
+      "heading": "There is more...",
+      "body": "Many of our atomic classes are also available for different breakpoints. All classes are listed below the individual demos in the \"CLASSES\" section of the Design page.\n\nWe constantly strive to improve the UIKIT to make it easier to use. If you have questions about the correct usage of these classes or feedback on components, please ask them in the UIKIT Slack channel.",
+      "examples": []
+    }
+  ],
+  "see_also": []
+}