Closed gabbybilka closed 1 year ago
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
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.
I would call it a Steps mode, I would also allow adding text to each step as well as states for:
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.
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:
Thank you!
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?
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.
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?
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.
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 beNumericPager
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
andDataGrid
. 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
- The spec mentions use with a
GridView
andDataGrid
. 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.
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.
Closing as PipsPager has shipped in WinUI 2.7 and in WinUI 3 through WinAppSDK 1.0+ 🎉
Proposal: PipsPager - UI to support glyph-based pagination
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.
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:
Related Links
Pip-related proposals:
602: Add Glyphic Index Display to FlipView
PagerControl-related links:
60: Feature Proposal: PagerControl
Open questions