Common Content Patterns
Sign InSpectrum of different content situations in our interfaces.
Actions
Actions are usually stated in buttons or in spill over menus.
Actions in buttons must be title-cased. We want to bring extra attention to the actions provided by buttons. Title casing on buttons also provides a subtle emphasis to borderless buttons.
Add Page
Do
Add page
Don't
Button text should be specific to the action that the button is performing.
- Use verbs that indicate the action
- “New” can be used as a verb, this is an exception to this rule.
Delete Document
New Web Content
Do
Delete document
New web content
Don't
When a modal contains an action, the action should be in both the title and the call to action.
Do
Do
Don't
Links
Make sure to include nouns (the thing it is linking to).
Policy Details
Do
Review
Don't
To ensure better accessibility, imagine listening to a list of links on the page. Would you know where it goes next without contextual clues?
Policy Details
Do
Details
Don't
Lists
To adhere to CMoS guidelines, always include a colon to introduce bullet points.
Full sentences require proper formatting including punctuations.
Benefits of upgrading:
- Get setup faster with a one step connection process.
- Secure your connection using blockchain technology.
- Control the data you want to send.
If they are fragments, no punctuation is required. However, they should adhere to sentence casing rules.
Benefits:
- Faster setup
- More secure
- Finer control of your data
Use parallel construction
ie: What to bring:
- Fruits
- Wine
- Spreads
- Blanket
- Sunblock
Do
- Fruits
- Wine
- Spreads
- A blanket incase its cold
- Sunblock
Don't
ie: Rules to stay safe:
- Don’t feed wildlife
- Explore in pairs
- Use trash cans
- Respect your neighbors
Do
- Don’t feed wildlife
- Explore in pairs
- Trash cans should be used
- Respect your neighbors
Don't
Avoid using the same first word:
- Enjoy yourself
- Have an adventure
- Build teamwork
Do
- It will be fun
- It will an adventure
- It will teach you team building
Don't
Messaging
Bad news
Bad news refers to situations where Liferay must deliver unwelcomed news.
- Client’s payment issues
- Cancellation of a scheduled event
- A feature that is not supported by legacy versions of Portal
- Sunset support of a version/feature
Be direct about the bad news
Be positive
Focus on the solution
Avoid you, your pronouns
Be transparent without self-blaming. If an apology is in order, apologize for the negative effect, rather than what we did wrong. Apologize when something we did, causes more work for the customer.
Liferay version 6.2 is no longer supported, but there's good news: we offer a wealth of archived 6.2 resources that might help.
Do
You have an outdated version of the portal and we don’t offer support for 6.2.
Don't
Descriptions
Sometimes descriptions are necessary to describe what the feature will help the user accomplish. Typically found during configuration, stepped walk throughs, forms, and settings screens.
Descriptions should be human/use-case centered rather than software centered.
Define an experience for XYZ segment by selecting contacts and content.
Do
Selecting contacts and content sets will dynamically change page content whenever analytics.load function is called by the API.
Don't
Boolean situations are those yes/no situations usually solved with checkboxes.
- Be as explicit as possible to let the use know the the impact of their decision.
- Do not hide helpful information in popovers, alerts, or secondary text.
Do
Trying to avoid:
Don't
Practice progressive disclosure
- Reveal information as needed. For example don’t over complicate things by worrying about what could happen down the line. Rather, explain the situation at the point of intention.
Do
Don't
- For the remaining text “Inactive events will automatically be set to hidden after 30 days of inactivity and removed if inactive for the duration for the retention period.”:
Display tooltip on hover over an inactive events and in the instructions under event settings.
Do
Instructions
Instructions are explanations that guide the user towards an action.
Practice progressive disclosure
Select a training period
Select items for training. Only items with interactions during the set period are available for selection.
Do
Select a training period, this will inform what items are available for the current training period.
Don't
When referring to a UI element, use the casing of the element on screen, there is no need to emphasize otherwise with bold, italics or a combination of both.
Do
Don't
Titles
Titles should use sentence casing.
Select file
Assign users to this site
Select site or asset library
Do
Select File
Assign Users to This Site
Select Site or Asset Library
Don't
Validations
Validations help reduce uncertainty for actions a user has taken or is about to make.
Confirmations
Use confirmations for destructive actions and actions with unintended consequences.
Do not use confirmations for error prevention or undo actions.
How to write a confirmation message
Your confirmation message must clearly communicate the situation and the potential results of proceeding with the action. An unclear message can result in the user mistakenly taking irreversible actions or finding themselves in an unexpected situation.
Follow these guidelines to write a good confirmation message:
- Do not write generic and open ended questions like Are you sure?
- Be clear and concise.
- Provide exact information to your user, so there is no uncertainty on the action to be confirmed.
- If the confirmation initiates an action, the label of the button to confirm should contain the verb associated with the action.
- If the confirmation is informational in nature, use an “Ok” button.
- Construct your questions and statements so they are clearly answered with "Ok" or "Cancel", the options provided by the browser.
Do
Don't
Acknowledgment
Acknowledgements are made with toast alerts. They acknowledge something that occurred in the background or as a consequence of a destructive action.
When to use an acknowledgement:
- After a non-destructive action that includes an undo option, such as removing.
Do
Don't
- An action occurs or is occurring in the background.
Do
Don't
Do
Don't
- After confirming a destructive action.
Do
Don't
- A bulk action is performed.
Do
Don't
Don’t use an acknowledgment when:
- An action occurs in the foreground. Assume add/remove actions that occur on a paginated table or list does not occur in the foreground.
Do
Don't
Errors
Error messages should reinforce trust in the product, without losing momentum in the task at hand. The goal is to build trust with each error message, however an error free experience is the goal.
- Describe the problem specifically
- Maintain momentum
- Be brief and simple
- Offer more information when necessary
- Provide recovery solutions
Error recovery
Prevent the same message from reappearing by:
- Supplying enough information to eliminate further mistakes
- Providing examples with hints or explicit help to eliminate the possibility of errors.
- Having a call to action or describe how to progress
- If the same error is triggered 2+ times, consider providing another way to progress.
Present the message in real time (ie: in forms, in call to actions)
- Inform about valid format rules
There are conflicting rules for your data request. Remove the conflict (a) or (b) and try again.
Do
Oops there is an error in your data request.
Oops there is an error in your data request. It’s probably very easy to resolve. Please refer to our documentation to find the resolution.
Don't
Unknown error
Sometimes there is an unknown error caused by something technical. Do not use the technical error provided by the back end. Do not try to explain the situation.
Recommended unknown error message:
“Something went wrong, try again.”
Do
Form
Form validations can occur on the fly or after the form has been submitted, depending on your need. If error messages are required, check them against these principles:
- Concisely describe the nature of the problem.
- Supply enough information to eliminate further mistakes.
- Give feedback in real time.
- Provide valid format rules.
- Avoid reiterating the problem.
To learn more, please visit form validations.