Ensure all Figma templates and components supporting Istanbul table work are accurate and "done"

[halocline]

Elements include:

• Data collection toolbar template
• Table (header cells, body cells, sorting, primary key, row selection, etc.)
• Pagination controls template

ToDos:

• [x] Review Marina's file to identify any outstanding issues
• [x] Fix as appropriate
• [x] Publish updates
• [x] Ensure Marina's file pulls in and applies updates appropriately
• [x] Ensure Marina's file no longer references "DS to fix bug" etc.

[SeamusLeonardHPE]

Marina's table guidance for reference.

https://www.figma.com/file/cWWkj83XeKhVu5cX4L8EQE/Standardizing-tables?type=design&node-id=0%3A1&mode=design&t=CjYRhZE1oc45EcVa-1

Major issues:

• [x] Missing table header sort component
• [ ] Pagination guidance needs agreement to be updated on DS site

Minor Issues:

• Pagination footer is a template, not a component. Discuss impact & process for updating.
• Data toolbar is a template, not a component. Discuss impact & process for updating.

[SeamusLeonardHPE]

@halocline @SOjaHPE

Woking though Marinas file and we will need to update our guidance to mirror suggestions. primarily-

• Pagination footer should always be present (minimal displaying results summary).
• Designer should choose step number based on expected results (20 is just default)
• Step selector should be included in any results that return more than one page of results.

Would be a good time for formalise the pagination footer into a component sinceI have previous work on this that could be wrapped up with minimal revision.

Summary of research & recommendations

https://www.figma.com/file/WEUMSfByx51eUCfEOOdibL/updated-pagination?type=design&node-id=0%3A1&mode=design&t=EYLSGJw3actjZ9vg-1

[MikeKingdom]

Why put the summary at the bottom disconnected from the filter controls? Note that the filter controls are also used for other things link List, Cards etc. This affects the pagination visibility since without the summary, the pagination controls seem rather silly on some data set that is less than one page, kinda like a scrollbar. Clutter

Also realize, more often than not, the bottom of the table and the pagination controls are scrolled off the bottom of the screen. Having to scroll to see the summary seems like you'll rarely even see the summary

And I though of one more....what if you're not using pagination? e.g. infinitescroll

[halocline]

• Pagination footer should always be present (minimal displaying results summary).

I do not think this ☝️ should be part of design system guidance unless we have solid rationale backing this guidance. There is already a result summary included in the data collection Toolbar. Including a pagination footer seems like unnecessary and unusable (no utility) UI elements being added to a screen, repeating information already present on the screen.

If Platform UX wants this guidance, that is fine, but it violates fundamental UX principles of keep simple, reduce, and only present items with utility, beneficial to the user.

• Designer should choose step number based on expected results (20 is just default)

"A reasonable starting point for page size is 20 records. This size strikes a balance between providing a user enough information to consume or find records of interest without being too much information leading to cognitive overload. That said, the default number of records per page should be tailored to the data set and determined by the UX designer. For example, a data collection displaying log files or notifications may choose a large page size as it allows a user to scan and understand activity in a efficient manner. Whereas as data collection presenting items in a news feed may only need to present a handful of records at a time."

Please submit a PR for the pagination page on the Design System site with modified guidance along these ☝️ lines.

• Step selector should be included in any results that return more than one page of results.

This point is not not necessary if the guidance is "only show pagination controls when results are paginated."

[halocline]

Would be a good time for formalise the pagination footer into a component sinceI have previous work on this that could be wrapped up with minimal revision.

Yes, I agree that it would be good to formalize the pagination controls as component. That said, before any implementation is done, I would like a "co-create design session" to be conducted. This session should be cross-functional (representatives from design and dev) which align on how the component(s) are constructed and built up. This session should define the anatomy(ies) of the component(s) and definition of the component regions (names, purpose). They should also ensure that the component(s) are built in a manner following the "reasonable default, config, custom slots, fully custom" approach.

For example, I see "pagination controls" as being 4 components (but this should be validated/refined in the co-create session):

• PaginationControls - layout component serving as the organizer of the following:
  • Pagination - next, back, page selectors
  • PageSizeSelector - Specialized Select
  • PaginationSummary - text summary providing the current page's context

This co-create session serves as a blueprint for how design and code components are approached and achieves shared understanding and alignment early in the process.

cc: @oliverHPE , @SOjaHPE , @MikeKingdom , @taysea

@oliverHPE, something like the above should be considered as part of your process work.

@SeamusLeonardHPE, please schedule a co-create session when you think make sense.

[SeamusLeonardHPE]

Late in the day here so maybe some fuzzy logic, but my understanding is that the toolbar summary and the pagination summary do not always contain the same information, on initial load yes, but not when a filter has been applied. One is the summary of the entire set, the other the summary of the viewable selection.

Alyssa is keen to include a pagination summary, even on small sets of data, so that users are confident that all items have loaded.

[SeamusLeonardHPE]

In order to avoid direct contradictions in guidance some edits to our DS guidance site some updates to text are suggested until we formalise the new pagination footer component.

Please review @halocline @taysea

https://www.figma.com/file/WEUMSfByx51eUCfEOOdibL/updated-pagination?type=design&node-id=128-4579&mode=design&t=43lpUjcFNA0uZ5Kv-4

[taysea]

Dropped a few small refinement comments. Once Matt has taken a look, can you file a PR on the site to update the text? @SeamusLeonardHPE thank you!

[halocline]

Dropped a few small refinement comments. Once Matt has taken a look, can you file a PR on the site to update the text? @SeamusLeonardHPE thank you!

Once a PR has been filed and merged, I believe this issue can be closed.

[taysea]

Some guidance has been updated prior to break: https://github.com/grommet/hpe-design-system/pull/3616

Although, I saw some small refinement comments you added to Figma @halocline, so I think a subsequent PR can be filed to address, then we can close. @SeamusLeonardHPE would you be willing to file a PR with any remaining guidance updates based on Matt's comments?

[SeamusLeonardHPE]

@taysea updated guidance based on comment added to figma Jan 9th. https://www.figma.com/file/WEUMSfByx51eUCfEOOdibL?node-id=128:4579&mode=design#643817151

and created PR https://github.com/grommet/hpe-design-system/pull/3636

Will close out this ticket when merged.