That is a very important change in UI. I personally never use that dropdown.

Don't we get to the edit view also when we just click the title of the article?

And the title link has title="Edit", so desktop browsers show "Edit" in a tool tip?

On both mobile or desktop the title is shown as a link.

If I have to move or even scoll down anyway to select an article for using the edit button, it is easier just to click the article link instead of selecting it and then move up and click the button.

Therefore I always use the title link, I neved use the button.

So why do we need an edit button for a single article on top or an edit item in the pulldown?

I think you just can remove the edit button from the toolbar and not add anything new for it.

@infograf768 YES it is indeed. The point is that having an edit button in the toolbar will only work if user selects only ONE item.
@richard67 Yes that was my first response as well, just get rid of it!
Actually an even better and less confusing approach to this awkward UX will be:
Remove the edit button from toolbar
And just echo the edit icon before the title in each item (row), if the user have edit rights. I will make an update so people can decide the best solution

@dgt41 "Remove the edit button from toolbar and just echo the edit icon before the title in each item (row), if the user have edit rights.": Perfect. The edit icon is much better visible than just the title not being a link in case if not edit permissions.

I don't like this change. IMO the users are used to have and use the edit button in the toolbar. This change is also only suitable in the articles view. What is with other views that don't have those action buttons? It will break the consistency in the backend!

The only thing that would be okay for me is if we would display a JavaScript alert if more than one item is selected. Such a solution could prevent the multiple selection and only editing the first item.

@richard67 @infograf768 @Kubik-Rubik I just made the changes to simplify the view and remove the extra clutter. Here is a preview:

I would like to see some input!

Personally

1. I dont see the value in adding the edit link next to the title as it is just a few pixels away from the title itself which a user can click on to edit
2. I am not a fan of permanently removing the Edit button on the toolbar. But if you want to do that then you must also remove all the other buttons that are already placed next to the article title for consistency.
3. I would personally prefer we aopt the UI/UX proposal from 2013 to only display toolbar buttons when they are enabled. ie you cant see an archive button until you have selected an article etc

I understand that this discussion is because of a simple bug that if you
select multiple articles and then click edit you only get to edit the first
item. This really seems to be a sledgehammer to crack a nut,

On 18 January 2015 at 15:59, Dimitris Grammatiko notifications@github.com
wrote:

@richard67 https://github.com/richard67 @infograf768
https://github.com/infograf768 @Kubik-Rubik
https://github.com/Kubik-Rubik I just made the changes to simplify the
view and remove the extra clutter. Here is a preview:
[image: screen shot 2015-01-18 at 5 55 49]
https://cloud.githubusercontent.com/assets/3889375/5793003/8f31628a-9f3b-11e4-8f08-070c256345b8.png

I would like to see some input!

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

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

@brianteeman

I dont see the value in adding the edit link next to the title as it is
just a few pixels away from the title itself which a user can click on to
edit

This is not ANOTHER link this is just an icon in the same <a> tag

But if you want to do that then you must also remove all the other buttons
that are already placed next to the article title for consistency.

All the other buttons work in the toolbar are mainly for many items (ok also working in single item, but for each item we already have an easier shortcut in the status column, or in case of checkin next to title)

I would personally prefer we aopt the UI/UX proposal from 2013 to only
display toolbar buttons when they are enabled

Totally agree on that!!!

The actual rendered html:

I think this changed doesn't makes it more consistent, I would prefer a full review or the UI/UX instead of fixing it here and there. So for me this is something we should look while working on 3.5.

This really seems to be a sledgehammer to crack a nut,

++

I'm personally against part of this change, the addition of new icon. How does adding an icon to the link improve anything? It adds clutter, and visual noise, but no functionality whatsoever.

In general icons should be used to provide additional context to user actions which might be unclear. I don't think there can be any misunderstanding that clicking a hyperlinked title will take a user to the edit page. Users already understand that links take you places.

1. I am not a fan of permanently removing the Edit button on the toolbar. But if you want to do that then you must also remove all the other buttons that are already placed next to the article title for consistency.

The other toolbar buttons, in this view, toggle actions @brianteeman. Edit is different, it takes you to a different view. It is a navigation option, not an action. In the case of the other actions, I agree that they should not be duplicated, they should be removed from either the status column or the toolbar.

Removing a superfluous button from the admin toolbar is a great improvement though

If we can agree that neither featured or archived are logical article states (#5819) then we can remove the dropdown completely and have only two icons, publish and trash.

Less UI clutter, better logic and better accessibility because articles can be trashed in one click instead of two.

Setting to Needs Review so the CMS maintainers can make a decision about this change

@infograf768 @richard67 @Kubik-Rubik @brianteeman @rdeutz @nternetinspired Thanks for the tests and comments! As @brianteeman said there is a better solution for this one by @phproberto with PR #2111. So I will close this one and hopefully we move the arguments over to Roberto’s PR.

Thanks again!