CCI-Tools
Ease specifying operation inputs
This issue is a generalisation and consequence of applying #744 to also resources, dimension names, indexers, and general properties ("kwargs" in Python speech).
Expected behavior
It should be much more obvious and easy for users to specify operation inputs of the following types:
- the name of a resource (any type, usually one of
Dataset,DatasetLike,DataFrame,DataFrameLike,GeoDataFrame); - the variable(s) of a given resource (types
VarNameandVarNamesLike); - the dimension(s) of given variable(s) (types
DimNameandDimNamesLike); - the indexer(s) into selected variable(s) (currently type
DictLike). Indexers are dictionaries of key-value pairs, where the key is a variable's dimension name and where the value is a valid label from a coordinate variable associated with that dimension. - properties or key-word value lists (currently type
DictLike). Properties are often used to provide rarely used arguments to underlying Python functions that can take a large set of optional keyword arguments ("kwargs"). Examples are matplotlib plot functions or xarray'sDataset.open_datasetfunction.
The editor fields should render and behave as follows (initial ideas):
Resource(s): Drop down box to select from list of available resources for a given type. If value is mandatory and there is only a single matching resource, auto-select it.
Variable(s): Text field to edit literal name or list of names and "..." button to select from list of available variables. If value is mandatory and there is only a single variable in the selected resource, auto-fill it with that variable's name.
Dimension(s): Text field to edit literal name or list of names and "..." button to select from list of available dimensions for given variable. If value is mandatory and there is only a single dimension in the selected variable, auto-fill it with that dimension's name.
Indexers: Text field to edit literal key-value pairs and "..." button to select from list of available dimensions and their possible label coordinate values for given variable. If value is mandatory and there is only a single dimension in the selected variable, auto-fill it with that dimension's name.
Properties: Text field to edit literal key-value pairs and "..." button to select from list of available keywords and their possible values. Default values should be displayed. Python implementation note: each property should be described by a set of attributes similar to the ones passed to @op_input(...).
Actual implementation and behavior
Resource(s): are already fine, but we should auto-select enforced, single-choice resources.
Variable(s): are already fine, but we should auto-fill enforced, single-choice variable names.
If associated resource changes, must validate and/or reset current variable name(s). This closes #744. Python implementation note: we use the input attribute valueSetSource whose value is the name of a resource input to associate the variable with a resource.
Dimension(s): are already fine, but we should auto-fill enforced, single-choice dimension names.
If associated variable changes, must validate and/or reset current dimension name(s). Python implementation note: we use the input attribute valueSetSource whose value is the name is a dot-separated combination of a resource input and variable input to associate the dimension with a variable.
Indexers: are limited to text field to let users enter key-value pairs in the form "{dimension name}={label}, ...". Unfortunately, users have no idea what to enter here, because we don't show possible dimension names and possible labels for them. Python implementation note: also none of our indexer inputs have a valueSetSource attribute set, so that it is linked with some variable.
Properties: are limited to text field to let users enter key-value pairs in the form "{keyword}={arg}, ...". Unfortunately, users have no idea what to enter here, because we don't show possible keywords and possible values for them.
Steps to reproduce the problem
Bring up any Operation Dialog for an operation that has inputs of the mentioned types and verify their current behaviour.
Specifications
Cate 1.0 - Cate 2.0
@kjpearson, @HelenClifton, @esacci, @JanisGailis, @dzelge, I'd appreciate if you'd find some time to read and comment these suggestions for a quite important UX improvement.
From my perspective your suggestions for res, var and dim to automatically pre-fill the fields if possible are 'nice to have'. But I don't think that's a crucial usability improvement, if your time can be spent on something more important. Unless that's 'an hour'.
Regarding indexers I agree that currently it's very difficult to know what can be put there. It'd be a great improvement to tie the field to the selected variable (it always appears in a context of a variable?), as well as show limits for the possible dimensions. Some additional dialog where the value for each possible dimension could be entered would be 'nice to have', such that users wouldn't have to do name=value, name1=value1 routine.
I don't think there's anything we can do about properties. I'm not aware of a method to dynamically determine what kwargs a particular method takes. Also, it is imaginable that such a properties field could be used to combine optional kwargs for multiple methods invoked further down the line. I think this is an advanced functionality, so people who would want to input additional properties for, say, an underlying matplotlib method will probably know how to handle it.
Speaking about advanced users. I still believe that we should simplify the 'initial' operation invocation dialogues by making sure only 'mandatory' options (Python args without default values) are shown and everything else being hidden under some 'Advanced' tab, as the operation dialogues can be pretty intimidating at the moment.
@JanisGailis thanks for your immediate response!
Regarding your last comment, we have an extra UX issue on that: #534. I fully agree that this has an equivalent if not higher priority and it is a little easier to implement.
When you say "nice to have", I believe UX is very often said to be a nice-to-have requirement, also because it is "softer" than a concrete feature request.
If you really start being productive with a tool and you use it more often than once in a while, UX becomes very important. You start getting annoyed for any extra click that the tool could otherwise have avoided by just being a little more intelligent and context-aware, especially in obvious cases.
@forman The 'nice to have' part is only my opinion and only in the context that if there are bugs or stability issues to resolve then that would take precedence in my mind. But I do agree that the seemingly small things can add up (quickly), so 'nice to have' does in no way mean 'not important'.
I agree that autofilling with sensible default options would help with useability so is a good idea. I have a couple of thoughts.
It may be more useful to remember the last set of values that were given to an operation than prefill with the first on the list. However, in a situation where the user changed the resource then subsequent options like variable name would have to update to new defaults.
In the case of single valid option then prefill with that value but leave the drop down menu so that the user can see for themselves that this is the only option if they click on it.
Being able to see the possible value pairs for Properties would be good. It would be important to have some way to easily find out what those meant if they aren't in the operation description.
@kjpearson input much appreciated, thanks!
It may be more useful to remember the last set of values that were given to an operation than prefill with the first on the list.
That's the "quick lists" idea, see #476, item 3 in list
Hi @forman a couple of points to add: I agree that #534 should be higher priority in terms of improving user experience. Also the user experience could be improved by fixing #591. Currently the user sometimes sees pre-filled variables that don't belong to the dataset.
