Discussion: Clear delineation for Text and Form field control designs

[mdtauk]

Discussion: Clear delineation for Text and Form field control designs

Summary

As changes are being made to the control designs for WinUI (specifically a change to Form control states, thinner borders for Text and Form fields, etc) - Some thought should be given to how you ensure all these controls distinguish themselves from each other, and provide a visual design language which matches expectation and behaviours.

Rationale

These controls all share common elements, and so as new controls of this type are proposed and created, there should be a logical rationalisation for the design of these controls to provide a familiar, consistent, and expectation for the users.

Scope

Capability	Priority
Whatever designs are decided on, should be applied consistently among all these control types	Must
I believe buttons which have a separate hit target and separate states should be visually separated by a border line	Should
Controls with a single hit target which separate the display of content, should be distinct from buttons	Should

Important Notes

Specifically with the Date and Time pickers, which are a single hit target in their non expanded state, I believe the three columns of text should use a separator line which does not touch the top and bottom of the control's border - but when they do expand these separator lines would extend to the full height, as each column is interactive separately.

Open Questions

At present buttons within these controls are only displayed as a glyph, until you hover over them. This has makes it impossible to distinguish between editable and non editable ComboBoxes, as well as future proposals for editable versions of the Date and Time pickers that have been proposed.

They also do not give confidence for touch users that their finger will hit the right part of the control, especially with controls like Calculator's proposed EquationBox, and the proposed NumberBox and Prefix/Suffix elements.

With the current thicker 2 epx borders, the controls feel lighter and cleaner displaying only a glyph, but as these borders are being made thinner, does this becomes less of an issue?

[shaheedmalik]

I do like this.

[chigy]

@mdtauk ,
Thank you so much for your proposal and thoughts and time that went into putting this together.

In order for us to be able to act on your proposal, I need your help understanding what is the exact proposal here. At this moment, this proposal is not actionable and your input is appreciated.

It appears I see following discussions in this single proposal:

1. "Whatever designs are decided on, should be applied consistently among all these control types"

I agree with your statement and we strive to deliver that, however I am not sure what specific action you are requesting us to take at this point. I am not aware of any issues since we haven't yet proposed new design, so you must have something you found that is broken today? Could you please be more specific?

2. "I believe buttons which have a separate hit target and separate states should be visually separated by a border line"

Could you explain why? What problem are you trying to solve? How is this better than the current design?

3. "Controls with a single hit target which separate the display of content, should be distinct from buttons"

Could you point out where this is not true today using specific example? I do believe our current design of button and the controls you specify look very different?

4. "Specifically with the Date and Time pickers, which are a single hit target in their non expanded state, I believe the three columns of text should use a separator line which does not touch the top and bottom of the control's border"

This seems like a very specific and separate feature request not related to the overall proposal? How is this related to Scopes you specified for this proposal?

5. "At present buttons within these controls are only displayed as a glyph, until you hover over them. This has makes it impossible to distinguish between editable and non editable ComboBoxes, as well as future proposals for editable versions of the Date and Time pickers that have been proposed."

Could you specify and point out exactly what the problem is? We have not received any feedback that this has caused issues to users using our controls to my knowledge and I'd like to undertand the probelm you are pointing out here better.

6. "They also do not give confidence for touch users that their finger will hit the right part of the control, especially with controls like Calculator's proposed EquationBox, and the proposed NumberBox and Prefix/Suffix elements."

Do you have any specific example that suggest this statement is true? We have not received user feedback that suggests that this control design that we have been shipping for many years has caused them issues. Control's sizes are made appropriate for touch.

[mdtauk]

@chigy I am happy to try to explain my thought process on these.

"Whatever designs are decided on, should be applied consistently among all these control types"
I agree with your statement and we strive to deliver that, however I am not sure what specific action you are requesting us to take at this point. I am not aware of any issues since we haven't yet proposed new design, so you must have something you found that is broken today? Could you please be more specific?

It is because changes to the control designs are currently being discussed and decided on, that I am making this proposal.

At least two new controls that fit into this control style, are being worked on. Other new controls are being proposed. as well as new properties being proposed for existing controls,

So I am hoping to ensure the design language can accommodate these.

---

"I believe buttons which have a separate hit target and separate states should be visually separated by a border line"
Could you explain why? What problem are you trying to solve? How is this better than the current design?

"At present buttons within these controls are only displayed as a glyph, until you hover over them. This has makes it impossible to distinguish between editable and non editable ComboBoxes, as well as future proposals for editable versions of the Date and Time pickers that have been proposed."
Could you specify and point out exactly what the problem is? We have not received any feedback that this has caused issues to users using our controls to my knowledge and I'd like to undertand the probelm you are pointing out here better.

At the moment, there is typically no more than two buttons contained within these Form Field controls. A search button and a clear text button for example. But the Calculator team are creating an EquationBox which has 3 buttons. NumberBox will have Two buttons. And with touch targets at around 32 x 32 epx - this could become an issue for touch users.

I believe borders help to give a user a clearer target to touch when they want to tap on the button, as opposed to entering text. This is a personal anecdote, from my time as a Windows Phone, and Surface touch user.

---

"Controls with a single hit target which separate the display of content, should be distinct from buttons"
Could you point out where this is not true today using specific example? I do believe our current design of button and the controls you specify look very different?

The Search button, the Show Password button are two buttons contained within a text/form field control, which has no visible touch target bounds - the glyph is the only thing to show it does something different compared to the text beside it.

For a text field with a single button this is less of an issue as you know to touch the very right most edge of the control (in RTL cultures). Your finger covers the glyph, but precision and confidence is less affected. Make that two, or maybe three buttons, this becomes harder to judge

---

"Specifically with the Date and Time pickers, which are a single hit target in their non expanded state, I believe the three columns of text should use a separator line which does not touch the top and bottom of the control's border"
This seems like a very specific and separate feature request not related to the overall proposal? How is this related to Scopes you specified for this proposal?

My purpose in showing these controls beside each other, is to distinguish between touch targets within one of these controls, and the controls themselves. The Date and Time pickers are a single touch target. If you were to make these touch targets visible as borders, ensuring those separators do not look like separate buttons becomes something to consider.

---

"They also do not give confidence for touch users that their finger will hit the right part of the control, especially with controls like Calculator's proposed EquationBox, and the proposed NumberBox and Prefix/Suffix elements."
Do you have any specific example that suggest this statement is true? We have not received user feedback that suggests that this control design that we have been shipping for many years has caused them issues. Control's sizes are made appropriate for touch.

Until now, there have not been any Text/Form Fields that have contained more than two buttons, and usually the Clear Text button is only visible in a focused/typing state. NumberBox, and Calculator's EquationBox are being worked on. There are proposals for an Editable Date Picker, a Separated Time Picker, Prefix and Suffix properties for the TextBox, and support for Masking in the TextBox.

Whilst the designs of these controls are in active discussion - I would think this is a good time to consider design guidance for these controls, so they don't all decide to deviate and then consistency goes out of the window.

[chigy]

@mdtauk, thanks. It helps to talk about issue at a time.

Just to re-iterate. This is the guidance to make proposal actionable that was mentioned in the other proposal that I’d like to use here as well:

1. State the problem(s) you are trying to solve clearly. Depending on the problem, the solution and approach can be vastly different.
2. Rather than creating one single big issue, break them down into small, independently actionable issues.
3. If proposing design change for a control design that’s already well established, explain what the problem current design impacting our users and how the new design help solve these specific problems.

"Whatever designs are decided on, should be applied consistently among all these control types"
I agree with your statement and we strive to deliver that, however I am not sure what specific action you are requesting us to take at this point. I am not aware of any issues since we haven't yet proposed new design, so you must have something you found that is broken today? Could you please be more specific?

It is because changes to the control designs are currently being discussed and decided on, that I am making this proposal.

At least two new controls that fit into this control style, are being worked on. Other new controls are being proposed. as well as new properties being proposed for existing controls,

So I am hoping to ensure the design language can accommodate these.

Thank you for pointing this out. That's what we do when we design so we do not introduce inconsistency or weird one-off behavior. At the moment, there is nothing actionable about this feedback unless you can show us exactly what we didn't do a good job on.

That said, we are human so we could make mistakes and you pointing specific mistakes out would be helpful. However lack of specific example makes this not actionable.

So if this was a separate issue, this issue would be closed as such.

---

"I believe buttons which have a separate hit target and separate states should be visually separated by a border line"
Could you explain why? What problem are you trying to solve? How is this better than the current design?
"At present buttons within these controls are only displayed as a glyph, until you hover over them. This has makes it impossible to distinguish between editable and non editable ComboBoxes, as well as future proposals for editable versions of the Date and Time pickers that have been proposed."
Could you specify and point out exactly what the problem is? We have not received any feedback that this has caused issues to users using our controls to my knowledge and I'd like to understand the problem you are pointing out here better.

At the moment, there is typically no more than two buttons contained within these Form Field controls. A search button and a clear text button for example. But the Calculator team are creating an EquationBox which has 3 buttons. NumberBox will have Two buttons. And with touch targets at around 32 x 32 epx - this could become an issue for touch users.

This is not a problem today as far as I am aware. We ship with multiple buttons and we have not received any signal that is problematic. I am not familiar with what Calculator is doing but I don’t believe we are building Number Box for that purpose. I could be wrong.

I believe borders help to give a user a clearer target to touch when they want to tap on the button, as opposed to entering text. This is a personal anecdote, from my time as a Windows Phone, and Surface touch user.

It is true that a bigger visual target gives user more confidence to touch it, but it doesn’t actually make the touch more accurate as far as I learned from research we did from Windows Phone days. People are also so much more used to targeting smaller UI than back then. There were additional touch study done and user testing performed when we made the standard control sizes smaller and we did not identify any issues with existing controls.

So this item is also not actionable, thus if it was separate issue, would be closed.

---

"Controls with a single hit target which separate the display of content, should be distinct from buttons"
Could you point out where this is not true today using specific example? I do believe our current design of button and the controls you specify look very different?

The Search button, the Show Password button are two buttons contained within a text/form field control, which has no visible touch target bounds - the glyph is the only thing to show it does something different compared to the text beside it.

For a text field with a single button this is less of an issue as you know to touch the very right most edge of the control (in RTL cultures). Your finger covers the glyph, but precision and confidence is less affected. Make that two, or maybe three buttons, this becomes harder to judge

Is this your opinion or you can share data that highlights this issue? One thing to keep in mind is if we change the design to “improve” the issue that doesn’t exist already, we could very well be introducing a new issue that doesn’t exist today. As far as I know, I haven’t heard any issue that complains about the touch-ability of these buttons.

Unless there is something concrete you can raise here, this item is also not actionable and will be closed.

---

"Specifically with the Date and Time pickers, which are a single hit target in their non expanded state, I believe the three columns of text should use a separator line which does not touch the top and bottom of the control's border"
This seems like a very specific and separate feature request not related to the overall proposal? How is this related to Scopes you specified for this proposal?

My purpose in showing these controls beside each other, is to distinguish between touch targets within one of these controls, and the controls themselves. The Date and Time pickers are a single touch target. If you were to make these touch targets visible as borders, ensuring those separators do not look like separate buttons becomes something to consider.

That is another reason why we do not touch a control design that’s not broken. By you introducing the vertical lines, you introduced the visual issue that didn’t otherwise existed, thus you now need to update the Date/Time control. I originally thought you were proposing this as an one-off design change but doesn’t appear so. Is that right?

Looks like this one is also not actionable yet until we settle on the design of the NumberBox, so closed.

---

"They also do not give confidence for touch users that their finger will hit the right part of the control, especially with controls like Calculator's proposed EquationBox, and the proposed NumberBox and Prefix/Suffix elements."
Do you have any specific example that suggest this statement is true? We have not received user feedback that suggests that this control design that we have been shipping for many years has caused them issues. Control's sizes are made appropriate for touch.

Until now, there have not been any Text/Form Fields that have contained more than two buttons, and usually the Clear Text button is only visible in a focused/typing state. NumberBox, and Calculator's EquationBox are being worked on. There are proposals for an Editable Date Picker, a Separated Time Picker, Prefix and Suffix properties for the TextBox, and support for Masking in the TextBox.

Whilst the designs of these controls are in active discussion - I would think this is a good time to consider design guidance for these controls, so they don't all decide to deviate and then consistency goes out of the window.

Thank you for your suggestion but as you mention, the design is not settled so this feedback, while appreciated is not actionable. Thus I’d have to say that this entire proposal is not particularly actionable until such time we have concrete examples.

Do you concur?

[mdtauk]

Thank you for pointing this out. That's what we do when we design so we do not introduce inconsistency or weird one-off behavior. At the moment, there is nothing actionable about this feedback unless you can show us exactly what we didn't do a good job on.

That said, we are human so we could make mistakes and you pointing specific mistakes out would be helpful. However lack of specific example makes this not actionable.

So if this was a separate issue, this issue would be closed as such.

This is pretty much a pre-emptive proposal, with two examples of controls being worked on which will need some guidance in terms of design.

---

This is not a problem today as far as I am aware. We ship with multiple buttons and we have not received any signal that is problematic. I am not familiar with what Calculator is doing but I don’t believe we are building Number Box for that purpose. I could be wrong.

This is the EquationBox design that is being worked on for Calculator by that team.

Create EquationTextBox control #547

And you are no doubt familiar with NumberBox that is in development

Here is an image of it pretty much sticking with the current form control visual style

Then there is the Prefix and Suffix and Masking ideas that have been proposed, which would necessitate some consideration as to how they would be implemented in the Base TextBox, which NumberBox would inherit

---

It is true that a bigger visual target gives user more confidence to touch it, but it doesn’t actually make the touch more accurate as far as I learned from research we did from Windows Phone days. People are also so much more used to targeting smaller UI than back then. There were additional touch study done and user testing performed when we made the standard control sizes smaller and we did not identify any issues with existing controls.

So this item is also not actionable, thus if it was separate issue, would be closed.

This is why I did not make it into a separate issue as all of these things need to be considered together.

If the problem is that adding multiple buttons to a Text/Form Field will make people less confident in hitting the correct touch target - this becomes a possible solution.

If the problem is ensuring future controls added to WinUI adhere to a consistent visual style, with predictable behaviours - this becomes a possible solution.

You could add borders to buttons within the current visual styling, but the 2 epx borders will make the control look heavier and inelegant. Which may be why the decision was made to display them, only as a glyph currently.

---

Is this your opinion or you can share data that highlights this issue? One thing to keep in mind is if we change the design to “improve” the issue that doesn’t exist already, we could very well be introducing a new issue that doesn’t exist today. As far as I know, I haven’t heard any issue that complains about the touch-ability of these buttons.

Unless there is something concrete you can raise here, this item is also not actionable and will be closed.

That is another reason why we do not touch a control design that’s not broken. By you introducing the vertical lines, you introduced the visual issue that didn’t otherwise existed, thus you now need to update the Date/Time control. I originally thought you were proposing this as an one-off design change but doesn’t appear so. Is that right?

Looks like this one is also not actionable yet until we settle on the design of the NumberBox, so closed.

At the very least it becomes a talking point, and not a static end goal that has to be reached. If you introduce the notion of making buttons within form fields visible through the use of borders - those controls which are a single button/touch target - would need to look different to buttons, so the user does not have an unexpected experience upon tapping.

Take this example #905 where @kikisaints shared an internal proposal for separate fields for Hours and Minutes in a Time Picker control. Her example used ComboBoxes to demonstrate how it could function, and have editable fields for keyboard entry.

The slight differentiation with the inner separating borders would distinguish between a single touch target, and multiple touch targets.

This is just a suggestion for the visual style, but I believe the concept of distinguishing the behaviour visually has merit, even if it is not actionable - its more of a starting point to examining our preconceptions.

---

Thank you for your suggestion but as you mention, the design is not settled so this feedback, while appreciated is not actionable. Thus I’d have to say that this entire proposal is not particularly actionable until such time we have concrete examples.

Do you concur?

Of course these are not immediately actionable, and it is not a simple tick box to solve a problem. This is feedback and suggestions. It is designed to provoke discussion, to go into design reviews, and fundamentally re-examine the current approach - based on examples from other parts of Microsoft, personal experience making XAML UIs, as a designer, and what others in the industry are doing.

To learn from others, to be persuaded against my ideas, or to persuade others, and begin a holistic approach to create a new visual language that is flexible, adaptable, and hopefully bring delight and confidence to a platform I am passionate about, and arguable has some trust to rebuild after Windows Phone, Windows 8, WinRT, Surface RT etc.

[chigy]

This is pretty much a pre-emptive proposal, with two examples of controls being worked on which will need some guidance in terms of design.

Proposal is to be opened for issues that can be acted on. This is not following the definition of a proposal for this repo, then?

---

This is the EquationBox design that is being worked on for Calculator by that team.

It appears to follow the same visual pattern as our current design system and item sizes sufficiently retained? What seems to be the problem?

And you are no doubt familiar with NumberBox that is in development
Here is an image of it pretty much sticking with the current form control visual style

That design seems to accurately describes the current system design and also it matches the calculator example you provided?

Then there is the Prefix and Suffix and Masking ideas that have been proposed, which would necessitate some consideration as to how they would be implemented in the Base TextBox, which NumberBox would inherit

Introduction of these prefix and suffix does not seem to have to impact the design of up/down boxes? What is exactly the problem you are trying to solve? You mentioned implementation issue but that has nothing to do with design choice here? Please help me understand?

---

This is why I did not make it into a separate issue as all of these things need to be considered together.

I guess I didn't say it clearly, then. Sorry for misunderstanding. This is not an issue that is actionable. Just because it is inside this single item, I am not able to close the issue but that does not make this item any actionable than it is.

If the problem is that adding multiple buttons to a Text/Form Field will make people less confident in hitting the correct touch target - this becomes a possible solution.

As mentioned, there is no signal that we received that this is the case. We have multiple buttons without the border next to each other (like command bar, calendar control's arrows, etc.) that has not received any customer concern.

If the problem is ensuring future controls added to WinUI adhere to a consistent visual style, with predictable behaviours - this becomes a possible solution.

You could add borders to buttons within the current visual styling, but the 2 epx borders will make the control look heavier and inelegant. Which may be why the decision was made to display them, only as a glyph currently.

This assumes we are going with the design you are proposing with borders. This discussion should happen once this decision is made.

---

At the very least it becomes a talking point, and not a static end goal that has to be reached. If you introduce the notion of making buttons within form fields visible through the use of borders - those controls which are a single button/touch target - would need to look different to buttons, so the user does not have an unexpected experience upon tapping.

This assumes we are going with the design you are proposing. This discussion should happen once this decision is made.

---

Of course these are not immediately actionable, and it is not a simple tick box to solve a problem. This is feedback and suggestions. It is designed to provoke discussion, to go into design reviews, and fundamentally re-examine the current approach - based on examples from other parts of Microsoft, personal experience making XAML UIs, as a designer, and what others in the industry are doing.

To learn from others, to be persuaded against my ideas, or to persuade others, and begin a holistic approach to create a new visual language that is flexible, adaptable, and hopefully bring delight and confidence to a platform I am passionate about, and arguable has some trust to rebuild after Windows Phone, Windows 8, WinRT, Surface RT etc.

Thank you for your passion. It makes it very difficult to debate about a design that is not something we are pursuing because we do not have a data that suggests the existing model is broken. As we finalize the design decision, we will take your feedback into consideration but this proposal itself is not actionable and I struggle since as PM assigned to this item, I am expected to take some action on a proposal our community open.

[chigy]

Status update

This issue marked "discussion"

@mdtauk , We just recently announced a new issue type "discussion" which I feel this one falls into. This conversation does not give me any concrete action I can make. Please read #966 and let me know what you think. If any of these discussions land on a proposal that is somewhat actionable, please open separate proposal per specific item so we can take them forward.

Community members should feel free to continue to discuss items here but please expect I won't be as active in those discussions as other proposal topics.

[mdtauk]

I don't think we have had any proposals for changes to the Text Fields yet, among the Buttons #3546 and Basic Inputs #3549 .

I would like to bring this back to the attention of those working on the visual refresh. @anawishnoff @YuliKl @chigy