QuickSearch Design Improvements

[tkrieck]

Hey everyone, currently the quick search panel has some design quirks that make it standout a little bit from the usual XWiki UI style. Stuff like the drop shadow being too strong, no border radius applied on the panel, and it also wastes space and is not mobile friendly.

With this in mind, I would like to propose a UI update to this panel. Mind you, this is only a UI update for now. We have other proposals on this that changes other aspects. Like this one from Adina and another one, from Marius

Some issues identified:

So my proposal is to make an update, mostly on CSS to get something like this:

Template

Example content

All in all, more streamlined, with lighter shadow, border radius like other elements on the interface. The Icon Theme should also be applied if possible.

The category name for each group of results was brought inline with the rest of the results, this way it is quicker for the user to follow from one field to another as they are in the same vertical.

The “Hide suggestions” was stylized like a close button on a dialog, as its behavior is the same.

The “Go to search page” was moved to the bottom of the panel. As in “none of these results interested me” so we provide a link to a more powerful feature.

Mobile View

The final looks are very close to what Marius proposed in his version, using bootstrap components. But here I am advocating more for a purely visual change initially, easier and quicker to do, but one that brings us some
usability improvements as well.

WDYT?

[gabrielc]

I honestly really like the proposed changes.

The only thing I’m somewhat uncertain of, is that in the example with content the horizontal lines separating sections don’t go across the whole width of the element. Is that intentional?

[tkrieck]

@gabrielc

The only thing I’m somewhat uncertain of, is that in the example with content the horizontal lines separating sections don’t go across the whole width of the element. Is that intentional?

It was not intentional, I’ve edited the post with the correct image. Thanks for pointing that out!

[amilica]

Looks great and it doesn’t seem that it would require a lot of coding effort to implement the changes. Thanks a lot for the proposal!

One thing that we could consider is keeping “go to search page” at the top.

I have no research to back this up, but I will suppose that most users with big wikis try to use quick search but end up clicking advanced search because quick search results are not satisfactory.

This is the case for me 99% of the time, but obviously I cannot be certain if everyone feels the same. I hope more people will let us know their opinion on this.

Other than that, maybe have:

• a bit more space around every item
• more space between sections
• having slightly more width to the whole dropdown because some pages will have unavoidable long titles

[CharpentierLucas]

@tkrieck

Hey everyone, currently the quick search panel has some design quirks that make it standout a little bit from the usual XWiki UI style. Stuff like the drop shadow being too strong, no border radius applied on the panel, and it also wastes space and is not mobile friendly.

Hello! Thanks, I got to spend time on this UI in the past for XWIKI-16140: Make quick search suggestions accessible, and it definitely needs some improvement. I would suggest that during implementation we pair these style changes with some cleanup on the semantics side, from what I can remember, the HTML generated is a bit legacy too .

@amilica

One thing that we could consider is keeping “go to search page” at the top.

I have no research to back this up, but I will suppose that most users with big wikis try to use quick search but end up clicking advanced search because quick search results are not satisfactory.

I thought the same at first, but I figured out advanced users could just submit the form (by either pressing enter on the search input or clicking the search icon next to it) to get redirected to the advanced search page. There’s already the search icon that fulfills this role here so I don’t think there’s any need to keep this link up here.
Definitely needed to be mentionned though, thank you

@amilica

having slightly more width to the whole dropdown because some pages will have unavoidable long titles

The same could be said for breadcrumbs
@tkrieck What should the behaviour be when the title gets longer than the width we’re giving it? (wrapping, ellipsis, cut out, …)
What should the behaviour be when the breadcrumb gets longer than the width we’re giving it?

Whatever the width we pick for the dropdown, it will happen and it’d be good to think beforehand about the kind of fallback we want here

---

Do you have a ticket opened about these improvements on our jira?
XWIKI-15115: Make Search Suggest use IconThemes would probably be solved by the improvements proposed here, it’d be good to link it to the ticket related to this proposal.

PS: I just saw Loading..., but we might need another issue to keep track of the implementation itself.

---

Thanks,
Lucas C.

[Simpel]

The quick search provides a lot of categories and 3 results per category. Thus we had not many successful searches. Most of the results were doubled in all the categories. So we decided to change the quick search radically. We only provide one category with an advanced search pattern showing 15 results and another category only showing 3 results focussed on user names.

With these changes I nearly find every page I’m searching for.

Top results (15):

__INPUT__ __INPUT__* *__INPUT__ *__INPUT__*
fq=type:DOCUMENT
fq=-space_exact:XWiki*
qf=property.XWiki.TagClass.tags^15.0 spaces^15.0 title^10.0 name^10.0 doccontent^2.0 objcontent^0.4 filename^0.4 attcontent^0.4 doccontentraw^0.4 author_display^0.08 creator_display^0.08 comment^0.016 attauthor_display^0.016

User names (3):

__INPUT__ __INPUT__*
fq=type:DOCUMENT
fq=class:XWiki.XWikiUsers
qf=property.XWiki.XWikiUsers.last_name^10 property.XWiki.XWikiUsers.first_name^5 name^2.5 object.XWiki.XWikiUsers
fq=wiki:xwiki

[tkrieck]

@amilica

• a bit more space around every item
• more space between sections
• having slightly more width to the whole dropdown because some pages will have unavoidable long titles

Nice ones, I adjusted the layout a little bit based on your feedback. It’s not a lot, but noticeable. I also added a line dividing the “Go to Search Page” to make it more clear that’s something else instead of a result item.

@amilica

I have no research to back this up, but I will suppose that most users with big wikis try to use quick search but end up clicking advanced search because quick search results are not satisfactory.

I did an example using this approach. For me, it feels a little bit odd, but I’ll leave this here so others can give their opinion.

Comparisson

@CharpentierLucas

@tkrieck What should the behaviour be when the title gets longer than the width we’re giving it? (wrapping, ellipsis, cut out, …)
What should the behaviour be when the breadcrumb gets longer than the width we’re giving it?

That’s a fair point to think about. I’d go with:

• Breaking the title to show the entire sentence (it can be very long). Because the search term can be anywhere inside the title
• But show a cut version of the breadcrumb. With the last page visible and the rest of the path up until the limits of the dialog, then insert an ellipsis. My reasoning for this is to give it only a general context of the item. The full path could be shown as a hint on mouse over. WDYT?
  Example:
  

@CharpentierLucas

PS: I just saw Loading…, but we might need another issue to keep track of the implementation itself.

Yes, that’s just the Jira for the proposal itself. We’ll need one (or more) for the implementation.

@Simpel

With these changes I nearly find every page I’m searching for. I can provide the two search patterns later.

Thank you for explaining your use-case! I’ll keep in mind.

[Simpel]

I would like “Go to Search Page…” at the bottom.

Btw: I updated my post above with the code we are using in the quick search.

[vmassol]

Would be nice to have @mflorea 's input on this since he worked on quick search, including a design proposal mentioned above. Thx