Missing time picker when query input is focused could be misleading

[bhavyarm]

Kibana version: 7.9.0 BC9

Elasticsearch version: 7.9.0 BC9

Server OS version: darwin_x86_64

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from staging

Describe the bug: If user enters a query and there are no results for that query in that particular time range - Kibana displays extend your time range but doesn't display the timepicker unless user clicks out of the search bar. This is very confusing.

Please note this is a regression from 7.8.1

Steps to reproduce:

1. use kibana sample ecommerce data and ensure your timerange is default (last 15 mins)
2. type the query in the search bar customer_first_name.keyword :"Wilhemina St." and enter - there are no results and kibana displays extend your time range message in discover but there is no timepicker display anywhere
3. User has to click outside of query bar for the timepicker to appear

Expected behavior: When there are no results - please let the user know there is a time picker when the focus is in search bar

Screenshots (if relevant):

Other:
#75289

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[bhavyarm]

I learnt that this was intentional from @kertal and @flash1293 because this PR went in - #70140 but Its not accounting for user experience when there are no results. We need to tell the user there is a timepicker when the focus is in searchbar? Thanks!

[kertal]

FYI: @snide

[LeeDr]

I agree that this is pretty bad. It really needs to show the timepicker without the user needing to click outside the query bar.

[Dosant]

I also was misled by this a couple times.

@snide, maybe we could come up with some super minimal collapsed calendar state? It shouldn't occupy much space and on interaction it would expand into a full calendar?
e.g.:

cc @elastic/kibana-design

[Dosant]

bump: one more concerned feedback: #93366

[Dosant]

@elastic/kibana-design, @snide, could you please take another look at this issue 🙏

One suggestion I had is to try a collapsed representation of a calendar: #75289 (comment)

There are also some implementation glitches like #92040 that I am trying to address in #94148, but maybe the right way forward here is re-reviewing the UX

[ryankeairns]

@Dosant I am +1 for trying the calendar button. The UX for that is not totally clear to me, but I presume it would focus the larger time picker input and/or open the popover while reverting the default layout (i.e. shorter query input; full date picker UI).

It would be helpful to try this out. Would you mind putting this on a branch/PR where we can iterate on the button a bit?

[cchaos]

Can we hold off any making any changes to this global component? We're already facing a possible redesign (including better UX) of the whole thing and I'd like to limit the number of changes we put to the user. It may be a few more release cycles and possibly not til 8.0, but I think it's better to tackle the whole thing than stopgaps. We'll obviously keep this point in mind during the redesign too.

[LeeDr]

I don't like a constantly changing timepicker either. But I really don't like the current state where it's just gone. I'm +1 for making a minor change so at least there's a clue that you can click somewhere to see the timepicker.

If the redesign was going to be in 7.14, we could maybe wait for it. But if we're talking possibly 8.0, I really think we need a short-term fix.

[cchaos]

Have we been getting any specific customer complaints about this? Or any other data that shows that this is a high priority issue? I want to ensure we're actually tackling a known problem and not an assumed problem.

[LeeDr]

My comment was based purely on my own experience using recent versions of Discover. Primarily in kibana-stats.

[Dosant]

@cchaos, I will hold off doing any intermediate changes.
From outside Kibana, I've seen this feedback: #93366
Personally, I also stumble into this from time to time.

[cchaos]

Yeah we're actively working on a full redesign. But we'll need time for user testing and all that which is why it will be a while. But I'm really hoping the final solution will be better than this stop gap.

[LeeDr]

@cchaos I think this was fixed in 7.14.0 ? I'm not seeing the problem now. If you know, can you reference the PR and close this?

[cchaos]

Nothing has actually changed in that component. It still behaves as indicated in the issue summary. But if it no longer feel like a bug I'm happy to close this.

[bhavyarm]

unfortunately this still feels like a bug. This is on latest snapshot of 7.15 Thanks!

[wayneseymour]

pls fix! so annoying! ...sorry I'm in an emotional mood lol

[LeeDr]

@cchaos we're approaching 8.0.0-beta1 FF. Do we have a plan for this?

[rashmivkulkarni]

This is critical, we need a fix!

[cchaos]

No, sorry, there's been no work done on this priorities being what they are. I was really hoping we'd have tackled this by 8.0, but have lacked in real solutions/engineering support.

@ryankeairns Do you have anyone that might be able to find a quick solution for this? I can try to help with implementation but it will take some time to come up with a solution that both solves this and doesn't remove the original fix from #70140.

[ryankeairns]

No, sorry, there's been no work done on this priorities being what they are. I was really hoping we'd have tackled this by 8.0, but have lacked in real solutions/engineering support.

@ryankeairns Do you have anyone that might be able to find a quick solution for this? I can try to help with implementation but it will take some time to come up with a solution that both solves this and doesn't remove the original fix from #70140.

I will discuss with the team and so who can help and when.

[MichaelMarcialis]

For the sake of applying a short-term solution, could a fix be as simple as removing the horizontal expansion of the query input on focus, but retaining the vertical expansion of the input when text exceeds the width of the input (i.e. breaks a line)? Doing so would stop the query input from covering the date picker, but still provide at least some comfort to folks crafting very large queries (per the original request). Thoughts?

CCing @randomuserid.

[lukasolson]

This seems related: #124062

If we were able to make the text a link that actually opened the date picker, I think this would be ideal.

[cchaos]

In #128401, we've updated this pattern to not hide the date picker completely, but collapses it just to the point of seeing the main calendar button that opens the quick menu.

[stratoula]

As Caroline mentions, I think that new design will fix this confusion. Are you ok with it @LeeDr @bhavyarm ? In order to close it when the PR is merged in main.

[LeeDr]

Yes. I think that will resolve the issue. Thanks!