Improvements on the Search page

[tkrieck]

Hey everyone, while researching XWiki I found some minor problems in the main Search page. Stuff like many technical terms being used, content misalignment on the filters, lack of default components where one would be a better fit and other minor ones.
So I would like to make a proposal with some minor improvements. These are filled under the issue Loading...

Context:

The improvements I would like to propose are listed in the image below. Explanations follows after that.

Annotated changes:

Sorting selection via pop over

The current way of sorting is efficient, but waste space. We could improve it by showing it under a pop over, with the categories of sorting separated by a line and each option clearly stating its use.
To make a selection we would have two clicks of interaction (one to open, another to select) but it would be consistent and a lot of space would be saved. This version also scales better in case we have more sorting options in the future.

With the horizontal space saved we can improve the vertical space occupation by placing the visibility control of elements on the same line.
Note that I changed the elements to have the proper checkbox looks, for better understanding of its use.

Technical terms

Words like, “facets”, “Rendered Document Content” and “Raw Document Content” are very developer oriented so I am suggesting to change them to “Filters” “Document Content” and “Document Code”

Filter box

Here the changes are mostly for better visual communication and standardization. Titles and content were differentiated a little bit.
The open/close arrow was moved to the beginning of the line, so the user can see better that it can be opened.
Numbers were right aligned and visually highlighted. The alignment issues I believe is a bug in the current version.
Also, the Reset and Collapse options at the top were given the standard “link” color to better communicate the action.

WDYT?

[jgilmore]

+1 this looks great!

[CharpentierLucas]

@tkrieck

Annotated changes:

• Arrows left aligned : -0, see XWIKI-14873: Accordeon in the Administration misses an indicator to show they are expandable by Sereza7 · Pull Request #2774 · xwiki/xwiki-platform · GitHub, I conducted a quick review of how we use carets on the left in XWiki platform. On your example we can see that the breadcrumb have the carets on the right of the items, which makes it less consistent. In my opinion it’s not really worth it to update it. There’s always the cost of changing user habits and I don’t think the advantage described here is enough to balance out this cost. (implementation tip: we don’t have a caret-right icon so I recommend to rotate the caret down ) This would make things easier for the sub category carets (e.g. those in file-type) where we also want to display the amount of items on the right…
• +1 for others changes overall

@tkrieck

Sorting selection via pop over

Is the pop over wording important? Usually when I describe these elements I use dropdown. I think this element should align in terms of functionality and style with other dropdowns. Do you have a reason why this shouldn’t react and/or look like the moreAction dropdown (see picture below) for example? It might be a bit of a nitpick, but I think it’s important to know if we’re talking about the same thing and make it clear in our documentation and code down the line

@tkrieck

Words like, “facets”, “Rendered Document Content” and “Raw Document Content” are very developer oriented so I am suggesting to change them to “Filters” “Document Content” and “Document Code”

We have multiple kinds of filters in XWiki. In my opinion, we should add precision to Filter at least in some places so that they are not mistaken with Notification filters

@tkrieck

Filter box

Looking good
Note that there’s a couple places where things get a bit complicated in this search filter selector. From what I could remember, the date filters have a custom date option with a date picker. For implementation we need to make sure those date pickers are still somewhat in line with the new visuals.

---

Thank you for this proposal @tkrieck !

[tkrieck]

@CharpentierLucas

Arrows left aligned : -0, see

Not a problem, I adjusted it in my mockups

@CharpentierLucas

Is the pop over wording important?

Not really, is a habit I have from working on other projects. We can standardize on dropdown without a problem.

@CharpentierLucas

We have multiple kinds of filters in XWiki. In my opinion, we should add precision to Filter at least in some places so that they are not mistaken with Notification filters

Even with the same wording, the context is different. Is there a scenario in which notification filters and search filters would be used interchangeably?

@CharpentierLucas

Note that there’s a couple places where things get a bit complicated in this search filter selector. From what I could remember, the date filters have a custom date option with a date picker.

Noted , I will do a mockup with different filters to test them visually.

[tkrieck]

Here’s a version with more filter types mocked up and the accordion arrows adjusted.

[amilica]

Hellooo everyone! Just read the proposal and it’s really, really good, thank you for working on this, Thiago!

Some ideas

I tried to use what you’ve done to include my ideas and suggestions explained below in this mock-up:

Explanations

Sooo, the ideas… they may or may not clash a bit with your redesign. They are more like suggestions:

Facets

The Facets button just collapses or extends the Filters Panel, right? Why not have directly on the Filters Panel? If it does anything else, let me know, it’s possible that I miss something.

Sorting

I actually liked the way I switched between sorting types, it made the search just a tiny bit quicker; I could check what kind of results each type of sorting would give me and then commit to the most relevant one.

I understand that the dropdown would be much more scalable and, UI wise, it’s just much better. UX wise, I’m not completely sure.

I think there is a way of saving space AND not choosing a dropdown.

Results spacing

I feel results are pretty close to each other and the info doesn’t breathe in the page (if that makes sense), both in the initial version and in your redesign.

I propose:

• having a bit more space between each result
• having a bit more spave between the main info of the page and the highlights

This space would extend the page downwards, but users don’t mind scrolling a bit more if the page feels lighter.

Filter panel coloring

I feel like this panel has too many shades of gray and it makes it feel old-ish, too detailed, making the page feel a bit overwhelming.

We can have a white background and make use of bold to highlight the collapsed filters’ headers.

It would all look cleaner this way.

Pagination

The current pagination looks like it could use a revamp. Maybe place the current page in the middle of the two arrows.

Last editor picture

It’d be a nice detail to have the picture of the last editor/modifier in the result. Makes the knowledge feel more human and, also, makes it easier for people in big companies/organizations to identify knowledge by faces they know.

Let me know what you think about all of this whenever you get the time

[Wardenburg]

+1 for these cool ideas!

I’d like to add that when the search page is added to say a home page using
{{include reference=“Main.Search” /}} that filtering causes duplicates of the rest of the page to load.

I’m not sure where this comes from (or of it’s intentional behavior when using the include macro) but potentially warrants a fix!

[tkrieck]

Hi @amilica thank you very much for your considerations!

@amilica

Facets

The Facets button just collapses or extends the Filters Panel, right? Why not have directly on the Filters Panel? If it does anything else, let me know, it’s possible that I miss something.

It hides and show it entirely. In this case I think it’s better to keep it hiding because when collapsing a significant interface element still is visible and takes a lot of horizontal space. This can lead to line breaking in small screens. But I agree that we could have the control directly on the panel, I would just use an X to close the panel, to get the panel back there would be a new control described below. What do you think?

@amilica

Sorting

I actually liked the way I switched between sorting types, it made the search just a tiny bit quicker; I could check what kind of results each type of sorting would give me and then commit to the most relevant one.

We could invert the logic and use the dropdown on secondary controls, like the visualization options (show filters and highlights). That way, we could have almost the entire line for sorting and a new “config” icon to choose what is available in the interface.

@amilica

Results spacing

I feel results are pretty close to each other and the info doesn’t breathe in the page (if that makes sense), both in the initial version and in your redesign.

This is to keep up with XWiki philosophy of giving user content priority in space. That’s why I inserted a divider line between results, it keeps search results separated but still condensed. We can tweak it, but it will be a balancing act between screen space and content separation.

@amilica

Filter panel coloring

I feel like this panel has too many shades of gray and it makes it feel old-ish, too detailed, making the page feel a bit overwhelming.

We can have a white background and make use of bold to highlight the collapsed filters’ headers.

It would all look cleaner this way.

We could go all in and remove all borders altogether, use bold text like you said and keep just one shade of gray on panel titles. It would make the panel feels lighters and I think it still keeps content separation nicely.

@amilica

Pagination

The current pagination looks like it could use a revamp. Maybe place the current page in the middle of the two arrows.

Agreed, but IMO it requires a proposal on itself because it would change the pagination layout on the whole system. I will keep this in mind for a roadmap item.

@amilica

Last editor picture

It’d be a nice detail to have the picture of the last editor/modifier in the result. Makes the knowledge feel more human and, also, makes it easier for people in big companies/organizations to identify knowledge by faces they know.

That’s a very good idea, and we already have a precedent on this on the notifications. However, placing the avatar in the middle of the sentence fells weird to me because it is breaking my reading flow. This can be completely personal but how about we place it at the end, so the user can read the line “last modified by User Name” in its entirety, then comes the avatar and then at the end comes the supplementary info of date and time.

Here is an updated mockup with everything discussed in context:

[amilica]

This looks really good! I agree with all of your points. The filter panel looks even better like this and the configuration icon for highlights and filters feels like a good idea.

I was debating in my mind if maybe it would be good for the dropdown to open on hover on the config icon instead of clicking on the icon. WDYT?

[tkrieck]

@amilica

I was debating in my mind if maybe it would be good for the dropdown to open on hover on the config icon instead of clicking on the icon. WDYT?

While it would be quicker to open, it would also require the user to have good motor control on the mouse, so it can impact accessibility. Also, other elements on XWiki UI, that shares similar functionality, use the click as a standard, like the “more” button on each page.

[amilica]

Ah, good thinking, you’re right! Thanks!

[vmassol]

Global comment: LGTM! Thanks

@tkrieck

Technical terms

Words like, “facets”, “Rendered Document Content” and “Raw Document Content” are very developer oriented so I am suggesting to change them to “Filters” “Document Content” and “Document Code”

I’m not sure for Facets. We use this terminology in the code and on xwiki.org. Users can customize them and add new facets. I think it could cause confusion if we were to use different terminology for the same concept in the XWiki UI and on xwiki.org.

@amilica

Last editor picture

It’d be a nice detail to have the picture of the last editor/modifier in the result. Makes the knowledge feel more human and, also, makes it easier for people in big companies/organizations to identify knowledge by faces they know.

I’m not a big fan of this (very close to -1) as I don’t see what it brings but the downside is quite obvious to me: it attracts the eye on something that is not relevant to the task at hand. We need the user to focus on the matched text instead.

Why would users want to see the last authors of documents when they search for something? What would make sense would be for them to see the author of the matched words, but that’s hard to implement Right now if they need to see the author for some reason (or the creator, or the blame view, etc) they can navigate to the document. I don’t feel the last author is important enough to be displayed directly in the results.

[tkrieck]

@vmassol

I’m not sure for Facets. We use this terminology in the code and on xwiki.org. Users can customize them and add new facets. I think it could cause confusion if we were to use different terminology for the same concept in the XWiki UI and on xwiki.org.

When you mention XWiki.org are you talking about help texts and descriptions about Facets?

On the current UI there’s already a help text explaining that this area is for filters. By naming the label “facets” to “filters” we can make it easier for the user to make the connection between the two.

.

Maybe we could try to use a parenthesis with the alternate label like “Facets (filter)” or the other way around, “Filters (facets)”.

[vmassol]

@tkrieck

When you mention XWiki.org are you talking about help texts and descriptions about Facets?

I’m referring to all the places where we use the term Facets, see https://www.xwiki.org/xwiki/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_type=DOCUMENT&f_locale=en&f_locale=&text=facet

But also in the code: Code search results · GitHub

[tkrieck]

Ah, got it now. Let’s stay with facets then, especially because of the release notes and user facing documentation. I can see that the word is hinted with descriptive text already so it’s not too bad.

I will update the proposal accordingly.

[Jan-Paul-Kleijn]

Coincidentally I was busy optimizing the search page for my wiki and I was pleasantly surprised to see that this has been picked up officially. Great first mockup @tkrieck, a true improvement if I may say so. If I may add this: Perhaps it would be a better choice to have the whole facet description as a control element, not just the caret.

@CharpentierLucas

On your example we can see that the breadcrumb have the carets on the right of the items, which makes it less consistent.

I disagree, the breadcrumb is a horizontal menu, the search menu is vertical, just like the document tree where the carets are also on the left. So, not to be rude or something but the way I see it is that what you imply is the exact opposite of consistency.

To go deeper into the rabbit hole, the caret in this case is a visual hint of what this control element does. Used horizontally (be it in a list or not) it is preferred to place it on the right side of the control element (just like for example the external link hint or footnote indications). The reason for this is that if a single line of text (or a horizontal list) starts with a control element that has a visual hint, the line does not start with the visual hint. Contrarily, the ordered and unordered lists start with the bullits, dashes, numbers, etc. This because it is a vertical list of lines of text (or control elements in this case).
This all is rooted in the fact that on this side of the planet we read text from left to right.

The practical side of approaching it this way is that when in the off chance you need the space on the right for another, different type of visual hint, it is right there waiting to be made use of. So in this way you keep the different types of visual hints neatly separated from each other.

And yes, I can make people go to sleep by boring them with detail, call it one of my superpowers.

I actually liked the way I switched between sorting types, it made the search just a tiny bit quicker; I could check what kind of results each type of sorting would give me and then commit to the most relevant one.
I understand that the dropdown would be much more scalable and, UI wise, it’s just much better. UX wise, I’m not completely sure.

@amilica, I personally think it is more wise to put the sorting types in a dropdown, this works better when the screen gets less wide because of the use of panels or just simply a portrait view screen (as you also stated). It gives the creative xwiki builders more options. For example to keep the whole wikiwide wiki content part (try to say that 3 times fast) the same size. This adds to the overall feel of consistency and can be important for the wiki pages that contain the actual content and the format of this content. In my case I want to keep the number of words per line between 15-20 words. It makes for better reading for my audience. APA advises even shorter lines (50-75 characters) but they state this on a page with about 15-20 words per line (75-100 characters), ironically enough . So this means that I want to make the content part of the page less wide by using a wide right panel, throughout the whole wiki. I also want to keep the margins left and right at a decent distance from the panels without creating an awful lot of white space on the right.
But besides the freedom it creates, a dropdown is the normal “go-to” solution throughout the internet (even on this forum). So why deviate from this with the XWiki search?

About the facet/filter panel coloring, I am 100% with you on that. I would even take it a step further. Because you proposed the use of bold type to highlight the collapsed headers, why not remove the horizontal rules between the filters? We eventually have arrived at a vertical list of control elements and the indentation of their options finishes the list format so horizontal rules seem awkward to me. I think that they’re no longer neccessary. I have the same opinion on the background colouring of the facets/filters.

Anyway, I hope I can see the new design soon. Thanks and have a nice day!

[tkrieck]

Thanks everyone who replied so far. It seems we have an agreement on the general idea, with some improvements proposed regarding the visual aspect.

I will update my proposal with these ideas and start with a template for implementation.

I am marking this as a solution, but you can still submit your opinions and ideas.

Thanks!

[mflorea]

@tkrieck

Technical terms

Words like, “facets”, “Rendered Document Content” and “Raw Document Content” are very developer oriented so I am suggesting to change them to “Filters” “Document Content” and “Document Code”

I know the party is over :), but I just wanted to mention that I find “Document Content” and “Document Code” confusing.

I don’t know any other place where we use “Document code” to refer to the document source content. I may be biased, but for me “code” means either some number / string used to secure access or some instructions written in some programming language. The rendered content of a wiki page is different from the raw (source) content even if there are no scripts (code) used.

As for “Document content”, my guess is that half of the users (most of the simple users) will understand this to mean what you see when you view the document (i.e. the rendered content) while the other half (most of the advanced users) will understand “the source content”, i.e. what you see when you edit with the wiki editor. So I’m not convinced that using “Document Content” makes things more clear.

Thanks,
Marius