Landing pages

Author: Mary Shakshober | Last edit: July 06, 2024 | Design type: Navigation, Onboarding, getting started | Product area: Hybrid Cloud Console
Overview
About HCC landing pages
See the HCC Landing Page Figma template to get started now!
What is this group of functionality that I've navigated to? What outcomes and use cases does it help me (the user) address? How do I get started using it? Are there prerequisites? Are there ways I can learn more about all the things that this service can do for me?
ConsoleDot landing page Bundle landing pages , for example …OpenShift overview Insights dashboard Subscriptions overview
Service group landing pages , for example …Inventory | Insights Systems Groups Images System Configuration
Service overview pages , for example …Maybe others in the future!
When to use Day0 components vs Day1+
Day 0 landing pages
Page anatomy
Header section Tabs section (only use if necessary) CTA section Pricing section (only use if necessary) Benefits / use case section / about section Recommended content section
1. Header section
Is the main call to action persistent after Day 0? |
|
---|---|
YES |
NO |
RECOMMENDATION |
RECOMMENDATION |
Use the ‘With button’ variant of the landing page header symbol. This header should have these elements …
Example ![]() |
Use the ‘Basic’ variant of the landing page header symbol. This header should have these elements …
Example ![]() |
2. Tabs section (only if needed)

3. CTA section
<nr-sentence class="nr-s105" id="nr-s105" page="0">Prerequisite: register your platform or system or whatever with console</nr-sentence>
How many ways do you want to recommend that a user gets started? | ||
---|---|---|
1 main way to get started | 2 main ways to get started | 3+ ways to get started |
RECOMMENDATION | RECOMMENDATION | RECOMMENDATION |
Create a full-width card with …
Example ![]() | Do side by side, 2-card layout. The actions should use the blue outline marketing style CTA style (or one filled in blue style if it is recommended). Use icons that indicate which CTA is a:
Example ![]() | We suggest that you collaborate with your PMs to determine 1-2 main actions so that we can take an opinionated stance on the best way to get started. Other possible ways to get started can be detailed in the 'Features / use cases' section. |
4. Pricing section (only if needed)
Is it imperative that users be able to access pricing information for your service? | |
---|---|
YES | NO |
RECOMMENDATION Use the hint pattern to give ~1 sentence of context and link out to a marketing page that has pricing. Example ![]() | RECOMMENDATION Don't include this in your design - move onto the next section. |
5. Benefits / Use cases / About section
Key features of the service Other possible actions (beyond the main CTAs) that a user might want to take Important structures in your service’s architecture to understand Use cases for your service
Do you have any key use cases, features, important structures, or additional important actions that a user could take (beyond the main CTAs)? |
||
---|---|---|
YES |
Sort of |
NO |
RECOMMENDATION Create a full-width accordion with icons in the toggle headers (this variant has been requested to PatternFly - view the GitHub issue). Each use case / benefit / feature should have it's own accordion section, with the following information:
Example ![]() |
RECOMMENDATION Create a 50% width accordion with your 1-2 items (in same style as the previous column) AND a 50% width static card with this content:
Arrange the accordion and the card such the the accordion is on the left and the card next to it on the right. Example ![]() |
RECOMMENDATION Create a full-width accordion with just one accordion item in it. Use a relevant icon in the toggle header (this variant has been requested to PatternFly - view the GitHub issue) that has this content:
Example ![]() |
Example ‘About’ copy:
Red Hat Advanced Cluster Security for Kubernetes is the pioneering Kubernetes-native security platform, equipping organizations to more securely build, deploy, and run cloud-native applications anywhere.
Lowering cost? (uses sales oriented words like pioneering, is a high level description)
Red Hat Advanced Cluster Security (ACS) improves the security of the application build process, protects the application platform and configurations, detects runtime issues and facilitates response. It is a Kubernetes-native security platform that empowers organizations to securely build, deploy, and run cloud-native applications. ACS helps protect containerized Kubernetes workloads in all major clouds and hybrid platforms.
6. Recommended content section
How many helpful resources does your service have? | |
---|---|
1 piece of learning content | 2+ pieces of learning content |
RECOMMENDATION Create a full-width card with the following content:
Example ![]() | RECOMMENDATION Start with a section header that says “Recommended content” at font size 20 Then create a three-column table with the following content:
Example ![]() |
Day0 example pages
Notifications Overview | Console Settings Integrations Overview | Console Settings Overview | Subscription Services ACS overview | OpenShift
Day 1+ landing pages
Page anatomy
These Day 1+ landing pages are less ‘templates’ and more so a collection of building blocks that different services can arrange on top of a pretty canvas. So, we can think about them like this …

The ‘dashboard chrome’ is pretty formulaic …
- Universal console masthead
- Breadcrumbs navigation
- Left hand nav (we could be making a service dashboard for a single page service or a multi page service, so you’ll see two chromes in your workspaces)
- Service header
-
Service tabs bar
- Dashboard
- Get started (so that a user could get back to their Day 0 experience if needed)
The ‘widgets’ are what really make up the meat of the dashboard! They are purpose-based cards that designers can browse from to create service day 1+ dashboards. They fall into a couple of categories
Console-owned widgets
Their APIs for grabbing content from the database are owned by console, so as long as a service has on boarded to that console feature, they can get these widgets for free.
![]() |
Notifications widget: any service that uses the console notifications feature can surface that service’s notifications without any additional API calls |
![]() |
Subscriptions widget: the subscriptions feature is very closely coupled with core console features and we should be able to surface subscriptions content on these dashboards without any service needing to do any additional API work |
Product + Console co-owned widgets
These are widgets that service areas will need to maintain and provide their APIs in order for the widgets to be populated, but that we (ConsoleDot UXD) will provide guidance for the design of.
![]() |
Health and status widget: we are providing a frame for how the content should be showed at a design level, but ENGs on the service will need to hook up the backend |
![]() |
At a glance widget: combines scannable information about three other widget’s content at a high level - requires service designers to do some custom work as well as ENG to do backend |
![]() |
[Objects] widget: this header should be renamed to indicate the kind of objects in the card like ‘Clusters’, ‘Instances’, etc. and would be a tabular view to show a couple of objects and provide quick access to the details of those as well as (if applicable) the ability to view an exhaustive list of those objects. |
![]() |
Learning resources widget: a service / product curated list of learning resources to show to the user now that they are beyond day 0 |
![]() |
Next steps widget: a service / product curated set of suggested actions to show to the user now that they are beyond day 0 |
Do-it-yourself (DIY) widgets
DIY widgets are ones that are designed and maintained by the product teams entirely.
![]() |
Custom widget: enable users to do actions directly in the Console, but just do not fit one of the established ‘Console-owned’ patterns. Examples could include, but are not limited it, A graph or chart view in the card body or mini wizard in the card body |
![]() |
External action widget: Several services that have a presence on the Console do not actually allow users to do their services actions in the console itself, and instead invite the user to walk through a door in the console that then spits them somewhere else. The idea of these widgets is to surface that actions or monitoring to be done (once action or monitoring mechanism per card), and then give them an action to point them to actually do that thing. ACS is a good example of this, where the user can spin up an ACS instance and view some details of that ACS instance in the console (time, owner, storage, infrastructure, etc.). But, then to actually do anything with that instance, the user has to click on the instance and then get moved into a specific new ACS console for that specific instance. |
Day1+ example pages
Note: The following are reference mockups, not necessarily finalized product directrions
- Integrations Dashboard | Console Settings
- ACS Dashboard | OpenShift
- Access Management Dashboard | Identity & Access Management