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

"Create index pattern" wizard. #13154

Conversation

cjcenizal
Copy link
Contributor

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

create_index_pattern_wizard_loading

Searching for matching indices

create_index_pattern_wizard_searching

Submitting the new index pattern

create_index_pattern_wizard_submit

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
Copy link
Contributor Author

See additional comments: #12689 (comment)

@cjcenizal cjcenizal mentioned this pull request Jul 27, 2017
5 tasks
@cjcenizal cjcenizal force-pushed the 10438/index-pattern-creation-wizard-squashed-2 branch from faf720c to b249ea1 Compare July 27, 2017 17:34
@cjcenizal
Copy link
Contributor Author

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

@alexfrancoeur
Copy link

@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?

- Create a directive for each step in the wizard.
- Reorganize files into conventional folder structure.
- Rename files with more conventional and consistent naming patterns.
- Display indices, partial matches, exact matches.
- Add loading, empty, and success states.
- Add option to include system indices.
@cjcenizal cjcenizal force-pushed the 10438/index-pattern-creation-wizard-squashed-2 branch from b249ea1 to e273403 Compare August 3, 2017 21:48
@cjcenizal
Copy link
Contributor Author

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

@alexfrancoeur
Copy link

@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?

aug-04-2017 14-25-17

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

screen shot 2017-08-04 at 2 33 20 pm

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

screen shot 2017-08-04 at 2 36 46 pm

screen shot 2017-08-04 at 2 41 39 pm

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.

screen shot 2017-08-04 at 2 42 22 pm

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.

screen shot 2017-08-04 at 2 44 10 pm

screen shot 2017-08-04 at 2 44 26 pm

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.

screen shot 2017-08-04 at 2 57 15 pm

cc: @skearns64

@cjcenizal
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

@alexfrancoeur
Copy link

@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
Copy link
Contributor Author

cjcenizal commented Aug 10, 2017

Handing this off to #13454

@cjcenizal cjcenizal closed this Aug 10, 2017
@cjcenizal cjcenizal deleted the 10438/index-pattern-creation-wizard-squashed-2 branch August 10, 2017 22:51
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.

3 participants