Log In
Back to Designs page

Application specific settings page

Author: Kevin Hatchoua | Last edit: March 21, 2023 | Design type: Details page | Product area: Hybrid Cloud Console

What do you mean by “application’s settings page”?

This is a page that will be under Settings > Applications > *your app name*, dedicated to your application. The settings in these pages will be organization-wide settings that would affect all accounts in your organization.  They will not be user-specific settings. User-specific settings go under the “user preferences” page found in the avatar dropdown.

Who is responsible for the [UX] design of my application’s settings page?

Your team is responsible for the design of the form (the UX designer on the team, specifically).

Is there a design template/standard for what these settings pages should look like?

Although the layout/form design is basically up to you and there are no standards or templates for that, there is a basic bare-bones structure for the page. *The screenshot below outlines the basic elements that will be the same on every app’s settings page. This includes:

  • The page header and description
  • The basic white card behind your form
  • The buttons in your form

Again, all of these basic elements will be the same from page to page, but the content inside the form card is up to you; the only restriction is that what you put inside the card should be a form at its core.
 


 

If the content inside the card is just a simple list of checkboxes, you should try to adhere to the layout seen in user preferences: 

Bolded header (RHT medium 16)) with left checkbox, and subscription (RHT regular 16) underneath


 

What can my form include?

Your form can include any form components found in PF4. It can also have tags and a wizard. You can also find the supported component API for data-driven forms here.

What form type do I need to use?

You must use a data-driven form (DDF). This should not limit you in your design, it is just for back-end purposes. You can still design it, however, you want following PF guidelines and using PF components. 


Reasoning for having to use data drive forms: (https://data-driven-forms.org/) is a package that applications can use to help the platform with forms. Instead of the platform team having to be responsible for the page and application forms, each app can make an endpoint in their API that the platform team can hit to render a form. So, for example, the platform can hit https://cloud.redhat.com/api/insights/v1/user-preferences/ to get the data-driven forms scheme. Then, using DDF, the schema renders into a form. If an app wants to update its fields, they just have to change its API to reflect the changes they want and the app will pick it up without the platform team making any PRs.

Will using a data-driven form impact my form design?

Theoretically, it should not impact the visual look of your form. You should be able to design the form however you like as long as the components you want to use are supported in PF4.

What if I want to use a component that is not in PF4?

If the component you want to use is not in PF4, then you should contact the platform-experience development team so that they can work with you to see if they can make a custom component for you to include in your form.

Once my design is done, who will be in charge of implementing it? Who should I hand-off my design to? How do I get my app specific settings page set-up?

There are two options you can take:

Option 1: You can do it internally by asking your developers to follow this guide

Option 2: If your team is having trouble, you can file an issue in the platform experience backlog to have the platform do it :


→ Project: Cloud services (cloud.redhat.com)
→ Tag: Platform-experience
→ Sprint: PlatEx staging