Related to #61657 and #65222
Add support for searching SOs across all spaces user has access to in a single query.
joshdover
All 6 comments
Pinging @elastic/kibana-platform (Team:Platform)
elasticmachine
on 2 Jun 2020
Pinging @elastic/kibana-core-ui (Team:Core UI)
elasticmachine
on 2 Jun 2020
pgayvallet
on 2 Jun 2020
@ryankeairns we should probably discuss more during our next planning sync, but I'd argue that we may want more granular search (https://github.com/elastic/kibana/issues/72680) before expanding to spaces. This will also help us hide (or remove) the feature directory.
alexfrancoeur
on 1 Sep 2020
@ryankeairns we should probably discuss more during our next planning sync, but I'd argue that we may want more granular search (#72680) before expanding to spaces. This will also help us hide (or remove) the feature directory.
+1 to that approach, having played with this a bit I only wish it had more depth of content :)
ryankeairns
on 2 Sep 2020
With the proposed designs for adding tags to the search UI, we've arrived at needing to reconsider the UX for cross-space search. The early designs of navigational search used the right end of the row to convey the Space as follows:
Early design
Evolving design with tags
As search has evolved organically, tags - and their use in the new search syntax (e.g. tag:mytag) - have arrived before cross-space capabilities. Through this evolution, we're also seeing that mixing results from multiple spaces generates interaction complexities and/or an increase in the sheer volume of results. The main takeaway is that it seems we're heading down a path where we're trying to do too much and risk losing the essence of what the search UI currently provides - simple, quick navigation.
Taking that into consideration, we're proposing moving forward displaying tags at the right end of the row and exploring alternatives for the Spaces UX. A number of initial ideas were generated, all of which leave us feeling confident that we can arrive at an alternative that won't be hindered by our decision for tags.
Some of those ideas include (non-mutually exclusive):
- Moving things such as cross-space search to a dedicated, advanced search page
- Adding
space:myspacenameto the search syntax - Display indicators where an item may exist in multiple Spaces (we're reserving the icon space on the left, just in case)
- Consider secondary actions for opening a focused item in the not-current Space
- Provide an advanced setting to toggle cross-space search
The good news is we have options. In the near to medium term, the additional search syntax may cover most of the use case.
cc:/ @MichaelMarcialis @myasonik
ryankeairns
on 20 Nov 2020
Related issues
LukeMathWalker
路
3Comments
tbragin
路
3Comments
spalger
路
3Comments
mark54g
路
3Comments
stacey-gammon
路
3Comments
Most helpful comment
With the proposed designs for adding tags to the search UI, we've arrived at needing to reconsider the UX for cross-space search. The early designs of navigational search used the right end of the row to convey the Space as follows:
Early design
Evolving design with tags
As search has evolved organically, tags - and their use in the new search syntax (e.g. tag:mytag) - have arrived before cross-space capabilities. Through this evolution, we're also seeing that mixing results from multiple spaces generates interaction complexities and/or an increase in the sheer volume of results. The main takeaway is that it seems we're heading down a path where we're trying to do too much and risk losing the essence of what the search UI currently provides - simple, quick navigation.
Taking that into consideration, we're proposing moving forward displaying tags at the right end of the row and exploring alternatives for the Spaces UX. A number of initial ideas were generated, all of which leave us feeling confident that we can arrive at an alternative that won't be hindered by our decision for tags.
Some of those ideas include (non-mutually exclusive):
space:myspacenameto the search syntaxThe good news is we have options. In the near to medium term, the additional search syntax may cover most of the use case.
cc:/ @MichaelMarcialis @myasonik