search

microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.28k stars 675 forks source link

Proposal: NumberBox control #483

Closed sonnemaf closed 4 years ago

sonnemaf commented 5 years ago

The WinUI Team has opened a spec and PR for this feature.

Proposal: NumberBox Control

Summary

The NumberBox control provides developers a fully featured control for receiving a numeric (integer, floating point or currency) value. The keyboard InputScope is set to Number and additional support such as Up/Down buttons, formatting, and basic computation is optionally provided.

Rationale

Scope

Capability Priority
Input validation (including min/max). Must
Mechanism to increment/decrement value by custom step size with enableable wraparound. Must
Formatting support for currency, prefix/suffix, etc. Must
Calculator support. Must
Scroll and drag to change input. TBD

Important Notes

Calculator support It would be nice if there was a calculator support. If you type '5 + 2' in the NumberBox it calculates 7 on lostfocus. image I have tried to implement this as a Behavior but I think a NumberBox control is more suitable and easier to discover. https://github.com/sonnemaf/XamlCalculatorBehavior

Input validation It would be nice if the control would validate all input. It wouldn't allow (for example) to enter the decimal separator twice. A CanBeNegative (bool) and DecimalsPlaces (int) properties would also be needed.

I have tried to implement this as a Behavior but I think a NumberBox control is more suitable and easier to discover. https://github.com/sonnemaf/NumberBoxBehavior

Up/Down buttons It would be nice if you can set a flag which allows met to add '+' and '-' buttons next to the NumberBox. A Minimum and Maximum properties would be nice. image

Currency support Support for currency input. image

Accessibility and Inputs

Open Questions

NumberBox with a tool tip above to show a preview of the calculation results

NumberBox with a calculation in progress and highlight text previewing the calculation results

ArchieCoder commented 5 years ago

As a starting point, Telerik has one https://www.telerik.com/universal-windows-platform-ui/numericbox. It is available in Open Source too: https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs.

What I like from them is their approach for the formatting with the property ValueFormat.

Example: ValueFormat="{}{0,0:C2}"

robloo commented 5 years ago

Please also make sure this is correctly localised. The Windows Community Toolkit implementation has some shortcomings:

The TextBoxRegex extension with ValidationType="Decimal" does not support all UI cultures. Instead it's fixed to InvariantCulture. In English decimal values are "10.1234" with a period. In Spanish or German decimal values are written "10,1234". Parsing the English will be correct; however, Spanish or German user input will just be "101234" with the fractional portion lost.

See: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2700

mdtauk commented 5 years ago

Up and Down arrows should increment or decrement the value by a value the dev can set, but the default should be an int of 1

adrientetar commented 5 years ago
xyzzer commented 5 years ago

My implementation in WinRT XAML Toolkit also supports drag up/down to change values and it makes it much more usable when using with mouse than clicking buttons in certain scenarios. https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

SavoySchuler commented 5 years ago

Hello, @sonnemaf , @ArchieCoder, @robloo, @mdtauk, @adrientetar, and @xyzzer! I have been assigned to this proposal.

First, thank you, @sonnemaf, for submitting this. I showed it at Microsoft Build 2019 last week and it received cheers from the audience! The community response here in the comments also reflects the excitement we have to see NumberBox happen.

I have read through everyone’s comments and updated the scope section to reflect the input received. I would appreciate it if everyone could take a chance to checkout this small update and let me know if I have not accurately captured your requests, noting that some details (such as formatting localization) will be handled at the spec level.

ArchieCoder commented 5 years ago

Hi @SavoySchuler,

This week, I'm working on accessibility feature on my app. This would be a plus if accessibility would be handled correctly with the new control for example, the increment can be said out loud instead of "plus", "minus". The rest seems fine to me.

mdtauk commented 5 years ago

Ensuring narrator is able to read out the values properly so it is clear what is happening is important.

Not sure if the Xbox controller will need any focus tapping to ensure the analog sticks and D-Pad will function correctly

xyzzer commented 5 years ago

Small correction - drag to increase/decrease should work on the text field itself until it is activated. IIRC in my implementation I had to put some transparent overlay on top of the text field to enable it and also hide the mouse cursor while dragging so that borders of the control or screen would not limit the drag distance and that when you're done dragging and I show the cursor again - it shows up where it first disappeared.

sonnemaf commented 5 years ago

@SavoySchuler you got a nice task. I can live with your scope. Calculator is a nice to have (WinUI 3.0 or 3.1). I have developed in many desktop environments (VB6, WinForms, WPF and UWP) and always missed a NumberBox. Finally we will get it.

Maybe you can also add the mouse scroll wheel for Up/Down. Blend for Visual Studio supports this.

I also love Drag-to-change, something I used a lot in Expression Blend.

I'm not sure what input validation will do and not do. Will it only be min/max or also limit keyboard (letters a-z, etc)? Will it handle Pasting invalid numbers?

I would love to read the full specs.

SavoySchuler commented 5 years ago

@ArchieCoder, I hear you loud and clear. Accessibility is a priority and its best handled upfront. I have started an Accessibility and Inputs section on this proposal where I have added your note.

@mdtauk, great question as always. I have added this to the Accessibility and Inputs section as a note to look into it.

@xyzzer, you're right. When reorganizing, the scope list, I grouped Up/Down buttons and drag-to-change as related functionality. Upon re-reading it did appear as though I was suggesting drag-to-change be a feature on the buttons. I have moved drag-to-change to its own section to provide clarity.

@sonnemaf, awesome. I will post a link to the spec as soon as its opened, which will likely be today or next week. Please feel encourage to join me in writing it! Until then, I've added scroll-to-change to the scope here.

All, With a note on calculator support - I believe in the value. I am working with my team to figure out if it is something we should modularize in the case the functionality could be leveraged further in the platform. Additionally, there is the question of how far do we go with calculator support? Would simple order of operations on +-/* do? Or something more comprehensive such as connecting to some kind of wolfram alpha service? Exploring a modular route could perhaps allow us to start with the more basic case while not blocking opportunity for a more comprehensive form of calculator support. I would be interested to know everyone's needs here.

For input validation, I have the same question. Does min, max, no letters, and no invalid pasting cover it?

ArchieCoder commented 5 years ago

I find the calculator feature cute, but practically how is this feature be discovered by a user? Is there going to be a little widget hint about this?

SavoySchuler commented 5 years ago

@ArchieCoder, do you think faded custom placeholder text in the NumberBox could appropriately prompt a user? If so, I imagine a string such as "a + b - c" or "enter equation" could be succinct ways to deliver that information. Excel has also created a standard with "=" appearing at the start of an equation. Perhaps once the user clicks the NumberBox, an immutable "=" appears at the front that the user then types behind?

We do have ToolTip or the heavier TeachingTip for guidance at the app level that we could ask developers to rely on, but my strong preference would be to solve this within NumberBox itself.

I'm interested to hear your thoughts here!

ArchieCoder commented 5 years ago

Placeholder would be indeed a good way as long as other context is not required due to the space limitation. I would think a NumberBox width will be smaller than a textbox for example.

xyzzer commented 5 years ago

Unless the control supports nullable numbers - it will always show a value, so there won't be space for a placeholder string inside of it.

On Fri, May 17, 2019 at 10:14 AM ArchieCoder notifications@github.com wrote:

Placeholder would be indeed a good way as long as other context is not required due to the space limitation. I would think a NumberBox width will be smaller than a textbox for example.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVVKWTI#issuecomment-493529933, or mute the thread https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA .

SavoySchuler commented 5 years ago

@ArchieCoder, looking as @sonnemaf 's examples (thank you again for these), any NumberBox that is not wide enough to display placeholder text for "a + b - c" would also not be wide enough to create a recommended user experience for entering equations into. In that respect, I would imagine this solution option is still viable for this purpose. However, I do think you're tapping into an area we have not addressed yet - scenarios where we want a compact NumberBox/only a simple number to be entered. I imagine Calculator support would need an API for disabling it, in which case we need not concern ourselves with long placeholder text nor breaking min space constraints the equation form of NumberBox would otherwise need - though some placeholder text option for compact mode may still be nice, even if its just for something like "#" or "e.g. 2".

@xyzzer, thanks for bringing this up. Let's make sure this is even the right user experience first and we can figure out the implementation from there! There's no need yet to cap our search for the right user experience due to technical limitations that we may be able to mitigate. :relaxed:

SavoySchuler commented 5 years ago

I have a higher priority question for everyone:

Would you rather have a NumberBox control that consolidates these features independent from a standard TextBox or would you rather have these features baked into TextBox as native capabilities that could be activated through APIs or InputScope?

(@sonnemaf, @ArchieCoder, @robloo, @mdtauk, @adrientetar, and @xyzzer)

mdtauk commented 5 years ago

It is a significant change to put all this into a TextBox control.

The validation for characters entered.

Using the correct keyboard layout with the InputScope

The differing mouse behaviours.

The ability to display spinner buttons as in the FabricWeb version.

If all of these things could be added, with a behaviour enum to define the TextBox type, without having an impact on everyone else currently using a TextBox in their app, then good.

And you could even consider combining other TextBox behaviours like an icon that could represent search or calendar which acts like a button. Masks for things like IP addresses or URLs which display "http://" in the style of placeholder text as you enter in text beside it.

FabricWeb has a wide variety with their TextFields.

https://developer.microsoft.com/en-us/fabric#/controls/web/textfield

https://developer.microsoft.com/en-us/fabric#/controls/web/spinbutton

Felix-Dev commented 5 years ago

I'd definitely go with an own NumberBox control instead of baking all these features into a TextBox control (similar to how there also is a PasswordBox control and not a TextBox with an input-mode "password").

The NumberBox control will be much more than a simple input field for IP addresses, for example. It will come with its own accessibilty/unique scroll & drag features, calculator support,... all which will distinguish it quite a lot from how I normally have used a TextBox so far (cases as simple as specifing a representation name for a group of data). And as even more special features/requirements will get proposed for the NumberBox control we can keep a nice and clean separation between both NumberBox and TextBox.

That spearation would also come down in the documentation and the app xaml layout (NumberBox more easily detectable than, say, a TextBox with a bunch of properties with one of them specifying the input mode). Instead of reading the TextBox documentation about its numeric input capabilities, that part would be nice and tidy in a specific NumberBox control documentation (just like with PasswordBox today).

adrientetar commented 5 years ago

With respect to the appearance of the control, I think the unit/suffix could be displayed aside with a smaller size/desaturated color so that it differentiates from the value itself:

Image 1

When mouse hovers over the control, up/down arrows could fade-in in place of the unit:

Image 1

An alternative is the number controls from figma.com, when you hover over the unit you can click+drag left/right to change the value.

image

Left/right is interesting because it's easier to move the mouse left/right than up/down (you don't need to lift your wrist).

Other things:

mrlacey commented 5 years ago

@adrientetar putting an indication of the unit inside the control creates lots of extra issues:

These would all be avoided by putting this in the header, description, or a separate TextBlock.

sonnemaf commented 5 years ago

I would go for a separate NumberBox control with a Value property and maybe not a Text Property. The Value should be a Double so we can databind (x:Bind) it. I'm not sure if we should also support the Decimal datatype, and how.

sonnemaf commented 5 years ago

Support for nullable numbers is a MUST I think (thanks @xyzzer). The Value property should be a Nullable datatype. I'm not sure if this will cause binding issues when binding it to a non nullable value.

xyzzer commented 5 years ago

While composition has benefits and having an attached behavior for numbered mode could be implemented and attached to a TextBox - I think it would make it unnecessarily complicated and limited. Some of the biggest problems you'd likely hit with implementation relate to accessibility. I believe to support some of the accessibility patterns - you'd need to bake in implementation of certain interfaces into TextBox that would make it confusing if a TextBox wasn't in a number box mode.

On Mon, May 20, 2019 at 2:33 AM Fons Sonnemans notifications@github.com wrote:

Support for nullable numbers is a MUST I think (thanks @xyzzer https://github.com/xyzzer). The Value property should be a Nullable datatype. I'm not sure if this will cause binding issues when binding it to a non nullable value.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVYHVVA#issuecomment-493910740, or mute the thread https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA .

SavoySchuler commented 5 years ago

I have one more question for everyone. Do you need/prefer input validation or masking?

(@sonnemaf, @ArchieCoder, @robloo, @mdtauk, @adrientetar, @xyzzer, and @Felix-Dev )

mdtauk commented 5 years ago

Validation is essential, as you can't add a number to a string. And mathematical operators need to be assessed and processed.

Does it need an error message displayed if it can't calculate, that I am not too sure about.

Masking would be useful, but it should probably be built into the Textbox itself, so URL and email entry can be handled. NumberBox would be Telephone Numbers, IPs, etc

xyzzer commented 5 years ago

I don't think a NumberBox should be used for phone numbers or IPs. These seem more like simple masking/filtering extensions for a TextBox. A NumberBox is something you'd want to use for entering a single value. Perhaps there's a potential to have a currency box control, but I also feel like it should be a separate control different than either TB or NB.

mdtauk commented 5 years ago

@xyzzer Making the NumberBox more flexible for any kind of numeric input seems like a good idea to me. It can be derived from a TextBox control, and that control could have a Mask property, as well as other behavioural properties.

Some of those properties on the NumberBox could be:

Properties that could be added to the TextBox could be:

image

image

These images are of the Fabric UI TextField - and it supports all these different states - we should aim to bring Fluent WinUI 3.0 controls to parity where possible

image

The Fabric UI Spinner buttons are too small for touch, so I would format it differently so the up and down buttons are side by side, not stacked on top of each other

sonnemaf commented 5 years ago

For me Validating is a MUST HAVE and Masking is a NICE TO HAVE. I never liked masking; it is too rigid.

sonnemaf commented 5 years ago

@rudyhuyn proposed on the Windows Calculator repository a nice feature. @mdtauk commented on it.

You can open a Calculator Popup from the NumberBox similar to a Date/Time/Calendar Picker.

image

mrlacey commented 5 years ago

Similar to what @xyzzer said above. There is a fundamental difference between a number and a string that contains a sequence of digits. The best way I've heard the difference described is that you can perform multiplication and division operations on a number. You can ask for half of a number and divide by two. You can't ask for half a zip-code or a "phone number" and get something meaningful.

Mixing a specific NumberBox that has mathematical capabilities with functionality to capture other values comprising of digits can lead to other issues too. "Phone numbers" may start with leading zeros (or a plus sign) and there they have meaning. For a number they don't and would be stripped. "phone numbers" are often also formatted with brackets and hyphens. When processed as mathematical operations these could easily end up being interpreted as requiring multiplication and subtraction.

Allowing masking in the same way as a TextBox and as a way of formatting input risks confusing the difference between a NumberBox and a TextBox and when each should be used.

Simple validation is a must have but there's a need to be careful that when validation comes to the platform, this doesn't result in ways of having conflicting methods of validation or something that could easily end up pushing developers to spreading their validation to multiple locations.

I'd keep validation to just be based on these properties:

Separately, there needs to be indication of

mdtauk commented 5 years ago

Masks would need a visual affordance to make it clear what is required, whereas basic calculation inputs would not be used alongside masked input.

The Fabric Web text controls seem to handle this nicely - but of course the scope for the NumberBox is separate to general fit and finish improvements to the default TextBox control.

The spinner buttons (and optional Calculator flyout perhaps) are the only visual things that seem specific to a NumberBox.

As for properties, perhaps if the keyboard up and down buttons are enabled for changing the value - a Step value could be included so you can choose how much to increment or decrement on key press.

sonnemaf commented 5 years ago

@mdtauk, I like the Step value, but not only on key press. Also on scroll and Up/Down button.

mdtauk commented 5 years ago

@sonnemaf Sure, the Step is good for something binary like a mouse wheel tick, key press or key down. Perhaps the distance dragged away from the box could ramp up the step amount?

So StepMinimum and a StepMaximum perhaps?

mrlacey commented 5 years ago

So StepMinimum and a StepMaximum perhaps?

I have no idea what those values might relate to or what to expect for them. If the purpose of "Step" is to define increments then call it "Increment".

This would allow Max:100 Min:0 Increment:10 to only allow the values 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, & 100 to be specified.

Having the step/increment amount vary based on distance dragged could lead to unpredictable value changes. If the purpose of this control is to make it easier to specify numeric values then if the value starts changing in varying amounts then I'd likely find this very frustrating which would defeat the underlying goal of having a dedicated control to make it easy.

mdtauk commented 5 years ago

@mrlacey I use Step as it is the property named for the slider and progress bars, but increment could be used if preferred. The value does go up and down so as long as increment does not get confused with only an increase in the value.

There is a proposal for clicking and dragging up or down to increase or decrease the value. If the user expects the value to change quicker, the further up or down you drag, then having a Stap Min and Max value would allow the developer to control this as the delta changes. So a small drag distance could step by 0.1 or 1 - but dragging further could change by steps of 5 or 10 for instance.

I am not saying the drag distance has to change the speed of the value change - only that its an idea that may be helpful, if it felt natural and gave the user some sense of confidence and control.

SavoySchuler commented 5 years ago

Awesome feedback, everyone! I have opened a spec & PR to start hammering out the details.

@KevinTXY will be joining me as the developer for this control. We'll keep the requirements conversation going on here and start the API/example specific conversation on the PR.

Please feel encouraged to join me in writing the spec.

TeachingTip's spec is a fully featured example of what a finished spec will look like. The main outline will be:

robloo commented 5 years ago

Great ideas, I like where all this is going. Adding my two cents:

I'm sure more ideas will follow. I look forward to reading the spec!

SavoySchuler commented 5 years ago

(@mdtauk, @xyzzer, @mrlacey, @sonnemaf, @robloo, @Felix-Dev, @adrientetar, @ArchieCoder )

I have the spec/PR filled out with APIs and examples for each. I think I have addressed formatting to your specifications with an enum for basic pre-defined types (still in-progress) as well as a custom formatting property that will override predefined types if set.

Please check it out and let me know if it does not resolve your concerns or if it can be added to or improved. I will accept pull requests that contribute to the specifications asked for here.

mdtauk commented 5 years ago

A popup calculator may make sense if there is coordination with the Calculator open source effort. Both for consistency in the look of the Calculator Flyout, but also in the engine behind it.

mdtauk commented 5 years ago

Not sure if this is the place to post this image, but here are designs for the various states that conform to the specs.

numberbox proposal Image is at 200% scale

mrlacey commented 5 years ago

@mdtauk what's the purpose of your mockups?

What state does each image attempt to show? Without you clarifying this we may make assumptions that are different to yours.

Are these intended to be pixel perfect references?

Can you call out where something in your images differs from the default of either the platform or the base control so it's clear what (if anything) you're adding or changing.

mdtauk commented 5 years ago

@mrlacey I could do a fuller breakdown if that would be helpful? I was just trying to illustrate some of the examples called out in the spec.

The purpose of them is to try illustrate how these controls could look with the various control elements proposed such as prefix, suffix, masks, up and down buttons. They are extrapolated from the FabricWeb control designs, but using XAML elements like the FocusReveal and control sizing for the buttons.

The examples show Rest - Focus - Disabled state

sonnemaf commented 5 years ago

The popup calculator would be a nice feature for V2.

I'm not sure where to put my remarks. Must I make a PR on spec or can I keep writing my thoughts in this issue?

Integer

Would an Integer value for the NumberBoxFormatType be useful?

enum NumberBoxFormatType
{
    IPAddress,
    InternationalTelephone,
    Currency,
    Integer,
}

Language

Would you use the language to specify the Currency, decimal digit-grouping symbols?

In the next example the Language is set to nl-NL. Does this mean that the Prefix is the Euro sign, the decimal symbol a comma with 2 decimals after it and the digit grouping is a dot? Negative currency has a minus sign in front and no parenthesis like in the US. 

<TextBlock Header="Price" 
    PlaceholderText="0,00" 
    FormatType="Currency"
    Language="nl-NL" />

Is this enough because there are many number & currency format options in Windows.

image

Value property or properties

Do we need a Value property and what (numeric) type would it be. I would use it to databind it. Should it be a double, decimal or int. Do we need Nullable support (double?, decimal?, int?). I don't want to use the Text property of the inherited TextBox control for databinding. We need support for Decimal too, double is not enough.

<TextBlock Header="Price" 
    Value="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

What if the Salary property of the Employee is a Nullable (decimal?). Do we need ValueNullableDecimal dependency property. The SelectedDate of the DatePicker control is a Nullable. Nullable is an issue, especially with databinding. 

<TextBlock Header="Price" 
    ValueNullableDecimal="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

Same thing with MinValue and MaxValue. They are now Integer in the Spec but shouldn't this be a Double?.

mrlacey commented 5 years ago

@sonnemaf because the spec says that the control is for anything where digits can be entered I think that has to mean it treats the "Value" as text and relies on the consuming code to convert as necessary. It's not ideal but even if there was a Value property that was a long or a float, there would still be lots of occasions where conversions would be necessary. It's better than overloads for every numeric type. Then there's things that the control is being designed for which can't be converted to a "numeric" type, such as US Zipcode, Telephone number, or IP address. For these sorts of values getting the text seems like the best (only) option. I think it's simpler (at least in the initial version to have one way of accessing the entered value and relying on converters where necessary. I can see a place for a collection of helpers (or subclasses) coming to the toolkit initially and then some of them being incorporated into the main control based on feedback.

Is a Language property necessary? Why would this not be the same as UILocale? There might be good reasons, but it seems like this should be user configurable (at an OS level) and giving the ability to specify a specific format could lead to more problems for developers when the format doesn't match elsewhere or what the user of the application wants. Off the top of my head: what if someone pastes in a value in a different format?

mdtauk commented 5 years ago

@mdtauk what's the purpose of your mockups?

What state does each image attempt to show? Without you clarifying this we may make assumptions that are different to yours.

Are these intended to be pixel perfect references?

Can you call out where something in your images differs from the default of either the platform or the base control so it's clear what (if anything) you're adding or changing.

@mrlacey Is this the kind of thing you were wanting? numberbox comparison

mrlacey commented 5 years ago

@mdtauk that's a bit better as it explains some of what you're trying to show.

Underlying question still remains though: What is your goal in showing this? Is it just an idea? Is it your preferred version after having explored different ideas? If so, why are these the best/preferred?

Comparing current controls with how you'd like the new controls to be displayed in your preferred new system wide styles means that it's not possible to separate what's specific to the control with what's in your preferred new system wide styles.

For example, you mention changing the transparency on a border. Is this change intended for all controls or just this one? And in which states?

Giving explicit sizes (for buttons) can be problematic in design comps as they don't always translate into evenly based on their container being resized. Should they always be square? or is their width fixed based on the default control height?

How are you proposing the background brush for prefixes and suffixes is determined? I'm presuming an existing system brush, but which one?

Masking isn't covered in this spec. Are your "Masked" examples intended to relate to format strings? How does you're masked example correspond to a format? I assume you're example is showing the entry of an version 4 IP address but there looks like a lot of assumptions there based on how neatly everything seems to fit. Should all non-enterable values have a background and margins? What if they're not always displayed? Should content be stretched to fit all available space, as appears to be the case in your example? How will the space allocated for non-enterable values be treated when panning content that is wider than the available space?

mdtauk commented 5 years ago

@mdtauk that's a bit better as it explains some of what you're trying to show.

Underlying question still remains though: What is your goal in showing this? Is it just an idea? Is it your preferred version after having explored different ideas? If so, why are these the best/preferred?

Comparing current controls with how you'd like the new controls to be displayed in your preferred new system wide styles means that it's not possible to separate what's specific to the control with what's in your preferred new system wide styles.

For example, you mention changing the transparency on a border. Is this change intended for all controls or just this one? And in which states?

The NumberBox Spec did not include any visual examples, and the images in the Original Proposal are rough examples for functionality. There is another PR #524 where the control templates are getting updated with CornerRadius values at 2epx, which is also the same rounding used by Fabric Web.

So making the assumption that the TextBox derived controls will be also similarily updated, I used that as a guide to show how the proposed functionality of NumberBox could fit into that. Fabric Web textfields already have support for Prefix and Suffix values, so I just took that design, and used the XAML metrics.

image

Giving explicit sizes (for buttons) can be problematic in design comps as they don't always translate into evenly based on their container being resized. Should they always be square? or is their width fixed based on the default control height?

The current TextBox has some integrated buttons, such as the SearchBox, the Password Reveal button, and the Clear Text button. Touch Targets for XAML suggest buttons be 32 x 32 epx - I just kept them square and used that guidance.

How are you proposing the background brush for prefixes and suffixes is determined? I'm presuming an existing system brush, but which one?

In my example I used the Theme Foreground Colour but using an Opacity of 15%. The FabricWeb ones use closer to 10%, and the XAML Buttons use 20%. There are similar brush values like the ListLowBrush but it may need a new TextBoxAppendixBackground brush. The Text Foreground would use the same PlaceholderTextForeground brush.

Masking isn't covered in this spec. Are your "Masked" examples intended to relate to format strings? How does you're masked example correspond to a format? I assume you're example is showing the entry of an version 4 IP address but there looks like a lot of assumptions there based on how neatly everything seems to fit. Should all non-enterable values have a background and margins? What if they're not always displayed? Should content be stretched to fit all available space, as appears to be the case in your example? How will the space allocated for non-enterable values be treated when panning content that is wider than the available space?

I won't pretend I have all the answers for this, and how it is visibly displayed on the control will come down to how the mask formatting is implemented in the controls.

I used the IP v4 address as it is the example featured in the spec, and my original intention was to illustrate what was being proposed (although the prefix and suffix examples were lacking so I chose other values)

I took a look at how other controls handle masking, and some use inline text which move the Caret as values are entered. Others will enter in things like brackets and hyphens when entering a telephone number. Some use tab or arrow keys to move between the segments. The closest example from Microsoft that comes to mind is entering in Product Keys during Windows Install.

I thought using the same styling as the appended elements, would fit the aesthetic, but I am aware this adds to the length of the control to fit it all in, and inline may make better use of space.

image

image

image

adrientetar commented 5 years ago

Just a note as I'm working with TextBox now, with it there's no single event to signal a value changed by the user (i.e. the union of lost focus and return key pressed), similar to https://doc.qt.io/qt-5/qlineedit.html#textEdited it would be great to have that in the NumberBox as it's meant for this kind of edits. By the way, if it's going to handle all kinds of values like IP addresses maybe "Number"Box is too narrow of a name? It could ValueBox or so

mdtauk commented 5 years ago

@adrientetar NumberBox seems fine as a name, because it all inputs count as numbers. IP Address has 4 numbers, Telephone numbers, Currency, Measurements, etc.

DigitBox, NumeralBox, etc are all variants that don't quite fit the Microsoft naming style.

Values also don't have to be numeric in nature, so ValueBox can also be a bit misleading.