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!

[mdtauk]

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:

This is a fair decision, as it has a much simpler set of behaviours.

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 the examples I posted before, I think the ability to display some text with each Page Item / Pip Item, whatever you call them.

For a step counter mode, you would need an additional state, so Completed, Current, Still to Come.

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

Pips does kind of pigeon hole the visual style of the glyph indicator. SimplePager, or PageIndicators would be more generic and not tied to the visuals.

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

Wizards and other step interfaces seem to be an area all platform OOBEs use, but no standard control exists for. This glyphic indicator control could be used for the FlipView and Carousel controls, so there is a consistent design for all of them, but whether the Steps mode can be done with this control, or if it should be it's own control - I am not sure of.

How would a unloaded, or Still to Come state be used for the simple glyphic only default style?

Does it only use glyphs, or could it use rectangles or other path/geometry elements?

[gabbybilka]

In the examples I posted before, I think the ability to display some text with each Page Item / Pip Item, whatever you call them.

I'll add this to the table however I'm unsure how this would tie into the simplicity of only assigning an indicator style on whether the page is selected or unselected. Each page would then have a unique text value tied to it. How would this adapt if only some pages had text associated? If the number of pages changes, would the text also change?

Pips does kind of pigeon hole the visual style of the glyph indicator. SimplePager, or PageIndicators would be more generic and not tied to the visuals.

I also like IndicatorPager however I'm unsure if that then implies that the pips aren't clickable.

Wizards and other step interfaces seem to be an area all platform OOBEs use, but no standard control exists for. This glyphic indicator control could be used for the FlipView and Carousel controls, so there is a consistent design for all of them, but whether the Steps mode can be done with this control, or if it should be it's own control - I am not sure of.

How would a unloaded, or Still to Come state be used for the simple glyphic only default style?

With the simple glyphic only style there could be different brushes or even different glyphs to indicate where a user has been, where they are currently, and what is upcoming. Currently there are two states a pip can be in, selected or unselected. This would add a third to split unselected into 'has been' and 'still to come'. If a user were to 'jump' to a specific page, does this break the sequential nature of the 'has been', 'is at', and 'still to come' states? Just brainstorming 😊

Does it only use glyphs, or could it use rectangles or other path/geometry elements?

Right now the Pip is a Button, so a user can flexibly customize it by setting a Style for both the selected and unselected (default) indicators.

[mdtauk]

In the examples I posted before, I think the ability to display some text with each Page Item / Pip Item, whatever you call them.

I'll add this to the table however I'm unsure how this would tie into the simplicity of only assigning an indicator style on whether the page is selected or unselected. Each page would then have a unique text value tied to it. How would this adapt if only some pages had text associated? If the number of pages changes, would the text also change?

I wonder if there is any use in having a ShowLabels option, and when the Labels are turned off, the text is displayed as a tooltip?

---

Pips does kind of pigeon hole the visual style of the glyph indicator. SimplePager, or PageIndicators would be more generic and not tied to the visuals.

I also like IndicatorPager however I'm unsure if that then implies that the pips aren't clickable.

Hmm, I think looking at the naming used by other platforms may help in deciding on the right name.

Speaking of the clickability, should there be an option to have the Pips visual only, without the ability to click/navigate?

---

Wizards and other step interfaces seem to be an area all platform OOBEs use, but no standard control exists for. This glyphic indicator control could be used for the FlipView and Carousel controls, so there is a consistent design for all of them, but whether the Steps mode can be done with this control, or if it should be it's own control - I am not sure of.
How would a unloaded, or Still to Come state be used for the simple glyphic only default style?

With the simple glyphic only style there could be different brushes or even different glyphs to indicate where a user has been, where they are currently, and what is upcoming. Currently there are two states a pip can be in, selected or unselected. This would add a third to split unselected into 'has been' and 'still to come'. If a user were to 'jump' to a specific page, does this break the sequential nature of the 'has been', 'is at', and 'still to come' states? Just brainstorming 😊

Hyperlinks have a Visited state, as well as default, hover, and active/pressed states. Maybe something similar could be done. Or maybe this too becomes a behaviour. If not, perhaps both visited and unvisited Pips should use the same style, and allowing the developer to set the state differently?

---

Does it only use glyphs, or could it use rectangles or other path/geometry elements?

Right now the Pip is a Button, so a user can flexibly customize it by setting a Style for both the selected and unselected (default) indicators.

Would this content be exposed as a Content property? Or perhaps a primitive type of Pip which the developer can re-template independent of the ____Pager control itself? Like a ListViewItem, within a ListView?

[mrlacey]

• Why "Pips" in PipsPager? Is this term known in other languages?

• If the pip is just a default UI representation (based on popular common conventions) but can be any Glyph, why not call this the GlyphPager?

• With the integration of this control, is it appropriate/sensible to rename the PagerControl to be NumericPager to make the difference between them clearer?

• Related: Why does PagerControl have the "Control" suffix? This seems unnecessary and inconsistent with other controls which don't have the "Control" suffix.

• Will this support different glyphs/pips/content for each item?

• How will the control handle sizing when there are more "pips" that there is space for?

• How does this proposed control compare to the CarouselPanel? Can the two work together easily? (By default?)

• The spec mentions use with a GridView and DataGrid. Are there examples anywhere of "pips" style indication used with a grid layout? I've never seen one.

[mdtauk]

Just posting my initial thoughts on this...

• Why "Pips" in PipsPager? Is this term known in other languages?
• If the pip is just a default UI representation (based on popular common conventions) but can be any Glyph, why not call this the GlyphPager?
• With the integration of this control, is it appropriate/sensible to rename the PagerControl to be NumericPager to make the difference between them clearer?

I had a similar concern with the name. GlyphPager is a good choice, NumericPager works but that control is more involved than the Glyphic one.

• Related: Why does PagerControl have the "Control" suffix? This seems unnecessary and inconsistent with other controls which don't have the "Control" suffix.

NavigationPager may better suit the need, but would that be a GlyphPager with an attached content pane?

• Will this support different glyphs/pips/content for each item?

For maximum flexibility I think it should, I believe there will be lightweight styles for the current Pip and the unselected Pip. I suggested a "visited" Pip may also be useful, but that may make sense with a StepPager control as was mentioned before.

• How will the control handle sizing when there are more "pips" that there is space for?

I would personally have the ContentAlignment control if the Pips stick to the Top or Bottom in Vertical orientation, and Left and Right for Horizontal - but should there be something else that controls this, as well as the Glyph size, and spacing between the Glyph buttons?

• How does this proposed control compare to the CarouselPanel? Can the two work together easily? (By default?)

I think the CarouselPanel should use this control as a TemplatePart so investment in this will be reflected elsewhere. FlipView is also a thing to consider.

• The spec mentions use with a GridView and DataGrid. Are there examples anywhere of "pips" style indication used with a grid layout? I've never seen one.

The new Xbox Store uses just this kind of control

[mrlacey]

• The spec mentions use with a GridView and DataGrid. Are there examples anywhere of "pips" style indication used with a grid layout? I've never seen one.

The new Xbox Store uses just this kind of control

An interesting use of "pips" in place of a scroll bar, but I suspect there are all sorts of potential complications and edge cases when in a resizeable window that may push this scenario out of scope.

[mdtauk]

The new Xbox Store uses just this kind of control

An interesting use of "pips" in place of a scroll bar, but I suspect there are all sorts of potential complications and edge cases when in a resizeable window that may push this scenario out of scope.

I assumed it was the Xbox team building the React Native app that brought about the Proposal internally, but it is a scenario that feels common enough. Things like first run experiences could also use this kind of control.

[gabbybilka]

Closing as PipsPager has shipped in WinUI 2.7 and in WinUI 3 through WinAppSDK 1.0+ 🎉