-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Lens] Make operation order more clear to users #48305
[Lens] Make operation order more clear to users #48305
Conversation
Pinging @elastic/kibana-app (Team:KibanaApp) |
We may want to run this text by Alona. I find this pretty confusing:
Also, Is "date" the xAxis field in your example? If so, it makes more sense. |
Also, since we're re-ordering in the table (and presumably in any similar interface), maybe the multi-nesting scenario should be labeled: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM w/ possible tweaks. We can always make verbiage tweaks later.
return !originalOrder.includes(id); | ||
}) | ||
); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be simplified, I think:
const sortedColumns = Array.from(new Set(originalOrder.concat(layer.columns)));
> | ||
<> | ||
<EuiRadio | ||
id={generator()} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with this, but is this predictive, or is it going to cause render churn? It seems totally fine to me to just specify an ID schematically here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like I'm supposed to pass a string, and it'll generate consistent ids if given a string.
|
||
if (!column || !column.isBucketed || !aggColumns.length) { | ||
return null; | ||
} | ||
|
||
const fieldName = hasField(column) ? column.sourceField : ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same logic as above. Not a big deal. But might be something we can tidy up later.
values: { target: target.fieldName }, | ||
}) | ||
: i18n.translate('xpack.lens.indexPattern.groupingSecondDateHistogram', { | ||
defaultMessage: 'Dates for each {target}', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this verbiage pretty confusing. I think {field} for each {target}
or something would be clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it improves the readability to use field names like that- especially when the editor is showing the current field in multiple places.
💔 Build Failed |
💚 Build Succeeded |
@elasticmachine merge upstream |
💔 Build Failed |
💚 Build Succeeded |
* [Lens] Make operation nesting more clear to users * Improve date wording * Update per comments
Closes #47281
Lens allows users to build multi-level aggregations using simplified editors, but user interviews indicated that even advanced Elasticsearch users were confused by our terminology of "Nesting."
This PR:
<a>
for each<b>
"The operation editor is used in all charts:
When there are 2 bucketed operations we show radio buttons:
This also works for dates:
Editor as seen in a data table:
Suggestion labeling: