Sorry, but I had to open this issue in GitHub as I was unable to insert images using issues.joomla.org and therefore I've been unable to attach appropriate labels.

Ah, when I open an issue in the issue tracker, I can attach the labels myself? Can I also chose category there?

Regarding this RFC: I also only judge it by UX aspects, and I would also like to have the search tools in the side bar and not for one thing here and the other thing there, and so I agree.

BTW, I noticed that at "phone" display sizes, while the "Toolbar" nicely collapses in an accordion, both the "Search Tools" and the "finder" part of the sidebar just disappear with no apparent way to have them displayed. But this is matter for a separate issue...

@richard67 Yes: when you open Issues in issues.joomla.org you can attach labels by yourself. I'm unsure what you mean by "category"....

One more aspect (I think I already said that somewhere else, but probably in a now closed PR...):

I see as a great mistake not having "Category" displayed as a sortable column in the items list, even tif we have it as a search criterion in the "Search Tools".

@smz With category I mean the category selection ("ACL", "Administration", "Authentication", ...), just have checked the "New issue" page. I assume it is the same as what you mean with the labels?

Personally it would be great if all the components and search tools like
com_content. That was always the intention of the UX sprint last year but
certain people were against that and made com_content the only one as an
"experiment".

As for categories being sortable I "think" the issue was how to handle sub
categories

On 25 December 2014 at 18:46, Sergio Manzi notifications@github.com wrote:

One more aspect (I think I already said that somewhere else, but probably
in a now closed PR...):

I see as a great mistake not having "Category" displayed as a sortable
column in the items list, even tif we have it as a search criterion in the
"Search Tools".

—
Reply to this email directly or view it on GitHub
#5522 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Well, if it was an experiment with com_content and the side bar, then we now can say this experiment is implemented, and it seems that many testeres liked it (have not seen complaints somewhere), and so we can also say that the experiment has been finished with success, or not?

Could we maybe convince these "certain people" in this way?

@richard67 Yes, the are all "labels"

@brianteeman

As for categories being sortable I "think" the issue was how to handle sub categories

Yes, that the first thing I thought too. What I'll do is to display just the "leaf" (terminal) category name as it is now displayed under the item title, but use the full category tree for sorting.

Now, I may be wrong, but wasn't there a time (3.0 or 3.1 maybe) when Category was sortable?

@richard67 If I'm getting it right the "certain people" was more on "our side", while Brian is on what has apparently been the "winning party"...

@brianteeman May I ask you for which reasons you find it better to have the search options horizontally aligned (but almost always on more than one line) above the items list?

Wouldn't have them stacked on the left make a better use of an area which is now almost empty (the sidebar doesn't have more than three items anywhere) and will allow more items to be visible especially on wide aspect ratio screens which (unhappily) are the norm today?

@smz With the "certain people" I referred to those Brian had mentioned. But maybe I got something wrong?

For me its about having all the tools in the same place at the top and it
is a familiar place for anyone used to using and google products

On 25 December 2014 at 20:00, Sergio Manzi notifications@github.com wrote:

@richard67 https://github.com/richard67 If I'm getting it right the "certain
people" was more on "our side", while Brian is on what has apparently
been the "winning party"...

@brianteeman https://github.com/brianteeman May I ask you for which
reasons you find it better to have the search options horizontally aligned
(but almost always on more than one line) above the items list?

Wouldn't have them stacked on the left make a better use of an area which
is now almost empty (the sidebar doesn't have more than three items
anywhere) and will allow more items to be visible especially on wide aspect
ratio screens which (unhappily) are the norm today?

—
Reply to this email directly or view it on GitHub
#5522 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Regarding stacked on the left or not: We maybe should check on mobile displays, too.

... I think so, but maybe I got it wrong...

On phones the stacked search options should become an "accordion" between the "Toolbar" and the "Items"...

Ah, I see.

Do you really need to be able to do everythign on a phone? Personally I
only ever do minor emergency tasks on my phone.

On 25 December 2014 at 20:05, Sergio Manzi notifications@github.com wrote:

On phones the stacked search options should become an "accordion" between
the "Toolbar" and the "Items"...

—
Reply to this email directly or view it on GitHub
#5522 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

No, I even do not have a smart phone. But maybe some people admin their websites with it? I don't know.

Do you really need to be able to do everythign on a phone?

I never manage my sites from my phone, but it seems to be the craze of the moment... "mobile first"!

That doesn't need an RFC. Just create a PR to introduce search tools for other extensions. It just happend thast nobody wrote it so far.

@Bakual Thomas, the point here the UI/UX for "Search Tools": I (and @richard67) would like to move them to the sidebar. I can try and create a PR for that, but I wouldn't want to waste my time in case decisions are already taken and immutable about their positioning...

I have to say that I don't like the search tools at the top horizontally. I had the experience myself and with 3 clients that we all couldn't find the filters in com_content and after we all found them (or rather my clients were directed by me) we all said that it was inconvenient that you have to do that one more click to even display the available filters...

Oh, and as @Bakual said earlier, it would be better to bring stuff like this up on the mailinglist than in an issue like here on github.

Well if Search Tools everywhere and not side bar, then is also would be consistent. Better than nothing from my point fo view. But as @smz does, I think, too, that some decision would be necessary about which way to go.

Oh, and as @Bakual said earlier, it would be better to bring stuff like this up on the mailinglist than in an issue like here on github.

Well... it doesn't seems to be what @Bakual said, but, yes, I agree that the mailing list too can be a "place" where to ask opinions about this. I did here mainly for two reasons: 1) I started writing this as an "issue" (the inconsistency in the UX between different components), but then changed my mind and constructed it as a question about which of the two is preferable, and, 2) as this seems to be a matter that at the end will require a PLT decision, I considered this to be the place where to get "closer" to the PLT as a whole that I have access to.

What to do now? Maybe I can post to the mailing list a link to this...

I'd like to see some UX testing being carried out to determine the best course of action.

My personal preference would go for putting the filters in the sidebar, but that counts for nothing without real evidence that it works better for real users.

Personally I like the Search Tools better than the sidebar. Both as a user and a developer.
It's also the direction chosen for the CMS and the idea always was to do the other extensions as well. Like said already.

So unless you have strong arguments why th sidebar is better, I wouldn't waste the time to revert the Search Tools implemented in com_content. By the way: If you look at their search UI, Google also seems to think that a button to show advanced filtering/sorting is fine :)

But please take such discussions to the mailing list. GitHub really isn't well suited for that.

By the way: If you look at their search UI, Google also seems to think that a button to show advanced filtering/sorting is fine :)

The thread you created is fine imho.

@Bakual I don't know why you don't like RFCs here (and sorry, I missed that before opening the issue: I saw your comment in Brian's RFC only later on).

IMHO, compered to the mailing list, here we have a much ordered organization, we don't have "citations over citation" (excluding some rare exceptions), an history is kept and in a way it becomes a more "official" document, stored on our servers too (the J!Tracker application). Inserting code snippets and screenshots is also way easier here.

I understand that we have quite many issues open, but we could introduce a specific tag for RFCs/discussions to filter them out when doing a "sanity check" about "what do we have still pending".

The optimum would be an area outside the "issues" for RFCs and, who knows, maybe even a polling app to tally how many are pro/against a specific proposal. In the mailing list there is too much clutter to do something like that...

Wouldn't this be a way to promote "The Joomla! way" (in the original sense of the word)?

Of course you're the boss and I'll abide, but... think it over...

This is an issue tracker. It's not a discussion forum.
We currently have over 100 open issues and almost 400 open PRs. We really don't need additional issues opened just for discussion.
Also, in GitHub you get notifications for every updated issue. Depeneding on the settings you also get an email for it. On a busy day, that's over 100 notifications for me. I don't like additional notifications coming from discussions.

Last but not least, we already have a perfectly fine platform for discussions. Let's use it.

The optimum would be an area outside the "issues" for RFCs and, who knows, maybe even a polling app to tally how many are pro/against a specific proposal. In the mailing list there is too much clutter to do something like that...

Please, just not another place to check. We already have more than enough applications and channels where something happens.

Of course you're the boss and I'll abide, but... think it over...

I'm not the boss. I just try to keep my (and our) sanity here

Really, really, really don't take this as a blunt reaction, but:

• to some this is an issue
• notifications for a specific issue can be turned off
• what you see as a "perfectly fine platform", IMHO sucks big
• I agree that "one more place" has its big disadvantages
• you're not the boss but you rule on what is fine or not to do here...

Actually, the project is run by the contributors. If all of you guys want to use GitHub for discussions, then so be it.

IMO you use what works best for a project. In the case of the issue
tracker, we have all but abandoned every platform we've tried that
isn't GitHub;
it just works for us. Maybe it works here for code talk, maybe not.
Nobody knows for sure.

On Friday, December 26, 2014, Thomas Hunziker notifications@github.com
wrote:

Actually, the project is run by the contributors. If all of you guys want
to use GitHub for discussions, then so be it.

—
Reply to this email directly or view it on GitHub
#5522 (comment).

I would like to recap which are the issues I see in the current user interface. The role of the sidebar will be pivotal in my analysis, but I'll also digress:

The role of the sidebar:

• The sidebar should be a pivotal element of the user interface and host a multitude of elements, utilizing an otherwise unused screen area.
• As it is now it is greatly underused, hosting what is essentially the list of possible different views for the active component. The empty area under it is wasted.
• Correctly implemented it will show its usefulness in "mobile" screen sizes.
• At this time it is instead hidden (has class hidden-phone) in "mobile" screen sizes
• A correct implementation will be that it becomes an "accordion" element located between the "Toolbar" accordion and the items list

What in my opinion could be a perfect implementation:

• The sidebar should contain all that is not "Items list", and the right area should contain just the items list
• When I say "all" I mean just that, all: "Search Tools", "Menu selection" (in com_menu), "Sorting options", "Pagination limits", everything.
• Unrelated elemens should be separated by a thin horizontal line and have a little more spacing.
• Group of related elements should be grouped and possibly have a group header
• The "Search" (input box) and "Filter" functions should be kept separate, with separate "clear" buttons: I don't want the "Clear" for the "Search" input box to clear my filters too!
• "Search" input box and its "Clear" button should be on the same line and an "x" icon is enough for the "Clear" button
• A filter for "Featured" attribute should be implemented (and the "Featured Articles" view eliminated from the sidebar)
• "Categories" and "Level" should be on the same line. A short heading for "Levels" is enough.
• Group of options should be organized from top to bottom according to their relevance in the context: most used or hierarchically more important at the top, less used at the bottom
• On the right side, for items list, the header for columns could be sticky to the top (at desktop sizes)

Unrelated:

• "Database" and "Warnings" do not belongs to "Extension manager" (even if they do programmatically): they should go to the "Control Panel" (Warnings)" and to "System" (Database)
• "Joomla! Update" should be in the sidebar of "Extension Manager"

Hi Sergio, while I agree with a bunch of your suggestions, I feel that this issue already goes massively offtopic. It started with the question of the hidden top filters vs. having them at the sidebar and now we are moving into totally different territory with refactoring search and filtering etc. I would split this up into 6 issues already.

1. How to make writing filters smarter. Because right now we can't simply change the position of the filters in the template.
2. Where should which part of the UI go? I personally want the pagination and page limit to stay where they are.
3. How should some of the elements on a page be formatted?
4. How can this also be done in the frontend?
5. How best to re-organize com_installer? See #5283 for a start
6. Do we need a system-health view somewhere and what should that contain?

That said, I would call it an initiative (for example "UI Changes 1/2015") and then have a discussion on the mailinglist for each of these, open one issue that keeps track of all issues/PRs related to this initiative.

Now, you want to have the maximum visibility for this in the beginning and that means the mailinglist. The issue tracker is NOT something that everybody visits all the time.

I'm happy to help you with all of this, but I'm a bit busy until the next year. If you want, we can discuss that then, even via Skype, and see how we can proceed.

How can this also be done in the frontend?

Btw: Search Tools as done in com_content works also fine in frontend. I implemented it with my extension and it works even with less code than I currently have.

There is also the UX forum: https://ux.joomla.org/
It was active around the time those UX changes were done. Today it's quite inactive.
If we need a place to discuss UX things, that could be a place to relive if someone is interested.

This was the original thread that started the logic about the com_content decision.

https://ux.joomla.org/forum/Usability/1062-improvements-ui

@coder4life Josh, thanks for the link. Essentially what I see is several proposals, the last one being Beat's one which roughly correspond to what we have now, and no decision by consensus...

I like what you proposed (dropdown filters above columns), but how do you cope with situations where more choices must be made about a "field", like with "categories", where you have to choose the category and the level? Side-by-side? That kind of interface would make particularly sense if it would be possible to choose which columns to visualize and leave more room for the "interesting" ones. In my day-bay-day operation, as an example, I have little to none use for the "Author" field, but I'm sure there are other situations in which that information is of paramount importance and (always as an example) "Access" is of zero interest.

Once again, anyway, I think current implementation in com_content (filters above + sidebar on the left) is the less intuitive, makes yours eyes jumps like crazy, fatigue and loose focus.

... and I still consider not having "Category" as a column is very close to a mortal sin.

@smz Yeah, this is why we did it the way in the screenshots listed in that thread in all honest. The goal was to avoid jumping between the sidebar and the table and not understanding the direct association with the filters with the data in a more immediate way. In the current design in Joomla (not in com_content(, there is a process of "searching/finding" how the filter is labeled and how the table column is labeled to learn correlation between the two sets of items that do actually interact in a way. With lots of data this requires a lot of "eye-scan". We wanted to avoid the jumping scenario. The filters in the picture on that page were based on a concept of preemptive thinking, and why they exist at the top of the table and give meaning to what was being filtered below. There is also a scenario where the screen real-estate is smaller and the filter list would be pushed down by sidebar menu items or many listed filter functions, which makes the jumping scenario worse. This was our best test case.

There is one thing we failed to address though, too many columns. Filters that work on the same column could be stacked, or wrapped in some form (not pretty but in large screens you will not notice this). One way to solve this is for multiple filters per column have some sort of modal (on mobile phone a full screen view) that would bring up a more sophisticated input mechanism. As for the column situation, some items really do not need filters, or could share a filter, especially were data will take two lines in one row.

In all honestly I rather have the sidebar a category list with a clicable menu, because by desgin that is what categories I meant to do. In the case of sub-categories on mobile views we could just have a list view (which is a common design decision on mobile phones) and drill down to specific items on a mobile interface (on desktop interface we could keep it as a sidebar). That would go to great lengths to clean up the current design of categories, child categories, and child items.

Everything on left is better, because now you can hide sidebar - (before that 'search tools' was ok)

Sidebar should have other icon imho, because 'x' icon is more for closing for good.

IMHO word 'select' in every select tag is not necessary. I always have to read more to find what I'm looking for.

@tottello If the sorting section of the side bar would be labelled with "Order by:", as the filtering section is with "Filter by:", and it would also have a button to hide it at its top right corner, as the other 2 sections above have, then the side bar shown on the screenshot above would be closer to perfect ;-)

@all The above screenshot

• my suggestions @tottello
• rename of "Featured" button to "Feauture" and ading of "Unfeature" button as done with recent PRs
• a new button for "Unarchive"
• a new list view "Archived Articles" as we have for "Featured Articles"
• consistent ordering e.g. of sort and filter options and displayed columns in the Articles, Feautred Articles and Archived Articles lists => Perfect in my opionion.

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5522.}

I updated the view. Another suggestion is to change color for current menu item on left. (for me current - long blue - version is little bit too much eye catching.
Two versions of current item background: white and gray.

Personally I really dont like this removal of the search tools back to the
side from above the content where to me it is more logical

On 12 January 2015 at 23:32, tottello notifications@github.com wrote:

I updated the view. Another suggestion is to change color for current menu
item on left. (for me current - long blue - version is little bit too much
eye catching.
Two versions of current item background: white and gray.
[image: sidebar_gray]
https://cloud.githubusercontent.com/assets/8938743/5713235/41d2c22a-9aba-11e4-9d34-72d0c170f498.jpg
[image: sidebar_white]
https://cloud.githubusercontent.com/assets/8938743/5713339/4bf69078-9abb-11e4-912b-3b13651b54fb.jpg

—
Reply to this email directly or view it on GitHub
#5522 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Still something should be done in other components

I agree - they should all use the search tools like in com_content as was originally proposed by the UX group

And I would ask to re-evaluate that decision, especially after working with com_content a lot more recently and finding the search tools to be not very usable, to state it mildly.

I 100% disagree - what is it you dont like - for me what I like is that they are positioned where i expect search tools to be - by the search and that they are above the columns that I am going to be filtering

We should have a voting tool for such decisions so the community can vote with 1 click - just to see what they all think about it.

The issue today is no consistency, an known issue, recently debated when we were working on the sidebar show/hide.
In the sidebar or on the top? There are pros and cons, and eveyone is right!
Just the goal to achive is too have all (submenus, search tools, ordering...) in the same place, i mean if all on the top, no "sidebar", if sidebar, no buttons on the top.

@totello's proposal (already a long discussion in the sidebar PR) to have all in the sidebar is a good one.
@brianteeman request to keep search tools button is a good one (and work done on search button is a good one, with possible little improvement).

Why not a switch button ?
Having search separated from search tools button, and having things on left in the same time as things on top, that's where there's an issue.

It's really possible to add all to the "sidebar" container and have a 2-display-type switch button:

• one to have all in sidebar on the left (or right on RTL)
• one with all (submenus included as a dropdown like search tools button) on the top (and could be used for the 2 options on small devices). The user could have the choice, and change this choice when he needs.

@richard67 I'm sure that with a voting system, it will be almost a 50/50 results, because the 2 ones are good, all depends on the way you use and manage a joomla admin. ;-)

I agree that there should be consistency throughout, and I think we can all agree on that. Good UX is built largely upon consistency and expectation.

However, whilst I do think that there are significantl usability improvements that can be made to com_content search tools I do think that they are in the right place.

Filters belong at the top of the items they are filtering. Like headings for table columns, they belong above the list of items they act upon.

Given free reign over the admin UI the first thing I would do is to remove the sidebar completely. The sidebar complicates UX substantially and is a significant UI design complication. Sidebars were a common design feature in a pre-responsive world, but the world moved on. We're no longer designing for desktops, or even mobile for that matter.

Either primary navigation is in a sidebar, or it is in a top bar. It should never, ever, be in both.

+10

On 16 January 2015 at 00:28, Seth Warburton notifications@github.com
wrote:

I agree that there should be consistency throughout, and I think we can
all agree on that. Good UX is built largely upon consistency and
expectation.

However, whilst I do think that there are significantl usability
improvements that can be made to com_content search tools I do think that
they are in the right place.

Filters belong at the top of the items they are filtering. Like headings
for table columns, they belong above the list of items they act upon.

Given free reign over the admin UI the first thing I would do is to remove
the sidebar completely. The sidebar complicates UX substantially and is a
significant UI design complication. Sidebars were a common design feature
in a pre-responsive world, but the world moved on. We're no longer
designing for desktops, or even mobile for that matter.

Either primary navigation is in a sidebar, or it is in a top bar. It
should never, ever, be in both.

—
Reply to this email directly or view it on GitHub
#5522 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Having the searchtools on top was a decision made with Joomla 3.2 (I think). Reverting that now would confuse users and that is certainly wrong.
I also think it's the right place and much better than what we had before in the side bar. I still remember that user were unable to spot them there since it's wasn't an intuitive place.

I agree that we need consistency. But for me that means adding searchtools to the other extensions. Not reverting them to the sidebar.

As for voting: Since we don't have a way to request votes from a relevant part of our users, it would not give us a true result.
We have to build on the feedback from UI/UX experts, which resulted in what we have now.

Like Chris stated long ago: If we want to go back to the sidebar, there should be strong points based on UX testing. Not because some developer thinks it looks prettier there.
Back it up with links to such tests or prominent example where it is used that way (like Google Search which uses search tools on top).

As for a toggle: There is a big NO from me to having yet another stupid toggle.

I think we can all agree that we want consistency and that we don't want to have a toggle/switch/parameter/whatever is also pretty much accepted.

@brianteeman What I don't like is, that right now the searchtools are hidden by default. People will not spot those as much as they didn't spot them in the sidebar in the past. The button for the searchtools is simply not visible enough. In com_content it is not the first element in the first row and "column" above the list table. It is also not the last element above the list table. I simply can't click on something to load the list view and already position my eyes on the spot where I think that button will be, because that position is not consistent. If it were in one of the corners, that would make that aspect better.
However that brings me to my bigger issue: By having the filters hidden by default, I have to do at least one mor click in order to set a filter and that is something that I don't like.

Those are the two things that bug me the most right now: Difficult to spot and requires more clicks than in the sidebar.

There are however more things that I think are wrong here. In the specific implementation in com_content, there are filters where I question their existence. If you don't have a multi-lingual site, the language filter does not make sense. For a site that does not use tags, the tags filter does not make sense. Quite frankly, as a simply user I would not understand what "Select max levels" means as a filter dropdown.

I can understand that the right place for filters is above the list and would simply believe the UX experts here. But I'm saying that our system right now is less usable, at least for me, than the sidebar filters.

As for a toggle: There is a big NO from me to having yet another stupid toggle.

+100

If you don't have a multi-lingual site, the language filter does not make sense. For a site that does not use tags, the tags filter does not make sense. Quite frankly, as a simply user I would not understand what "Select max levels" means as a filter dropdown.

Agree, 100%. We should never show irrelevant options. Personally, I don't see how max-levels is ever useful, I've certainly never used before, but maybe that's just me.

As for the language filters the UX sprint also submitted a PR at the same
time as search tools to do exactly that but it was not accepted

@nternetinspired It took me some time, but I guess the idea is to show articles from a category and its children up to a certain level. I can see the use for that, but I would rather expect a toggle button that is visually grouped with the category dropdown instead of the current additional dropdown.

I also wanted to make clear that I have no intent of just bitching around about all that is wrong. I am looking for ways to improve this and see my statement above as a means to provide you some input what I think does not work. So let me try to give you some ideas on how we could improve this:

1. Lets remove stuff like language from the list view when the site is not multi-language. It would also be interesting to have this removed from the actual edit view. Or is there another use for the language in a mono-language site?
2. Remove the "select max levels" filter by a toggle that is appended to the category dropdown to either display or hide the articles from child-categories. Please notice that bootstrap currently does not seem to support this on select boxes. Since we are using chosen everywhere, would that solve that issue?
3. Add a method to a language class that takes a query and optionally a table name and an alias, that adds selecting the right language based on if the site is multi language or not and if not, simply returns * all the time. That way we stay backwards compatible and have a consistent state in both mono- and multi-language sites.

I think in general we need a way to disable options altogether. If my site does not need the timed publishing feature, I can disable that globally and I have 2 form elements less in my article edit view and 4 WHERE clauses less in my queries. Disabling the print/mail icons globally would also remove another 3 form elements from my system. As I wrote earlier, our edit screens are too complex and it would be good to slim them down. For example, we have around 105 form elements (depending on associations, etc.) on the article edit screen, excluding the editor itself. I'd say that we would have to be able to cut that by half and it would still be a lot. Please be reminded that I'm not asking to remove functionality here, but to allow to disable features globally, so that they don't show up each time I work on a content item.

Re points 1 and 3
We tried and it was not accepted. Coincidentally I am planning on
resubmitting that next week and have been checking the code with
@phproberto only yesterday.

Re point 2
I am not sure I understand

Re 2: In com_content you have a filter for the category. Next to that filter is another filter that allows you to select a level of child-categories from that first category. This most likely simply lets you display the articles from that category and its child-categories up to a certain level. I think that such a filter is useless for 99.999% of our users and they would instead already be helped with a switch that either does or does not display the articles from child-categories.

Now Bootstrap allows you to append controls to form elements, so that they are visually grouped. For example the button sticking directly to the text input. While this works great for all form elements, the select element is excluded from that, at least in BS2, according to their docs. The question now was, if it might still work since we use chosen, which replaces the select with a more complex HTML structure, but which might work correctly with that append thingy from BS. In any case, we simply have to test this.

Right the code and it can be tested :)
On 16 Jan 2015 09:19, "Hannes Papenberg" notifications@github.com wrote:

Re 2: In com_content you have a filter for the category. Next to that
filter is another filter that allows you to select a level of
child-categories from that first category. This most likely simply lets you
display the articles from that category and its child-categories up to a
certain level. I think that such a filter is useless for 99.999% of our
users and they would instead already be helped with a switch that either
does or does not display the articles from child-categories.

Now Bootstrap allows you to append controls to form elements, so that they
are visually grouped. For example the button sticking directly to the text
input. While this works great for all form elements, the select element is
excluded from that, at least in BS2, according to their docs. The question
now was, if it might still work since we use chosen, which replaces the
select with a more complex HTML structure, but which might work correctly
with that append thingy from BS. In any case, we simply have to test this. [image:
]

—
Reply to this email directly or view it on GitHub
#5522 (comment).

I think that such a filter is useless for 99.999% of our users…

I agree, and I think we need to take a long hard look at options like this and balance any potential utility they have against the UX benefits of a cleaner, more intuitive, UI.

A user-friendly UI does not have 1001 options. It's that simple. I am in favour of completely removing the items that .001% of people may use but that damage the UX of the 99.999%.

Concerning the language filter: if I remember well, it was decided to keep it to let users know Joomla has a multilingual functionnality.
Someone may very well start using a monolanguage site, add content languages and prepare all to change the site to be multilingual (except the home pages until the last minute), WITHOUT enabling yet the language filter plugin.
I am therefore not in favor of hiding the field.

Concerning the language filter: if I remember well, it was decided to keep it to let users know Joomla has a multilingual functionnality.
Someone may very well start using a monolanguage site, add content languages and prepare all to change the site to be multilingual

The installer prompts for the installation of additional languages, letting the user know this is possible:

Couldn't we hide language filter options until additional languages are installed?

@infograf768 I see your concern and would conter that with a request to have a tutorial system in the core and/or a guiding system, where you can select different things like "I want to create a multi-language site" or "I want to have SEF URLs" and Joomla guides your through the process step by step. We could use something like Amberjack2 for this: http://amberjack2.org/

Saying all this: It could be part of a greater strategy to slim down, speed up and improve the Joomla UI.

The installer prompts for the installation of additional languages, letting the user know this is possible:

Indeed, this did not exist when we discussed the issue.

Couldn't we hide language filter options until additional languages are installed?

Additional languages as such can be used in a monolanguage site.
Additional "Content Languages" may not, except that some distros released by language communities do include both en-GB and xx-XX AND add their related "Content Language".
Therefore, if we were conditionning the display of the language field to the existence of multiple items in the _languages table, we would not act right.

Let's keep the language field in the 3.x series.
IMHO, the whole multilingual system should be reviewed for 4.0.
For example, I think we could have a switch in the Global Configuration plus regroup many aspect of multilingual (including managing associations and editing associated items) in a single core component.

@infograf768 I don't think it is wise to postpone changes to any of our systems to 4.0. As far as I can see it, the move from 3.x to 4.0 will in 90% of the cases be simply the point where we drop backwards compatibility for old stuff. But the new stuff has to be already in place. This covers routing, language stuff, MVC classes, etc.

As long as we are B/C, I do not think anybody, including myself, will oppose to evolution.

After reading all your comments, with so different opinions, but with full of good suggestions and ideas, i think Joomla as implicated volunteers, but Joomla needs to have more feedback and testing of UX from end users, not developer or beginner.

We have Joomla! events, where many active contributors (developers, testers, advanced users...) are attending.
Why not create a Joomla! UX Day event, open to public with limited places but free entry, where a end user comes and will be ask to achieve different tasks (create an article, search for something...), where a skilled user checks the way a user succeeds or not, the difficulties he had, what he achieved with no issue, and what he was searching too long?

for Consistency
for simplicity / flexibility / usuability for ALL users (not only skilled users)

Sure thing for me is:

• eliminate word "Select" from filters
• show filters only when they can improve searching (dont show Language filter And Language column if site is not multilangual)

What I suppose is good UX will be something different for different users. For someone who is starting using Joomla a lot of visible options could be overwhelming. Even for more advanced users in simple sites there is no need tu put all options visible. But it should be an option to do that.

If we assume that is better to hide to many options (and only some users can reach them by some toggle - like 'Search tools' or other system option) than why not to hide propably all buttons beside "New"?

Sidebar just as a another menu is not a good idea. For me other menu items could be below Top Bar.

Some preview to make discussion even more interesting ;-)