@rio-cloud/uikit-mcp 1.1.9 → 1.1.11

package/dist/docs/start/guidelines/supported-browsers.md

@@ -3,8 +3,15 @@
 *Category:* Getting started
 *Section:* Guidelines
 *Source:* https://uikit.developers.rio.cloud/#/start/guidelines/supported-browsers
-*Captured:* 2026-03-06T10:39:55.894Z
+*Captured:* 2026-04-27T14:57:06.000Z
 
 We currently support the following browsers:
 
-## Supported Browsers
+## Supported Browsers
+
+| Browser | Version | Platform |
+| --- | --- | --- |
+| Mozilla Firefox | >= 140 | Windows / macOS |
+| Google Chrome | last 5 versions | Windows / macOS |
+| Microsoft Edge | last 5 versions | Windows |
+| Apple Safari | last 5 versions | macOS / iOS |

package/dist/docs/start/guidelines/writing.md

@@ -3,7 +3,7 @@
 *Category:* Getting started
 *Section:* Guidelines
 *Source:* https://uikit.developers.rio.cloud/#/start/guidelines/writing
-*Captured:* 2026-03-06T10:39:55.679Z
+*Captured:* 2026-04-27T14:57:06.810Z
 
 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.
 
@@ -13,6 +13,10 @@ Consequently, the language sometimes proves to be confusing, lacking consistency
 
 A 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.
 
+Sources:
+
+This guide is heavily inspired by the following guides:
+
 - Microsoft Writing Style Guide
 - Intuit content design
 - Google’s content design
@@ -66,14 +70,22 @@ A good understanding of UX writing plays a pivotal role in creating better digit
 
 ## Voice and tone
 
+In the same way that products should maintain a consistent look and behavior, they should also maintain a consistent style of communication. Maintain a unified voice while adjusting the tone to suit the specific context of the situation.
+
+In general, try to be
+
 - Clear and understandable
 - Friendly, honest, and responsible
 - Concise and simple
 
 ## Write like you speak
 
+Write like you speak
+
 Read your text aloud. Does it sound like something a real person would say? Be friendly and conversational. No. Robot. Words.
 
+Example
+
 > You need an ID that looks like this: "someone@example.com"
 
 > Invalid ID
@@ -92,6 +104,8 @@ Read your text aloud. Does it sound like something a real person would say? Be f
 
 ## Project friendliness with contractions
 
+Project friendliness with contractions
+
 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.
 
 However, sometimes "do not" can give more emphasis than "don't” when caution is needed.
@@ -100,22 +114,32 @@ However, sometimes "do not" can give more emphasis than "don't” when caution i
 - Be mindful of how many contractions you use in a sentence. Too many contractions can make things difficult to read.
 - Avoid using contractions when dealing with legal concerns, payment processing, and account security. Casual isn’t always the best style when handling sensitive information.
 
+Example
+
 > 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. The business is closed
 
 > 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. The business's closed
 
 ## Get to the point fast
 
+Get to the point fast
+
 Lead with what’s most important. Front-load keywords for scanning. Make customer choices and next steps obvious.
 
+Example
+
 > Save time by creating a document template that includes the styles, formats, and page layouts you use most often. Then use the template whenever you create a new document.
 
 > Templates provide a starting point for creating new documents. A template can include the styles, formats, and page layouts you use frequently. Consider creating a template if you often use the same page layout and style for documents.
 
 ## Be brief
 
+Be brief
+
 Give customers just enough information to make decisions confidently. Prune every excess word.
 
+Example
+
 > Create a chart that's just right for your data by using the Recommended Charts command on the Insert tab.
 
 > The Recommended Charts command on the Insert tab recommends charts that are likely to represent your data well. Use the command when you want to visually present data, and you're not sure how to do it.
@@ -126,12 +150,16 @@ Give customers just enough information to make decisions confidently. Prune ever
 
 ## Addressing users clearly
 
+Addressing users clearly
+
 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.
 
 Don’t combine first and second person. Avoid mixing 'me' or 'my' with 'you' or 'your.'
 
 An exception to this rule are found in agreements or acknowledgments. For example, “I agree to the terms of service.”
 
+Example
+
 > Profile and settings Lorem 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.
 
 > My profile & settings Lorem 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.
@@ -142,6 +170,8 @@ An exception to this rule are found in agreements or acknowledgments. For exampl
 
 ## Active and passive voice
 
+Active and passive voice
+
 Use active voice in most cases and use passive voice sparingly.
 
 - With active voice, sentences are simpler, shorter, clearer, and more conversational.
@@ -153,6 +183,8 @@ Using present tense and an active voice shortens and simplifies our sentences. P
 
 One 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.
 
+Example
+
 > John Doe resolved your comment Your payment has been declined Something went wrong
 
 > Your comment was resolved by John Doe We declined your payment An error happened
@@ -167,8 +199,12 @@ One exception is when you want to specifically emphasize the action over the sub
 
 ## Focus your message
 
+Focus your message
+
 Create a hierarchy of information. Lead with the main point or the most important content, in sentences, paragraphs, sections, and pages.
 
+Example
+
 > To remove a photo from this album, drag it to the trash.
 
 > Drag a photo to the trash to remove it from this album.
@@ -177,6 +213,8 @@ Create a hierarchy of information. Lead with the main point or the most importan
 
 ## Title case vs. sentence case
 
+Title case vs. sentence case
+
 In most products and websites today, there are two ways to capitalize words:
 
 - Title case: Capitalize every word. This Is Title Case.
@@ -186,8 +224,12 @@ Even though title case looks more formal, serious and provides symmetry especial
 
 Sentence 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.
 
+A more detailed comparison between the two cases can be found at: https://www.everyinteraction.com/articles/title-case-vs-sentence-case-in-ui/
+
 ## Sentence case rules
 
+Sentence case rules
+
 Use sentence case, even in headings and titles, labels and buttons.
 
 Sentence case is friendly. It helps support the approachable RIO style and brand personality. It also makes translation a bit easier.
@@ -198,6 +240,8 @@ Sentence case improves consistency. In an environment of many independent teams,
 
 Proper nouns, Products, and branded terms may also be capitalized.
 
+Example
+
 > Create new partner Company name of the partner Cancel Add partner
 
 > Create New Partner Company Name of the Partner Cancel Add Partner
@@ -208,8 +252,12 @@ Proper nouns, Products, and branded terms may also be capitalized.
 
 ## When in doubt, don’t capitalize
 
+When in doubt, don’t capitalize
+
 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).
 
+Example
+
 > Find a RIO partner New RIO customer Limited-time offer Join us online
 
 > Find a RIO Partner New RIO Customer Limited-Time Offer Join Us Online
@@ -232,6 +280,8 @@ In contrast, examples of common nouns include:
 
 ## Use ALL CAPS only when you should
 
+Use ALL CAPS only when you should
+
 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.
 
 There 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.
@@ -240,6 +290,8 @@ There are capitalization exceptions on some marketing pages. To attract new cust
 
 ## Skip periods and unnecessary punctuation (" : ! ?")
 
+Skip periods and unnecessary punctuation (" : ! ?")
+
 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.
 
 - Labels
@@ -251,26 +303,40 @@ Skip end punctuation on titles, headings, subheads, UI titles, and items in a li
 - Long or complex sentences, if it suits the context
 - Any sentence followed by a link. Links themselves should not be full sentences.
 
+Example
+
 > Move a tile 1. Press and hold the tile.
 
 > Move a tile. 1. Press and hold the tile.
 
 ## Skip colons in headings
 
+Skip colons in headings
+
 For headings on lists of items, do not use colons. For lists within body text, use a colon.
 
 ## Use exclamation points sparingly
 
+Use exclamation points sparingly
+
 Exclamation points can come across as shouting or overly friendly.
 
+Example
+
 > Congratulations! You created your first connection
 
 > No contracts! Save a contract and it’ll appear here
 
+Exclamation marks can be used to emphasize celebratory momentsAvoid using exclamation marks for empty states and common tasks. Save it for bigger accomplishments
+
 ## Remember the last comma
 
+Remember the last comma
+
 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.
 
+Example
+
 > Android, iOS, and Windows
 
 > Android, iOS and Windows
@@ -279,6 +345,8 @@ In a list of three or more items, include a comma before the conjunction. Don't
 
 ## Buttons
 
+Buttons
+
 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.
 
 Pair action verbs with nouns. Is the user saving details, downloading an invoice, or editing an order? Pairing tells the user exactly what will happen.
@@ -290,6 +358,8 @@ Pair action verbs with nouns. Is the user saving details, downloading an invoice
 - Explain what’s going to happen next
 - Be concise
 
+Example
+
 > Back Remove component Add new vehicle
 
 > Back Remove Add New Vehicle
@@ -298,6 +368,8 @@ Pair action verbs with nouns. Is the user saving details, downloading an invoice
 
 Ambiguous 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.
 
+Example
+
 > Edit order? Are you sure you want to edit this existing order? Never mind Edit order
 
 > Edit order? Are you sure you want to edit this existing order? Cancel Edit
@@ -314,10 +386,14 @@ To help users, always use clear words on buttons that tell them exactly what wil
 
 If 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.
 
+Example
+
 > Cancel your order? Keep order Cancel order
 
 > Cancel your order? Cancel Confirm
 
+Source: https://medium.com/sainsburys-customer-experience/a-quick-guide-to-writing-better-button-labels-69daecff3497
+
 **Don’t truncate button text**
 
 Avoid truncating button text, as it can confuse users about the buttons intention.
@@ -326,6 +402,8 @@ Strive for concise button text, and consider using labels if needed.
 
 If 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.
 
+Example
+
 > Save & continue Submit application
 
 > Save and continue editing Submit application for review
@@ -336,6 +414,8 @@ If your buttons have longer text that doesn't fit due to limited space, stack th
 
 ## Forms
 
+Forms
+
 **General form guidelines**
 
 Please follow these rules when implementing and designing form in your service
@@ -358,6 +438,8 @@ Please follow these rules when implementing and designing form in your service
 
 By using techniques like debouncing, on-blur validation, and friendly error messages, you can provide a balanced and user-friendly validation experience.
 
+Example
+
 > Name Email address Password Phone number (optional) In case we need to call you for further details
 
 > Name* Email address* Password* Phone number
@@ -372,6 +454,8 @@ When using the * character to mark required fields, please add the explanation f
 
 ## Input placeholder
 
+Input placeholder
+
 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.
 
 **Best practices for placeholder text**
@@ -390,12 +474,16 @@ Placeholder text for form inputs generally should not contain a trailing "..." (
 - "New message"
 - "Enter keywords (e.g., documentation, examples)"
 
+Example
+
 > Password Your password must include 1 lowercase letter and 1 uppercase letter as well as a special character
 
 > Password
 
 ## Form labels and placeholders
 
+Form labels and placeholders
+
 When designing forms, it is crucial to use labels and placeholders effectively to ensure a clear and user-friendly experience.
 
 **Differentiating labels and placeholders**
@@ -406,30 +494,46 @@ When designing forms, it is crucial to use labels and placeholders effectively t
 - 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.
 - 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.
 
+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.
+
+Example
+
 > Email* Form section using fieldset Lorem ipsum
 
 > Name Email* Search features
 
 ## Dialogs
 
+Dialogs
+
 Avoid presenting users with unclear choices. “Cancel” doesn't make sense here because no clear action is proposed.
 
+Example
+
 > Not part of your order The selected item is not part of you order and cannot be assigned Ok
 
 > Not part of your order The selected item is not part of you order and cannot be assigned Cancel Ok
 
 ## Error states
 
+Error states
+
 Always use the header and the description of a state when using components like ErrorState, NotFoundState, EmptyState, or any other state.
 
 Leaving out the message and using the headline for the user action feels like shouting to the user.
 
+Example
+
 > You have no vehicle selected Please select a single vehicle from the list of your vehicles on the left hand side of your screen
 
 > Please select exactly one vehicle
 
 ## Notifications
 
+Notifications
+
 This guide outlines the best practices for crafting notification messages. The aim is to ensure consistency, clarity, and brevity across all notification messages.
 
 **General notification guideline**
@@ -457,6 +561,8 @@ Naming the subject first in notifications is a common and effective best practic
 - The file could not be uploaded
 - Your changes could not be saved
 
+Example
+
 > Your request has been submitted Data load error Something went wrong while loading your data. Please refresh the page. Invalid input Please check your email address and try again Appointment not scheduled There’s a conflict with your calendar. Please choose a different time. New feature: Order tracking You can now easily track your orders directly from your account. Check it out today! Account review completed Your account details are up to date. No further action is required.
 
 > Completed successfully The form has been submitted Error JSON parse error: Unexpected token < in JSON at position 0 Invalid Input was incorrect Error The appointment wasn’t scheduled because of a conflict with your calendar. Scheduling failed. We’ve added a new feature that lets you track your orders more easily. Try it out today and see how it can improve your experience! Account info: Your account details were recently reviewed, and everything seems to be in order. There’s nothing you need to do at this time.
@@ -522,6 +628,8 @@ All success notifications for clipboard actions should follow this structure: "<
 - Name copied to clipboard
 - Text copied to clipboard
 
+Example
+
 > Coordinates copied to clipboard
 
 > 48.11293, 11.53486 Copied to clipboard.
@@ -530,6 +638,8 @@ All success notifications for clipboard actions should follow this structure: "<
 
 ## Errors in general
 
+Errors in general
+
 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.
 
 No matter the design component or the length of the message, the most thorough error messages consist of three clear communication elements
@@ -538,40 +648,68 @@ No matter the design component or the length of the message, the most thorough e
 - The underlying cause (if possible)
 - How to fix it
 
+What happened
+
+The underlying cause
+
+How to fix it
+
+Example
+
+Your request could not be savedWhat happenedThere was an error in connecting to the server, so this request was not added to the list of support requests.The underlying causePlease wait a few seconds and try saving the request again. If the problem continues, please let our support team know.How to fix it or to become unblocked
+
 ## Avoid showing a message whenever possible
 
+Avoid showing a message whenever possible
+
 The best error message is no error happening at all.
 
 Find ways to avoid the error altogether, like by using in-line validation, visual cues, and disabled states to guide users.
 
+Example
+
 > Description (required) Submit
 
 > Description (required) Description required Submit
 
+Utilize the "disabled" feature of elements to show that users need to do something before they can move onDon't create unnecessary error messages as a workaround to unintuitive design
+
 ## Have the system automatically resolve errors
 
+Have the system automatically resolve errors
+
 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.
 
 For 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.
 
+Example
+
 > Input that auto-corrects %
 
 > Input that allows invalid data Invalid input. Please enter a maximum of 100% %
 
 ## Use plain language, and avoid jargon
 
+Use plain language, and avoid jargon
+
 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.
 
 Technical 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.
 
+Example
+
 > We had trouble processing your request because the server's pathway to the data was slow. We're working to fix it.
 
 > Your request encountered a server-side bottleneck due to inefficient API endpoint routing
 
+More information the error message topic can be found here: https://spectrum.adobe.com/page/writing-for-errors
+
 ## Commonly misspelled or misformatted words
 
 ## List of commonly misspelled words
 
+List of commonly misspelled words
+
 There are quite a few words that are commonly written incorrectly or inconsistently in software and UI texts. Here are some frequent ones
 
 - Login vs. log in ✅ Correct: Log in (verb) / Login (noun, adjective) ❌ Incorrect: Login to your account (should be Log in to your account)
@@ -588,48 +726,136 @@ There are quite a few words that are commonly written incorrectly or inconsisten
 - 2FA vs. two-factor authentication ✅ Correct: Two-factor authentication (2FA) ❌ Incorrect: 2FA authentication (redundant)
 - Wi-fi vs. wifi vs. WiFi ✅ Correct: Wi-Fi ❌ Incorrect: WiFi (often seen but not the official spelling)
 
+Login vs. log in
+
 - ✅ Correct: Log in (verb) / Login (noun, adjective)
 - ❌ Incorrect: Login to your account (should be Log in to your account)
 
+✅ Correct:
+
+❌ Incorrect:
+
+Sign up vs. signup
+
 - ✅ Correct: Sign up (verb) / Signup (noun, adjective)
 - ❌ Incorrect: Create a sign up (should be Create a signup)
 
+✅ Correct:
+
+❌ Incorrect:
+
+Log out vs. logout
+
 - ✅ Correct: Log out (verb) / Logout (noun, adjective)
 - ❌ Incorrect: Please logout (should be Please log out)
 
+✅ Correct:
+
+❌ Incorrect:
+
+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)
 
+✅ Preferred:
+
+✅ Correct but technical:
+
+❌ Incorrect in general UI:
+
+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)
 
+✅ Correct:
+
+✅ Correct within copy:
+
+❌ Incorrect:
+
+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 in German UI:
+
+❌ Incorrect:
+
+❌ Incorrect:
+
 - ✅ Correct: E-Mail-Adresse (official and correct)
 - ❌ Incorrect: Email-Adresse without capitalization in German
 
+✅ Correct:
+
+❌ Incorrect:
+
+Username vs. user name
+
 - ✅ Correct: Username
 - ❌ Incorrect: User name (though some older UIs still use this)
 
+✅ Correct:
+
+❌ Incorrect:
+
 - 🟢 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)
 
+🟢 Preferred:
+
+✅ Formal:
+
+❌ Incorrect:
+
+Last name vs. surname in German context 🇩🇪
+
 - 🟢 German UI: Nachname
 - ✅ Official forms: Familienname (but avoid in casual UI)
 
+🟢 German UI:
+
+✅ Official forms:
+
+Ok vs. okay
+
 - ✅ Correct: OK (most common in UI)
 - ❌ Incorrect: Okay (too informal for UI)
 
+✅ Correct:
+
+❌ Incorrect:
+
+Home page vs. homepage
+
 - ✅ Correct: Home page (two words)
 - ❌ Incorrect: Homepage (often used but technically incorrect)
 
+✅ Correct:
+
+❌ Incorrect:
+
+2FA vs. two-factor authentication
+
 - ✅ Correct: Two-factor authentication (2FA)
 - ❌ Incorrect: 2FA authentication (redundant)
 
+✅ Correct:
+
+❌ Incorrect:
+
+Wi-fi vs. wifi vs. WiFi
+
 - ✅ Correct: Wi-Fi
-- ❌ Incorrect: WiFi (often seen but not the official spelling)
+- ❌ Incorrect: WiFi (often seen but not the official spelling)
+
+✅ Correct:
+
+❌ Incorrect: