Back to Designs page

Landing pages

Mary Shakshober avatar

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!

In the perspective of ConsoleDot, a ‘landing page’ is a top level page that provides high level information, context, and actions related to more detailed pages. Landing pages can occur at various levels of the console information architecture, but should serve the purpose of providing contextual, 'at a glance' content around a given service or set of services. Think of landing pages as an umbrella page that ties together important bits about services and helps tell a story about the workflows that the service(s) helps the user achieve.  

In general, landing pages should answer questions like ...

  • 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?


 Levels of landing pages can include (in order of highest level to most narrowed focus)…

  1. ConsoleDot landing page
    1. Console homepage dashboard
  2. Bundle landing pages, for example …
    1. OpenShift overview
    2. Insights dashboard
    3. Subscriptions overview
  3. Service group landing pages, for example …
    1. Inventory | Insights
      1. Systems
      2. Groups
      3. Images
      4. System Configuration
  4. Service overview pages, for example …
    1. Advanced Cluster Security | OpenShift
    2. Notifications | Console Settings
  5. Maybe others in the future!


When to use Day0 components vs Day1+

Landing pages will most often be dynamic because they will change what content they show once the user has configured the service and has begun using it. We refer to the orientation state of the landing page as the “day 0” page. We refer to the landing page state that appears after that as the “day 1” page, or dashboard.

Use Day0 templates when the user has NOT taken the main action or actions required to get started actually using a given service. Examples of use cases for Day0 template could include ...

Use Day1+ templates once the user HAS taken the main action or actions required to start using the given service. See examples of Day1+ landing page use cases cross all tenants of ConsoleDot below. 


Day 0 landing pages

Page anatomy

While every landing page will be different, there are common components that the ConsoleDot UXD team recommends. 

  1. Header section
  2. Tabs section (only use if necessary)
  3. CTA section
  4. Pricing section (only use if necessary)
  5. Benefits / use case section / about section
  6. Recommended content section

1. Header section

Is the main call to action persistent after Day 0?
In other words, will someone regularly repeat this action?

YES
Users will repeat this action beyond Day0 (ie. a user might want to ‘Create cluster’ even after their Day0 experience, so we can keep this high level action in the header at all times)

NO
Once users do this action once, and then their journey will look different beyond Day0

RECOMMENDATION

RECOMMENDATION

Use the ‘With button’ variant of the landing page header symbol. This header should have these elements …

  1.  Name of service 
  2.  A 1-2 sentence ‘elevator pitch’ of your service should go here to help set context of page.
  3.  A ‘Learn more’ link that should open a new tab to provide more context for what the service is. We recommend having this URL destination be one of the RH websites (ie. related product page on developers.redhat.com or redhat.com)
  4.  High level main action that can be repeated beyond Day0. Use the CTA style button.

Example

Use the ‘Basic’ variant of the landing page header symbol. This header should have these elements …

  1.  Name of service 
  2.  A 1-2 sentence ‘elevator pitch’ of your service should go here to help set context of page.
  3.  A ‘Learn more’ link that should open a new tab to provide more context for what the service is. We recommend having this URL destination be one of the RH websites (ie. related product page on developers.redhat.com or redhat.com)

Example


2. Tabs section (only if needed)

Show a tab only when your page transitions to day 1; put the overview content (still relevant day 0 stuff) on a tab called “Overview.” (will explore more in Day 1). 


3. CTA section

Make most important CTAs prominent. Use the marketing CTA button for the 1 or 2 prominent CTAs. Try to avoid showing every possible way to get started with your services on this day 0. (too much noise, too many bold buttons). 

Include a prerequisite that transitions to a CTA when the prereq is done. If you can’t do that, show a sequence of steps. For example:

<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 …

  1. ‘Get started with <Service Name>'
  2. Body copy to help the user gain context of what the main action is, 
  3. A blue marketing style CTA, and 
  4. A right-aligned spot illustration (be intentional with these images -- don’t use anything too general)

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:

  • (we provide) Trial
  • Connects to existing subscription
  • Kicking off a process that doesn’t require a subscription (cuz you already registered systems or you can create an instance of something free like a cluster)

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
Users should be able to access pricing if needed.

NO
There isn't any reason to show pricing / there is no pricing info

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

This section can contain several things. This section can detail things like …

  • 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 

The display of this section should be consistent though, using an expandable list with the first list item defaulting to being in its expanded state. Use the presentation table below to determine how you should present the content that you have available. 

Do you have any key use cases, features, important structures, or additional important actions that a user could take (beyond the main CTAs)?

YES
I have things to populate in this section

Sort of
I have one or two items that could go in this section, but not much

NO
This service is very small, new, or otherwise a bit unknown to us -- we do not have these things flushed out enough to surface to the user

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:

  1.  Relevant icon
  2.  "<Use case or benefit>" in the header
  3.  Description of the use case, feature, benefit, etc. and a ‘Learn more’ link that goes out to other RH website to describe it more.
  4.  (Optional) If there is a relevant action that a user could take to actually DO something (not just learn more) with a given feature / benefit /use case, you can include this in the far right of its toggle header. 

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:

  1.  "About <Service name>" in the card  header
  2.  A ~1 paragraph detailed description of what the service provides. See the ‘About’ copy example below for inspiration.

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:

  1.  Relevant icon
  2.  "About <Service name>" in the toggle header
  3.  A ~1 paragraph detailed description of what the service provides. See the ‘About’ copy example below for inspiration.

Example

Example ‘About’ copy:

Instead of this: 

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)

Try this:

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?
These could be, but are not limited to ... documentation, learning paths, quick starts, videos, demos, etc.

1 piece of learning content

2+ pieces of learning content

RECOMMENDATION

Create a full-width card with the following content:

  1.  “Recommended content” as the card title with font size 20
  2.  <Title of learning item> with font size 16 (medium, not regular weight)
  3. 1-3 sentences to ‘preview’ to the user what this piece of learning content will teach them and why it is valuable to them.
  4. Arrow link to interact with the learning item (ie. ‘Begin Quick start’, ‘Read the documentation’, etc.), that opens any external URLs in a new tab and directly moves user to the learning item if it is internal to console (ie. Quick starts) 

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:

  1.  <Title of learning item> with font size 16 (medium, not regular weight)
  2.  A label with the content type
    1.  Documentation (orange)
    2.  Quick starts (green)
    3.  Learning paths (cyan)
    4.  Other content types (purple)
  3.  An action-oriented link (ie. ‘Begin Quick start’, ‘Read the documentation’, etc.), that opens any external URLs in a new tab and directly moves user to the learning item if it is internal to console (ie. Quick starts)

Example


Day0 example pages


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 …

Screenshot_2024-07-06_at_7.58.17 PM_.png

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.png Notifications widget: any service that uses the console notifications feature can surface that service’s notifications without any additional API calls
Subscriptions.png 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_+_Status.png 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.png 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.png [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.png 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.png 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.png 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_link.png 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