Join GitHub today
Reordering fields to enable smoother path through form #9991
As suggested in the issue:
I started off this PR by trying exactly this suggestion. Turns out there are parts of this form that appear and disappear depending on various checkbox states so this simple move didn't feel sufficient to me. So I took a step back and tried my best to take a more principled approach the organization/flow of fields in this form.
The new ordering of fields in this PR tries to follow these principles:
Also, when "Index contains time-based events" is checked, the "Time-field name" field is always shown. The field is disabled (used to be hidden) when Kibana in unable to retrieve a mapping for the index pattern. IMO, this makes the form less "jittery" by not hiding and showing elements.
In other words, the interaction with the form is smooth and the flow of making various choices is linear from the top to bottom until the user chooses the deprecated option. At that point the form gets re-jiggered a bit which might be a bit jarring to the user (but might be acceptable given the user is choosing the deprecated option anyway?).
If either @cjcenizal or @alt74 have some time to spare (LOL) I'd love their feedback on this PR. One consideration: At this point I don't want to completely overhaul the current UX, but more just tweak it to make it better than the status quo. A more holistic overhaul to this UX probably needs to happen, but could wait till later.
I think you're approaching this problem with the right set of principles in mind! As I explored this UX, I encountered a few minor issues and one larger issue.
"Missing index" error reporting
The message "Unable to fetch mapping. Do you have indices matching the pattern?" is too disconnected from the source of the error (the bad index pattern field). I think the solution is:
Disabled inputs shouldn't have error state
If you get the Time-field Name input into an error state by focusing it and then blurring without selecting an option, it takes on an error state. This is confusing for the user because s/he's being told to fix a problem, but is then prevented from doing so. When blurring, we should reset the error states to avoid this from happening.
Clarify "Do not expand index pattern" explanatory text
When the option is checked, two very similar messages are visible, but one is treated as a "notification" and the other is just regular text. When I read these two messages, it's hard for me to figure out which one applies to the checked state. I think this is partially because a) the notification treatment obscures the fact that the two messages are two sides of the same coin and b) the second message is broken up into two paragraphs, and the second paragraph makes a statement that doesn't apply to the checked state but doesn't make this clear.
I think we can fix this by removing the notification treatment, and adjusting the copy to clearly identify what happens when the option is selected and not selected. Let's change this copy and keep all of it visible regardless of whether the option is checked or not:
FYI, if you or anyone decides to massage this copy further, this comment #8128 (comment) has some suggestions on how it should be rephrased.
Split the form up into three forms
I think we can break this form up into three distinct forms, to reduce its complexity from a UI perspective.
It looks like a user has three ways to create an index pattern:
If we got rid of the "Index contains time-based events" and "Use event times to create index names" checkboxes, and replaced them with tabs, then we could surface each of the above forms individually. This could also make the logic within this view a bit simpler.
I actually think this reordering is a step forward already.
The only thing that I also noticed what @cjcenizal mentioned, was the error-outlining of unused input. e.g.:
It comes across as a little strange.
As for @cjcenizal's suggestion to split up in 3 forms, that seems to be like a larger effort. Note that that would also require updating all the tutorials/getting started doc, something I think you could get away with if we just keep it at this reordering.
Wow @cjcenizal, amazing feedback. I agree that splitting this into 3 forms to reflect the 3 possible ways of index creation is the best approach here.
However, I also agree with @thomasneirynck that this PR may not be the place to tackle that change — not just because it's a larger effort but also because I suspect the entire index creation / getting started with data flow needs a rethink (@skearns, I know you've mentioned this before so any thoughts here?).
I will fix the error highlighting on the disabled form field now.
referenced this pull request
Jan 23, 2017
I have the makelogs-created
@ycombinator First you create the error by clicking the select dropdown and then deselecting it without choosing an option. It should now take on an error state. Then either change the index pattern to an invalid one (in my case) or check "Use time events to create index names" (Thomas's case).