search

microsoft / xaml-standard

XAML Standard : a set of principles that drive XAML dialect alignment
Other
807 stars 54 forks source link

Discussion: Data entry requirements #198

Open JerryNixon opened 7 years ago

JerryNixon commented 7 years ago

Since so many XAML apps are forms-over-data, I think it is reasonable to consider typical user requirements for this kind of interface. Specifically, I am referring to data entry (which still dominate line-of-business apps). There are recurring, common requirements implemented gain and again by developers.

Note: This functionality is typically implemented using one of two approaches: either extended controls or attached behaviors. Extended controls basically means more custom code and more required testing, and more opportunity to either not support accessibility (et al) or to introduce errors. Attached behaviors, on the other hand, (especially for large forms) basically introduces new memory & performance impacts making the approach delightful for small apps and horrific for larger, more significant ones. I am recommending we consider if any of these requirements be in the Standard.

  1. Go to field on Key (usually enter) this behavior is more like what we expect Tab to do, but in data entry applications, users generally prefer the Tab behavior to result from the Enter key. Using an element {Binding} would certainly make this simple.
  2. Submit form on Key (usually enter) this behavior is just like finding the 'Submit' button and pressing it. Keyboard bindings can also do this, but think about login forms, etc. - this is a typical ask. Pointing to a ICommand in your view-model is a fine option.
  3. Tooltip reveal (usually on focus) when the user enters the field a tooltip with information on the field or instructions on the definition of valid is a common requirement. Dynamically or prescriptively positioning the tooltip would be an important part of such behavior.
  4. Tab through invalid fields this is less about Tab and more about dynamically manipulating TabIndex values to jump focus to controls indicated as invalid. This is related to #18, but in general, think in the context of a multi-page, or multi-tab form a user is working to complete through the app.
  5. Form structure visualize In Visual Studio you can set the scroll bar to "map mode" which I have implemented in WPF forms using the VisualBrush. Information workers visually recognize the shape of their forms and navigate easily through them this way. I am not sure the VisualBrush will make it in the standard, here, but I wanted to recommend solving this requirement with something native.
  6. Can't leave until valid there are times when editing a form field should be flexible, letting the user enter invalid data and just preventing saving. There are other times when a user should be compelled to enter valid data before doing anything else. This is that feature.
  7. Highlight related fields When entering the rate for a mortgage, it makes sense to refer to the loan type. It is common for a field's value to be coerced by the value of other fields. If I were to identify those fields in some way, when this field receives focus those would be highlighted in some way.

There are more, and we have all solved these with extensions, attached properties, and behaviors, but I am recommending that we consider if any of these are worthy of native implementations for the sake of large-scale forms (which still dominate most use cases) and overall performance, as a result.

GeraudFabien commented 7 years ago

I'm pretty sure i should make a new issue about it but TextBoxFor, RangeFor, ... Who, like InputExtentions give simple xaml. With three template LabelTemplate, InputTemplate and Template. If thinks of it for while with the "Acess to attribute property in Binding" issue to get the label and do the globalization. Currently the only way i find is to make another property that give Label for Each. The main goal are