Proposal: PipsPager - UI to support glyph-based pagination

[gabbybilka]

Proposal: PipsPager - UI to support glyph-based pagination

Previously this issue was proposing to add a Pips DisplayMode to the PagerControl. We have since decided to create a new control for the Pips visualization as there is specific functionality and behavior unique to glyph-based pagination UI. More information about the plans for the current PagerControl is in the existing proposal.

Summary

In various types of media apps there is a common pattern to show content that is not explicitly ordered but paginated with glyph-based indicators instead of numbers. This concept of glyph-based representations of numbers can be noted as Pips.
We'd like to introduce a baseline set of features for this visualization currently and open up to further functionality after the initial foundational control. A PR has been opened for the in-progress priorities below. However we're interested in the community's feature needs for pip UI in general and want to open up conversation here to dive into your asks.

We've opened a new spec to begin defining this initial, foundational work.

We're interested in learning more about the scenarios where you would use "pips" UI and the corresponding functionality to help guide future pip UI work. I'll be updating the "general pip needs" table with your requests, the in-progress prioritization table will stay stable.

Shout-out to @chingucoding for all of his work done to complete the base PagerControl, thank you!

Rationale

Due to the current and potential feature asks and scenario differences between the existing PagerControl and what's required here we believe a new pager control for this visualization is required. The functionality to specify the max number of indicators shown, to customize the styling of the selected and default indicators, and the desired removal of the first/last buttons for the default experience motivated this separation. We still want to align this pagination UI with the existing PagerControl through a common interface, base class, or other solution and will share our intentions once defined.

Prioritization

For in-progress, committed work:

Capability	Priority
Glyphs to represent pages (pips) instead of numerics	Must
Vertical and horizontal orientation for keyboard/touch interaction and glyphs	Must
Additional button visibility option to only show navigation arrows on user hover	Must
Scrolling behavior between pips if the max number of pips displayed is less than the number of pages in the layout view	Must
Glyph customization to change default and selected pip styles	Should

For general pip needs:

Capability	Priority
Common interface, base class, etc. to align with the PagerControl for easier integration with layout controls	Must
Option for the pips to be indicators only, no ability to navigate to a page	Must
Event to fire once the user attempts to navigate past the last page to enable looping behavior in the application (from last to first)	Should
Long-press touch interaction to change pages	Should
Awareness of pages visited and intended with styling customization	Could
Display text with each pip that could be shown with the glyph itself or as a ToolTip	Could
The Pip is customizable and can be re-templated independent of the PipPager itself	Could

Related Links

Pip-related proposals:

• Proposal: Add Glyphic Index Display to FlipView #602: Add Glyphic Index Display to FlipView

PagerControl-related links:

• Feature Proposal: PagerControl  #60: Feature Proposal: PagerControl
• #80: PagerControl spec PR

Open questions

• In your applications, where would you use this display mode? What scenarios? What layout views? Why would you orient it vertically or horizontally? What functionality would you require?
• Is there a different name other than PipsPager that make more sense to you? 😊
  • Note: StepPager has been proposed by @mdtauk, thanks! Should the step functionality be grouped with the glyph indicator functionality and scenarios or as its own separate pager control?

[mdtauk]

The new ReactNative Xbox Store app has this kind of pips display.

The original Xbox One setup OOBE, used a similar step pager control

So I think navigation pattern with the Control Pad, as well as keyboarding and both inactive and interactive modes (showing the current page/step or actively moving between pages when tapped) - should be considered.

As well as visually how it should look as a Fluent Design platform wide approach.

This is the Xbox One X/S OOBE which looks more like the Navigation View

[marcelwgn]

I think a common scenario for pips are (image) carousels, like here: https://owlcarousel2.github.io/OwlCarousel2/demos/basic.html

A common expectation for those carousels is that you can swipe to get to the next page, so having support for this would be great on touch devices, though it might be a bit tricky to get the API right here if PagerControl is not page aware like it is right now.

[mdtauk]

I would call it a Steps mode, I would also allow adding text to each step as well as states for:

• Completed Steps
• Current Step
• Steps to come

The developer could provide the icon or shape of the indicator, so a bullet or pip could be used without text, or a horizontal/vertical bar like with the navigation view, or the Windows OOBE steps.

You could use a StackPanel and bubble up the Orientation property.

[gabbybilka]

Thanks @mdtauk and @chingucoding for your suggestions so far! I've added the ideas in the general pip UI needs table.

Since opening this proposal we have decided that instead of adding a Pips DisplayMode to the PagerControl to instead create a new PipsPager control altogether. The rationale for this split is included in the initial issue text and below:

Due to the current and potential feature asks and scenario differences between the existing PagerControl and what's required here we believe a new pager control for this visualization is required. The functionality to specify the max number of indicators shown, to customize the styling of the selected and default indicators, and the desired removal of the first/last buttons for the default experience motivated this separation. We still want to align this pagination UI with the existing PagerControl through a common interface, base class, or other solution and will share our intentions once defined.

We've also opened up a PR for the PipsPager based on the in-progress feature table above. We are still interested in what you would need in a glyph-based pagination UI in your applications to add in into the next iteration of this control. I've copied the open questions below:

• In your applications, where would you use this display mode? What scenarios? What layout views? Why would you orient it vertically or horizontally? What functionality would you require?
• Is there a different name other than PipsPager that make more sense to you? 😊
  • Note: The name StepPager has been proposed by @mdtauk, thanks! Should the step functionality be grouped with the glyph indicator functionality and scenarios or as its own separate pager control?

Thank you!