"Create index pattern" wizard.

[cjcenizal]

Replaces #12689.

Changes

• Create a directive for each step in the wizard.
• Reorganize files into conventional folder structure.
• Rename files with more conventional and consistent naming patterns.
• Remove all translations.
• Display indices, partial matches, exact matches.
• Add loading, empty, and success states.
• Add option to include system indices.

Changes to the UX

Loading indices

Searching for matching indices

Submitting the new index pattern

To-do later

• Implement polling for new data (and surface a spinner to show the UI is working for you).
• Fix form validation when fields are untouched.
• Convert directives into React components and add unit tests.
• Improve the cross-cluster search UX.
• Improve list of matching indices to be a table of "matching", "partially matching", and "non-matching" lists, between which the indices shuffle as the user enters the index pattern. Based on suggestions from @skearns64 and @spalger.

Feedback

From @skearns64

• The layout doesn't strongly connect the index pattern input and the search results
• Where are we inside of the app? We need to underline the “Index Patterns” tab
• We should hide the sidebar when creating a new index pattern
• The sidebar warning is visually distracting. Let’s make it clearer in location, appearance, and language. (My note: this could be replaced with an improved onboarding message).
• Let’s remove template index patterns for now and treat it as a later optimization.

From @alexfrancoeur

I feel like we're missing some sort of graphic on the new index pattern flow. There's a lot of text that I'm worried people still skip over. What are your thoughts on providing some sort of graphic that explains an index pattern. It could be small even. ES is filled with documents, documents make up multiple indices, an index pattern is used to match against all those indices. It could almost look like a flow diagram. This might be unnecessary but I'd like to see how we can visually improve the page as well

[cjcenizal]

See additional comments: #12689 (comment)

[cjcenizal]

For posterity, here is the previous get_indices.js implementation: https://github.com/elastic/kibana/pull/12689/files#diff-c46d514c03a32aa0b3f2a37d1ce2da63.

[alexfrancoeur]

@cjcenizal @chrisronline I wanted to use the current build to provide feedback and see if we can incorporate any of @alt74's designs. The PR doesn't seem to change anything in master at the moment. The create index pattern management screen looks the same to me. Is it ready to pull down?

[cjcenizal]

@alexfrancoeur I just rebased against master. It should be working now.

[alexfrancoeur]

@chrisronline some initial feedback with the current PR

There seems to be a refresh of the entire table as I type for an index pattern. Is there any way we can dynamically filter the results in the index table without doing a complete refresh?

It'd be great to show where the pattern matches the index. Any chance we can bold where it matches?

I'm struggling with how this can best work. If you look at the below screenshot, we are saying that an index pattern matches in it's current state. While the text matches the indices, the index pattern won't actually match the indices without a wildcard

What if we automatically appended a wildcard as soon as they start typing? A user could remove it if they'd like but at least the initial experience would work as expected. Otherwise, we are specifying a single index which I believe is used much less than an index pattern with a wild card (but may be wrong).

I'm not sure we want to advertise the optional ID so much. We prefer users use our unique ID. Can we add an advanced settings option here to hide it a bit? I believe this was in the original PR.

I'm not sure "Optional Time filter field name" is the best header here. Especially given the fact that making a selection here is a blocker for me moving forward. Also, the option to "not use a time filter" is pretty hidden. I wouldn't think to click into this drop down to create an index without a time filter. This is an issue with the current index pattern creation view as well.

What if we called the title "Select time field" where the dropdown provides all available options, with a checkbox that would disable this drop down and allow a user to create an index without a time field. @cjcenizal @snide I believe there is some history here for why this option is in the dropdown. Any additional info you can provide or suggestions for a better approach?

There have been a number of designs from @alt74 around the index pattern management page for K7. On the design side of things, we seem to be in agreement that this information architecture is a good approach. There are still some kinks to work out but at a high level, the single step / side by side approach is preferred. What are your thoughts around the work effort to implement for K6? I'll set aside some time early next week to discuss in more detail.

cc: @skearns64

[cjcenizal]

@alexfrancoeur To provide some context, this PR currently doesn't function properly because of a technical issue. My suggestion is that we wait for @chrisronline to solve that issue, and then assess whether there are any design problems which need to block this PR from being merged. If this design is one which can logically evolve into where we're headed with K7, then I think we should merge it, and then open up discussions about design improvements. The longer this PR is outstanding, the more likely it is to be delayed by merge conflicts, the longer we have to wait on merging, etc. creating a vicious cycle. Unless this PR creates an objectively negative user experience, I think we should merge it and iterate -- progress over perfection. 😄

[cjcenizal]

As part of this PR, we should make sure labels are properly associated with their inputs, per #12863.

[alexfrancoeur]

@cjcenizal I agree wholeheartedly with progress over perfection, there are a few items in my feedback though that I feel are blockers to the user experience. I agree, once the PR is in a working state we can revisit. Also, I'm not too concerned about the IA change from K6 ==> K7 and am happy to see this naturally evolve. I just wanted to bring it up as a discussion point.

[cjcenizal]

Handing this off to #13454