About the X for hiding facets, I decided to not implement it and just keep using the checkbox to control the state of visibility of facets, just like highlights.
About the facet vocabulary, I worded three translations to talk about “filters” rather than facets. I only kept the “facet” word at the very end of the updated description.
The interest point here is the few texts in the top right, but don’t hesitate to share feeback about the other changes to the UI
I had to improvize a bit for the “highlight all matches” button, AFAICS you didn’t cover it in your redesign. It was styled as a link before, but clicking it triggers an action, not navigation, so IMO a button is more fitting. Since I went with the “primary” color instead of the discreete grey of the “default” color, I made them as small as our standards allow.
PS: I fixed the regression that caused the ‘no language’ facet link to be blue on this screenshot.
I’m not sure if I understand, you only reworded the translation?
Since this is a support button for the user (and I guess, not used very much), I would leave it as a default and small. The primary styling makes this button clutter a lot of the UI.
One thing that perhaps it’s not the best on the new implementation is that the sorting area became a bit less useful.
The purpose of the redesign was to make it as straightforward as possible but very unobtrusive in terms of visuals, that’s why all the options were worded a bit more extensively and without borders.
This new implementation requires three clicks instead of two (open the menu, make a choice, use the sorting arrow), also the word “Title” is not very explanatory on itself.
We could choose two paths for improving it:
A - Change this version a little bit
Add “sort by” at the start of each option. In your screenshot, it would be “Sort by Title”,
Sorry for being unclear, those strings are translated, so I reworded what I could in english, and translation contributors will be able to update their own language if they want to. I avoided adding new translations and deprecating old ones, talking about facets in the language of your wiki is still better than getting an untranslated string about filters
Okay, updating it before submitting the changes in a pull request.
There were a couple issues when I tried to implement the select from your initial design:
It didn’t map one-to-one to an existing form input. This means that we’d need some extra logic to generate and map every entry to a pair of inputs (sort criterion and sort order).
The wording for the order of different sorting criteria was different. In addition, extensions and customizations can add their own sorting criteria. It would mean that they have to update somewhere to add from A to Z and from Z to A… it feels like it’s a lot of complexity for very minimal gain. In my eyes, it also felt like a lot of clutter in the option labelling and it would be okay to replace it with a simple caret button.
Note that using the principle of “even a broken clock is right twice a day”, half of the time the user will not have to perform the third click because the order is already right
After thinking about it a bit, I guess we should just introduce a few new translation keys to contain the whole string “Sort by title”, “Sort by last modification date”,… It adds a bit of work for localization contributors and extensions/customizations adding their own search options but I guess we can’t avoid it here and I believe it’s not that difficult to figure out what to update (sortby and field name translations are deprecated, now we ask for a translation named sortby.fieldname ).
Thanks for the feedback! I’ll probably ask you again on the PR directly if there’s any more changes.
Yes, this was proposed to make each option contextual to the concept being ordered and remove the interpretation of what a caret up and down might mean. Of course, I don’t know the extra steps and implementations needed on the code side, so we can leave it for further improvements .
Another course of action would be to add the “Sort by” in front of the field. In this case, we might not remove the border from the select though.
Thanks @tkrieck for proposal and upcoming improvement.
My only concern is that replacing the text Rendered document cotnent with “Document content” might confuse new XWiki users if they haven’t used XWiki before. For me from technical view, page content is the actual source code of the page, so that would be the document code field that would be next in your image. Whereas rendered document content is the textual representation of your page based on the macros, styles, etc. you added. Same for Facets word.
IMO what “Rendered” means here is not common knowledge for someone who’s not working in tech.
Document Content // Code is easier to understand for most people than Raw Document Content // Rendered Document Content. Instead of relying on technical terms, we rely on the user’s experience with the tool: Document Content is what I can see in the document (and what I see when I edit the document in WYSIWYG, which is the default edition mode). Code is what I see when I view the document Code, and what I view when I’m in an advanced edition mode (Wiki edition or Source toggle in the WYSIWYG editor).
This is a change from what was before so experienced XWiki users would most of time prefer no changes. IMO the improvement for the average new user justifies this inconsistency of the wording between versions of XWiki.
Okay, updating it before submitting the changes in a pull request.