hpe-design-system
hpe-design-system copied to clipboard
grommet
PageHeader - Add button properties to Figma component
Background
During a call with the GLCP team, it came to our attention that the PageHeader component isn't working for teams in terms of having to hide the buttons within the layer panel.
In addition, designers feel that showing all 3 buttons is encouraging to have to use all 3.
To solve this, we can add button properties to hide and add buttons rather than having to hide them in the layer panel.
Todo's
- [x] Collect use cases from across services ( Platform - Sylvia Shen,
CoM - Greg Furuiye, Justin Barton, GLC - Chandan, Bhim) - [x] Understand what the 80% use case for designs is when using the PageHeader (should we design to have 1-2 buttons, if so, which ones?)
- [x] Insert use cases within this Figma file. You'll also find previous use cases here that could be helpful for you to understand the needs.
- [x] Share with team reasoning/direction
- [x] Create a branch in Figma (ask Vicky for help on this)
- [x] Add properties to Buttons to turn on and off buttons
- [ ] Default PageHeader should be determined by the 80% use case
- [ ] Get a review from Vicky on properties
- [ ] Publish and announce
The default variant when a user pulls in a pageheader should be the 80/20 use case. For pageheader, I'd assume the default variant should just show one primary button.
The default variant when a user pulls in a pageheader should be the 80/20 use case. For pageheader, I'd assume the default variant should just show one primary button.
Maybe one secondary button as the default so that we aren't assuming what the primary action of the page is?
Please create a branch when working on changes. Let me know if you need help on how to do that.
I will familiarise with the ticket issue and understand the requirement.
I will be collecting the use cases from across services.
I was able to get the use cases for GLCP team. Collecting the other cases from different teams you mentioned, I have also added the button properties of page header for ANT, Atlassian and Polaris to understand their views on the same.
Hi @ashifalinadaf , We have very few instances of page-level actions that consist of three buttons and our screen designs almost do not include mockups for smaller screens. Although I don't see that the page component require significant updates, we have given limited attention to optimizing the user experience for smaller resolutions. Generally, GLCP users tend to be task-oriented and operate primarily through a monitor. However, services such as market place may provide valuable insights on how to enhance the button experience on mobile devices.
Here is the use case that i collected for more complex page level actions https://www.figma.com/file/fNJhhmEO66r8pfFuBEp0Dk/GLCP-Component-research?type=design&node-id=1609%3A98788&t=ECdTnrpWhoRu1DeY-1
Hi @ashifalinadaf , We have very few instances of page-level actions that consist of three buttons and our screen designs almost do not include mockups for smaller screens. Although I don't see that the page component require significant updates, we have given limited attention to optimizing the user experience for smaller resolutions. Generally, GLCP users tend to be task-oriented and operate primarily through a monitor. However, services such as market place may provide valuable insights on how to enhance the button experience on mobile devices.
@SylviaShenCC note that the contextual help panel being added to GLCP has triggered the lack of smaller screen support an issue across GLCP. When the panel is open the rest of the app is forced into a smaller size which approaches mobile sizes.
@ashifalinadaf were you able to connect with Greg and collect use cases from him?
No, @vavalos5 but I did connect with Sylvia and Srinivas (from Storage team) and collected necessary use cases and inputs.
- Asif is going to connect with Justin to collect use cases.
- Next, he will review what we already have as guidance on the design system site in regards to the PageHeader and button placement.
- After, he'll annotate the use cases to better understand the needs and conclude what the 80% most common use cases are to help direct the design.
@SOjaHPE Please review the analysis done on the different use cases and let me know about the next steps or any corrections needed. Figma file.
As per Scott's guidance, I was able to get the inputs for the final outcomes. Had a discussion on the same with Scott and doubts were clarified. Summarising the findings and will be put for discussion for the team.
I have gathered some of the button groups from the different services having 80%+ use cases. Please review them and let me know if we can use the same for further steps. @SOjaHPE
Had a discussion with Scott and review comments were discussed and moving forward with next step of creating the button group component - Add properties to Buttons to turn on and off buttons.
Hello @vavalos5 I have created some button properties for page header based on the research, if you can have a look and comment on the same, will help me to move for the next step. Figma file (created a branch) and other Figma file. (research).
Great work Asif!
It's really nice seeing the built out components based on the different use cases. I think as a next step, we have to think about the pros and cons of using slots which we'd then have to deprecate the current PageHeader component and refactor the new one using the the components you created. This would mean that everywhere that this component is being used across services would have to be updated by the designers.
OR we can keep our current component and just add a property where you can swap all of the different variations you've created. This would just update designers that there are new variants available and all they need to do is hit a n "update component" button. this wouldn't affect designer's files and wouldn't have to update unless they want to use one of the new variants.
-
I'd suggest to go with second option - adding a property where we can swap all of the different variations. This property can be brought at the top to use it often. This would help us to not meddle with current page header component and also help the designers to have a choice.
-
Using the slot component can help the designers to quickly swap the button components but this needs effort for us to manage and to educate designers on how to use it. This will also create more components to share and maintain. Components might be swapped with every component in our design system.
Chatted with Asif. A quick fix would be to add properties to each type of button to provide designers the flexibility to toggle off and on to their liking. Since buttons already have icons baked into them, this shouldn't be an extra step.
Created button properties with switch on off the button component, submitting for review. Figma file
Nice work Asif, i've left some comments on your Figma file.
Inviting @KennyAtHPE to review as well.
Changes have been done to the file and on/off toggles have been added to page header component.
Met with Asif. He will be starting a new branch since the other branch he's currently working on has been altered with and is no longer showing our current PAgeHeader component. The current page header component is needed to add the boolean off/on properties to the buttons themselves. In addition, the menu button and the kebab buttons will be added to the set of buttons container so it is available to toggle off/on.
As suggested, added boolean on/off properties to the buttons themselves and also men button and the kebab button added to the set of buttons container.
I have created two branches for the Page header component.
As action menu was added as a button in the current component.
I have created a separate branch for action menu as a menu component. I will clarify on the which component to be retained merge the branch with main after the review.
Figma (Action Menu as button)
Figma (Action Menu as separate component)
Thank you Asif for doing this, it looks awesome! . I think your v2 file is the direction we want to head towards. I left a few comments on your file. I'd say the next steps we need to do is to reflect one use case on the PageHeader. By that I mean, not showing all of the buttons at once and choosing one use case to follow. For example, showing the Primary Button and the Secondary button. However, ensuring that it is reflected appropriately across each t-shirt size.
In addition, it would be great to put a comment on the component that lets our designers know that they should be following our guidance on the design system site and include the link to where the PageHeader component is located on our site. This way, there isn't confusion as to how many buttons can be utilized.
Lastly, ask other designers across services to test the component in a "test frame". Similar to the current one you have now where you have a light and dark mode example. Just ensure the components are within an actual frame and name it "test".
Awesome job! 👏
[celebrate] Oja, Scott reacted to your message:
From: Vicky Avalos-Campos @.> Sent: Monday, June 5, 2023 6:15:22 PM To: grommet/hpe-design-system @.> Cc: Oja, Scott @.>; Mention @.> Subject: Re: [grommet/hpe-design-system] PageHeader - Add button properties to Figma component (Issue #3290)
Thank you Asif for doing this, it looks awesome! . I think your v2 file is the direction we want to head towards. I left a few comments on your file. I'd say the next steps we need to do is to reflect one use case on the PageHeader. By that I mean, not showing all of the buttons at once and choosing one use case to follow. For example, showing the Primary Button and the Secondary button. However, ensuring that it is reflected appropriately across each t-shirt size.
In addition, it would be great to put a comment on the component that lets our designers know that they should be following our guidance on the design system site and include the link to where the PageHeader component is located on our site. This way, there isn't confusion as to how many buttons can be utilized.
Lastly, ask other designers across services to test the component in a "test frame". Similar to the current one you have now where you have a light and dark mode example. Just ensure the components are within an actual frame and name it "test".
Awesome job! 👏
— Reply to this email directly, view it on GitHubhttps://github.com/grommet/hpe-design-system/issues/3290#issuecomment-1577255263, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AT6XOA6ECGJNREZJEB6ETFLXJYO3VANCNFSM6AAAAAAW6VMHCY. You are receiving this because you were mentioned.Message ID: @.***>
Thank you Vicky, for looking into and for the comments.
- Reflecting one use case on the PageHeader. Figma I'd suggest to use 'Primary and Secondary Button' for the XL, L and M sizes. After the research on various use cases 'Primary button' alone is used in most cases only before the 'Primary and Secondary button', however the DS guidance says 'Most pages wont have Primary Button' hence suggesting to use the 'Primary and Secondary Button' for XL, L and M sizes.
And also 'Action Menu and Primary Button' for Small size, & More icon (action menu icon) with Primary button for xtra small (if we can only use the different component restricting 2 buttons for small size and 1 icon and one primary button for Xtra small) had a discussion with @SeamusLeonardHPE , he is helping to find a solution on this.
or we can use the same component everywhere and guide the designers on the usage.
But If we have a look at the DS guidance xtra small size shifting itself below the subtitle and aligning to the left.
We will have to device different component for XS cases, it wasn't the case for current page header.
I will be adding the comment and link for the designers to follow the guidance and use the buttons accordingly.
Working on the 'testframe' and share with others to get the feedback across services.
Tagged Greg, Justin, Bhim, Sylvia and Srinivas in Figma file for testing the component.
I had a look at the DS guidance and it says
'If the screen breakpoint is small or x-small:
If there is a primary action, then all actions should appear beneath the title and subtitle and be left-aligned with page content. To implement, apply responsive={true} to PageHeader. If there is no primary action, then the overflow menu should remain to the right of the title.'
I have added additional components for Small and X-Small as per DS Guidance. Figma
@vavalos5 let me know if this is okay or we can just have x-small component with stacked component as suggested by Chris.
Discussed with Vicky on the small and x-small component and guidance for the use of page header component. X-small size - lower resolution component with stacked button added to the Page header, Based on the inputs from @taysea added stacked component to the small size too. Tagged designers (Greg, Jeff, Bhim, Sylvia and Srinivas) and developers @taysea and @halocline for the inputs to the page header component.
And also had a discussion with @KennyAtHPE on boolean properties issue, it was clarified that 2 buttons can be used for all the components and suggested to create another ticket to add the guidance as per the developers input.
Removing the x-small instance from the Page header component, x-small example of stacked example added.
I did get some inputs from GLCS team on the test component:
- It was easy for the designers to toggle between the buttons, time saving.
- Designer may need to go though the guidance to understand how to use the buttons (number, order, size).
- Concern about the order of the button for action menu and primary button/secondary button this is covered in ticket #3387
Other inputs will be added from developers and other designers once received.