Can we start discussing some UI aspects of this proposal?

Largely the time to discuss the UI was when the design proposals got released nearly 18 months ago in December 2017. So basically no unless it's minor things.

It should also be noted that the installation template was updated. This is not just the administrative interface.

Ahh, yes, I updated the intro post. The installation template is heavily dependend on the backend template (sharing the same CSS), so we had to take care of both.

It should be pointed out that both @zwiastunsw and myself have expressed several accessibility concerns with the quickicons on the home dashboard

I consider this Home Dashboard as a full mess. Is that out of debate?
For example:
Update Checks should always be prominent and, if any one really wants to add the redundant icons through the same parameters available in the 3 different modules (Site, System, Update Checks ) Update Checks should always be on top.

IMHO, Update Checks should just be alone, with the real Updates and nothing else. Its default order should be first among position icon.

Where can I find an installable version?

Where can I find an installable version?

@TobsBobs Download:
Sorry, misleading Information @TobsBobs, please read comments below.

@franz-wohlkoenig
https://github.com/bembelimen/joomla-cms/tree/backend-template

+ Module quickicon loads the Select module page depending on the filter state in the modules Manager, therefore can display Admin modules when the common use would be Site Modules

Monochrome option in the template does not work joomla/backend-template#348

Keyboard navigation of search tools does not follow expected path - this is an a11y fail
joomla/backend-template#310

@infograf768 re the quickicons - you are not alone. they really are a clusterf.... of usability and accessability See joomla/backend-template#115

Repeating it here because it will be lost on the other repo.
Most of the changes in this PR were committed directly in to the template repo without any usable commit message and zero testing .
Thats why there have already been so many correction comments

There are also a number of changes here that are not template related and as many/most of them were committed directly it is going to be challenging to test them all. Especially critical things such as login

User status on edit user seems a little backwards.

That was nothing to do with this PR - created a fix here #25575

Largely the time to discuss the UI was when the design proposals got released nearly 18 months ago in December 2017. So basically no unless it's minor things.

Except that there are many aspects of this code that do NOT match the design proposals - in fact I find only one image from the proposal https://magazine.joomla.org/issues/issue-nov-2017/item/3289-episode-iv-a-new-user-interface-for-the-joomla-backend that matches

Largely the time to discuss the UI was when the design proposals got released nearly 18 months ago in December 2017. So basically no unless it's minor things.

As you can see taking this one example. There was considerable objection to the "marketing" in the help screen. So there was discussion it was just ignored
#21990

https://developer.joomla.org/backend-template/ Nightly builds for the backend template

For @TobsBobs and others who want it for testing

as i can test changing bootstrap grid for dashboard module doesn't works :
1 edit quickicon module
2 set bootstrap size to 12
=> no change module is display in 1/2

I like the view and the behavior of the new template very well. Thank you for this.

I just installed the nightly build.

What I noticed is:

The options tab are broken in my case:

This issues still exist in my case:
joomla/backend-template#302
joomla/backend-template#332
Screenshots from the nightly build.

Some OK:

Some not OK:

I tested it on ubunut 18.04 in Firefox on a notebook with the resolution 1366x768

What needs to be fixed

the logo for login page have an heigh

Why this should be fixed

disable height is better

Steps to reproduce the issue

Edit atum primary color like 105
Save and reload

Expected result

color seating need be 105

Actual result

color setting is always 207

Quick icon on dashboard
#25579

Search and filter in backend
#25582

What needs to be fixed

new dashboard add 2 buttons
1 for list
1 for add
but i think the design isn't good because too many button in same zone, different size, different design ...

Why this should be fixed

Maybe when have more consistent design to use same systeme like media manager

Need to check if accessibility is good ..

=> i do it with simple css modfication (i am not great css writter i didn't push code) no html change ..
for me have 2 same labels for each button isn't good for acessibility. ex users button to user list and an other button user to add isn't consistent..
its a detail but its the first screen for every user
maybe this can be better

@coolcat-creations @bembelimen what do you think ?

What needs to be fixed

hello i like new administration template it realy good first step !!!
i like the idea that joomla will be more simple and usefull (group button, group action)

Why this should be fixed

i think we can do more with filter and search ... many time user doesn't use it realy i think. It a big block for nothing at first

How would you fix it

Maybe we can move this bar in action zone hide search input

or maybe more
put all in a search and filter button

@micker I can only speak for myself that I and my customers use the searchbox a lot - usertesting could reveal if thats generally the case.

@coolcat-creations i didn't the global answer too... lol
maybe we can group number + order in filtering zone for me its a filtering take search outside
we will win space, more usuable admin i think

@alikon You mentioned the default null date for postgresql in your review. But how about MySQL? In the code of this PR here '0000-00-00 00:00:00' is used everywhere for MySQL, but hasn't that changed to '1000-01-01 00:00:00' with some MySQL version lower than the minimum for 4.0?

@richard67 should be better to start in 4.x with '1001-01-01 00:00:00' imho that's why i've made #25461, but seems few people care about db's stuff

other return :
1 logo
when we use custom logo in admin, joomla logo is changed that cool but when we collaps the left menu this logo is change for joomla! logo. In fact its a good idea to change but for user it's not very good. Old user already know that joomla logo go to principal dashboard but new user need to understand ... it can be good to use an home or dashboard icon ?

Dashboard
its realy a good adding dashboard and subdashoard, the adding button on bottom is pretty cool ! but we have an no finished function... did you plan to add drag and drop ordering and rezize width ?

Thanks for team works

@micker there are THREE logo fields in the template style to give you maximum flexibility and to fix your problems I think

@brianteeman .. ahh i forgot we arlready have 3 fileds ? maybe its not realy necessary because need to create a very small logo but you are right its the most flexible

The reason that rows have borders is to help with the readability. They prevent your eyes from wandering on to a different line when you scan from left to right etc.

If you look at the border on the new template admin modules it is so light that it might as well not be there and the extra white space due to the increased row height and reduced font size make it so much harder to read.

Current Template

New Template

It is even worse on full width list views that do not have a lot of columns

https://alistapart.com/article/web-typography-tables/

"Designing Tables to be Read, Not Looked At" Avoid using row or column borders unless the data alignment, spacing and grouping are not sufficient to guide your reader’s eye. If you do need to use rules for this purpose, use them in one direction only and employ a lighter colour to reduce the impact of the lines: you are making a distinction, not constructing a barricade.

Thank you for confirming exactly what I said. That article also says to avoid zebra striping and yet almost every example in the article is using zebra stripes

I actually did not confirm it, the article says to avoid using borders.
The change was made due to users feedback. Just saying.

https://design-tips.caneco.xyz/
https://design-tips.caneco.xyz/20170816/

unless the data alignment, spacing and grouping are not sufficient to guide your reader’s eye. If

IMHO this layout is completely sufficient to lead a readers eye - its more calm, has more spacing, less clutter, much easier to read and less disturbing. Only way to find out the truth is to do some user testing with a significant large group and A/B tests.

@richard67 should be better to start in 4.x with '1001-01-01 00:00:00' imho that's why i've made #25461, but seems few people care about db's stuff

@mbabker Why were you confused about this? Is it wrong?

Lets merge it and work from this point, with such a bit PR (change) we can discuss to the end of the world or later.

@rdeutz that goes against everything you said when the private repo was created.

If you merge, please merge with 1 commit only. If you merge the complete commit history, our CI tests will be busy for the next 100 years ;-)

@rdeutz that goes against everything you said when the private repo was created.

no

@richard67 we squash PR's usually

This work will at one point be made available to the public and also be open for criticism and after another (hopefully short) round of iterations, can be accepted into the Joomla project as the finished Joomla 4.0 backend template.

So you propose merging this template (that does not match the original design proposal) as is without comment or iteration :(

It was available to the public for a long time now before the PR was created....?

@brianteeman as long there is no more than border colors to discuss I am for merging it. And btw. this is now for months publicly available.

If you merge, please merge with 1 commit only. If you merge the complete commit history, our CI tests will be busy for the next 100 years ;-)

This would be exactly one build. The builds are not run for every single commit, but per push.

There are lots of review comments and they do not all deal only with code style. It is a bit work to click the "Load more ..." button so often and then go through all of it.

Especially the review comments from @C-Lodder were not dealing with border color stuff only.

None of these reviews was corrected or even answered here up to now.

@richard67 I see this from a practical point of view, we can now spend time on fixing merge conflicts or say comments are vaild lets work on smaller PR to sort things out.

if you remember the repository started as private because quite frankly you did not want ongoing feedback and review from people qualified to do so.

No I don't remember because this was not the reason. What I wanted was a save environment for a new team to work together and not to be in cross fire from people who are always in the frontline when it comes to share opinions in the most friendly way possible.

@rdeutz Then I was working in the wrong way all the time. I got used to the practice that we review a PR, test it when ready for test, and then merge it when all good. Now it seems to become different.

To be honest, I am not sure if anybody will check any old comment here when this PR is merged, and so the issues will come up slowly one by one. And we will make then 20 new small pr, need to review, test again, and so on, and maybe the one or other issue will be forgotten and not be handled.

I've heard we wanna go beta soon. If you have 20 or 30 additional testers then ok, let's go, let's merge this and proceed as desired.

Have you seen how few people we are here who are regularly testing?

Check the people's activity in the issue tracker menu.

I think it would save us time if the people from the template team go through the reviews here and fix them. And then we test this, and then it can be merged. But maybe I am just too old-fashioned.

First of all thank you all for your comments. There are a lot of them valid and we will try to respond and fix as many as possible. I also want to thank people that you all stayed rather civil and I personally have expected a much worse discussion. ?

If you look higher up, a few of the review comments have already been fixed in the code. Please give us some more time to address more and to mark them in this thread accordingly. The people doing this currently have personal commitments, but will get back to this as soon as possible.

The backend template team has no interest in merging this prematurely.

Unless there's intention to remove copy template function, template namespacing here is completely broken.

@rdeutz @coolcat-creations I am well aware that the repository was open (if not publicised) as I created 83 bug reports, 16 pull requests and countless tests and code corrections and if you notice I am thanked in the initial post here.. But I guess that was while you were both absent from the repo. So before attacking people it would make sense to get your facts right.

@Hackwar Thanks - we can always count on you for a sensible comment

@ALL If this proposal was what was actually proposed originally then there would be little need for comment and it could simply have been reviewed for code quality. Sadly thats not the case at all.

Final comment - the objections of the accessibility team leader have also been ignored/rejected

Not code related but not less heartfelt @bembelimen @coolcat-creations, @svom, @chmst , @Hackwar, @nadjak77, @fancyFranci, @lavipr, @rdeutz and @karo3 thank you very much for your great effort in making this happen

Not sure why the Hound bot isn't doing its job properly. Doesn't seem to be detecting any code style issues in the SCSS

@bembelimen
Please modify administrator mod_version VersionHelper
Use

abstract class VersionHelper
{
	/**
	 * Get the Joomla version number.
	 *
	 * @return  string  String containing the current Joomla version.
	 */
	public static function getVersion()
	{
		$version = new Version;

		return '‎' . $version->getShortVersion();
	}
}

This will solve the redundant Joomla! as @mbabker remarked above and also RTL
We should get this in LTR and RTL

Fetching those 2 (non existing?) images on each window resize is probably dumb... Also because I'm totaly stupid, can somebody explain me the benefits of using AJAX for the login form? Lastly, did anyone actually reviewed that script from a security point of view?

Why is there an embedded delay of 300ms on each page rendering? This is against common sense, people try to create fast responding UI's not delaying the loading of every page on purpose...

All right, one last comment here...

The performance of the new template is really disapointing:

Comparing to the current one:

So I did some digging and found out that this:

is the bottleneck.

As a minimum action, this code (the helper + all the libraries) should be removed and reimplemented in a more static fashion (eg create the css vars as a static css file on style save or something similar).
@wilsonge this should be considered a merge blocking issue (IMHO)

@bembelimen
Keeping $version::PRODUCT does not solve the issue in RTL by just adding the indicator....
It gives

If you absolutely want to keep the term Joomla! then, as I have explained in details above (so far above I can't find it anymore), you need to modify the _header.scss

      .joomlaversion {
        min-width: 6.6rem;
      }

to

      .joomlaversion {
        min-width: 6.6rem;
        direction: ltr;
      }

One will get:

Evidently, no use to modify anymore the VersionHelper when the css is corrected.

@dgrammatiko could you please verify that you NOT had throttling activated for the new backend template and NO throttling for the old one?

@bembelimen I assume it was on a simulated 3G connection which is what we do all of our performance tests on.

That is what you should be aiming for

@bembelimen I assume it was on a simulated 3G connection which is what we do all of our performance tests on.

That is what you should be aiming for

Yes, ofc, but my suspicion is: one test was made with throttling on the other with throttling off...

@bembelimen I doubt it. The first thing i did when viewing the new template was to run a performance test compared to the current template. Results are pretty much the same....give or take 1-2%

Why is FontAwesome and Bootstrap included in template.css?

Copied template is broken:

@bembelimen it's a standard process on chrome/edge(beta) without me playing around with the settings. Also, I suspect I'm one of the lucky ones to have the lastest and greatest Mackbook Pro. So...

Anyways, please undo the animation part for the wrapper, etc and roll back this colour helper with all the external libraries introduced as a minimum to bring back the performance to acceptable levels

All right, one last comment here...

The performance of the new template is really disapointing:

Comparing to the current one:

I can not replicate this. I've now run ~30 of these audit runs (to prevent any issues with load on my machine, etc.), 10 on the current 4.0-dev template, 10 on this PR, 10 on this PR with the helpers commented. I checked this on the home dashboard on new, clean installations.

The results were always the same: There is a slight difference (nearly in the range of measuring error) between the old and the new template, but none when commenting those helper files (and thus disabling the animation) and leaving them in.

In my tests right now, this template performs better than what we currently have in 4.0-dev. This is not a merge blocker. You maybe should check your tests again.

You maybe should check your tests again.

Sure, just make sure you use Simulated Fast 3G, 4x CPU Slowdown and most importantly enable Clear Storage. It goes without saying that in the Network tab you have checked the Disable caching...

You maybe should check your tests again.

Sure, just make sure you use Simulated Fast 3G, 4x CPU Slowdown and most importantly enable Clear Storage. It goes without saying that in the Network tab you have checked the Disable caching...

Yes, I did.

I mean, do you think I can't see the difference between the template having animations during the tests and not having animations?

@bembelimen @Hackwar @wilsonge you know what? Just ignore me and ship it!

@mbabker The question is, if this is related to the helpers and animation, as @dgrammatiko claims and I can't replicate that. There is no difference at all with and without the animations (and the helpers).

Also please be aware that the default dashboard has different loads in 4.0-dev and this PR.

I'm not doing a comparison between current branch and this pull request, I'm strictly running this pull request. The point here though is there is a performance concern based on these benchmarks. I don't have the time to do any other experiments, but I can confirm @dgrammatiko results on my system.

Hello @mbabker thanks for looking into this PR. Just two comment why I think your "tests" are not valid.
First, as @Hackwar mentioned, the discussion is not about if the edit screen is slow but if the slowness is caused by this helper file (and as we have no 3 proves: no it's not => so @dgrammatiko tests are wrong).

The second question is now: is the edit screen slower than before?
And comparing the old template (in current 4.0-dev) and the one from this PR I also can say: no difference. On both templates the edit screens are slow.

So my conclusion is: the new template is not significant slower than the old one....but the edit screen should perhaps be tackled in another PR (independend from the template).

Sorry @mbabker do you really want to talk on this level? As stated above: I agree with: "the edit screen is slow", no questions here, this should be fixed, but not in this template PR, because the problem is not releated to the template, as assumed. So commenting out the helper file does NOT solve the slow edit screen, so the tests which "proves" that everything is the helpers files fault is wrong.

Last comment then I'm unsubscribing since it now seems you want to go out of your way to discredit myself and @dgrammatiko.

As I said, I did not do any major experiments with disabling features added to the template. I simply ran the Lighthouse test and validated @dgrammatiko results in that the performance is below acceptable, a test report which it seems people want to write off as invalid. I do not know if this is a regression from the current version of the template, and unless someone is going to pay my company's hourly fee for consulting services I am not doing any more testing of this template thanks to the attitude in this pull request. I tried to do the one thing nobody would when I wanted to get 3.9 released, test the major feature, and you all want to basically say "thanks but you're wrong". So, yeah, I'm done here.

Regardless if there is a measurable performance penalty or not, it would make sense to look into creating a static templatestyle specific CSS file during templatestyle save and load that during pageload.
I do that already in J3 for my own template (using a system plugin on the onExtensionAfterSave event). I think it should be reasonably simple to add that technic to core.

1. I have been unable to replicate the test findings. Perhaps some difference in the LAMP stack - I dont know but there is clearly something causing those test findings. The only other explanation is that the images are fake and obviously thats not the case.
2. The color functionality really doesnt work well. I have already commented several times that the monochrome option does not make it monochrome but I now see that other settings such as hue do not truly apply a hue to the site.

Thought I'd share my research on this too.

• Windows 10
• Chrome 75.0.3770.142 (Incognito mode and no 3rd party extensions)
• Lighthouse 4.3.1
  • Device: Mobile
  • Throttling: Simulated Fast 3G
  • Clear Storage: Enabled
• Wampserver

Dashboard

List view

Edit view

In my opinion, none of these are acceptable.

Just by moving 2 single lines:

<jdoc:include type="styles" />
<jdoc:include type="scripts" />

to just before the closing </body> tag, I was getting 80.

Things I'd suggest to be changed:

1. Move CSS/JS to before the closing body tag or truely async load it (by this I do not mean add the async attribute)
2. Use SVG's for icons as opposed to Font Awesome
3. Remove the poorly performing code that changes the opacity pretty much all nodes on the page (here: https://github.com/joomla/joomla-cms/pull/25570/files#diff-8fcf842cab1f27e713458dd9d3890954R67 and here: https://github.com/joomla/joomla-cms/pull/25570/files#diff-1cc50e9b809f51e446bac57823e7b08cR42)
4. I commented above about importing SCSS files for the sake of it and the reply was This is more a "service" for the user. So one could e.g. use carousel in a backend module.. If this is the case, it should be split into separate CSS files and developers can use JHtml which will load the necessary files. The killer for unused CSS in Bootstrap is the utility classes (about 5k lines of CSS). I would seriously suggest looking into this.

@C-Lodder what score do you get on the current template in the edit view

@brianteeman

• Dashboard: 72%
• List view: 54%
• Edit view: 16%
  • Edit view (codemirror): 35%
  • Edit view (no editor): 54%

@C-Lodder I like the idea of the splitted CSS. Would you support us in creating this strucutre?

@bembelimen I'll submit a some commits today if I have time

@bembelimen I'll submit a some commits today if I have time

Thank you very much!

Just by moving 2 single lines:

<jdoc:include type="styles" />
<jdoc:include type="scripts" />

to just before the closing </body> tag, I was getting 80.

Things I'd suggest to be changed:

1. Move CSS/JS to before the closing body tag or truely async load it (by this I do not mean add the `async` attribute)

I moved the scripts to the bottom. I'm honestly not sure about the styles. Because then the DOM will be generated without styling and we have "jumpings" on the page. Perhaps your solution with splitting the CSS could lead to this change, so a base CSS is ("hardcoded") in the head and all the other stuff is in the footer.

This isnt going to work as any inline scripts or scripts added to the head will fail if they are dependent on any of the scripts now loaded at the bottom

@brianteeman If they use addScriptDeclaration() it will work just fine. It's only an issue if they use their own <script> tags

thats what I meant just expressed badly

and even with this change all the JS for the custom elements etc are still loaded in the head

@brianteeman sorry you’re wrong about the custom elements, these are the only scripts that are lazily loaded (if you check the page source you’ll see that those scripts do not exist in the server response, they are populated by JavaScript, also called progressive enhancement)

ok thats good to know

hello i check 75d4e11 but seems doesn't work

@dgrammatiko and @mbabker one thing I want to clearify (which seems to be missunderstood, because of my bad English or because I hadn't enough time to formulate it clearly): I didn't want to discredit you or your tests, they are absolute valid and have to be tackled. What I wanted to say is, that the helper (in my opinion) isn't the cause of the slowness but the system itself.
So I'm very sorry if you felt offended or insulted by me, that was not my intention.

@bembelimen as the monochrome option doesnt work (as previously explained) and the HLS option does not work everywhere that it should maybe just drop it.

@brianteeman the color selector concept is similar to the one in the J! 3 backend template. You can colors for specific areas and they will change, but not all areas. Important things like some buttons etc. will not change.

Could you show me an example where the Hue value fails please? Thx.

@micker thanks for your tests.

hello i check 75d4e11 but seems doesn't work

Could you elaborate a bit more, what you tests, what's the result and what's the expected result? Thx.

The individual colour options are fine - its the hue and monochrome that dont work.

HUE test

Monochrome test

@bembelimen and see this issue for more information about the monochrome option joomla/backend-template#348

@bembelimen sorry its about save principal color after save color return to 207 all the time

Applying filter:grayscale(1); to the body tag will convert everything to monochrome.

@micker this should be already fixed.

i add last patch via patch tester i didn't see any change maybe i do a mistake

@micker Patchtester is not enough.

You need a development environment for testing.

For setting up a testing environment see https://docs.joomla.org/J4.x:Setting_Up_Your_Local_Environment/en. That document is also available in other languages, at least partly translated.

@micker Or you can use a nightly build. See test instructions. @richard67 Please correct me if this is not correct.

@astridx well it needs a development environment as far as I know to run ‘npm install’. And it needs to run the Schema update sql scripts in SQL. I’ve reduced my testing instructions to a link to the doc for J4. Later me or someone else can provide instructions for the rest. It needs 2 test scenarios: 1. New install of the CM/S including the new template stuff, and 2. Update CMS with running the Schema update SQL. Will be long testing instructions if described with every step.

@astridx I just see you meant nightly build of the template’s repo. No idea if this is up to date with latest changes in 4.0-dev.

Regarding the monochrome/hue feature:
Yes, the feature is supposed to color (almost) everything in the given colors. There are however certain exceptions, like signal colors for important messages or for buttons with irreversible actions. That is why some buttons are not also monochrome, like the delete button in your screenshot or the messages. It would be pretty strange if a success message had a red color, just because the current color scheme is red. So keeping certain colors in certain areas is a conscious decision and right now the feature works as it is supposed to.

So keeping certain colors in certain areas is a conscious decision and right now the feature works as it is supposed to.

Then sorry to say but it is wrong. You are using a color to indicate a special meaning and assuming that everyone sees red as you do. By using monochrome I am assuming that everything will be in "shades of grey" and I understand the different shades. Red has no meaning at all to me (nor does green) that is why I switch to monochrome

The monochrome feature seems completely over-engineered considering it can be implemented with a single CSS property. A CSS approach would convert everything to monochrome. It would also allow you to re-define some of the color variables to better contrasting monochrome shades. The current red and green in monochome are indistinguishable from each other.

it is over-engineered because mistakenly they don't want to apply it everywhere

@micker
I made a tut in french on how to test J4 and its dependencies
https://github.com/ghazal/tester-joomla-4

As it seems I need to provide more reasons why changing the hue of the template or making it monochrome should apply globally and not keep red/green buttons try this.

Filters clarify the digital world for the colorblind - https://community.windows.com/en-us/stories/color-filter

If the use case for these features is to improve accessibility then it fails

I agree with you for red/green buttons, but we have made every effort to make sure, that every information is visible indpendent from colours. If you find an element which has information only with colours and has no text and/or icon, please let us know.

@bembelimen for color save is fixed #25570
size of login logo not

width of dashboard module not (set size 12 for icon button, no effect)
small behavior in dropdown button in chrome

thanks your works

just a question to understand some choice ... why did we have full with input its realy strange for eyes ...
for exemple in media manager the deplacement for understand value is realy long

its for acessibility ?

It is terrible for accessibility especially if you have reduced motion or are using a screen magnifier

@micker @brianteeman Cause of this: https://github.com/joomla/joomla-cms/pull/25570/files#diff-4fb62b8a0eddc5883b2258f9cc6fbf1dL68

@brianteeman @C-Lodder sorry i am not sure to understand that necessay or need find an other way ?
because if we need to reduce motion need to reduce size ..

@micker

administrator/templates/atum/scss/_variables.scss (line 68)

$input-max-width: 240px;

was replaced with:

$input-max-width: 100%;

The 100% is causing the problem with the long input widths. It was set to 240px for this specific reason :)

If the use case for these features is to improve accessibility then it fails

It's not, it's just to color different area. But probably we should convert the monochrome option to a A11y feature. So having it off => just color different aspects, switching it on => do the full page in monochrome.
Is setting this CSS filter enough to fullfill the monochrome A11y requirements?

@bembelimen for color save is fixed #25570
size of login logo not

Yep logo is not solved yet, but we have it on the list.

Thanks for reporting.

grrh. computer crashed in the heat right in the middle of a long reply. Not going to type it again. Summary was.
Just drop the library and go with @ciar4n suggestion. It is the correct way to do it. it gives the user the expected experience. it doesnt introduce a11y issues and its more performant

Thanks for making the monochrome change
We still have the same situation with the HUE settings not being applied to everything. It should be applied globally just like monochrome.

The changes #25708 are creating conflicts here. The changes here should have been made in the layout and not in the template files as previously commented

Thanks for making the monochrome change
We still have the same situation with the HUE settings not being applied to everything. It should be applied globally just like monochrome.

No, we don't have. Hue is not for changing every aspect of the page but just explicit ones.

Explicit as per the code but NOT explicit as for the UI.

So the colour options here are supposed to theme the backend template rather than provide an accessibility hue option for the site - so the backend matches the branding of companies. So probably what we need here is to rename the tab to theme settings (or similar). if we additionally want to add hue options for individual users for a11y per the a11y plugin @brianteeman has suggested we can then do that.

@wilsonge The hue option is still wrong. Even with your comment that its to match the branding of a company.

1. As already stated by others it applies to the logo if that is svg
2. It is not applied consistently to UI elements eg
   Help button - hue applied
   Save buttons - hue not applied
   etc
   I would expect it to be at least consistent
   
   
   

OK logo i agree it's a simple fix. joomla/backend-template#406

Buttons in the toolbar I can see your point but seems more complicated. How do we expect these to act. Because the buttons aren't all a uniform colour. And I don't think we can have a dozen colour inputs to determine the style of each one. Having colour options for our templates existed in J3 and I think the same issue exists there? https://github.com/joomla/joomla-cms/blob/staging/administrator/templates/isis/templateDetails.xml#L50-L98 (or at least something quite similar) and this to me is an improvement because we get a11y optimised schemes (usually using the library) for the template rather than people manually selected each section to be give or take the same colour.

Having colour options for our templates existed in J3 and I think the same issue exists there?

No because they

1. Only apply to elements that have colour for decorative purposes
2. Are specific colours not a global hue. Much easier to match your brand that way ;)

At the end of the day - the HUE stuff is the least of the issues with the template style

At the end of the day - the HUE stuff is the least of the issues with the template style

OK So what issues are left here - as I see it there:

1. The quickicon issues have largely been addressed - there's some arguments over whether there should be so many - but the numbers have been removed largely and the mobile fixes are nearly finished (and I believe will be fixed soon)
2. There's some arguments over whether the performance should be fixed too now or whether it's something that can be left until later (fwiw whether i disabled the lines @dgrammatiko mentioned i got 0 differences on my lighthouse report although the performance was bad before and after - but according to lighthouse was dominated by the time of the CSS to load)

I can't see anything else that's been mentioned here that hasn't been addressed and is a serious blocker to merge at this point (i think even the majority of the comments that people have deleted in the post have been addressed at this point)

@wilsonge It would need some test for updating the CMS to see if the schema updates work, but that could also be done later after merge ... I have the feeling anyway that we need to clean up the schema updates a bit before going beta.

If someone would fix the 1 conflicting file we would have a new nightly build of the template repo tomorrow and could test installing and updating the CMS on MySQL and PostgreSQL to see if all SQL is ok.

@wilsonge since you've mentioned me a couple of things here:

• The test I conducted gave me the impression that the colour thingy was the bottleneck (since the only thing was added in the iterated template was the colour thingy I wrongly pointed to that).
• That doesn't mean that as a developer I'm not irritated by seeing this solution as the one that was acceptable.
• How about doing the whole bloody work on the client-side and save the values in the template params? That way you have 0, yes 0 performance penalty and still have the functionality you wanted. Eg https://github.com/bgrins/TinyColor has all the function people used in PHP with exactly the same names, who would have thought that...

@bembelimen apparently, I still didn't get an answer for my 2 other questions:

• What problem are you solving with the ajax login?
• On what facts/metrics/articles/books did you based the 300ms delay on the main content (I mean the useless fade-in animation)?

To save others trying to scroll through 500 messages

• What is $color-xx? - #25570 (comment)
• Remode the sidebar - #25570 (comment)
• Help links - joomla/backend-template#259
• Help links - #21990
• Empty lists - #25570 (comment)
• Add module client - #25570 (comment)
• Filter navigation - joomla/backend-template#310
• codestyle - #25570 (comment)
• codestyle - #25570 (comment)
• codestyle - #25570 (comment)
• quickicon module size #25570 (comment)
• row borders #25570 (comment)
• login css review #25570 (comment)
• import scss #25570 (comment)
• joomla version #25570 (comment)
• full width fields #25570 (comment)
• quick icon a11y joomla/backend-template#115
• performance

I remember discussing this in the template repo but can't find the link now.

When you add a module to any admin dashboard by clicking in the add dashboard module area the newly added module is not displayed until you have refreshed the page. It should be displayed as soon as the user saves the new module

@brianteeman that's an easy fix: trigger a page reload on the modal close. What is interesting though is that people treat Joomla as a Single Page Application (or as a client-side app). It's not (except the media manager and that without the edit page). Thus the animation part on the main content is wrong: you're not replacing parts of a page, you are always loading again the whole page

Hello everyone, I am writing to you here because I am angry and I am not proud of Joomla!

First of all, who I am. I'm not a professional. I use Joomla! out of love for this CMS, out of conviction. I have about ten sites that I have created and that I manage free of charge for friends or associations. I do this out of pleasure, out of a desire to use Joomla! And today it's no longer the case.

You present us these last few days a third template of the Joomla administrator! 4. To my God it's ugly! I understand that it is to make Joomla! compatible with standards. I understand that Joomla! is aimed at professionals. But now I say stop. Joomla! 4 makes me nauseous running around, clicking and clicking. The colours are unbearable. We are attacked, even violated by the disproportion of the buttons.

You are apparently taking the direction of a professional use, or even integrator or developer. If this were the case, you would have started by integrating a backup system, a use or even a configuration of the SEO. You would have long ago set up a complete media manager, with the creation of views of different image sizes for articles, with the creation of image names in relation to the title of the article. You would have integrated a basic social network management system. Without social networks, there is no visible site. You would have allowed multi-category for articles. You would have set up an article template manager based on categories.

You have chosen a direction to attract professionals. But if Wordpress occupies 30% of the net, it is precisely because it is used by professionals. The trend is towards soft, slightly round templates with coloured tips, and a dark mode. Look at Joomlart's new T4. Look around you. There will be no success if the product is not attractive. It can have all the functions of the world. Aesthetics, pleasure and essential on the rest. With this template we have the impression to go back in 2012 with the first version of Windows 8.

I sound an alarm bell here, a cry from the heart, because I am sad to see my CMS become a soulless and heartless gas plant.

@Magnytu2 I think this is the wrong place for your complaint. This PR is about forms and colours of the template, nothing else.

Hello then, I suspected a little, but where can I scream my pain so that it affects the makers of Joomla?

Twitter seems to be a good place these days

Twitter seems to be a good place these days

Nah, that's ignored too.

Apparently it is not obvious to attract the attention of the makers of Joomla! 4

Apparently it is not obvious to attract the attention of the makers of Joomla! 4
There is no such things as "the makers", anybody can participate. Anyhow i wonder how it is the project missed reaching those of you with other/alternative idea's. The basic design idea's were presented years ago and the repository is public for a more than 4months.
What could the project have done to get your feedback and involvement earlier. Note that i'm not trying to assign blame, i'm trying to understand how it could improve

I am the project Joomla! 4 from the beginning. I am perhaps the first to have it installed in France. And the first template was fine. The second asked me questions. But the third, sorry, is the symbol of what not to do. Why not use Joomla 3.9 updates to send messages to users and ask their opinion? I am sorry to express myself here. but I use Google translate and Github and a digital border that is difficult to understand for someone who does not develop. I just want to shout at you my misunderstanding!

I think we discussed this on face-book. Constructive criticism is always welcomed. It should however be precise and actionable.
And unfortunately with a big project like this not everybody can get his/her way.

Having said that i conclude by saying we should be more respect to the people actually putting in a lot of effort and working on "stuff", for free, not just the template

Hello and sorry, I do not want to be disrespectful. I respect most of all, all the people who give for Joomla.
I just want to say that if for 7 years I'm proud of Joomla, and that for 7 years I speak Joomla to my friends. Today this is no longer the case. I have no pleasure to use, to discover Joomla! 4. Until now I was like a little boy in front of his package Christmas presents, before each evolution of the CMS.
Today this is no longer the case.
The community lives on the love of CMS Joomla! If there is no more love, there will be no more community!

Hello, I think @Magnytu2 is right here. Beautiful is the new template not. The proposal from Elisa was nice but nothing is left of it. Nevertheless, thanks to all who worked so hard on it.

@brianteeman Could you mark the 3 codestyle items in your to-do list as done? I just checked, they have been solved with last 3 commits by bembelimen.

The system message in the backend template editor is rather large:

A few CSS tweaks would make it look something like this:

Before I go through the trouble of raising an issue or PR for this, does anyone else agree with this and, if so, raised an issue/PR? Thanks.

In the template editor, the folder icons are not clickable, only the names, i.e. 'css', 'html', 'images', etc., even though the icons change to black from blue when you hover over them. They are clickable in J3.9.10.

Also, in J3.9.10 the file icons are white, which makes them more easily distinguishable from the blue folder icons.

It seems it needs to copy brianteeman 's checklist down here because on deskop it disappears again in the long history, if you don't use the "Show more" button several times.

@bembelimen Am just preparing a PR against this repo for SQL stuff. Stay tuned.

Sorry for the conflicts, my fault: #25805 . I've noticed too late that this PR here fixes that already. Resolve should be easy because source = target.

So at this point all items on @brianteeman 's summary list have been fixed with 3 exceptions

• Help buttons (both links were effectively the same issue so I've closed the one in the template repo joomla/backend-template#259 in favour of #21990 ) and will bring this up in a vote at the next Production meeting (cc @HLeithner )
• Quick icon module size #25570 (comment) - this is definitely a user bug but is kind of expected as we've moved the dashboard onto CSS Grid (as a result for obvious reason the bootstrap classes don't work). Obviously this needs solving - but I'm happy to open that up as a release blocking issue rather than trying to solve it here
• joomla/backend-template#310 the keyboard navigation of the filters - this is something again I'm going to open here as a release blocking issue. This just needs some javascript to deal with moving the tabindex around - I don't think it's a major issue to solve - although is of course important to solve for our a11y requirements
• performance - Actually once you use the gzipped version of the CSS then performance increases quite a lot in lighthouse. plus in my personal opinion whilst we of course want to optimise the backend template as best we can (and we can do things that @dgrammatiko has recommended like preloading fonts and maybe the template css in future PRs) we don't need to optimise it to the extent of the frontend template either - we're not looking to get a top google rated backend template ?

I've also asked some people from the backend template team to look into your comment about the template edit view @Scrabble96 you mentioned here #25570 (comment)

At this point unless any major new issues arise before next wednesday I will look to merge this and immediately tag a new alpha of Joomla 4

We are aware that once this is merged more people will be testing it and new issues will be discovered. That doesn't mean it's buggy or poor quality - it's just an acknowledgement that this was and still is a huge task and it's not possible for a small group of people to test, discover and fix everything

we don't need to optimise it to the extent of the frontend template either - we're not looking to get a top google rated backend template

Performance is not about satisfying some results from a stupid tool! It's all about User Experience. Actually, it's fundamental to UX, because quite simple people -that's all of us- we are impatient, so it's engraved in our DNA. Also since Joomla is an App that actually depends on the network (speed, availability, etc) the performance will always fluctuate, at times getting even worse than the bad scenario that the performance tools set as the bottom line. Also, performance is about being inclusive: wp's edit page will never function at an acceptable level in low powered machines (eg low price android tablets) due to the number of scripts that need to run (hello React!). Keeping an eye at the performance means you care for your users. Also means that you don't consider "potential users" only people from the first world...

@wilsonge please also take care of:

• the useless animation in the main content
• the colorpicker field

You know the drill

Well, regarding animation I agree with @dgrammatiko : It is not something to have in backend.

Maybe I am not really neutral at this point because my job is related to software for controlling enegry transmission and distibution networks, and we never would lose time with animation in such a critical application.

But here I think we can fix that later.

I think now we should wait for the next nightly build on https://developer.joomla.org/backend-template/ which will include the latest changes and then test new installations and updates on MySQL and PostgreSQL in order to see if there are serious issues to be fixed. Other small stuff can be fixed later. Just let's make sure nothing will be forgotten.

Hmm, I just see there is only a nightly build for new install, no update package.

I ran the job manually after I posted that comment by now the nightly build should have that stuff in

@wilsonge Could you provide update package, too? It needs to test updates from 3.9.10, too.

No longer at my machine I’m afraid so no. I’m happy to test the update scripts after this gets merged if required though. If I find time this weekend I’ll get them uploaded. But as it’s the second-last week of gsoc my priority this weekend is now to focus on getting my student ready for the google evaluations

I will see if I can make a patched update package based on 4.0-dev nightly builds. If so, I will provide a link.

@richard67
Is it possible to test an update from 3.9.10 to 4.0 by using the component Joomla Update and uploading the Nightly Build here?

Update is planned from 3.10 > 4.0

@astridx not at this time

@wilsonge please also take care of:

* the useless animation in the main content

* the colorpicker field

You know the drill

Pardon? I think your remark is very impertinent. George is neither your slave nor is this the place to make any demands. If you want to have something change, please feel free to create a PR against my branch.

I agree, that we can remove the animation, please make a PR which removes it + all implications and I will happily merge it.

What exactly is the current problem with the colorpicker field? After we agreed, that the performance issues are not from the helper I don't see any problems here? (I would claim, that there is no mensurable impact).

@bembelimen dude, please take it easy, will you? I'm referring to George because we had a discussion on these issues, he knows what I'm talking about.

About the colorpicker:

• Joomla has already 2 of them, one based on jQuery and totally inaccessible
• There is an open PR for another one
• This PR is introducing also another one, globally and also some composer dependencies.

I think we can do better than that, that's all...

@astridx and others: No, you can't update with the nightly build linked above because that only offers a full install package. But you can find an update package here, I've just built that: https://test5.richard-fath.de/Joomla_4.0.0-alpha11-dev-Development-Update_Package_2019-08-10__backend-template.zip.

Thanks for the explaination, I see the problem you mention.

First of all we had the challange, that we need some hue selection. What we did was: we used the existing colour picker field and extended its functionallit by adding a new layout (not a complet new field). But you're right we have to many colour picker in the system.

TBH I really don't want to lose the color changing functionallity, because it was a great feature in J! 3. So I would rather like to see a improvement of the current implementation instead of a complet removal.

But as I said, I have no feelings for the animation, please feel free to remove it.

And sorry @dgrammatiko that I took your comment the wrong way.

The shadow of the alert does not clear after dismissing it using Firefox Quantum v68.0.1. Windows 10.

I found some smaller issues, too:

1. Some of the language strings in the help screen seem to be missing, see red frames in following screen shot.

I assume this is what wilsonge refers to with the first item in his comment above, so I think that's a known issue to be fixed later.

2. When clicking the "Accessibility Settings" link in the User Menu at the top right corner, nothing happens except that the browser console shows an error "Empty string passed to getElementById" for file skipTo.js, line 455, column 28. This does not happen with other links in backend.

3. The link of that "Accessibility Settings" item in the User Menu is just the top of the actual page, don't know if that is by purpose.

@Quy Do you mean that statistics dialog which is shown at the first login to the backend? Or any other alert? I want to try to reproduce that. With the statistics dialog I can't reproduce that, same firefox version as you have, in 64 bit.

Specifying an image for the custom admin menu menu items does not work (did not find a way to make it work).

Also UI is broken depending on screen size.

Nice

Not nice

Note: not speaking here of the remaining issue with tabs/accordion which is not fixed.

Specifying an image for the custom admin menu menu items does not work (did not find a way to make it work).

Are you sure it works without this template

Are you sure it works without this template

It does not either. But as other stuff has been fixed (we can now create a custom admin template although some aspects don't work yet), I was expecting some changes.

In any case, the important stuff here (for now) is UI is broken depending on screen size. which depends totally on the js/css of the template.

@Quy I can't reproduce the alert shadow issue with Firefox Quantum v68.0.1 64 bit on Windows 10. Could you check again with cache cleared and if still having that issue provide some detail about how to reproduce?

@infograf768 "UI is broken depending on screen size": Isn't that the case with current 4.0-dev, too?

PLEASE only report issues here that are specific to this template. IE if it doesn't work without this PR applied either then report it as its own issue

So at this point all items on @brianteeman 's summary list have been fixed with 3 exceptions

@wilsonge

The following still not addressed..

#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)
#25570 (review)

These are a review of the login scss. I havent checked the rest.

@richard67 All alerts. Probably duplicate of #21803, but visibly more prominent with this template.

@bembelimen If you merge my 4 PR's against your repo, updating from staging (or any other previous version) to 4.0-dev will work with the new template with MySQL and PostgreSQL. Otherwise it does not work on both DB's.

I've already updated my modified update container with my changes: https://test5.richard-fath.de/Joomla_4.0.0-alpha11-dev-Development-Update_Package_2019-08-10__backend-template.zip

@Quy Strange, can't reproduce that, neither on new install of the nightly build of the backend-template repository nor with an staging updated to 4.0-alpha11-dev with a modified update package. Do you have 32 or 64 bit Firefox?

64 bit. Tested with nightly and 4.0-dev branch. Duplicate issues #21803 #23425
Same issue in Google Chrome Version 76.0.3809.100 (Official Build) (64-bit)

@Quy Then it's a 4.0-dev issue, with or without the new template?

@richard67 Yes.

@infograf768 "UI is broken depending on screen size": Isn't that the case with current 4.0-dev, too?

Nope.

PLEASE only report issues here that are specific to this template. IE if it doesn't work without this PR applied either then report it as its own issue

It IS specific to this PR! Testing before posting is helpful.

This is what we get for the current template: we do NOT have this issue:

EDIT: Issue comes from css

.options-grid-form > div {
    grid-template-columns: 1fr 1fr 1fr;
}

When it should be

.options-grid-form > div {
    grid-template-columns: 1fr 1fr;
}

EDIT:
Solution is to add a class (here for itemadmin_component.xml, did not test with all menu items xml but looks similar for alias, heading, separator, url). As done for site menu items.

	<fields name="params" label="COM_MENUS_LINKTYPE_OPTIONS_LABEL">
		<fieldset name="menu-options"
			label="COM_MENUS_LINKTYPE_OPTIONS_LABEL"
			class="options-grid-form-half"
		>

Good to have the 'real' name requested when installing Joomla, but could this say 'display name' instead?

@Scrabble96 The "real name" to be entered at installation has nothing to do with the new template and so nothing to do with this PR. It was a change made in 4.0-dev with Pull Request (PR) #25774 and came to the backend template by merging in latest 4.0-dev changes. So if you like to change that, make a new issue for 4.0-dev branch. But if it shall be changed, it should be changed everyhwre. Up to now I don't remeber having seen the term "display name" anywhere in J4 for the user name, so using this only at installation would be inconsistent with J4 after installation.

Thank you everyone who was involved here. @ciar4n i'm working on your sass changes at the moment and will do a PR to fix them over the next day or so (unfortunately a bit swamped with real life work at the moment). I know there are some issues raised in here that still aren't fixed but I don't believe these issues to be blocking the merge at this time either so that we have the unified code base and more people can explore and contribute towards this template.

I'd also like to reiterate the below comment I made

We are aware that once this is merged more people will be testing it and new issues will be discovered. That doesn't mean it's buggy or poor quality - it's just an acknowledgement that this was and still is a huge task and it's not possible for a small group of people to test, discover and fix everything