This is not broken design you have a to small screen :P

In the past some ways to fix that got redjected e.g. Show the button only when it makes sense. E.g. The edit button only if you have selected one item etc. I'm not sure if we have other ways to fix it before a complete new backend design ;)

Im sorry but 1024/768 is NOT a too small a screen !!

Also I'm on a 27 INCH IMAC - Half of this screen is far bigger than most users ever use.

It was a joke not a personal attack :)

It's not a "new" issue. At 1024 width on a 3.6.4 site...

Without doing something to make the buttons shorter on smaller screens (and this becomes trickier because the breakpoints are 980 and 1200 so it's not even making changes at "normal" template breakpoints here), I don't know what we can do, but it's definitely not something caused by the UI refresh.

Not new, no, but still something that could and should be addressed :)

One options is to put Edit, Publish, Unpublished, Feature, Unfeature, Archive, Check in, Batch and trash in a dropdown named Actions. That way we end up with New, Actions, Help and Options which will behave better on smaller screens

Please don't. That's terrible

Google's Gmail doesn't agree with you @brianteeman:

Those are secondary actions though. I'm not sure what on our toolbar would actually be "good" candidates for a dropdown, and we've already resisted following Google's lead on a contextual toolbar because "users might not know what they can do".

and we've already resisted following Google's lead on a contextual toolbar

@mbabker that's another bad decision, IMHO

No further comment. I just know a lot of UX effort in 2013 was discarded, that being one of the things.

@mbabker I've tried to resurrect that PR few months ago: #7592

But as you said, no further comments, there is a UX team that should take care of all these issues

there is a UX team that should take care of all these issues

I get told this a LOT... /facepalm/

http://www.w3schools.com/browsers/browsers_display.asp 3%of screens at 1024

It was a random size picked from memory

The screenshot in the opening comment was also from half the size of a 27" iMac - whatever that resolution is, its hardly small, and probably a lot bigger than most, and still the toolbar is forced onto two lines.

On the iMac with using the whole of half the screen:
My Screen Resolution is 2560x1440
My viewport is 1280x1235

One option would be to hide the icons for this range of screen size...

Interesting idea - I fear that this would only be a temporary stop gap
solution though

I still prefer the "hide icons that are not active" approach adopted by
gmail et al

On 8 November 2016 at 10:43, Ciaran Walsh notifications@github.com wrote:

One option would be to hide the icons for this range of screen size...

[image: icon-hide]
https://cloud.githubusercontent.com/assets/2803503/20094097/a9612aaa-a597-11e6-90f1-c037d7f8b1f1.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8QeN_vYCH-vV3N83pyJY16-h4Pb7ks5q8ERfgaJpZM4Kql0Z
.

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

One option would be to hide the icons for this range of screen size...

I don't think that this will guaranty that buttons will actually be in one row. Think of a 3rd PD component that has one more button there...

I fear that this would only be a temporary stop gap solution though

@brianteeman I agree

Something that would dynamically add wrapping items to a dropdown would probably be ideal.

One options is to put Edit, Publish, Unpublished, Feature, Unfeature, Archive, Check in, Batch and trash in a dropdown named Actions. That way we end up with New, Actions, Help and Options which will behave better on smaller screens

I'm not against this. In fact all the actions are available in the article list (Publish/Unpublish/Archive/Feature/Unfeature).

Not if you multiselect and then want to use the button

On 8 Nov 2016 11:45 a.m., "Luca Marzo" notifications@github.com wrote:

One options is to put Edit, Publish, Unpublished, Feature, Unfeature,
Archive, Check in, Batch and trash in a dropdown named Actions. That way we
end up with New, Actions, Help and Options which will behave better on
smaller screens

I'm not against this. In fact all the actions are available in the article
list (Publish/Unpublish/Archive/Feature/Unfeature).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8QVKSB0DDwzNodsaBAKo28ci6O6Mks5q8FKkgaJpZM4Kql0Z
.

Don't know about 3.7, but this will be catered for properly in J4

Don't know about 3.7, but this will be catered for properly in J4

And what would it be?

Just 1 example:

3.7 is supported for at least 2 years - we cant just push things away
because they will be in 4

On 13 November 2016 at 10:09, Lodder notifications@github.com wrote:

[image: toolbar]
https://cloud.githubusercontent.com/assets/2019801/20244855/3d55efe4-a989-11e6-9629-cf4467eb134d.gif

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8TRV1O8s7FEXvVk-E1lJKpEdZ0Ioks5q9uHSgaJpZM4Kql0Z
.

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

I don't mind adding this into J3.7, providing it's what people want.

3.7 is supported for at least 2 years - we cant just push things away
because they will be in 4

I dont think people should be working on 4 at all - thats the way major jumps and huge backward incompatible changes are made and is the reason there are so many Joomla 1.5 and 2.5 sites still out there today... small incremental changes, even b/c breaking changes is the correct way forward.

Holding out the next major series all the time as "the answer to all current problems" just causes even more problems...

You cant build on a foundation that has not even been developed yet - thats called a fork, not a "next major version"

@C-Lodder that animated gif bears no relation to the page reported in the opening of this issue - which was of a list view, and not a edit view.

Having seen your comment before editing it...

https://github.com/joomla/joomla-cms/tree/4.0-dev
https://github.com/joomla/joomla-cms/labels/PR-4.0-dev

Also, even though that GIF isn't specific to the page you chose to highlight, the same concept applies across the board with that new dropdown button.

@PhilETaylor - perhaps my comment above the gif was unclear? And this feature is in no way a B/C break. The standalone buttons are still doable.

@mbabker yeah ive not had coffee yet - there are other "hidden" "forks" though :)

@C-Lodder your gif doesnt address the issue reported in the opening post of this issue. Which of the tool bars in a list view would you consider bunching together? When you say Joomla 4 will fix this, do you mean that the work has already been done, or that it will be done, or is someone actively working on it, or is that a throwaway wish ?

@PhilETaylor @mbabker @C-Lodder just resurrect #7592

Like I said, I dont have the answers, its not my area of interest either - I just know that, as shown in my opening post, it is wrong. And with the addition of Shareable Draft button the problem is getting worse and not better...

I guess the UX team needs to make a decision on this one. I am gonna close it for now

A phrase I read FAR TOO OFTEN!

@PhilETaylor just to be fair that comment was done when UX team was still very fresh (like 4-6 months)

To quote you "@dgt41 commented 7 days ago"

there is a UX team that should take care of all these issues

Out of the list of people listed in the "team" here

https://volunteers.joomla.org/teams/user-experience-working-group

The only ones I can find with @ on github are

@brianpeat @wilsonge @cpfeifer

@PhilETaylor I was referring to the other PR

I guess the UX team needs to make a decision on this one. I am gonna close it for now

so I just checked Joomla 4 branch and this problem is even worse at the moment, and not resolved.

Saying Joomla 4 solves this is therefore factually incorrect at the time of this post.

Even without Shareable draft buttons, on half a 27" iMac - Joomla 4 has:

And @C-Lodder gif on the save button is UNNEEDED as in Joomla 4 there is ZERO clutter on the edit screen! I see that as not progress but merging buttons for the sake of merging, more clicks to achieve the same thing #fail

@PhilETaylor the repo you checked doesn't have the new template that @C-Lodder was referring

Then you cannot say it is resolved then - it is not - if the development is not being done openly in the Joomla 4 branch you cannot say that this issue is resolved!

@philetaylor its in the secret repo that might be merged

On 13 November 2016 at 19:28, Dimitri Grammatikogianni <
notifications@github.com> wrote:

@PhilETaylor https://github.com/PhilETaylor the repo you checked
doesn't have the new template that @C-Lodder https://github.com/C-Lodder
was referring

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8QhpTY3q9phZmwrGlCX6kPemxyKsks5q92TqgaJpZM4Kql0Z
.

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

Ah yeah, because Open. Source. Matters. (apparently)....

/unsubscribe.

Re-read George's post at https://developer.joomla.org/news/658-joomla4-manifesto.html and it's made clear from the beginning the template work is purposefully happening in a closed space. Because we all know damn well design by committee doesn't accomplish anything, and that's exactly what happens when stuff like that happens in an open space.

Nobody's guaranteeing what's happening there will be merged as is. And if anyone is, they're drunk. But let them work in a space without everyone and their mother trying to be a distraction and let them get a presentable product to share.

@PhilETaylor @brianteeman it's not SECRET, but the few people working on that want to present something functional and complete (from design point of view). Having many people with irrelevant views is not going to help up us produce anything

Having many people with irrelevant views is not going to help up us produce anything

Pathetic. Nice to know how you feel.

Re-read George's post

And to which Joomla 4 does this relate to, the Joomla 4 or the Joomla X/aka 4 ... I give up....

Nobody's guaranteeing what's happening there will be merged as is.

So my point stands, this issue is still an issue until resolved.

Having many people with irrelevant views is not going to help up us produce anything

This is a rephrase of

Because we all know damn well design by committee doesn't accomplish anything

Maybe not well written, but same meaning. Sorry if it sounded pathetic!

No I get it - my view is irrelevant... fine... I know nothing about UX or Joomla...

@PhilETaylor - I said it will be catered for. The Gif provided is an example. It's not necessarily the concrete solution. Now if anyone (not targeting you Phil) has a different solution or any ideas, then please, do share.

So my point stands, this issue is still an issue until resolved.

It can't be fixed with the current 3.x API. So you're right, it's not fixed in a repo that has production code and technically cannot be considered fixed until a release is issued with whatever changes are necessary (because even when something's merged that doesn't guarantee it gets released).

What are you looking for here? Aside from telling us that this issue needs high priority attention. I can rattle off a list of things I find more embarrassing for Joomla than the fact the toolbar wraps.

@PhilETaylor sorry, but we share the same view, yours is not irrelevant. Tried before to solve (kinda) this, but there are too many stubborn people around. The hold the one and ONLY truth!

What are you looking for here? Aside from telling us that this issue needs high priority attention. I can rattle off a list of things I find more embarrassing for Joomla than the fact the toolbar wraps.

Even without Share draft button, Joomla 3.7.x tool bar will wrap onto two lines, on even the largest 27" iMac half screen.

If Share Drafts gets merged in Joomla 3.7.x then this will be an issue on every screensize, including half of a 27" iMac.

I'm not saying its a high priority issue, I'm just saying its an issue and one I don't have a solution for, but thats why we have a (missing in action) UX team and apparently a non-open repo that promises to fix all known problems in Joomla and bring about world peace...

The fact is Joomla 3.7.x branch HAS this problem NOW and there is no plan to fix it until "the new admin template in Joomla 4"

This is wrong imho.

I am reopening this and changing the title to reflect the shareable draft issue

It isnt ok that the toolbar break on any screensize below 1390px

I'm just saying its an issue and one I don't have a solution for

And having the issue open is enough to raise the attention to it. Whether it gets fixed in 3.x or not, I don't know, but my gut feeling is it doesn't.

Charlie pointed out he has a solution in the 4.0 template he's working on. That doesn't mean a fix waits for 4.0. If it can be done in a B/C way in 3.7 then great. I honestly don't see it being that easy though; sure the dropdown button concept can probably be added but it makes major changes to workflow and documentation, do we consider that potentially disruptive change acceptable? UX isn't my thing, I'm not commenting further on that aspect.

Another option worth a mention that would be easily implemented is to collapse the margin between the buttons and restyle them slightly at the point when the buttons wrap. This will allow us down to 1080px without a line break, less if we tweak the button size...

The UX team will review this issue asap, among many others. I've been tied up with JWC for the past month.

Now it's over and I'll be home tomorrow night. We worked out a strategy over the weekend to have more streamlined involvement and input between our team and the development process across all 3.x & J4 issues. Just FYI

Another option worth a mention that would be easily implemented is to collapse the margin between the buttons and restyle them slightly at the point when the buttons wrap. This will allow us down to 1080px without a line break, less if we tweak the button size...

Button size tweak: one has first to think about other languages than English...

@infograf768 A fair point. I was thinking on the extended 'New' button. Could scrape a few pixels having it the same as the rest. All n all this option would reduce the width of the button set by about 250px regardless of the language. It's just an option to fall back on if all else fails.

I just hope that, in this "secret" group, some one is there to say whatever has to be said for other languages. ?

is there a reason we couldn't stack the buttons in that giant empty space in the side bar? I know it's a completely different direction, but it seems to me we have plenty of space over there, and not enough at the top (still thinking this through, could be a bad idea).

I think the best scenario here is if the screen is too small to show the icons we jump them into a more button which is like the gmail preview earlier in the message.

From a UX point if the user is viewing in a full screen usually and see's all the buttons, when it shrinks down and the buttons have gone they will naturally look for 'more' hence the gmail usage. at which hovering over will show the additional button which do not fit within the screen.

Alternatively we look at an additional button along the lines of 'Bulk' which on hover shows all the additional buttons to do the bulk actions.

My approach leave the toolbar to javascript, don't render it in php side. Also per row we can have some data attributes for published, featured, etc so whenever a user selects an item only the relative icons show (if it's already published what's the point of having a publish button?). Then group some icons under a button named actions and you end up with a clear screen. Always!

Looking at all the toggles, you COULD put publish/unplublish, feature/unfeature both under a drop menu type button, that would drop 2 buttons right off. I wish we could get rid of the edit button as you normally can't edit more than one at a time anyway (it's only there if someone checks a single item and clicks edit instead of clicking item name right?). They could also be reorganized into 2 rows, with different types on each row.

But yes, it could collapse down into several hover drop downs once the screen gets too skinny. As a user that wouldn't bother me at all if there was an "action" menu that appeared on smaller screens.

I don't think that's going to work. JToolbar needs to be usable without JavaScript. Use it to enhance the layout, but we can't make the entirety of the API rely on it.

as it is now, it's almost button overload even at full width, so I'm all for condensing some actions under hover drop downs.

@mbabker in j4 you won't be able to login if js is disabled, so we can rely on js as it is a prerequisite to access backend

For the backend, maybe. JToolbar isn't a backend only library though (at least it shouldn't be, otherwise it should be moved out of the global libraries directory if it's really only usable in the backend), so keep that in mind.

Good point

That's a very good point @mbabker we use it in the frontend too.

We could extend JToolbar for a backend class?

And just to be clear, I've got nothing wrong with finding ways to improve the toolbar overall. I just always cringe a little when a solution comes down to rendering "major" page elements in a JavaScript only context when working with "mixed" apps like PHP stuff is structured. Even in my own projects I get this feeling, at least for the main one I'm thinking of that's a sign we picked the wrong technologies for our UI.

The toolbar is the least of the problems with the shareable draft pr

@mbabker actually if you think the back end as an app, then you would like to defer whatever possible to js (e.g. vue). I know, it's out of joomla's interests...

Different approaches I guess. I've always tried to make my resulting markup/structure/output at least usable as much as practical without relying on JavaScript. Obviously that's not always possible (unless you do something goofy like wrap an entire modal in a <form> tag so you can have the modal buttons which usually render in a disconnected element from the main modal body trigger the right behavior).

Anywho, now that I've sidetracked this with my functional JavaScript versus display JavaScript rambling, I'm going back to hacking more JavaScript together and offering a sacrifice to the UI people in the process.

progressive disclosure is the only solution but it has always been rejected

• despite it being a very old and common ui pattern.
  https://www.nngroup.com/articles/progressive-disclosure/

Technically we sort of do this with the search button now. Clicking it reveals a bunch of stuff you couldn't see before clicking it. Sometimes I hate it, other times I'm glad all that stuff isn't always showing. Whatever we do, someone will get upset :)

Yes that is correct the search tools is Progressive disclosure and we
should have more. ;)

Just getting a chance to look at this. I like all the ideas, however there may a more simple solution to consider for now. Maybe not the most perfect solution, but not an overly difficult adjustment to make.

On desktop, the options and help buttons have a right float on them, which switches to no float at 767px. We could simply make it float:none all the time and then those two buttons would behave exactly as the others do.

#toolbar #toolbar-options, #toolbar #toolbar-help { float: none; }

With Float:

Without Float:

I'm not entirely sure why those two buttons are floated and the others are not, but it's inconsistent and it's causing the issue in question here. Personally, I don't think we need to re-invent the wheel to fix this one in the short term.

If anything else, we could look at the media query breakpoints. Those could be adjusted to control when and where the buttons begin to stack. Just my opinion :)

I'm not entirely sure why those two buttons are floated and the others are not, but it's inconsistent and it's causing the issue in question here.

It was decided to separate options and help from the rest of the toolbar icons for some reason (I don't remember anymore but it was purposeful and honestly it's not that terrible as long as you're at a viewport where it works right). Also to lump in with JToolbar being in as desperate need for attention as it is, there isn't a way to pass in classes anywhere in the toolbar API.

If anything else, we could look at the media query breakpoints.

The 4 Bootstrap viewports obviously aren't enough for our needs but given how long 3.x has been around I'd almost suggest not trying to add additional breakpoints for different behaviors to the template at this point. I've had to clean enough bad templates that had random breakpoints causing inconsistent displays than I care to count (there was once upon a time our own website template had different behaviors at 978, 979, 980, and 981px simply because of inconsistent implementations and not to mention the random breakpoint at 737px for the mega menu when the rest of the mobile breakpoint was at 767px).

I still feel like it's button overload, and a few drop down type options or a system where on a huge screen it's got all the buttons, but as it shrinks they collapse into an actions drop menu might be better.

Another thing playing into the issue is the width of Bootstrap's buttons. Let's go back into history with Bluestork:

Even sharing a row with the page title, unless you had a heavy excess of buttons or really lengthy titles, this issue just didn't exist. Granted the template wasn't responsive, but down to 980px things were just fine.

We've added two buttons to the toolbar, moved the toolbar to a dedicated row, and because of things like the New button being 152px wide versus 49px in Bluestork, we've created new issues.

I forgot about that. Those stacked buttons look old, but the idea is still valid as they DO take up a heck of a lot less space.

I get the intent after thinking about it, the help & options are meant to be on the right. But we don't have enough real estate and this isn't the way to do it.

Since every button has an #ID, we can target it easily through CSS or JS. Or we could put an HTML container around those two buttons.

We can do break points anywhere we need them if they only affect our code. We aren't necessarily forced to use only the standard break points, we can add to them if we need to.

I think the buttons are a bit much, the question is: do we want to rethink it now, or make small adjustments and rethink it later?

What about being a bit radical in terms of help and settings? Make them just icons and ditch the text since the icons are very prominent and used in the correct scenario you can understand them.

@tonypartridge - Icons only is a very bad idea. Icons do not always define what a button does.

Prime example being the "Batch" button. It's a solid square......not very descriptive

That's why I suggested it for ONLY the help and settings buttons @C-Lodder. Tit would free up space

You're then looking at inconsistancy :/

Good point, I was being short sighted with just reducing space.

On Wed, 7 Dec 2016 at 09:11, Lodder notifications@github.com wrote:

You're then looking at inconsistancy :/

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglvbQ8wZyf4g9pM9KpSRL9S-di5q8ks5rFnhTgaJpZM4Kql0Z
.

Since every button has an #ID, we can target it easily through CSS or JS. Or we could put an HTML container around those two buttons.

What's there now is the same as if we had pull-right classes on those buttons or putting them in a container that had a pull-right class. But again, the JToolbar API sucks and there isn't a way to group buttons into a bigger HTML container, or add classes to a button in any way but hardcoding it into the layout.

We can do break points anywhere we need them if they only affect our code. We aren't necessarily forced to use only the standard break points, we can add to them if we need to.

I get that totally. I honestly feel like though if we can't work with the four viewports provided by Bootstrap though we're already doing something wrong and personally it just feels inconsistent to introduce additional breakpoints into the UI for a single container.

So it sounds like we need to do things:

1. Come up with a short term fix for now
2. Rewrite the JToolbar API for the future (or replace it with something entirely new)

Ya know, sometimes I wish as much time went into real code and architecture issues as it does discussing how "ugly" a two-line toolbar is ?

haha yeah, I wish I could code. It sucks when you're not a coder as anything I submit has to be mock ups and ideas.

@mbabker I bet you couldn't code up a new toolbar by next week.......

This is the J4 repo so no we dont want to create a quick fix. That would be
counterproductive

On 7 December 2016 at 14:18, Tony Partridge notifications@github.com
wrote:

@mbabker https://github.com/mbabker I bet you couldn't code it up a new
toolbar by next week.......

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8W_XHsXg4Dhr6gi6cmXQPw8enAHmks5rFsBRgaJpZM4Kql0Z
.

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

You're right, got far too much to do otherwise and any attempt I would make at rewriting JToolbar would have next to zero backward compatibility because its API is the purest form of ? that can be found in the development ecosystem today.

• Inconsistent method signatures on fetchButton() methods
• Inability to inject anything into most buttons
• A lot of call_user_func_array() and func_get_args() magic with undefined parameter lists (goto point 1)

Reverse phycology works well on my 2 year old... doh!

I would propose if we decide a new Toolbar we legacy the old one with the
current support as shown looking pants. And allow the 'active' developers to
utilise the new one.

Funny enough, I'm just extending and re-writing the JToolbar and JSidebar for
our component to get a particular look as we can't pass in addition options.

I get that totally. I honestly feel like though if we can't work with the four viewports provided by Bootstrap though we're already doing something wrong and personally it just feels inconsistent to introduce additional breakpoints into the UI for a single container.

That's not entirely true, maybe it was when BS2 was introduced but not necessarily today. Finding and dealing with custom breakpoints for unique situations is fairly standard responsive design practice. If we stick with the standard points, we could just move the breakpoint so it only floats on 1200+ instead of 767+

3.7 will be a big release but it's still considered a minor release and it's been this way for a long time. Changes are definitely coming in 4, but do we have time to put them into 3.7? Either way is fine with me, I'm just being practical as always :)

My design skills are always 3 or 4 years behind (considering my degree is technically in web design, that's not something I should be proud of), so never take what I say as the word from the gospel. I have a hard enough time remembering 4 general breakpoints, don't ask me to remember that a toolbar container has additional breakpoints as well.

I understand, you can do things I'll never be able to do, we're all good at different things. We should keep in mind how old BS2 is, things have changed a lot since then. Many popular modern techniques are specifically designed to deal with these kinds of situations because there is no "one size fits all" answer.

There are a number of easy adjustments we could make to deal with this in the short term. We could also dig into this and make major changes to the interface. My only concern is the time frame and the amount of work we'll be looking at.

Here are a few crude mockups of some concepts we can consider. Please excuse the quality, it's been a long day and just wanted to get something up here.

The basic premise is consolidation. This one keeps a few critical items at the top and moves the rest under a dropdown.

This one moves everything under a dropdown other than "New"

This one is about as simple as it gets. The second variation has a few different options in top bar to mix it up.

Another possible variation

This one is a kitchen sink of ideas. It moves the filters and search closer to the criteria, which might help people understand the functionality. It also explores adding additional sort options, I've always wanted more date sorting options personally, but that concept could also apply to other criteria. Maybe we could let people choose what they want to see and what controls they want, or maybe that's out the scope of this issue, it's just an idea I've been kicking around.

There's 1000 ways we could do this. We also could do some simple CSS tweaks, but I'd prefer to go in the direction of future releases to smooth the transition between 3 and 4. Again, the timeframe is definitely a factor.

Regardless of my opinion, I think this is perfect A/B testing scenario material and I think we should take it to our users. Setting up a solid usability testing system on a zero dollar budget is a challenge, but we can get something out for this in the next week. Any thoughts, feedback or other ideas in the meantime are appreciated.

Some interesting ideas @cliff I think a more direct option would be good
I.e. Hiding them all and calling t batch options since this is what the
options really are for. All in one drop down is good. Then if we edit each
row to have a publish icon, edit icon and delete.

@cliff can you add Brian peat to this Git account, he has some interesting
ideas for J4UX and whilst he can't code his opinion would be good.

On Fri, 16 Dec 2016 at 10:26, Cliff notifications@github.com wrote:

Here are a few crude mockups of some concepts we can consider. Please
excuse the quality, it's been a long day and just wanted to get something
up here.

The basic premise is consolidation. This one keeps a few critical items at
the top and moves the rest under a dropdown.

[image: simple toolbar 01]
https://cloud.githubusercontent.com/assets/3790835/21259121/38c4699c-c33d-11e6-9d41-0fc40911f85e.png

This one moves everything under a dropdown other than "New"

[image: simple toolbar 01a]
https://cloud.githubusercontent.com/assets/3790835/21259138/5141cb04-c33d-11e6-9d93-3a2824d66cb5.png

This one is about as simple as it gets. The second variation has a few
different options in top bar to mix it up.

[image: simple toolbar 02]
https://cloud.githubusercontent.com/assets/3790835/21259197/a02c7872-c33d-11e6-9eca-1061f1fa7d4d.png

Another possible variation

[image: simple toolbar 03]
https://cloud.githubusercontent.com/assets/3790835/21259268/db884360-c33d-11e6-9954-38cf586c91b4.png

This one is a kitchen sink of ideas. It moves the filters and search
closer to the criteria, which might help people understand the
functionality. It also explores adding additional sort options, I've always
wanted more date sorting options personally, but that concept could also
apply to other criteria. Maybe we could let people choose what they want to
see and what controls they want, or maybe that's out the scope of this
issue, it's just an idea I've been kicking around.

[image: assorted toolbar ideas]
https://cloud.githubusercontent.com/assets/3790835/21259291/f1cd0a02-c33d-11e6-97cb-3ba010cfc78e.png

There's 1000 ways we could do this. We also could do some simple CSS
tweaks, but I'd prefer to go in the direction of future releases to smooth
the transition between 3 and 4. Again, the timeframe is definitely a factor.

Regardless of my opinion, I think this is perfect A/B testing scenario
material and I think we should take it to our users. Setting up a solid
usability testing system on a zero dollar budget is a challenge, but we can
get something out for this in the next week. Any thoughts, feedback or
other ideas in the meantime are appreciated.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglv47Z1hnGGwN8OJCCWq7fcG66HkEks5rImdxgaJpZM4Kql0Z
.

@cpfeifer You cannot A/B this scenario. There is very little in Joomla! we can truly A/B test as the end result will always be the same, where the user achieves what they intended. You can ask users their opinion on which is best but that is a different thing to A/B testing.

Personally I don't like the mix of toolbar and filters. Simplification and consolidation should be done with some clear plan (in this case what are the pros and cons by doing that?).
Also from a UX perspective a drop down (extra click to reveal the available actions) is harder than what we have (which is broken for smaller screens)....
Obviously this is a hard to solve problem, that's the reason the previous UX team didn't found an acceptable solution

Do we have any stats on the usage of the bulk options within the toolbar?

I can't see it being used much..

On Fri, 16 Dec 2016 at 14:52, Dimitri Grammatikogianni <
notifications@github.com> wrote:

Personally I don't like the mix of toolbar and filters. Simplification and
consolidation should be done with some clear plan (in this case what are
the pros and cons by doing that?).

Also from a UX perspective a drop down (extra click to reveal the
available actions) is harder than what we have (which is broken for smaller
screens)....

Obviously this is a hard to solve problem, that's the reason the previous
UX team didn't found an acceptable solution

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglvkz1IhhG2a5A6d3b606Ni09ibF2ks5rIqWggaJpZM4Kql0Z
.

These are all just ideas that were quickly thrown together, but we need to start this conversation somewhere. It isn't just about this one issue, it applies to future versions of Joomla as well and we'll have to deal with it at some point.

The reality is we don't have any user data on the interface controls and that's what we're trying to change. All of the buttons are useful and most of us appreciate the amount of control Joomla offers, some buttons are more used than others. If we are going to stash buttons or consolidate controls they should be lesser used buttons and we should have the most used buttons front and center. We just need to find out exactly which controls are the most important to our users as a whole.

I've got some ideas for turning around some quick data regarding interface buttons and getting some workflow feedback. Getting our user testing going is my plan for the weekend, we need something in place for every project and issue. We'll never all agree on a solution, user feedback can provide a direction.

Honestly, some of the buttons don't even make sense. In a list view, Edit only works if you select a single item, yet we continue to leave it in because I guess it makes people feel better to see it there? I mean I suppose there are users who don't click the title and instead check the box and then click edit? No idea.

I was thinking the same thing last night. As far I know you can't edit multiple articles through a selection, but maybe I'm missing something.

The edit button seems like it would be important because it's right next to the "new" button, but only time I've ever used it was 10 seconds ago to see what happened if I selected more than 1 article. In my opinion it's fairly useless, it just adds a click to do something you can do easier without it. Maybe there is a good reason for it to be there like that but I don't know what that reason is.

We have considered removing the edit button and instead adding an indicator to article items when hovered. Something like the following....

I love this, a great and simple visual indicator.

One button less to deal with in the toolbar gives us that much more real estate to work with.

The biggest concern with this was accessibility and how to handle it on touch devices (no hover). Can we presume that mobile users will know to click the title to edit. A possible work around is to always display the icon below a certain screen size although this may look a little busy.

I was thinking the same thing, I don't think it's necessary on anything smaller than desktop personally, but it's a nice touch. However it is implemented, it should never get in the way of anything else but I really like the concept.

We can show it be default on movil devices. Or even, always show it. It's
quite common to show an edit icon on the row
On Fri, 16 Dec 2016 at 22:12, Cliff notifications@github.com wrote:

I was thinking the same thing, I don't think it's necessary on anything
smaller than desktop personally, but it's a nice touch. However it is
implemented, it should never get in the way of anything else but I really
like the concept.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVgllJw7C9Xj74Hl__o3_lGOgSynwY9ks5rIwzagaJpZM4Kql0Z
.

@tonypartridge @cpfeifer I think we should sync at some point. It's quite annoying to see people trying to solve problems that are already fixed (or some possible solution are already considered) elsewhere...

@dgt41 There is definitely a disconnect between the backend project and the UX team, we have no idea where you're at or what has been done or is what is planned.

I was asked to provide input on this issue yesterday and I was asked by George to whip up some mockups. Nothing is being worked on officially, it's just ideas. Personally, I find it frustrating to be asked for input then be told that it's already being worked on when I put something together. It's not a productive approach.

If there is a proposed solution to consider I would love to see it. I have not seen anything relating to this issue other than this thread.

This thread speaks of the wrapping of buttons

I argue that a more important UX issue, is that the -number- of buttons,
they are getting to be too many,
and scanning them horizontally to find something is a little tiresome

Anything to reduce the number of buttons shown will be good,

e.g. the above mentioned proposals:
-- remove the "Edit" button, and always show an edit icon next to the titles
-- move all state / status buttons to a drop down "State / Status",

i know this last one requires 2 clicks, but i think this can be faster / less tiresome that seeing all these buttons there on the toolbar and scanning it to find the right button, it looks a little intimidating / complex to me

Just the archive / trash buttons should (probably) be out of the drop down ! and the publish / unpublish / Feature / Unfeature / (and Checkin) be moved under it

PR to remove edit button and add inline icon on hover.. #13250

We are conducting user research and testing on the article interface buttons this week. Once we have some user feedback we'll be able to provide a better direction for this particular issue.

Can you give us a bit more info for the user research and the testing part? (testing means that you already have some proposed solutions? Are those available somewhere?)

We are in the process of implementing testing environments and our research team is creating materials to address this issue specifically. It is a top priority and I will share more information as it becomes available.

it has been three months since you said you conducted the user research. did you do it? What were the results?

Initial testing and feedback testing provided generally inconclusive results. Most of these buttons are useful under various circumstances. The only button that stands out is the edit button which has no batch functionality and I have yet to encounter anyone who ever uses it.

Bottom line, this is not a UX issue. It’s a minor responsive design issue which is the result of a design change. The new design looks very nice but the slightly larger buttons is bringing attention to something that has gone unnoticed until now in the 3.x series.

The answer to this issue in my opinion is adjusting the design. I don’t feel this particular issue is cause to redevelop the entire toolbar at this time. I think it should be redeveloped, but I don’t think this is the right time to it. We’re throwing a lot of new stuff at our users in this release, but it is a minor release so we need to be mindful of making drastic changes to familiar work flow controls.

We are launching workflow related use case studies this week which will include scenarios utilizing these features. These are features we all appreciate, but they are really only applicable to larger sites and more advanced users, so we need to perform more advanced research and that is what we’re doing for the rest of the month.

For now, I’ve got PR with some simple style adjustments. I think this direction or something similar is the best solution for now. We’re all overworked and understaffed, and we don’t need to reinvent this wheel right now. We can certainly do more in future releases and that’s the plan.

For now, I’ve got PR with some simple style adjustments

Please provide the PR so the Issue can be closed and referenced to it.

We’re all overworked and understaffed

Easily fixed... this is open source development...

Our new interface survey is live, you can help us by taking it and sharing it.
https://ux.joomla.org/content-management-survey

The initial results from our testing phase are attached. As you can see there isn't necessarily a clear path to follow here. Some buttons jump out as not being particularly valuable, but that's about it. We'll be running this for a few weeks and we'll see what we get. Again, I recommend touching up the styling for now, there is no other absolute solution for 3.7.
JUX04-survey-testing-results.pdf

If you want the UX team to go faster, join the team and help us. That's the only way anything will change.

Grouping is a great idea IMO. Of course grouping items really close in actions (like the save). I hope it's not a hover action, though, but a proper click...

i am closing this due to inactivity plus the original posters comment about shareable draft buttons is no longer relevant as that feature has not been implemented