Skip to content
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

Removes the "Index contains time-based events" checkbox #11409

Conversation

ycombinator
Copy link
Contributor

@ycombinator ycombinator commented Apr 25, 2017

This PR addresses the first part of #10444.

Currently we show a checkbox labeled "Index contains time-based events". The user has to check this box, and is then shown a select list with time fields.

This PR simplifies this UX by:

  • Taking away the checkbox and always showing the select list
  • For valid index patterns, showing the first item in the select list as "No Time Filter field". For empty or non-existing index patterns, the select list is empty
  • For index patterns with no time fields, disabling the select list
  • For index patterns with time fields, enabling the select list
  • Renaming the label of the select list to "Time filter field name" to better reflect where the selected time field is used
  • [Cleanup in related code] Renaming the label for the time field on the Edit Index Pattern page to "Time filter field name" for consistency

When no index pattern is specified

screen shot 2017-04-25 at 6 52 38 am

When a non-existing index name/pattern is specified

screen shot 2017-04-25 at 6 52 57 am

When an index containing no time fields is specified

screen shot 2017-04-25 at 6 53 07 am

When an index containing time fields is specified

screen shot 2017-04-25 at 6 53 40 am

screen shot 2017-04-25 at 6 53 49 am

@ycombinator
Copy link
Contributor Author

/cc @skearns64

@epixa epixa added v6.0.0 and removed v4.6.0 labels Apr 25, 2017
@epixa
Copy link
Contributor

epixa commented Apr 25, 2017

I assume you wanted the v6.0.0 label here :)

@epixa
Copy link
Contributor

epixa commented Apr 25, 2017

Two suggestions:

Can you move the "Unable to fetch mappings" error message to immediately below the index pattern field? This way the error appears at the place that caused it/where it can be fixed. You may need to play around with a disabled submit button instead of hiding the submit button entirely, but honestly this is really how the form should work anyway. Not showing a submit button until everything is kosher is kind of awkward. I don't want to churn too much on this, so if this seems to blow open the issue, we can address it in a follow up.

Rather than "No Time Filter Field", which doesn't do a great job describing why that may be the case or what the effect may be, how about two different possibilities:

For indices without time fields at all: Not time-based: Matching indices do not have date fields

For indices with time fields but without one selected: Not time-based: No date field selected as the primary time field

Thoughts?

@ycombinator
Copy link
Contributor Author

Can you move the "Unable to fetch mappings" error message to immediately below the index pattern field? This way the error appears at the place that caused it/where it can be fixed. You may need to play around with a disabled submit button instead of hiding the submit button entirely, but honestly this is really how the form should work anyway. Not showing a submit button until everything is kosher is kind of awkward. I don't want to churn too much on this, so if this seems to blow open the issue, we can address it in a follow up.

Yeah, I agree with this change but I'd like to address it in a follow up PR. I've created an issue so we don't forget about it: #11410.

Rather than "No Time Filter Field", which doesn't do a great job describing why that may be the case or what the effect may be, how about two different possibilities:

For indices without time fields at all: Not time-based: Matching indices do not have date fields

For indices with time fields but without one selected: Not time-based: No date field selected as the primary time field

Yeah, ++ to making the messages more helpful to the user. Changing.

@cjcenizal
Copy link
Contributor

cjcenizal commented Apr 25, 2017

When an index containing no time fields is specified

screen shot 2017-04-25 at 6 53 07 am

In this situation, can we replace the select with some text stating, "The indices which match this index pattern don't contain any time fields."

When an index containing time fields is specified

screen shot 2017-04-25 at 6 53 40 am

Can we change "No time filter field" to "None selected"? The former sounds like there simply are no time filter fields available, and I think the latter clarifies that the user hasn't picked one yet.

Edit: This is basically echoing Court's suggestions, but with my own spin on them.

@ycombinator
Copy link
Contributor Author

@cjcenizal Did you see Court's comment earlier? It addresses the same issues you brought up. I'm putting up a new commit with some better verbiage shortly.

@cjcenizal
Copy link
Contributor

@ycombinator Yeah I saw his comment afterwards and edited my comment. We have the same things in mind, but I think the language I suggested is a little more human-readable.

@ycombinator
Copy link
Contributor Author

Okay, changing to the language suggested by CJ.

@cjcenizal
Copy link
Contributor

Winning!

@ycombinator
Copy link
Contributor Author

I updated the verbiage per @cjcenizal's suggestions but I kept the select lists always in place per the spirit of the conversation here (or my understanding of it anyway): #10444 (comment).

Updated screenshots for all the cases below.

When no index pattern is specified

screen shot 2017-04-25 at 9 38 17 am

When a non-existing index name/pattern is specified

screen shot 2017-04-25 at 9 38 31 am

When an index containing no time fields is specified

screen shot 2017-04-25 at 9 38 45 am

When an index containing time fields is specified

screen shot 2017-04-25 at 9 37 49 am

screen shot 2017-04-25 at 9 38 03 am

@cjcenizal
Copy link
Contributor

cjcenizal commented Apr 25, 2017

@ycombinator What do you think of this? The reason I suggest these changes is because I think we need to explain what's going on to the user a bit more, and I don't want to overload the select component with a ton of text.

index_pattern_creation_time_fields

If you think this works, we can implement it by adding a paragraph below the select:

<p class="help-block" ng-if="!controller.doesIndexHaveDateFields">
  The indices which match this index pattern don&rsquo;t contain any time fields.
</p>

And updating the controller like this:

if (this.dateFields.length === 0) {
  this.doesIndexHaveDateFields = false;
  this.dateFields.unshift(TIME_FILTER_FIELD_OPTIONS.NO_DATE_FIELDS_IN_INDEX);
} else {
  this.doesIndexHaveDateFields = true;
  this.dateFields.unshift(TIME_FILTER_FIELD_OPTIONS.NO_DATE_FIELD_SELECTED);
}

And making this change in the translation file:

  "KIBANA-NO_DATE_FIELD_SELECTED": "None selected",
  "KIBANA-NO_DATE_FIELDS_IN_INDEX": "None available",

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks awesome! Just had some UX and other small code suggestions.

<label>
<span translate="KIBANA-TIME_FIELD_NAME"></span>
<span translate="KIBANA-TIME_FILTER_FIELD_NAME"></span>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious: what does time filter mean in this context?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm using that per this suggestion: #10444 (comment).

I think "time picker" might be more appropriate but I'm not sure if users know what that is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... I guess "time filter" works. I like "time picker" because I know what that is, but I'm afraid that might couple these field too closely to a particular UI component.

name: $translate.instant('KIBANA-NO_DATE_FIELD_SELECTED')
},
NO_DATE_FIELDS_IN_INDEX: {
name: $translate.instant('KIBANA-NO_DATE_FIELDS_IN_INDEX')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really minor suggestion: technically, we're referring to "indices", and not a single index, right? It all depends on how many indices match the index pattern. Maybe it's just me, but when I first started using Kibana, it took awhile for me to understand the difference between index pattern and index. I think renaming these to be plural will help reinforce the relationship, e.g. NO_DATE_FIELDS_IN_INDICES and KIBANA-NO_DATE_FIELDS_IN_INDICES.

<div class="form-group time-and-pattern">
<label>
<input
data-test-subj="createIndexPatternIsTimeBasedCheckBox"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to update the functional tests to remove references to this element.

: undefined;
let timeFieldName;
if ((this.newIndexPattern.timeField !== TIME_FILTER_FIELD_OPTIONS.NO_DATE_FIELD_SELECTED)
&& (this.newIndexPattern.timeField !== TIME_FILTER_FIELD_OPTIONS.NO_DATE_FIELDS_IN_INDEX)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be reduced to:

![
  TIME_FILTER_FIELD_OPTIONS.NO_DATE_FIELD_SELECTED,
  TIME_FILTER_FIELD_OPTIONS.NO_DATE_FIELDS_IN_INDEX
].includes(this.newIndexPattern.timeField)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I considered something like that but I find it less readable. In particular, I found the .includes relationship to be inverted (in terms of readability).

I'd be fine with shortening this if we could express this in reverse, so something like (pseudocode):

!this.newIndexPattern.timeField.isOneOf([ ... ])

But I don't think there's any way to do that, either in JS itself or using a helper library.

So I'd prefer to leave it the way it-is for added readability.

If you strongly disagree, we can get a third person to break the tie.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's all good, I don't feel very strongly about this.

@ycombinator
Copy link
Contributor Author

@cjcenizal This is ready for review again, based on your feedback. I still need to implement the spinner though, so if you just want to wait till that's done, that's cool too.

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for making those UI changes.

@ycombinator
Copy link
Contributor Author

@cjcenizal On second thought, I'm going to tackle the spinner as a separate PR, since there's a neat little separate issue for it that specs it out well already: #10439.

@rhoboat
Copy link

rhoboat commented Apr 25, 2017

@cjcenizal @ycombinator Just being a ceiling cat here, but in the gif that CJ posted, I couldn't tell that the text The indices which match this index pattern don't contain any time fields. appeared below as a message corresponding to the change in the input box. Maybe flashing a background color highlight that fades after a second would help draw attention?

Copy link
Contributor

@w33ble w33ble left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple small things, up to you if you want to make the changes. lgtm.

@@ -63,13 +53,16 @@
</label>
<select
data-test-subj="createIndexPatternTimeFieldSelect"
ng-disabled="controller.fetchFieldsError"
ng-disabled="controller.fetchFieldsError || (controller.dateFields.length === 1)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be clearer to use !controller.doesIndexHaveDateFields here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, that was introduced later and should definitely be used here. Thanks!

}

this.dateFields = results.dateFields || [];
this.doesIndexHaveDateFields = this.dateFields.length > 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.indexHasDateFields fits the pattern better, and reads better when used for conditionals.

@cjcenizal
Copy link
Contributor

@archanid Good point! I think it's better to address that as part of our new notifications designs. Would you mind chiming in with your thoughts and cross-linking on #8194 ?

@ycombinator
Copy link
Contributor Author

Tests are failing but they are unrelated to the changes in this PR. Merging...

@ycombinator ycombinator merged commit 02787e3 into elastic:master Apr 26, 2017
ycombinator added a commit that referenced this pull request Apr 26, 2017
* Removing "Index contains time-based events" checkbox

* Rename label

* Adding "No Time Filter field" to time field select list

* Using translation for i18n and consistency with label on create form

* More useful verbiage

* Updating copy

* Adding help block below select for added clarity

* Removing functional tests that used time-based events checkbox

* s/INDEX/INDICES/ to be reflect reality

* Fixing logic error

* Updating functional test to match new behavior

* Use controller property instead of inline expression

* More readable variable name
@ycombinator
Copy link
Contributor Author

Backported to:

@ycombinator ycombinator deleted the mgmt/kibana/index-patterns/create/default-time-filter-field branch April 26, 2017 23:27
spalger added a commit to spalger/kibana that referenced this pull request May 25, 2017
In elastic#11409 we added two new possible options to the "Time Filter field name" drop down. These options display a message that "there are no time fields" or "I don't want to use the time filter". These new options were added to the `controller.timeFields` array, which is where the other options were, but they don't actually represent time fields.

This change updates `controller.timeFields` to instead be a list of options, specifically created to populate the select box in the view. They are now stored at `controller.timeFieldOptions` and each option has a `display` property (which will be rendered in the view) and optionally a `fieldName` property. The selected option, `controller.formValues.timeFieldOption` is checked for a `fieldName` property when the Index Pattern is created.
spalger added a commit that referenced this pull request May 26, 2017
* [indexPatterns/create] timeFields -> timeFieldOptions

In #11409 we added two new possible options to the "Time Filter field name" drop down. These options display a message that "there are no time fields" or "I don't want to use the time filter". These new options were added to the `controller.timeFields` array, which is where the other options were, but they don't actually represent time fields.

This change updates `controller.timeFields` to instead be a list of options, specifically created to populate the select box in the view. They are now stored at `controller.timeFieldOptions` and each option has a `display` property (which will be rendered in the view) and optionally a `fieldName` property. The selected option, `controller.formValues.timeFieldOption` is checked for a `fieldName` property when the Index Pattern is created.

* [indexPatterns/create] populate `this.timeFieldOptions`

* [indexPatterns/create] unify fetching and errors for timeFieldOptions

* [indexPatterns/create] refreshFieldList() -> refreshTimeFieldOptions()

* [indexPatterns/create] unify "No time fields available" messages

* [indexPatterns/create] disable the timeField select when loading

* [indexPatterns/create] only require a time field is there are options

Doing this prevents the time field from rendering as invalid when there is no matching index pattern (which has it's own error display) and when the fields are loading

* [indexPatterns/create] isolate side-effects

* [indexPatterns/create] let refreshTimeFieldOptions() control model

* [indexPatterns/create] attempt to make default field selection clearer

* [indexPatterns/create] explain why we set timeFieldOption

* [indexPatterns/create] make timeFieldName `undefined` when not set

* [indexPatterns/create] Don't pass two args to .then() unless needed

* 💅
spalger added a commit that referenced this pull request May 26, 2017
* [indexPatterns/create] timeFields -> timeFieldOptions

In #11409 we added two new possible options to the "Time Filter field name" drop down. These options display a message that "there are no time fields" or "I don't want to use the time filter". These new options were added to the `controller.timeFields` array, which is where the other options were, but they don't actually represent time fields.

This change updates `controller.timeFields` to instead be a list of options, specifically created to populate the select box in the view. They are now stored at `controller.timeFieldOptions` and each option has a `display` property (which will be rendered in the view) and optionally a `fieldName` property. The selected option, `controller.formValues.timeFieldOption` is checked for a `fieldName` property when the Index Pattern is created.

* [indexPatterns/create] populate `this.timeFieldOptions`

* [indexPatterns/create] unify fetching and errors for timeFieldOptions

* [indexPatterns/create] refreshFieldList() -> refreshTimeFieldOptions()

* [indexPatterns/create] unify "No time fields available" messages

* [indexPatterns/create] disable the timeField select when loading

* [indexPatterns/create] only require a time field is there are options

Doing this prevents the time field from rendering as invalid when there is no matching index pattern (which has it's own error display) and when the fields are loading

* [indexPatterns/create] isolate side-effects

* [indexPatterns/create] let refreshTimeFieldOptions() control model

* [indexPatterns/create] attempt to make default field selection clearer

* [indexPatterns/create] explain why we set timeFieldOption

* [indexPatterns/create] make timeFieldName `undefined` when not set

* [indexPatterns/create] Don't pass two args to .then() unless needed

* 💅

(cherry picked from commit 801549c)
snide pushed a commit to snide/kibana that referenced this pull request May 30, 2017
* [indexPatterns/create] timeFields -> timeFieldOptions

In elastic#11409 we added two new possible options to the "Time Filter field name" drop down. These options display a message that "there are no time fields" or "I don't want to use the time filter". These new options were added to the `controller.timeFields` array, which is where the other options were, but they don't actually represent time fields.

This change updates `controller.timeFields` to instead be a list of options, specifically created to populate the select box in the view. They are now stored at `controller.timeFieldOptions` and each option has a `display` property (which will be rendered in the view) and optionally a `fieldName` property. The selected option, `controller.formValues.timeFieldOption` is checked for a `fieldName` property when the Index Pattern is created.

* [indexPatterns/create] populate `this.timeFieldOptions`

* [indexPatterns/create] unify fetching and errors for timeFieldOptions

* [indexPatterns/create] refreshFieldList() -> refreshTimeFieldOptions()

* [indexPatterns/create] unify "No time fields available" messages

* [indexPatterns/create] disable the timeField select when loading

* [indexPatterns/create] only require a time field is there are options

Doing this prevents the time field from rendering as invalid when there is no matching index pattern (which has it's own error display) and when the fields are loading

* [indexPatterns/create] isolate side-effects

* [indexPatterns/create] let refreshTimeFieldOptions() control model

* [indexPatterns/create] attempt to make default field selection clearer

* [indexPatterns/create] explain why we set timeFieldOption

* [indexPatterns/create] make timeFieldName `undefined` when not set

* [indexPatterns/create] Don't pass two args to .then() unless needed

* 💅
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants