Microsoft-ui-xaml: Proposal: PipsPager - UI to support glyph-based pagination

Created on 22 Oct 2020 · 11Comments · Source: microsoft/microsoft-ui-xaml

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:

For general pip needs:

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?

area-DesignDiscussion discussion feature proposal

Source

gabbybilka

❤1 👍1

All 11 comments

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

mdtauk on 22 Oct 2020

❤1

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.

chingucoding on 22 Oct 2020

❤1

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.

mdtauk on 22 Oct 2020

❤1

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!

gabbybilka on 12 Nov 2020

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?

mdtauk on 12 Nov 2020

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.

gabbybilka on 13 Nov 2020

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?

mdtauk on 13 Nov 2020

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.

mrlacey on 1 Dec 2020

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

mdtauk on 1 Dec 2020

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.

mrlacey on 1 Dec 2020

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.

mdtauk on 1 Dec 2020

Was this page helpful?

0 / 5 - 0 ratings