All toolbar buttons that only work when one or more items are selected, will only show up once at least one item is selected.
Buttons that only work on single items will only appear when one item is selected (and not be visible when no or more than one item is selected). =>

See vid:



Note: This is the work and result of the JUX Workgroup's JUX Code-Sprint 2013 ]
Opened On:
26 Aug 2013, 18:37 by Beat
Closed On:
23 Aug 2014, 7:57


Posted on 26 Aug 2013, 20:14 by Nick Savov

Thanks Beat! I'm moving this over to pending. Please have the UX Team and others document the latests tests in here.
Posted on 30 Aug 2013, 22:17 by Beat

[JUX] Pull-request:

Posted on 2 Sep 2013, 14:27 by Brian Teeman


Does what is says. I Like this as it removes options from the screen when they have no meaning/function
Posted on 20 Sep 2013, 11:09 by Beat

Final pull-request to master, identical to that part of PR1882 (so previous tests are still valid):

This is mergeable and testable and thus meets 3.2.0-features-freeze deadline.

Posted on 1 Oct 2013, 3:33 by Brian Teeman

As discussed at JD13ES this feature is accepted and Roberto will be providing the final PR - in future it would be good to move this to a jlayout
Posted on 2 Oct 2013, 8:14 by Roberto Segura

Setting this pending again as the full PLT has to review things independently.
Posted on 2 Oct 2013, 10:50 by Roberto Segura

Please test this patch:
Posted on 2 Oct 2013, 11:37 by Brian Teeman

@test I tested successfully the following views successfully (see end for errors)

Menu Manager: Menus
Menu Manager: Menu Items
User Manager: Users
User Manager: User Groups
User Manager: Viewing Access Levels

User Notes

Category Manager: User Notes Categories

Article Manager: Articles

Category Manager: Articles

Article Manager: Featured Articles

Banner Manager: Banners

Category Manager: Banners

Banner Manager: Clients

Contact Manager: Contacts

Private Messages Manager: Messages

News Feed Manager: News Feeds

Redirect Manager: Links

Smart Search: Manage Indexed Content

Smart Search: Manage Content Maps

Smart Search: Manage Search Filters


Web Links Manager: Web Links

Category Manager: Weblinks

Extension Manager: Manage

Module Manager: Modules

Plugin Manager: Plugins

Template Manager: Styles

Language Manager: Content Languages

Language Manager: Language Overrides


Language Manager Site and Administrator dont show the Default icon when a language is selected
Posted on 2 Oct 2013, 11:52 by Roberto Segura

Thanks for testing Brian.

I've fixed the language manager issue. Can you test it again?
Posted on 2 Oct 2013, 11:58 by Brian Teeman

Retested and all is Good now
Posted on 2 Oct 2013, 12:06 by Jean-Marie Simonet

I confirm Brian's findings. We lose the Default in toolbar and do not get it when selecting a language.
I can live without though.
Posted on 2 Oct 2013, 12:19 by Jean-Marie Simonet

Retested too and OK here
Moving ti Ready for Review
Posted on 2 Oct 2013, 17:45 by Bud Manz


Failed - I still have clickable buttons with out checking any boxes.

Version is Joomla! 3.1.4 Stable [ Ember ] 25-July-2013 14:00 GMT

And using the Isis template for the administration
Posted on 2 Oct 2013, 18:08 by Beat

@Bud Manz: Make sure to clear your Javascript and CSS browser and proxy caches and to use Isis.

Posted on 2 Oct 2013, 18:09 by Brian Teeman

@Bud please check again using the current Master downloadable from github -
Posted on 3 Oct 2013, 1:46 by Jean-Marie Simonet

After a good night sleep, I think we should reconsider this patch.

The code looks so nice to us that we do not see It defeats our purpose, i.e. make the UI easier.

In fact, we, experienced users who tested this, do indeed know the possibilities of action will display when we tick an item, but a newbie will never know and I imagine that even not so newbies will hesitate...
The toolbar not only displays icons but these icons have a legend which explain their purpose. How would a newbie (client) know that one or multiple items may be trashed, archived, checked-in, part of a batch, etc. ?

Posted on 3 Oct 2013, 2:38 by Brian Teeman

I will admit I wasnt a fan of this at first glance.

But after just a few hours I loved it and as a trainer who deals with absolute beginners everyday I can tell you that they will love it too. I even did some testing with some clients and they had no issues at all.

In fact if you use gmail you are instantly familiar with this as it is exactly what gmail does. See screenshots. While I'm not saying gmail is perfect at everything they dont make a change like this without extensive UI testing so hiding buttons until they are needed is clearly something that worked for them and their gazillions of user.
Posted on 9 Oct 2013, 17:08 by Roberto Segura

I rebased it vs the latest master.
Posted on 9 Oct 2013, 17:41 by Thomas Jackson


Tested against the current master. Works exactly as described.

Out of curiosity, when did we drop the ability to copy an Article in the Article Manager?
Posted on 10 Oct 2013, 5:26 by Brian Teeman

@thomas - quite a long time ago. It was not present at all in 2.5 but when the Batch button was added to the toolbar in 3 the functionality was restored
Posted on 10 Oct 2013, 7:12 by Thomas Jackson

Ah! That explains it (we're still on 1.5 - moving to 3.5 next year).
Posted on 10 Oct 2013, 11:44 by Geoffrey Schaller

I am a big fan of learning by seeing what options are available to me.  If something is grayed out, I know it's possible, but not at this moment... until I learn what the trigger for that option is.

This enhancement great for advanced / familiar users, but I worry about people new to, looking to adopt, or inheriting Joomla as a product.  For the sites I have built for clients, a lot of them still see the back end as "that place the Webmaster goes to do stuff I can't figure out," and I don't want to make it scarier or more dynamic, without conscious thought.

Would it be possible to implement this as an option, that could be configured?
Posted on 10 Oct 2013, 12:02 by Josh W

I agree with Geoffrey. I had the same reaction, and same thought for my users.  Hiding items until they are needed does not necessarily make it easier to learn.  There is some unpredicatability about what may or may not be usable during the specific context of the webpage.

I want to follow up with a post on twitter "Do you like google's way of hiding buttons until you need them? Would you like to see it in #joomla?"

My initial thought to that question, I have a difficult time finding out what options are available to me in Google's user interface.  It was not intuative since there was no ability for me to question a visible state of why a button may look different compared to other buttons, it was just missing.  As a result I could never understand the options given to me without playing around with the interface to know what does what.  One could argue that you would have to play with an interface anyway to make a button disabled into an enabled state, and yes I agree.  However there is no predetermined understanding that the option was given me to begin with, which is why learning becomes severly inhibited.
Posted on 10 Oct 2013, 13:26 by Roberto Segura

Ok. Based on the feedback received I think we need to try the disable alternative. I'll try to find a way and send a PR tonight.
Posted on 10 Oct 2013, 13:35 by Brian Teeman

Fair enough. We will need to make sure the entire button is displayed as clearly disabled not just the icon and label for it to be immediately obvious it is disabled.
Posted on 10 Oct 2013, 14:13 by Vincent Ertveld

I can't agree with Geoffrey.

I think the point of Brian regarding Gmail not taking this kind of decision without heavily testing it.

How could you "really clearly" set a button as disabled ? Bootstrap disabled state wouldn't be enough ?
Posted on 10 Oct 2013, 14:36 by Brian Teeman

Thats my point Vincent - bootstrap disabled just changes the label not the button styling and really doesnt look disabled
Posted on 10 Oct 2013, 15:36 by Beat

@test success

I tested the rebased JUX patch of Roberto and looked at the code and it works and looks as before.

Posted on 10 Oct 2013, 16:23 by Beat

Geoffrey and Josh,

The whole point here is to get the unnecessary user-interface clutter out of the view of the user and to focus on the content and on the task at hand.

Keep in mind that all list item actions have been redone with a clean drop-down always visible instead of only on hover (that is merged to master): See screen-shot here:

Thus the actions of buttons at top that apply to a single item are really available in that item actions. So nothing to "discover" up there.

Adding another setting to Joomla seems counter-productive to me in our quest to simplifying the UI.

At Jux meeting in Manchester with Brian, Roberto and 5 other participants, we have already tried out many variants of the top hiding/greying and animations, and my conclusion that most participants agreed to, and that got decided for this FR was to show only actions that make sense. This is the best approach to unclutter the UI for making it less scary to beginners, and more efficient to pros.

Showing controls that are needed in a given context and state is the essence of bringing a good UX to focus on content and tasks in the workflow, and not "showing off the tools".

There are many reference UX articles on that subject, and leading web Uis like google's and Apple's to cite 2 are doing it too. Here is one of those articles:

Google Drive makeover puts the focus on your work, not the interface

For a beginner, a clean top shows him the basic actions he can do "New", and if items are there, he sees the actions on each. The checkboxes are pretty clear too, and invite to click them when you want more than one item.

Conclusion: hiding the unneeded scary clutter is a big Win for the Beginner.

For an advanced user, having less to read to go to the essential is an obvious win too.

I really recommended and continue to recommend to not "show disabled buttons", which will still represent clutter, as their single-item functions are available in the line-controls, but to hide them as designed in this PR. But you should try it and see how it looks even more cluttered when half disabled. For your usability tests with beginners you need latest master, and merge in this PR and the PR for Search Tools to get the picture of the JUX decisions work result, which is also shown in Brian's excellent video of JUX team's results and decisions, which got approved by PLT. jQuery allows you to those tests very simply by changing 2 function names.

Thus, please try it out as you see, show it to beginners as alternate to 3.1.5 way, then come back. That's what betas are for ?

That feature has already been accepted as is by PLT, and as I understand simply hasn't been merged yet because it needed to be rebased first, and I personally consider it as one of the JUX key improvement for beginers and for pros in lists, together with the Search Tools PR (not committed yet too because rebasing was needed). Show that combo to a beginner on one side and the 3.1.5 interface on the other ;)

We can always improve current state if issues appear during betas. :-)
Posted on 10 Oct 2013, 16:25 by Beat

Oops: Description wasn't clear!

@test success

I tested the rebased JUX patch of Roberto and looked at the code and it works and looks as before the rebasing, so all ok for this accepted FR. :)
Posted on 10 Oct 2013, 17:30 by Roberto Segura

What about something like this for disabled:

vs the enabled status:

I modified a bit the disabled status to make it more "visible"
Posted on 10 Oct 2013, 18:13 by Brian Teeman

I personally still prefer the hidden option but those screenshots are, for me at least, an acceptible alternative 
Posted on 11 Oct 2013, 2:12 by Peter van Westen

I vote for the original idea: hide the button completely.

Tested that and ok.
Posted on 11 Oct 2013, 5:40 by Beat

Thanks Roberto :-) your 2 images are worth more than my 1000 words. :-D

I vote too for the original idea: hide the button completely.

Pro-memo: my @test was success
Posted on 11 Oct 2013, 8:42 by Thomas Jackson

I have to admit, I like Roberto's screenshot for the disabled. It provides all the benefits of the intent of this patch without any of the negatives (IMHO).
Posted on 23 Oct 2013, 11:23 by Jean-Marie Simonet

Agree with showing the disabled, as I commented above.
People NEED to know what is available... It is essential for a good user experience.
Posted on 23 Oct 2013, 13:18 by Kyle LaRose

I vote to keep the original idea of hiding the buttons completely.
Posted on 31 Oct 2013, 18:01 by Beat

As just written on the tracker:

Reading the above and having thought quite a bit of all feedbacks, I have following proposal:
- Inactive Buttons appear dimmed when the toolbar is hovered with the mouse
- When mouse is not over those buttons, they are hidden.
Thoughts ?
That would be best of both worlds and very easy to imlpement with jQuery.
Status-Quo remains imho worst solution of all 4.
Posted on 20 Feb 2014, 5:37 by Brian Teeman

I really would like to see this PR reseurrected and considered again for 3.3
Posted on 23 Aug 2014, 7:58 by Brian Teeman

Thank you for your contribution. We have now moved our tracking process to so please do not update the issue here. The link on the new tracker for this issue is